Fwd: Distribution CPG Protocol - Some Thoughts

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

Date: Thu, 28 Dec 2000 11:43:44 -0500 (EST)
From: Oliver Spatscheck <spatsch@research.att.com>

Stephen Thomas writes:
  >
  > On the assumption that the WG goes forward, here are some initial thoughts
  > on protocols. Some (most?) of this is possibly obvious, or perhaps some
  > (most?) is brain-damaged. I'm interested to hear either way.
  >
  >
  > Distribution CPG Protocol. This has been likened to BGP several times, so
  > it seems like a good place to start is looking at what BGP offers (and 
what
  > it doesn't) that appear to be relevant to CDNs.
  >
  > First, BGP is an advertising protocol. BGP peers advertise autonomous
  > system paths that reach CIDR IP subnets. In our case (again, thinking only
  > of distribution), two options are available. Distribution CPGs could
  > advertise surrogates, or they could advertise content. If DCPGs advertise
  > surrogates, it would be up to the recipient CPG to arrange to have content
  > pushed to the surrogates. Alternatively, if DCPGs advertised content, then
  > it would be up to the recipient to arrange to have its surrogates pull 
that
  > content. I suppose there's no technical reason to limit the protocol to 
one
  > of these options, but, in the interest of schedule and focus, at least
  > picking one to start with seems preferable. My own instinct is that
  > advertising content works better. There's sort of a one-to-many
  > relationship (one content to many surrogates) that makes it more natural.
  > (In the reverse, you have to worry about different content providers
  > contending for the same advertised surrogate space.)
  >
  > Proposal 1: The protocol should advertise the availability of content.


Actually I like more the model of advertising surrogates. Advertising content
alone prevents the owner of making the decision of which surrogates to use and
breaks the model in which the origin of the content keeps full control of the
content for accounting, invalidation, QofA and security.... .  And why do you
have to push content if you select surrogates? You only have to let the
surrogate know where the content is if need be. To pick up your argument there
is kind of a one-to-many relationship here too.  (one surrogate keeps many
content) .... .

Maybe the protocol should advertise both, but in contrast to BGP the
advertisements will actually change if somebody uses it. For example,
if a content provider uses a particular surrogate the surrogate might
stop advertising. I guess what I try to say is that in the CDN
peering environment in contrast to BGP the protocol has to be load
sensitive to meet the SLAs a CDN gave to a origin site.


  >
  > Proposal 2: The protocol need not support aggregation.
  >
  >
  > Third, BGP assigns paths to its advertised objects. When a server learns a
  > new destination from a peer it adds its own AS to the path on subsequent
  > re-advertisements. In the simplest case, I don't think paths are relevant
  > to DCPGs. Say CDN-1 advertises content to CDN-2, who, in turn,
  > re-advertises it to CDN-3. Now, if CDN-3's surrogates want to retrieve 
that
  > content, is there any need to go through CDN-2? Simplest case says "No";
  > we're on the Internet after all. CDN-3's surrogates can go right to the
  > content's source. I can think of two complications that might affect this,
  > though. First is security. Suppose CDN-1 only trusts CDN-2; maybe it's
  > never even heard of CDN-3. In that case, perhaps it wouldn't want CDN-3's
  > surrogates grabbing its content. The second complication might be
  > accounting/billing. Perhaps CDN-2 expects to get paid for relaying the
  > advertisements from 1 to 3, and maybe it needs to know when that 
content is
  > actually retrieved in order account/bill appropriately. In the interest of
  > simplicity, I'd propose to reject both of those arguments. For the case of
  > security, CDN-1 can construct its advertisements in such a way that when a
  > CDN-3 surrogate retrieves the content, the retrieval request identifies 
the
  > advertisement. (For example, CDN-1 could embed the identity of CDN-2 in 
the
  > URL.) The billing argument might be more persuasive, but I'm loathe to add
  > complexity to any protocol solely to accommodate billing. And finally, 
it's
  > quite possible that CDN-2 could implicitly achieve the same effect as a
  > path by advertising the content as its own and then proxying to the real
  > content.
  >
  > Proposal 3: The protocol need not explicitly support the notion of paths.


I also disagree with this point. One of the main features of paths in BGP is
the detection of routing loops (routing itself depends more heavily
on policy ....). We have a similar problem. We have to eliminate advertisment
loops. It is also a good debugging tool. Debugging problems in peered
CDNs is one of the main challanges of CDN peering.


  >
  >
  > Fourth, BGP accommodates policy. I wouldn't go so far as to say that BGP
  > supports policies, as (to me) that seems more of a quality of BGP
  > implementations rather than the protocol itself. I do think, however, that
  > this same sort of accommodation is critical for CDNs. To as great an 
extent
  > as possible, though, I'd suggest leaving that to implementations rather
  > than protocols. For the protocol, therefore, it is only necessary to
  > provide sufficient information to allow implementations to carry out 
policy
  > decisions.
  >
  > Proposal 4: The advertised objects must carry sufficient identifying
  > information to allow for implementations to make policy decisions; 
however,
  > there is no need for the protocol itself to carry policy descriptions.
  >

Agree! Especially if we use settled peering policy will be crucial.


Oliver