Subject: RE: Candidate re-charter/new WG

From: Gary Tomlinson <[email-masked]>
Date: Sun, 5 Nov 2000 21:57:41 -0800

I don't see mirrors being something CDNP is likely to work on.  CDNP is
focused on the peering (interconnection) of CDNs, while surrogates
(including mirrors in my definition) are network elements within CDNs
themselves.  Currently CDNP doesn't address intra CDN issues, and sees
surrogates only in their abstract form.  

I see mirrors as possible work within WEBI.

>-----Original Message-----
>From: Patrik Fältström [mailto:[email-masked]]
>Sent: Sunday, November 05, 2000 12:55 PM
>To: Wojtek Sylwestrzak
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: Re: Candidate re-charter/new WG
>
>
>At 20.26 +0100 00-11-05, Wojtek Sylwestrzak wrote:
>>Are you saying that mirroring fits both into CDNP and WEBI
>>within the proposed plan ?
>>We'd not like to have it lost somewhere in the middle.
>
>It is up to people on this mailing list to decide that. We run by
consensus...
>
>I just wanted people to see what is currently written about all three 
>proposals, in a consistent way, so I was sure that you know what is 
>behind the three proposed charters.
>
>    paf

Gary

---

From: <[email-masked]>
Date: Mon, 6 Nov 2000 09:01:17 -0800 (PST)

> focused on the peering (interconnection) of CDNs, 

I am a little uneasy with our use of the term "peering", because I
think we run the risk of implying something about settlements we don't
mean.  There is a big chunk of the BGP crowd that still thinks of
peering as meaning "traffic exchange without settlement".  I think we
want to talk about CDN traffic exchange and interworking, but I don't
think we want to imply "without settlement".

I don't want to start a big "rethink the name" effort, but I think it
may be something that we should cover early in the BOF, just to
eliminate any peering vs. transit discussions.

			regards,
				Ted

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 6 Nov 2000 10:25:13 -0800

>surrogates only in their abstract form.

I see your point.

>I see mirrors as possible work within WEBI.

And what you _really_ talk about are not (only) mirrors, but "network 
elements inside a CDN"? [Part from the specific functionality which 
the extensible proxy group will talk about]

    paf

---

From: "Phil Rzewski" <[email-masked]>
Date: Thu, 09 Nov 2000 12:01:44 -0800

As long as we're on the topic, I have similar concerns about the 
interchangeable use of the terms "CDN Peering" and "Content Peering", which 
seem to imply they're equivalent.

It therefore comes down to the use of the term "CDN". There's once again a 
"crowd" that has been using the term in a particular way, in this case the 
crowd being industry. Outside of the IETF/draft communities, there's 
reasonably well-defined differences between what's been called CDNs, 
Hosters, and Access Providers. Now, doing a meticulous reading of 
[draft-day-cdnp-model-02], I get the impression that perhaps there's an 
attempt to categorize Access Provider cache deployments as being a 
degenerate form of CDN, but I think this might be a mistake because it 
would create a disconnect between industry terminology (which was 
established first) and standards terminology.

For example, say a cable modem provider (CMP) puts caching proxies in each 
of several cable head ends. CMP informs their subscribers in each area of 
their local cache, and all subscribers explicitly configure their browsers. 
The CMP then creates a peering relationship with several CDNs to have 
content distributed into these caching proxies, and to provide logging 
information to those CDNs in return. This means there is distribution and 
accounting happening between the CMP and the peer CDNs. Therefore, the 
caching proxies take on a partial role as a "surrogates". So far, CMP's 
cache deployment has some traits of a CDN. However, there is "null" 
redirection (the cache in a subscriber's head end is defined as "good" for 
any content request).  Also, the CMP is not operating a "relatively complex 
system encompassing multiple points of presence around the world" 
[draft-day-cdnp-model-02]. Each cable head end is an isolated and 
tightly-coupled relationship between the subscribers in that area and the 
cache.

Anyway, without splitting hairs any further, I'd like to offer the thought 
that "Content Peering" as a general concept could safely be defined in 
terms of things like direction/distribution/accounting between entities 
(need a term... "Content Peering Entities"?). Then "CDN Peering" would be a 
specific type of Content Peering. That would allow for other types of 
Content Peering, such as that between an Access Provider and a CDN, as 
shown above.

--
Phil

--
Phil Rzewski - Senior Architect - Inktomi Corporation
650-653-2487 (office) - 650-303-3790 (cell) - 650-653-1848 (fax)

