[e2e] e2e principle..where??....

[John Day]

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 
>servers).

Frankly, any principle that says you can't do optimizations that 
actually help won't last long.

Take care,
John