[e2e] RE: mobility -> aggregation (TRAP?)

[Dmitri Krioukov]

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:
http://citeseer.nj.nec.com/83743.html
http://citeseer.nj.nec.com/clark88design.html).
--
dima.



> -----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
> BARAN.
>
> 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
> up-to-date,
> 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:
>
>     http://www.reed.com/Papers/EndtoEnd.html
>
> for those who would like to refresh their memory of it) is,
> quoting from the
> paper:
>
>   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 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
> architecture.
> 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.
>
>
> 	Noel