Re: Distribution CPG Protocol

[brad cain <bcain@mediaone.net>]

Stephen,


First, I will second Alex's opinion that this protocol is
really about about the content routing problem

 
> Is there consensus that the distribution protocol operates in three phases?
> 
>    1. CDN advertises its capabilities
>    2. The Content Provider requests the use of CDN services by identifying
> content to be distributed.
>    3. The CDN confirms (or denies) the request for service

I'll push back on stage #3... It looks like "inline qos" to me... what
I mean by this is that I don't think we should be negotiating any type
of QoS in the protocol... I would say you just advertise to your
neighbors
and make sure the off-line SLAs cover any QoS... 


> Drilling down, I don't (yet) sense a consensus on all the details, but are
> these all the attributes proposed for phase 1?
> 
>    1a. footprint (expressed as a set of IP address prefixes)
>    1b. cost
>    1c. content type supported
>    1d. performance
>    1e. generic metric
>    1f. load measure
>    1g. cache capacity (I'm generalizing from "max file size")

I vote for simplicity sake only for: 1a, 1c, and 1e

I would strongly recommend that we not try to design a QoS routing
protocol... inter-provider QoS is difficult (if not nearly
impossible) to achieve dynamically (i.e. without off-line SLAs
and strict measurement)

> For phase 2, are these the set so far?
> 
>    2a. URI path
>    2b. Authoritative Source (generalized from "Content AS")
>    2c. "next hop" (I don't understand this attribute, so I may be
> mis-characterizing it)
>    2d. "metric" (ditto)
> 
> I'd also suggest adding
> 
>    2e. unique content identifier (e.g. ETag + source ID)
>    2f. content size
>    2g. generic content attributes (e.g. HTTP entity header values)

Why exchange content size and identifier?

We also need an attribute for looping... this could be a 2b extended
to a "content AS path" (with the first being the authoritative) 

> Phase 3 could be pretty straightforward. The simplest approach would be a
> binary ACK/NACK, but there might be some value in a bit more fine-grained
> response. Just to get the discussion started, here are some possibilities
> off the top of my head.
> 
>    3a. accept/reject
>    3b. time frame of commitment
>    3c. partial acceptance (e.g. only 10 GB of the 50 GB requested)

Again, I'm against putting QoS negotiation in an inter-provider
protocol... history shows its very difficult


There are other questions we need to ask:

1. How are aggregates represented?
2. Should hashes or full URIs be used?


-brad