Re: Distribution CPG Protocol - Some Thoughts

[brad cain <bcain@mediaone.net>]

[I'm going to follow Gary's lead and try to address this
thread with one or two e-mails]

I've pasted Stephens initial proposals in here as I believe
they begin to cover the hard questions for the protocol

>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 also believe that these two types of information can be
carried within the same protocol (analogy: MBGP address
families).


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


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

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

Absolutely agree.

> Fifth, BGP works best for relatively stable information. There have been a 
> fair number of protocol tweaks and configuration folklore to minimize 
> route-flapping, but (as is common with distance-vector and path-vector 
> protocols) the protocol behaves better when the information is relatively 
> stable. Is this the case for CDNs? (I honestly don't know.) How frequently 
> is advertised content expected to change? I don't have a specific proposal 
> here, and I'm not sure there's much to learn from BGP. (Route convergence 
> is only an issue when you have routes, e.g. paths, and proposal 3, at 
> least, has rejected them.)

My guess would be that advertised content doesn't change that much and
content advertisements wouldn't flap because:
	1. content providers would have a single root redirection
	domain that would originate advertisements for their content
	2. cdns being virtual networks would mean a very flat
	hierarchy which would limit problems with flapping


[new stuff]


I believe that content peering initially makes most sense between
a middle man/operator and a set of ISPs. (in other words, it will
be very difficult for classic CDNs to peer because of overlap, etc)
In this model, it is important for the operator to know the potential
layer-3 coverage of the ISPs CDN as well as have basic feedback for
failover, etc.

Therefore I propose that the following type of advertisements
be exchanged:
	1. aggregates of content (e.g. http://www.blah.com/images)
	2. ip prefixes of surrogate coverage (e.g. 128.1.1.0/24)
	3. basic metric for cdn health

[i sent an e-mail in the past with this proposal which i'll resend
to the list.. this one is already too long]


-brad