"Soft" and "Hard" State

This note was prompted by reading "Architectural Considerations for Mobile Mesh Networking", (by S. Corson, S. Batsell, J. Macker - draft-rfced-info-corson-00.txt). As I read it, I realized that the terms "hard" and "soft" state were perhaps not as clearly defined as I'd be happy with.

In fact, the lack of clear definitions seemed to be causing communication problems, as people used the terms to refer to different internal functional models, with the obvious result! I had a number of conversations with people about this, and I thought I'd try and pass along the results, in the hope that they might prove useful. I think the conclusion is fairly important to clear communication when using these terms and concepts.

The document startled me by seeming to use "soft" and "hard" to refer in part to the method by which state was maintained (i.e. probabilistically versus an explicitly reliable mechanism), and in part to refer to the duration of the state, viz:

"hard-state" protocols, meaning that in the absence of some event to trigger a protocol response, the protocol's state will remain unchanged or "hard" for an unbounded time period.

(The document did not define "soft state" explicity, or indicate which of the documents which does define that term it was using for the definition.)

This all confused me, as I had always though "soft state" referred to state that could be discarded by the routers as a local decision (e.g. because it was out of room), and the user would continue to receive service, albeit perhaps at a degraded level. This always seemed to me the most important attribute of "soft state", since to me how one maintains state is a more mechanistic question, whereas the question of whether the state is needed for operation (at whatever level of quality) seemed more fundamental.

So, I went to look at the relevant papers, to see what they said. The original paper which defined the term ("Design Philosophy of the Internet Protocols", by Clark), said:

"the state information associated with the flow could be lost ... without permanent disruption of the service features being used."

This did not clarify it for me, so I looked at RFC-1633 ("Integrated Services in the Internet Architecture: an Overview"), which defined them as:

the "hard state" (HS) approach .. and the "soft state" (SS) approach ... Under the HS approach, this state is created and deleted in a fully deterministic manner by cooperation among the routers. Once a host requests a session, the "network" takes responsibility for creating and later destroying the necessary state. ... Since management of HS session state is completely deterministic, the HS setup protocol must be reliable, with acknowledgments and retransmissions. ... RSVP takes the SS approach, which regards the reservation state as cached information that is installed and periodically refreshed by the end hosts. Unused state is timed out by the routers.

This left me wondering where my impression that "soft state" meant state that could be discarded without total loss of service came from.

I then engaged in some side discussions with people working in this area (one of whom did agree explicitly with my characterization that "soft state" was "state that could be discarded without any warning, and the network could continue to operate").

(These discussion surfaced a number of terminology issues not necessarily related to this point; in particular, to some people, "critical state" refers to the fate-sharing principle saying that all the state about the communication with the other entity(ies) which the application absolutely has tohave, in order to function correctly, must be co-located with the application. This conflicted with another definition of "critical state", used below.)

In any event, after a certain amount of discussion, I came up with the following framework for discussing state.

There seem to be a number of somewhat separate axes (there are obviously some connections between some of them, as you will see) along which one can characterize the state in the network. To list them:

How the state is maintained; i.e. whether a probabilistic mechanism is used, or rather a more definite mechanism such as an explicit acknowledgement.
How consistent the state has to be among the various network nodes which have that state; this is related to the previous point, of course, since if the state can be less consistent, less powerful mechanisms can be used.
Which entity has the responsibility of maintaining that state; the network nodes the end user, or some combination thereof.
Which entity has the authority and responsibility to discard that state when it is no longer useful or needed; the network nodes, or the end user (and again, this is related to the question above).
Whether or not the state is critical to continued handling of user traffic; i.e. whether or not the user will continue to receive service, albeit perhaps at a degraded level, if the state is lost.

There may be more, but those are the ones that seem to have come up so far.

In any event, the term "soft state" seems to refer to a *particular* collection of choices along all these axes, and it is thus incorrect to try and characterize "soft state" along just one of them. As best I can gather, "soft state" refers to a *system* of choices in which:

State is maintained probabilistically;
State is not necessarily consistent;
The user bears the entire responsibility of maintaining the state;
The network bears the entire responsibility of discarding the state;
Existence of the state may or may not be critical to receiving service, that is likely to be a local administrative decision.

(If I have made any errors here, I hope some "soft-state" aficionado will correct me.)

I'm not sure which of this set is "more important" in terms of being a key underlying philosophical point of "soft state", and I'm not sure it really matter anyway. (I'd love to hear from some of the "soft state" aficionados any views they might have on which of these is more important to "soft state"; I wouldn't at all be suprised to hear that different people come up with different answers!) What does really matter is to understand that the term "soft state" seems to refer to a system with a *collection* of answers to basically disparate questions regarding state.

More importantly, it is *critical* for clear communication that people realize that there are *multiple* potential systems which differ from this "soft state" model. I.e. there is no such thing, really, as "hard state", since two systems, neither of which is "soft state", may in fact be quite different from each other.

For instance, I can think of one system (names withheld in the interests of preventing prejudice on the part of the readers) in which:

State is maintained explicitly;
State is necessarily consistent globally;
The network bears the responsibility of maintaining the state (if the network has a problem, the user's only option is to retry from the beginning);
The user bears the bulk of the responsibility of discarding the state (although the network must protect itself from broken users);
Existence of the state is critical to receiving service.

whereas, for another:

State is maintained via a mixture of explicit and probabilistic means;
State is consistent in less global ways;
The user and network share the responsibility of maintaining the state, but with the ultimate burden falling on the user (much as the ultimate burden of retransmisison falls on TCP, although local unreliable links may do retransmission locally);
The network bears the responsibility of discarding the state, although the user will usually assist;
Existence of the state is critical to receiving service.

These are clearly very different systems, but to call them both "hard state" is clearly confusing. Even more amusing, the latter system was described by one person I talked to as "close to soft-state" (or words to that effect), even though I'm not at all sure that description is warranted (as seen from the enumeration above).

So, the bottom line is that "soft state" is not the name of a single characteristic, but a *package* of characteristics, and there is no *single* opposite to such a package, but many perhaps fundamentally quite different designs, all of which are "not-soft-state".

Back to JNC's home page