[e2e] where end-to-end ends

[David P. Reed]

Guys, I helped formulate the end-to-end argument's precise definition, and 
co-wrote the paper.  We didn't say anything about "buffered, stateful, 
asynchronous networks".  In fact Jerry, I, and Dave Clark said that the 
end-to-end arguments are a class of arguments that focus on function 
placement in any network context.  You can read the paper online if you 
need reminding ( http://www.reed.com/papers/endtoend.html ).

Lots of people seem to have redefined what we said to something they wished 
we said, often as a strawman to attack, for example:

the end-to-end argument is equivalent to TCP's design choices being the 
best for *all* applications (not true - I used the argument to justify the 
existence of UDP, for one contradictory example).

the end-to-end argument is for packet networks (also not true, it applies 
to function placement once virtual circuits exist, and can be used to argue 
that "telnet functionality" should not be embedded in TCP).

the end-to-end argument is for "best efforts" networks (also not true - the 
argument indicates where one should place the functions related to various 
quality of service goals).

the end-to-end argument says that the network should be dumb. (also not 
true, it says that applications-specialized intelligence should not be put 
in the net, but the net can be as smart as it wants about routing, 
compression, fault-tolerance, self-organization, and other attributes that 
are related to its transport function alone).  If you want to see what our 
views on "active networking" w.r.t. end-to-end arguments are, you can read 
our recent IEEE Network commentary.

But please read the darn paper, especially before trying to argue with one 
of the authors (I may not always apply the argument right, and there are 
other criteria that are important besides the end-to-end argument, but we 
should at least agree to common terms, and it's our term, having coined it).

- David

At 08:14 AM 5/23/01 -0400, Micah Beck wrote:
> > But I'm afraid that
> > gross delay, while it might call for an alternative to TCP, does not
> > invalidate the "end-to-end argument".
>
>Gross delay turns data transmission into a data buffer, and makes not only
>TCP but any kind of syncrhonous end-to-end signaling impossible.  Thus the
>end-to-end argument has to be applied to buffered, stateful, asynchronous
>networks.  This is not the usual context in which the end-to-end argument is
>applied, and is considered by many to be antithetical to the notion of
>end-to-end communication.
>
>For example, if my mail server holds my mail and I manage it using IMAP, is
>the client-to-client delivery of mail considered to be end-to-end?  The mail
>server, considered as part of the network, is acting as a buffer under the
>control of the end-point.  However, it is subject to failure modes that a
>stateless netework would not see.
>
>/micah