[e2e] e2e principle..where??....
day at std.com
Sat Jun 2 15:17:04 PDT 2001
At 11:09 -0400 6/2/01, David P. Reed wrote:
>Just a thought. The end-to-end argument does not argue against
>designing an application to use caching as an optimization. Since
>caching of the Akamai sort (just to use the typical model in use
>these days) is NOT transparent to either end of the application (the
>server-side explicitly generates URLs that point to the cache, and
>the client fetches explicitly from the cache), this seems like a
>protocol where the lower networking layers (the "Net transport"
>layer) provides no caching functionality whatsoever. Thus, the
>Akamai approach is an end-to-end design - there was no need to
>modify the existing network protocols or spoof them to make it work.
This is more like the Initial Connection Protocol that was used with
NCP to get around the fact that sockets were half-duplex. A
connection to the well-known socket returned the socket where your
connection was supposed to operate. (ICP went away with TCP where the
src and dest sockets in the header provided sufficient resolution
that everyone could connect to the well-known socket.) But as Dave
says, this is totally consistent with the end-to-end principle in
that the application essentially tells the requestor to "go over
there" for the same thing.
>The "transparent cache" approach (pioneered by @Home) where the
>network itself spoofs HTTP and tries to second-guess what the user
>wants - that is not end-to-end, and creates huge secondary problems
>(since the server and client don't know that caching is going on,
>they may assume the client is getting up-to-date information,
>whereas the out-of-date cached information is being fed).
This is more like an OS paging model, where the OS tries to guess
what pages the program is going to need next. (Are they doing
working sets?!) But as you indicate, this doesn't have all of the
properties of page caching. A good question whether this violates
the e2e or is merely orthogonal to it.
>What the end-to-end argument does *not* say is that applications
>must be designed without optimizations that suit their needs - and
>caching at the application level is an optimization that just
>includes more "ends" in the application layer protocol (the cache
Frankly, any principle that says you can't do optimizations that
actually help won't last long.
More information about the end2end-interest