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

Manish Karir karir at wam.umd.edu
Sat Jun 2 09:23:58 PDT 2001


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




More information about the end2end-interest mailing list