[e2e] RE: mobility -> aggregation (TRAP?)
dima at krioukov.net
Wed Apr 17 16:46:49 PDT 2002
Noel, I suspect you've misinterpreted my reply
to some extent since *I* agree with many of these
points. But not all.
In particular, the "fate-sharing" principle
(which I (erroneously?) thought was a part
of the end2end principle) calls for *minimizing
the amount* of state in the network (one of the
major reasons being to minimize signaling, etc.,
after a failure). Please explain how keeping
source- and/or connection-related information
in the state helps to achieve this goal.
However, another point would be that I don't
think that any principle should be static and
considered as the absolute truth forever.
In this sense, it is "good" :) that
"Rethinking the design of the Internet:
The end to end arguments vs. the brave new
world" is co-authored by the same person
who (co-)authored the papers you've mentioned
(which are available at the CiteSeer, BTW:
> -----Original Message-----
> From: J. Noel Chiappa [mailto:jnc at ginger.lcs.mit.edu]
> Sent: Wednesday, April 17, 2002 1:52 PM
> To: irtf-rr at puck.nether.net
> Cc: end2end-interest at postel.org; jnc at ginger.lcs.mit.edu
> Subject: RE: mobility -> aggregation (TRAP?)
> > From: "Dmitri Krioukov" <dima at krioukov.net>
> > I think I know Tsuchiya's works (Landmark, Pip) reasonably
> well but I
> > can see a big difference between Landmark/Nimrod on one
> side and TRAP on
> > the other side -- Antonov is a strong (the strongest?)
> proponent of the
> > e2e principle
> Sigh, this old canard again. (And since it involves the end-end
> principle, I'm
> going to CC this to the end-end-interest list - apologies in
> advance if this
> offends anyone.)
> I am utterly unable to see how any of Landmark/Pip/Nimrod in any way
> contravene *either* the original end-end principle, or a relative
> of it that
> some people misname through seeming lack of familiarity with the real one
> (which says something quite different), and also label "end-end".
> As far as the second one goes, yes, they have state in the network, state
> which if not properly maintained will cause packets not to flow -
> BUT SO DOES
> EVERY OTHER PACKET NETWORK DESIGN SINCE THE HOT-POTATO ALGORITHM DESIGN OF
> 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* *perfectly* synchronized and
> things *will* go to hell in a handbasket.
> To castigate a design because it has state in the network, to me,
> merely shows
> that the criticism is severely poorly thought through.
> The "real" end-end principle, as stated in the original Salzter/Clark/Reed
> paper (which is available here:
> for those who would like to refresh their memory of it) is,
> quoting from the
> 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.
> 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 none of the mentioned systems (which
> affect only the
> routing of packets, and do nothing to try and make their delivery
> reliable, or
> anything like that) have anything to do with the "end-end principle", as
> originally given.
> Many people seem to think of 'end-end' as an alternative name for
> a principle
> that is related to a principle called 'fate-sharing'; this
> confusion may have
> started with RFC-1958 (by Carpenter), which says:
> 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'qs
> 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 Clark in the classic
> "Design Philosophy of the DARPA Internet Protocols", which alas
> does not seem
> to be available online.
> However, the 'fate-sharing principle' does not say (in effect)
> "do not have
> state in the network", it says (in effect) "all state which is
> *critical* to
> the end-end communication, such as information on what data has been fully
> acknowledged from the far end, 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 -
> although obviously it's a closely related topic. 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.
> Anyway, even considering this "no critical end-end state in the network"
> variant, none of the things you alluded to violates that, either.
> In fact, I don't think that Landmark (in particular) does
> anything different
> with state in the network than all the classic Destination Vector systems
> (e.g. RIP). It's just a distributed computation which sets up
> routing tables,
> just like the rest of them. The only difference is that the abstraction
> boundaries are diffuse, and an objects' address is composed of
> the names of a
> series of 'landmarks', of increasing scope of visibility.
> > and his TRAP is much closer to the "pure IP". Keywords like
> > "source-based routing", "state in the core" (anything "flow-ish" or
> > "circuit-ish"), etc., are indicators of the absolute evil to him.
> I'll let Vadim get away with some of this hyperbole because he's
> really smart.
> (I 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
> the Internet
> version is either "soft state good, hard state bad", or "end-end good,
> state-in-network bad".)
> However, since all real network designs, *including the one bringing these
> bits to you*, have state in the network core (albeit not end-end state), a
> useful criticism of any design has to say something more than just "it has
> state in the core". It has to think about the cost and complexity of
> maintaining that state, what happens when something goes wrong,
> etc, etc, etc.
> BTW, TRAP (having read it) focusses mostly on the details of how
> to allocate
> addresses, and says almost nothing about routing. As such, it's
> more in the
> same class as Landmark, which is mostly an address allocation
> The actual selection of paths is not really described, but from
> the allusions
> to it (in section 2.10.2) it seems to be a classic Destination
> Vector system.
More information about the end2end-interest