Re: Distribution CPG Protocol - Some Thoughts

[Eric Dean <eric@crystalballinc.com>]

Quite frankly, I see a two stage process:

1) Exchange capabilities between CDN's
2) Exchange URL prefixes

Point being that there is little reason for me to advertise content to a
CDN that isn't capable of delivering it.

On Fri, 5 Jan 2001, Stephen Thomas wrote:

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

Eric Dean
President, Crystal Ball Inc.
W 703-322-8000
F 703-322-8010 
M 703-597-6921