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

[David P. Reed]

The answer to your confusion is pretty simple.  The end-to-end argument is 
about where to put functionality in a layered network architecture - it is 
not about how many network hops are involved in an application.  If you 
read our original paper, we are discussing whether certain functions should 
be placed "in the network layer" below the various applications that the 
network layer serves.

If there is a contradiction to be perceived in what I said, it arises from 
a  misreading of what the end-to-end argument is.

Now the end-to-end argument is often correctly applied to argue against 
certain "hop by hop" functions (like link-level security and link-level 
reliability functions, which are often suggested on the basis that they are 
"more efficient" than source-destination encryption and source-destination 
error correction).  But the idea that something that is done in a 
distributed fashion is not against the end-to-end argument, if the 
distribution does not place the function into the network layer itself.

I hope this helps.

At 12:23 PM 6/2/01 -0400, Manish Karir wrote:

>I think I find your mail quiet contradictory. The first part I would
>tend to agree with, except with one exception.  I would argue that the
>Akamai approach to caching is not caching in the "real sense".  The akamai
>approach seems to me to be closer to server load balancing.  The akamai
>systems does not cache data.  It simply provides a distributed server, for
>people to offload content to.  A cache would imply that the akamai servers
>only keep a copy of the data, but the akamai servers, actually "serve" the
>data.
>The last part of your email is what seems confusing to me. You say that
>"caching is an application level optimization that just includes more
>ends..."
>by this I take it you mean that a cache server is an end point and
>e2e priniciple hold for transfers betwn client-cache ???
>but if we were to follow this reasoning then we could say that
>what the e2e principle does not really refer to client-server data
>exchange, but to any segement of that exhange...where it might
>be that end points are the client and server, but does'nt have to be.
>In this scenario, again, we could say that proxies are e2e priniciple
>compliant, because each segment is e2e compliant..???Is that correct???
>
>manish karir
>
>
>On Sat, 2 Jun 2001, 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.
> >
> > 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).
> >
> > 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).
> >