On Tue, Sep 19, 2000 at 05:11:31PM -0700, Joe Touch wrote:
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.
Thanks; that makes it somewhat clearer to me. Although I've read the
original paper, there's been a lot of bandying the term about, somewhat
blurring its meaning in usage.
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.
Many have been explaining the Evils of interceptions proxies in this way,
which is why I started from this angle.
That having been said, I'm more interested in the effects below than these.
Interception problems seem to have enough people concerned about them
(although we still need to *do* something about them). In this respect, it
was a poorly chosen subject line, but my perception was that these points
were previously articulated as end-to-end problems.
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.
Of course; I wasn't suggesting that E2E prohibited application level
gateways, etc., but that if current work goes forward without considering
the social and legal effects of what they do, there will be trouble.
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)
It's a surrogate which implements a cache. You've made my point well - Web
caching isn't a good economic model, and even risked legal problems at one
point, because it isn't done on behalf of the content provider. Rather, it
is done by the access provider, who isn't concerned with cache correctness,
etc. nearly as much as the content provider.
Value-added services are a good thing, but there needs to be a framework to
address these issues. While some content providers may not care that their
content is transcoded by a proxy in front of the user, others may.
For example, if a legal document is changed in any way (translated,
summarized, etc.) it becomes invalid.
The most oft-cited example that makes me shudder is the dynamic
insertion/replacement of ads by the access provider, without permission of
the content provider. While I'm sure there's a market for this out there, it
brings up significant issues.
I'm not sure that IETF is the best place to address this; W3C seems (to
me) to have a more active view on social/legal issues. However, this is
where these capabilities are being talked about, so it seemed a good
starting point.
--
Mark Nottingham
http://www.mnot.net/