Subject: WREC/CDNP/extproxy ... moving forward

From: Ian Cooper <[email-masked]>
Date: Tue, 10 Oct 2000 20:49:28 +0100

In order to try and move in some kind of positive direction I've compiled 
the following list of possible things to work on, as identified in emails 
and in the WREC known problems document.  Apologies if it's a bit rough 
around the edges, but the idea is to try and get some discussion going 
among us.

Having spoken to a few folks, Mark Nottingham and I are coming around to 
the idea that splitting some of the CDNP work into a separate group (as 
proposed) is probably a good thing.  However, we still think there are some 
things that WREC should be working on (the items identified for WREC below 
are those Mark and I believe we can make progress on and which need to be 
delivered in a reasonable timeframe).

I've tried to identify some of the issues I think CDNP might be interested 
in looking at, though I'm probably ignoring some other obvious 
things.  (This is really an attempt to ask "can you take these on?" while 
also working from Patrik's small list.)

There are also some other issues that are interesting and which a group may 
wish to visit down the road, or else a group might possibly form to address 
them.  If there are other bullets that folks think need adding, please do 
so.  Similarly, if you think I've got something in the wrong place please 
feel free to edit.

WREC
====
* Proxy/surrogate discovery protocol for user agents
   - initial intent is probably for "user agents" to mean browsers;
   - should also consider some aspects of wider proxy/surrogate discovery 
or registration that will probably be interesting to CDNP and extproxy 
(e.g. proxies/surrogates being able to discover other proxies or surrogates)
   - obviously of interest to the folks doing the extensible proxy work

* Cache coherence/invalidation protocol
   - including delta encoding and preloading within the administrative 
control of the data owner
   - will probably touch on expiry semantics in passing
   - will be of interest to the CDNP folks too

(Yes, that's it for now.)

I'm not going to suggest milestones at this point, but we feel that aiming 
to have these completed within a 12-14 month window shouldn't be too 
unreasonable.  (And we definitely want to try and keep things focused and 
achievable.)

CDNP
====
* Distribution of data from origin servers outside of the administrative 
control of the data owner

(I'd specifically exclude the scenario where the distribution occurs within 
a single administrative domain... do we really need to standardize that?)

* Routing request to closest site (service) with the requested data
   - should probably consider caching proxies in the model
   - (obviously has some aspects of competitive advantage as was discussed 
from the WREC KP draft in Pittsburgh)
   - definition of the "closest" site (see WREC KP draft on known failings 
of ICP in heterogeneous network)
   - may overlap with, or provide us with, (or show us that it's 
unnecessary to have) some replacement for ICP in the caching world

Billing (and more)
==================
There seems to be a case for billing/accounting to be covered in all three 
of WREC, CDNP and extensible proxies.  I believe that the extproxy folks 
have commented that this may be appropriate work for another group (AAA?), 
and it definitely seems that it's beyond any one of those being discussed here.

If we therefore open the scope to the wider issue of authentication and 
authorization I guess we can add

* Exchange format for log summaries (essentially some form of accounting 
records; this is the problem identified in the WREC known problems document)

* User session management

* Authentication models for multi-sited services/TLS interaction

(A pet peeve of mine is that there's an awfully large amount of non-private 
information that has to get sent via https and could be cached.  Can that 
issue be addressed, or is it simply a browser implementation issue?)

Remainder
=========
The remaining items I have on the list are:

* Outstanding HTTP header issues
   - "Vary header underspecified"
   - registration of new HTTP headers

* Various end-to-end issues and concerns (includes content negotiation)
     most likely something that needs to be considered for a world where 
surrogates and extproxies live in the network; a few folks are interested 
in this; may be a very short lived WG in its own right

* Some kind of documentation to cover those recurring items on "how to make 
servers and content cache friendly"
     not really an IETF WG matter; individual submission/W3C or elsewhere

* Re-visit the taxonomy
     something that WREC and/or CDNP will need to revisit in the future... 
perhaps the WREC and CDNP terminology sections need rolling into one?
   - definition of a surrogate ;-)

---

From: Keith Moore <[email-masked]>
Date: Tue, 10 Oct 2000 19:56:07 -0400

> control of the data owner

assuming I understand what you mean by the above, I don't think IETF
should be endorsing such practices at all.    I see two pieces:

1. how the content provider makes data available to consumers, and
how it makes the locations of those data known to consumers

2. how consumers find and access such data

the first is under control of the content-provider; the second
is under control over the consumer.

I see no legitimate role for a third party that isn't acting under
explicit instructions from one or the other of the first two
parties.   IMHO, *this* is what IETF should standardize.

> a single administrative domain... do we really need to standardize that?)

