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@ginger.lcs.mit.edu] > Sent: Wednesday, April 17, 2002 1:52 PM > To: irtf-rr@puck.nether.net > Cc: end2end-interest@postel.org; jnc@ginger.lcs.mit.edu > Subject: RE: mobility -> aggregation (TRAP?) > > > > From: "Dmitri Krioukov" <dima@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
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT