Re: Distribution CPG Protocol - Some Thoughts

[Stephen Thomas <stephen.thomas@transnexus.com>]

At 12:26 PM 2001-01-05 -0500, brad cain wrote:
> >Proposal 1: The protocol should advertise the availability of content.
>
>I partially agree with this design decision... However, I also
>believe that MINIMAL surrogate information should also be passed
>between CDNs with a very simple metric.  Let me explain:
>
>Advertising surrogates is problematic for the following reasons:
>         1. CDNs don't want to share intimate knowledge of their
>         networks (and this is coming from someone who used to work
>         for one).
>         2. Exchanging meaningful QoS between providers has proven
>         in other worlds (i.e. layer-3) to be extremely difficult.
>         This is why I propose a very generic metric that would be
>         CDN to CDN specific.
>         3. Treating CDNs as a "black box" for now is the most
>         pragmatic approach and one that I believe is necessary
>         to get something started.  Enhancements can be made
>         later as necessary (analogy: inter-provider diff-serv).
>
>However, I do think that advertising a tiny bit of surrogate
>information is useful.  My proposal is to advertise IP prefixes
>with a generic metric between providers.  This proposal isn't
>geared at "classic cdns" (i.e. akamai) because they are complete
>Internet overlays.  It is intended for ISPs who deploy their
>own CDNs and want to advertise POPs that have surrogates.

I'm rapidly turning into a broken record, here, (and I'll really try to 
shut up on this), but it is necessary for CDNs to advertise prefixes, or 
can a CDN just post its list on its Web site? Potential customers (or 
peering partners) have a look at this list before they sign up with the 
CDN. I'm not trying to be a pest because I have any particular notion of 
what the market will or will not accept. I'm just trying to push back on 
anything that might complicate the initial protocol. (And I am only 
worrying about the initial protocol; there's always ng, or, as folks have 
taken to lately, bis.)

> >Proposal 2: The protocol need not support aggregation.
>
>Disagree here... If a URL is a single content unit then content
>aggregates
>such as http://www.blah.com or http://www.blah.com/images could
>represent many URLs and make the protocol more scalable.

As is common, I didn't do a very good job explaining this proposal. By 
aggregation I meant to refer to the process, within a CPG, of taking two 
(or more) different advertisements and combining them into a single 
advertisement for re-distribution. That, I think, just flat doesn't work. 
It's probably so obvious to everyone else that I kind of confused the issue 
by even bringing it up.

> >Proposal 3: The protocol need not explicitly support the notion of paths.
>
>Slightly disagree... I believe that a simple method of preventing
>loops should be used so that content advertisement loops don't
>form.  However, the analogy to BGP doesn't exactly apply because AS's
>generally have some form of (network) geographic significance.
>
>A simple proposal would be to use path vector on content sets where
>a content set is a set of content advertised from a single "root"
>domain.

I definitely agree that we need loop detection. Could be path vectors (like 
the HTTP Via header). Could also be by unambiguously identifying each 
advertisement (e.g. Entity tag + origin server + sequence number). That's 
for example, how OSPF handles the problem in its flooding stage. Since I 
think we'll need an unambiguous advertisement ID anyway, my guess is that 
add path information solely for loop detection would be redundant. But then 
I haven't really thought too much about a specific mechanism, so my brain 
could definitely be off in left field here.


____________________________________________________________________
Stephen Thomas                                       +1 770 671 1888
TransNexus, Chief Technical Officer    stephen.thomas@transnexus.com