yes, because there is a need to have standardized interfaces between
content providers and content-distribution networks acting on
behalf of the content providers.    there is also a need for a standardized
and efficient interface between content users and content 
distribution networks - the stuff we are using now is quite crude.
 
> of ICP in heterogeneous network)

not sure how to define it better but "closest" (or any superlative) may 
be over-ambitious 

Keith

---

From: "Mark Day" <[email-masked]>
Date: Tue, 10 Oct 2000 22:52:45 -0400

> parties.   IMHO, *this* is what IETF should standardize.

The data owner (the content provider) is often not the owner of the
distribution network/system. That's all that I think Ian means by "outside
of the administrative control of the data owner."

Our discussions about CDN peering have pushed this separation between
content and distribution one step further, to the idea of distributing
content onto networks not directly contracting with the data owner, but
(say) acting as subcontractors, or in other similar arrangements.

I don't know if such arrangements would strike you as "explicit
instructions" from the content provider (indeed, part of the value is in
hiding the seams of such distribution-provider cooperation from the content
provider).  But I have trouble identifying the illegitimate part of such
arrangements.

I don't mean to be argumentative (yet ;-)), so if you do mean to say that
such subcontracting of content distribution is evil, then please help me out
by elaborating a little on why.

I think that your two-piece division (how content is advertised; how content
is found) is fine as far as it goes.  I'd claim that CDN peering deals with
refining each of those two parts to fill in the details of how they should
work in the presence of multiple administratively-distinct networks that
nevertheless choose to cooperate.

Feel free to explain to me that I'm missing your point.  I have a sense that
you're vigorously attacking as illegitimate something that I see as a
technically challenging but ethically sound goal, so I suspect there's some
sort of misunderstanding here.

--Mark

Mark Stuart Day
Senior Scientist
Cisco Systems
+1 (781) 663-8310
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Tue, 10 Oct 2000 22:52:11 -0400

I don't see much in your message with which I would disagree.

> distribution network/system.

right, and I see nothing wrong with that so long as the distribution
network is distributing the material with the consent of the content
provider, and according to whatever instructions to which they might
mutually agree.  

part of the point (which I'm struggling to articulate even to myself) 
is that the system as a whole needs to behave predictably and there
needs to be a clear division of responsibility between the various
parties that handle the data. otherwise, when something goes wrong,
(say, incorrect, altered, or stale data is delivered to the consumer)
there will be no clear direction as to which pieces are at fault
and who is responsible for fixing it.  (yes, I realize that such
problems often occur even in well-designed systems, but we should 
try to minimize them)

Keith

p.s. note that the content provider is not necessarily the owner of the
data in a legal sense, though in general one hopes that the content 
provider has permission to distribute the data.  still, there's a subtle
difference between roles that should be specified by the protocol
architecture and those that are specified by laws - the protocol
architecture should be concerned with reliable and predictable
operation (and hence, for instance, that the replicas of data 
that are obtained by querying the content provider are actually
those intended by the content provider) but the protocol should not 
concern itself with whether a content provider has the legal right 
to make that content available.

---

From: Ian Cooper <[email-masked]>
Date: Wed, 11 Oct 2000 15:18:34 +0100

>parties.   IMHO, *this* is what IETF should standardize.

Mark was right in his comments.  This was meant to mean distribution to 
servers where the data owner/content provider is not the owner of the 
systems to which the end-user connects in order to retrieve material (e.g. 
surrogates within a CDN).

>distribution networks - the stuff we are using now is quite crude.

Looks like I was misunderstood, since I meant that part to be where a 
content provider wanted to do distribution across systems that they owned 
rather than CDNs.  Is that something that we should be looking at?

>not sure how to define it better but "closest" (or any superlative) may

Yes, that was the sort of point I was trying to raise.  The KP draft gives 
an example where "close" (network RTT) may be worse when there's more 
bandwidth available between 2 points.

We need a succinct way to say "there, yes, that thing, that's in the 
currently optimal place to serve it".  I seem to recall some heated 
"discussion" over the use of the word "optimal" in Mark's presentation at 
WCW5 earlier this year.

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 Oct 2000 11:10:19 -0400

> rather than CDNs.  Is that something that we should be looking at?

from a protocol perspective, I don't think it matters whether the CDN
is owned by the content-provider or whether it is owned by a separate
party.  we still need to define the interaction between the two, so
that there are standard components.  then it's a business decision
on the content-provider's part as to whether to build the CDN itself
(and whether to do so out of standard components or to roll its own),
or pay someone else to do that function.

(note that accounting/billing support are useful even when 
the content and the CDN  are owned by the same party)

Keith