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