Re: Distribution CPG Protocol - Some Thoughts

[Oliver Spatscheck <spatsch@research.att.com>]

In one of the many emails I sent I proposed a three phase protocol
( I changed the terminology here which might make it clearer):


PhaseI: CDN advertise capabilities
PhaseII: the contenet is advertised to a subsest of CDNs (maybe even
	 subset of surrogates within a CDN)
PhaseIII: the CDN accepts the content advertisment 

The reason for the third phase is that this allows a surrogate to advertise
the same capacity to many other CDNs, however, the capacity is not committed
to any of the CDNs until a content advertisement is received and
acknowledged. If phase III is not present the advertising CDN has to either 
reserve capacity as soon as it advertises or the CDN which uses it will not be
sure if the capacity is available.

Oliver

Eric Dean writes:
 > 
 > 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 
 > 
 > 
 >