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:
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:
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:
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