[e2e] where end-to-end ends
David P. Reed
dpreed at reed.com
Wed May 23 12:35:41 PDT 2001
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).
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
>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.
More information about the end2end-interest