---

From: Fred Douglis <[email-masked]>
Date: Thu, 09 Nov 2000 15:08:26 -0500

Phil,

You make a good point: "CDN Peering" may be too specific to cover the scenario 
you've described, unless one is generous with the definition of a CDN.

However, I think "Content Peering" is a poor term, because we're not peering 
"content", we're peering entities that deliver content.  (This is similar to 
the forwarding-versus-routing debate that has hit the cdn mailing list today). 

I'm not sure I have a third suggestion that I like more than these two, just 
that I think "Content Peering" is the wrong direction to take this.  For now I 
would be inclined to include your scenario under the CDN framework.

Fred

---

From: Dan Li <[email-masked]>
Date: Thu, 09 Nov 2000 12:29:37 -0700

>their local cache, and all subscribers explicitly configure their 
>browsers. The CMP then creates a peering relationship with several CDNs to 
>have content distributed into these caching proxies, and to provide 
>logging information to those CDNs in return. This means there is 
>distribution and accounting happening between the CMP and the peer CDNs. 
>Therefore, the caching proxies take on a partial role as a "surrogates". 
>So far, CMP's cache deployment has some traits of a CDN. However, there is 
>"null" redirection (the cache in a subscriber's head end is defined as 
>"good" for any content request).  Also, the CMP is not operating a 
>"relatively complex system encompassing multiple points of presence around 
>the world" [draft-day-cdnp-model-02]. Each cable head end is an isolated 
>and tightly-coupled relationship between the subscribers in that area and 
>the cache.

This is the "vertical peering" scenario, meaning a set of caches in one 
administrative domain without full-fledged CDN functionality can 
participate as leaves in a full-fludged CDN of another administrative 
domain. Technically, the protocol for vertical peering may be similar in 
many aspects to that used inside of a CDN. E.g., content preloading, 
invalidation, and accounting.

Dan

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 9 Nov 2000 19:01:32 -0800

Stepping back a little bit, it might be useful to explore the relationship
between "content" (a term that has recently been used a lot, but is poorly
defined) to "resource", as used by the W3C (e.g., URI, etc.).

"Content" might be defined as the bits that are shoved around on the wire;
"Resource" is the service, and describes a higher-level concept. Anything
with a URI is a resource.

See http://www.w3.org/Architecture/Terms.html

Also, Jeff Mogul's discussion of resource/entity/variant/instance in section
three of
  http://www.ietf.org/internet-drafts/draft-mogul-http-delta-07.txt
might be relevant as well.

I haven't thought deeply about this, and I'm not suggesting that we call
them "Resource Distribution Networks" (yet!), but the bandying about of
'content' without a solid definition has disturbed me for a while.

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Nov 2000 23:35:00 -0500

> 'content' without a solid definition has disturbed me for a while.

I tend to think in terms of distributed systems that implement a service
which might or might not be available at multiple locations on the network.
The service implements one or more named resources each of which whose 
function might or might not be to provide (static or dynamic) content.

For this and other reasons it's useful to separate the problem of how
one maps from a resource name to a location on the network, from the
problem of how one actually makes the service available at multiple
locations with a reasonable degree of consistency (for that service).

If the service more-or-less passively provides content, this is a very 
different problem than if the service absorbs content, or if it involves 
substantial interaction.  But a passive content replication service
can still be a useful substrate in implementing a more dynamic service -
provided the services are layered correctly.

(we should avoid thinking of services as inhernetly being the sources
of content...they can as easily be sinks)

Keith

---

From: "Mark Day" <[email-masked]>
Date: Fri, 10 Nov 2000 05:29:03 -0500

> seem to imply they're equivalent.

I think we started out with "content peering" and subsequently decided the
"content" part was technically inaccurate, so we changed to talking about
"CDN peering".

I think we've recently decided in design team discussions that the "peering"
part is also technically inaccurate, so we might be better off calling it
"CDN interoperation" or "content distribution internetworking."  But the
CDNP acronym has become a handy shorthand for people, so it didn't seem
vital to do another name change right away.

Whatever we call it, I'd like to get the definitions and names right so that
you feel comfortable that your scenario is included within what we're
discussing in CDNP. You're absolutely right that your scenario is not
between two CDNs, but I think that it's an example of what we'd like to be
covered.  It still has two distinct but cooperating administrative domains,
and it still has the issues of how to distribute, cache, and serve content
in the context of that cooperation across different admin domains.

--Mark

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