First, the "real" end-end principle, as stated in the original classic Saltzer/Reed/Clark paper, "End-To-End Arguments in System Design", actually says something quite different from what most people seem to think it does. Its name is much taken in vain - sadly, because it makes an important point, one that ought not to be lost behind an alternative masquerading as the real thing.
(I often feel like one of the critic animals in "Animal Farm", where every
time someone says something unpalatable, the chorus pipes up with the
de-rationalizing refrain "four legs good, two legs bad" - except that in
the Internet community, it's either
"soft state good,
hard state bad",
or, as in this case, "end-end good, state-in-network bad".)
functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level. Examples discussed in the paper include .. duplicate message suppression .. and delivery acknowledgement.or:
The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible.Thus, it is clear that the end-end principle (as originally given) has nothing to say about the placement of state in the network - except insofar as that may be done in an attempt to avoid having state in the endpoints.
This principle has important consequences if we require applications to survive partial network failures. An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing). An immediate consequence of this is that datagrams are better than classical virtual circuits. The network's job is to transmit datagrams as efficiently and flexibly as possible. Everything else should be done at the fringes.The fate-sharing principle was first enunciated by Dave Clark in the classic "Design Philosophy of the DARPA Internet Protocols". He says:
state information which describes the on-going conversation must be protected. Specific examples of state information would be the number of packets transmitted, the number of packets acknowledged .. If the lower layers of the architecture lose this information, they will not be able to tell if data has been lost, and the application layer will have to cope with the loss of synchrony. .. In some network architectures, this state is stored in the intermediate packet switching nodes of the network. .. The alternative, which this architecture chose, is to take this information and gather it at the endpoint of the net, at the entity which is utilizing the service of the network. I call this approach to reliability "fate-sharing." The fate-sharing model suggests that it is acceptable to lose the state information associated with an entity if, at the same time, the entity itself is lost.It's clear that the "end-to-end protocol design" discussed in RFC-1958 is in fact referring to the fate-sharing concept discussed in the Clark paper, not the (possibly more general) principle of the original Salzter/Reed/Clark End-To-End paper.
(It's also worth nothing that although the referenced paper which describes
fate-sharing dates to 1995, the fate-sharing principle, with that exact name,
was understood and followed many years before. I recall it being explained
and discussed in a presentation that Dave Clark prepared for DARPA,
explaining the basic concepts behind TCP, sometime in the late 70's, when I
first started working at
the intermediate packet switching nodes, or gateways, must not have any essential state information about on-going connections. Instead, they are stateless packet switches, a class of network design sometimes called a "datagram" network.The state that the fate-sharing principle is concerned about is state which is critical to the end-end communication, such as information on what data has been fully acknowledged from the far end. It is that state that must be co-located with the application, so that "they all go together when they go".
The fate-sharing principle actually says nothing about state in the network,
where that state is related to the operation of the network itself (such as
routing tables - which are obviously necessary state) - although obviously
it's a somewhat related topic.
Moreover, that state is state such that, if it is not properly maintained, that will cause packets not to flow. In other words, it is also critical (in the sense of "it has to be right, or the communication doesn't work") state. RIP, OSPF, IS-IS, BGP - they all maintain state, and often include extremely complex and powerful mechanisms to ensure that that state is perfectly synchronized - because if it isn't synchronized perfectly, and up-to-date, things will go to hell in a handbasket.
RFC-1958 goes on to say:
To perform its services, the network maintains some state information: routes, QoS guarantees that it makes, session information where that is used in header compression, compression histories for data compression, and the like. This state must be self-healing; adaptive procedures or protocols must exist to derive and maintain that state, and change it when the topology or activity of the network changes. The volume of this state must be minimized, and the loss of the state must not result in more than a temporary denial of service given that connectivity exists. Manually configured state must be kept to an absolute minimum.all of which is sound - but does ignore the need for some communication between the network and the end-system about that state.
E.g. if a network component failure means that a previously guaranteed QoS
allocation can no longer be met, the network can't "fix that" on its own - it
has to inform the application, which is the only entity that knows whether it
can accept a lower rate of service, or must terminate - a perfect example of
the real end-end principle in action.