Mark Nottingham wrote:
>
> There's been a lot of talk in various places about end-to-end
> problems, and their relation to intermediates (e.g., HTTP caching
> proxies, surrogates, etc.).
>
> Things have gotten somewhat religious. Rather than go down that road,
> I'd like to examine the issues and separate them into distinct
> problems.
>
> * Network Layer
>
> The end-to-end principle applies to *network* layer functions; it is
> not meant to preclude an application-level gateway.
The E2E principle applies to all services implemented at the endpoints,
not just transport. This includes reliable transfer, security, etc.
It does not preclude anything, per se. It merely says that
E2E services (e.g., reliable transport, app security, etc.)
cannot be composed _merely_ out of equivalent hop-by-hop services.
> I _think_ that most everyone will agree that functions that break
> end-to-end transparency at the network layer cause problems. In other
> words,
>
> Interception Proxies are Evil.
The problem with interception proxies isn't breakage of E2E;
it's breakage of standard protocols. See
http://www.isi.edu/touch/pubs/hazards-outline.txt for further info.
> Proxies and surrogates can do a number of things to requests and
> responses as they flow through. I've been roughly classifying them
> as;
>
> - access control (e.g., blocking, filtering)
> - request modification (URI rewriting)
> - response modification (transcoding)
Yes - and these are actually discussed in the original E2E paper.
This is basically value-added services. There are plenty of them.
The E2E principle doesn't prohibit HBH services; it just
says HBH alone do not compose to yield E2E. It specifically
allows (if not encourages) HBH for performance enhancement,
with the caveat that it is also possible to degrade performance
if not done carefully.
> It's interesting that Web caching seems to be losing ground to CDNs
> so rapidly; to me, this illustrates the point perfectly. Web caching
> was always performed in the interest of the access provider, not the
> content provider (or arguably even the user). As a result, content
> providers don't trust Web caches. What's it going to be like out
> there when access providers can slip a transcoding, rewriting module
> into a proxy on the fly?
CDNs use web caches, don't they? or at least what do you call the
rented Akamai server? I call it a cache...
(CDN is just an economic model for charging the provider for space
on the cache)
Joe
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:29 MST