[e2e] where end-to-end ends

[Micah Beck]

> 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