Subject: End to End thoughts [long]

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Sep 2000 20:14:08 -0700

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.

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.

While it's nice to think that we can convince the world of this, it's
more realistic to find out why people use them, and give them a
better alternative.

To my knowledge, most people use them because they need an easy way
to assure that Web traffic (or at least port 80) goes through a
proxy. While browser have proxy auto-configuration, it hasn't changed
in quite a few years, there's no standard to implement, and it relies
on JavaScript.

WPAD was a good start; unfortunately, it never really went to far
beyond Microsoft. Additionally, a more sensible, standard format for
the configuration file would help. Over all of this, we need
participation from the browser vendors, or we won't get anywhere.

* Application Layer

All of this being said, HTTP intermediates *do* raise issues at the
application layer, which aren't end-to-end problems, but do get
confused with them, as the causes are similar.

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)

These operations are often performed in the interest of one of
different parties:
  
- content provider
- access provider
- user

There have been numerous papers and discussions about the interesting
things that can be done by intermediates. However, I don't think
there's enough attention being paid to the problems that enabling
these functions on intermediates can cause.

* HTTP

The HTTP makes a primary assumption of semantic transparency - that
an entity body will not be changed 'in flight' - that, discounting
transfer-encodings and so forth, what the server sends in the
response is what the client gets.

Jeff Mogul brought up issues with entity identity, as expressed in
the ETag, in Lisbon. There was also general concern (it may have been
Jeff in particular, my memory isn't that good) that an operation
performed in one portion of the network may not be performed in
another, causing unpredicatable behaviours.

There are lots of other little examples here that should be covered,
but I'll leave it for now.

* URI

One of the premises of URIs is that they refer to a specific,
identifyable resource, and that the authority for that resource has
control over it.

Many applications have dependencies on this. PICS, Robots Exclusion,
P3P, and other kinds of metadata systems break, sometimes
disasterously, when intermediates change the semantics and/or payload
of a message. The privacy implications are especially of concern.

Overall, content providers have a reasonable expectation that the
object which they deliver will be the one that the user gets, unless
the user doesn't want it.

These effects are largely social and legal; however, they're enabled
by the technology that's being pushed out there. We need to reconcile
the capabilities of the products and frameworks that we're building
with the expectations that have been set by our base protocols.

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?

One person who I've talked about this with pointed out the issues we
had a while back in caches vs. copyright, legally. There's much more
direct potential for problems here.

-- 
Mark Nottingham
http://www.mnot.net/

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Sep 2000 17:11:31 -0700

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

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

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

> there when access providers can slip a transcoding, rewriting module

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Sep 2000 17:41:26 -0700

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

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

> with the caveat that it is also possible to degrade performance

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.

> (CDN is just an economic model for charging the provider for space

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/

---

From: Jean-Sylvestre Gakwaya <[email-masked]>
Date: Wed, 20 Sep 2000 12:07:33 +0200

Hello all,

I am a newbie in caching stuff :O) I have a very simplicist question :OS
What is the relationship between replication and caching? I mean that to
elaborate a caching mesh, or when a document is stale, problem of replication
comes ... so, is there any protocol about interaction between both kind of
protocols: caching and replication?

Thanks in advance,

Jean-Sylvestre Gakwaya, Alcatel employee

---

From: Alexei Novikov <[email-masked]>
Date: Wed, 20 Sep 2000 14:48:50 +0400

> protocols: caching and replication?

Actually you can integrate replica (WWW or FTP mirror) in the caching
mesh. It can be done quite easily with writing:
1) ICP daemon that will provide HITs or MISSes based on the knowledge of
the replicated content.
2) Tool to create cachedigest file (for better scalability of the
communications with the cachedigest enabled caches)
3) Module for the web server that will respond to the proxy requests
with internal redirects to the replicated content.

You can do this using Martin Hamilton's Perl modules WebCache:ICP and
WebCache:Digest and <100 lines perl script for the Apache Web server.  

The good thing is that one can create such replicas with the
authorization of the content provider (and under supervision), the bad
is that ICP is poorly scalable.

		Alexei.

---

From: "Micah Beck" <[email-masked]>
Date: Wed, 20 Sep 2000 07:23:56 -0400

Terminology in this context:

replication = making a copy of the source object
caching = capturing and replaying the server response

Both have the effect of creating a new point of service (surrogate).
/micah

----- Original Message -----
From: "Alexei Novikov" <[email-masked]>
To: "Jean-Sylvestre Gakwaya" <[email-masked]>; "WREC
Working Group" <[email-masked]>
Sent: Wednesday, September 20, 2000 6:48 AM
Subject: Re: question about caching and replication

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 Sep 2000 09:50:54 -0700

> were previously articulated as end-to-end problems.

There certainly is room for work here.

> the social and legal effects of what they do, there will be trouble.

