Re: Distribution CPG Protocol

[Dan Li <lidan@cisco.com>]

At 10:14 AM 1/15/01 -0500, Stephen Thomas wrote:

>This is an interesting perspective that is quite different from the one 
>I've been stuck on. I can't completely connect all the dots, but I'm 
>willing to explore it a bit.
>
>I would characterize the main difference between Dan's perspective and my 
>own as one of peer-to-peer vs. client/server. My view of the CDN peering 
>problem was very definitely a client/server one. One CDN has surrogates 
>(it's the "server"), and another CDN (or the content provider itself) has 
>content (it's the "client"). In that view, it cannot be "the pair that 
>gets advertised" since only the 'server' knows its surrogates and only the 
>'client' knows the content.

This peer-to-peer view largely stems from the analogy to BGP, except 
prefixes are replaced by content sets. Almost everything else stay the same.

>Now let me see if I can context-switch to a peer-to-peer perspective and 
>ask intelligent questions.
>
>At 05:48 PM 2001-01-12 -0800, Dan Li wrote:
>>At 04:33 PM 1/12/01 -0800, Tomlinson, Gary wrote:
>> >The fundamentals of advertising surrogates vs advertising content or 
>> both is
>> >clouding my thought processes at the moment.
>>
>>It's both. Take domain name as a simplified representation for content 
>>(URL is more elaborate but you see names like "images.foo.com" that 
>>encode a class of content into a name). Then, content routing is the task 
>>of mapping a name to a location, similar to routing a IP to a location. 
>>Then, a surrogate is mere a location for a *set* of names it supports.
>>
>>So a route advertisement would have these two parts:
>
>So, what is a "route advertisement"? Is it a content provider advertising 
>its content? Or a CDN advertising content that it is distributing? I kind 
>think the latter, but it doesn't hurt to check. If that is the case, I 
>have a couple of questions:
>1) This assumes that the content has already been distributed, right? I 
>think that the issue I was dealing with was primarily how to get the 
>content distributed in the first place? I guess, though, that a content 
>provider with content on origin servers is a degenerate case.
>
>2) This approach seems to imply that CDNs exchange content with each 
>other. But, if a new CDN wants to acquire content to distribute, wouldn't 
>it just grab the content from the origin servers? It might learn about the 
>content from another CDN, but it sure would be more efficient to get the 
>content directly from the origin. (I can think of security/business 
>associations that might, at first, create some obstacles, but I think 
>those are actually fairly easy to solve.)

Yes, A is advertising that it hosts content set X. So if another surrogate 
which doesn't yet have X but wants to. It will be able to go get it from A, 
if A is the shortest route. A could well be the original site if the 
original site wins according to the metrics.

>>1. "route to content set X is via next hop M to content server A with 
>>metrics K", where A is chosen (based on metrics K) among other possible 
>>destinations B, C, D, which all advertise support for the same set X).
>
>Okay, what is the difference between M and A? Which one is the surrogate? 
>I think A is the surrogate, but then I don't know what M represents.

Yah, I probably shouldn't have mentioned M. M is one node on the BGP mesh 
but I guess we may not need it in the content world.

>Do you think the metrics K are an intrinsic property of the surrogate 
>only, or are they a property of both the surrogate and the particular 
>content? I sure would like to see something concrete for these metrics.

I think K is the property of the content set X *and* surrogate A. Surrogate 
A (in fact a data center with local content switch) may host 3 distinct 
content sets X, Y, and Z (e.g., SPORTS-NEWS, FINANCIAL-NEWS, and 
MY-IMAGES). Then what's advertised is that "if you access content set X via 
A, this is the metrics you'll get; metrics may include A's current load 
allocated to set X, X's billing properties, A's affiliation, ...)

Think of this as a single-source multicast group, whose identifier is 
(Source, Group). Then Source is A and Group is the content set. Together 
they identify where to get what.

Thanks!
Dan

>Stephen
>
>
>