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

[J. Noel Chiappa]

    > 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