Re: Distribution CPG Protocol

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

At 10:53 AM 2001-01-09 -0500, brad cain wrote:
>First, I will second Alex's opinion that this protocol is
>really about about the content routing problem

See my earlier response. I don't think I've done a good job explaining the 
scenario.

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

No. This is not QoS. The idea is that a content provider asks a CDN to 
accept its content. The CDN then answers yes or no. "Yes" just means that 
the CDN has agreed to distribute the content. Although see my original 
message for some variations.

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

I agree.

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

Content size so the CDN can make a decision as to whether or not it can 
accept the content. E.g. if the CDN has but 100 GBytes of cache space, it 
needs to know if the content provider has 200 GBytes of content. (So it can 
decline the request.)

Content identifier is so the content provider can revise its advertisements.

>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

Me too, but I don't see this as QoS. With 3b, for example, Content provider 
says "please distribute the URLs for me" and CDN replies "OK, I'll do that 
for the next 72 hours".

>There are other questions we need to ask:
>
>1. How are aggregates represented?

Aggregates of what? Content or surrogates?


____________________________________________________________________
Stephen Thomas                                       +1 770 671 1888
TransNexus, Chief Technical Officer    stephen.thomas@transnexus.com