The IETF, far as I can tell, doesn't consider these issues, unless:

	1. there are technical solutions somewhere underlying
	   the social and/or legal

	AND

 	2. the legal issues constrain technical solutions
		i.e., solutions which are obviously not viable
		from the legal aspect are probably not worth 
		spending time on technically

> It's a surrogate which implements a cache. 

That's marketing doublespeak. It's a cache.

> You've made my point well - Web

The primary problems with caching, in that sense, are:

	1. content providers do not _want_ to provide expiration dates
		these dates must be determined in advance, and limit
		when changes will propagate.
		the CP's would like to 'recall' old items; this 
		doesn't work with our current caching model, regardless
		of who runs the cache.

		the reason the CDNs are useful is that the CP's 
		can push updated info out to the caches, in that sense

	2. authentication is lacking

		CP's could sign their pages (e.g., PGP sign)
		again, there is disincentive, because it
		would inhibit user access (slow it down, 
		stall it while waiting for key retrieval, etc)

There is certainly a model for client-directed caching; several
have worked just fine. Local premesis caching works if the 
organization is large (e.g., a school, a company, or a large ISP).
Egress/ingress caching works on national scales, esp. where
bandwidth is limited (e.g., Australia).

The model is the same as TV and radio. People can decide what
they want to see (e.g., PBS, request radio shows), but there
is more money to be made by being advertiser-driven. E.g., I
doubt people _want_ to watch infomercials all day long on the
weekend, but there's money there. But you can buy pay-per-view 
or HBO and not have infomercials. 

People want to direct their cost (free); advertisers
want to direct the content (and will pay). 

(but I digress - this may be an interesting coffeehouse
chat at an upcoming IETF, though).

> brings up significant issues.

Happens with local TV too. Without monitoring, it happens.

> where these capabilities are being talked about, so it seemed a good

These issues are addressed in the open court of public opinion,
or in classes in business schools :-)

Joe

---

From: Dan Li <[email-masked]>
Date: Wed, 20 Sep 2000 10:00:55 -0700

>caching = capturing and replaying the server response

Moreover, replication implies object consistency, while caching offers no 
guarantee on freshness. So replication is inherently costlier/harder on the 
Internet, while on the other hand caching is increasingly unacceptable as 
the world embraces dynamic content.  What the Internet needs is something 
in between, that offers guaranteed "delta consistency" and works in a CDN 
environment. We hope wrec will take it up as an initiative. Here is some 
work-in-progress:

Abstract

Cache consistency is a major impediment to scalable content delivery. This 
document describes the Web Cache Invalidation Protocol (WCIP) which uses 
invalidations and updates to keep changing objects up to date in web 
caches. Moreover, it allows automatic one-to-may relay and many-to-one 
aggregation in a CDN (content delivery network) environment.

WCIP is an extension to HTTP. It runs between the invalidation server, the 
participating web caches, and channel relay points (if any). An 
invalidation server may maintain one or more invalidation channels, each of 
which cover a class of related objects. E.g., the CNNfn channel may contain 
web articles of the day's top financial news and stock quotes. Web caches 
subscribe to channel(s) they are interested in, while the invalidation 
server(s) send out invalidations and/or up-to-date objects to the channel(s).

WCIP employs heartbeats to guarantee the freshness of the cached objects 
even under network or server failure. Moreover, WCIP can set up channel 
relay points via transparent caching, a cache hierarchy, or a CDN. A 
channel relay point performs application-layer multicast, i.e., channel 
relay (one-to-many) or channel aggregation (many-to-one).

Thanks!
Dan

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Sep 2000 13:34:03 -0700

> 		spending time on technically

IMHO both conditions may be met; since there is a group actively discussing 
a framework to enable these functions, and there clearly are legal issues,
even if the extent of those issues are unclear.

I believe that there can be technical solutions to these problems, as it
seems that there is other work in the IETF about trust models, etc.

> That's marketing doublespeak. It's a cache.

Err, no, it's the terminology defined in the WREC Taxonomy. There can be
significant differences in the cache implemented by a proxy and that
implemented by a surrogate.

> bandwidth is limited (e.g., Australia).

There is a model, yes, but I'd debate that it's worked "just fine".

Cheers,

-- 
Mark Nottingham
http://www.mnot.net/

---

From: Patrick McManus <[email-masked]>
Date: Thu, 21 Sep 2000 19:39:16 -0400

[Mark Nottingham: Mon, Sep 18, 2000 at 08:14:08PM -0700]

> providers don't trust Web caches.

I think your conclusion doesn't go far enough. I completely agree that
caching is moving from a information consumer to information provider
driven model, but I think this is because of both a lack of trust on
the part of the information provider (as you assert) and a desire to
see more thorough deployments. Information consumers, in many
situations, didn't have sufficient motivation to deploy the
infrastructure that the providers do and this limited the breadth of
installations.  

CDN as an extension of hosting has really come, and I suspect will be
with us for a while.. it makes interesting economic models available
as choices.. (can I go with a bargain basement origin hosting
facility if I have a decent CDN? Probably depends on your content..)

-P