Re: Distribution CPG Protocol

["Phil Rzewski" <philr@inktomi.com>]

Lots to respond to. :)  In this message, I'll talk about the 
"advertisements" issue (which I'd like to think of as a "metrics" issue).

At 01:11 PM 1/10/01 -0500, Oliver said it best when he said:
>For each CDN you are peering with the  policy engine calculates:
>
>exchanged_value + off_line_SLA + policy ==> comparable_value
>
>and then the policy engine compares the results.

In fact, I'd like to couple this with an earlier Oliver quote, regarding 
whether the reservation of "22 units" of a CDN carries meaning:

>It does if the SLA you have with that CDN tells you what 22 units are.
>I wouldn't mind defining some "standard units" here, however, I have
>the impression that people are resisting this effort. So I proposed
>the minimum which supports my business modell.... .

As usual, I'd like to bore everyone with BGP folklore [ :) ]. This problem 
was solved in the BGP universe with Communities. Each route may be 
optionally tagged with a list of Communities (up to 16, I think?) each of 
which is just a number that only has significance to the people on that 
peering session (the side that defined it & the side that interprets it). I 
don't wanna be accused of always trying to turn this work into BGP, but I 
have a fetish for things that have reached implementation.

Indeed, once you've just got a list of numbers, there's really not even a 
need to name them "Bandwidth", "Disk space available"... you've just got a 
list of "Genric Metrics". We certainly CAN think of some metrics that are 
likely to have some use (such as "Bandwidth"), but if we build them into 
the protocol, we'll just be taking up extra space in the event those 
specific metrics aren't used somewhere. Since we can't possible think of 
EVERY metric someone might want to define, we'll need to have a place for 
Generic Metrics anyway. Why not make them all Generic?

(That being said, it would be silly to just do exactly the same thing as 
Communities, as Communities are just single 32-bit values. They're nice for 
tagging things like "this route came from Acme" or "you should attach a low 
preference to this route", but NOT good for tagging things like "the 
temperature is 62 degrees at the place where this route came from". As a 
result, since we want to indicate things like "Bandwidth=128", I imagine 
that each Generic Metric in the list would look like Metric1=valueA, 
Metric2=valueB, etc. Should all values be only numeric? Hmm. Myself, I'm ok 
with numeric.)

Also, just another response to a related issue...

At 12:20 PM 1/10/01 -0500, Kobus van der Merwe wrote:
>The capacity advertised to a peer would reflect the capacity available
>to the peer based on some contractual agreement (not the total capacity
>of the CDN).

I think this is an important distinction. Once again, I think this makes a 
case for a Generic Metric. One of the things I was previously stuck on with 
regard to capacity advertisements was an implication (assumed on my part) 
that these advertisements might have some universally-accepted meaning. 
:)  In other words, if we imposed a "space available" metric, and every CDN 
actually had to catalog their available space and advertise it, I think a 
lot of them would not want to participate because they'd never wanna send 
the message of "there's no room at the inn". Fear is that they'd end up on 
the cover of CDN Illustrated with the headline "Foobar CDN is out of space!" :)

By making it generic, it becomes an issue of local significance between a 
CDN and their peers. One CDN might be very strict with resource allocation 
and, indeed, would want to turn people away when they're "full", so they'd 
establish this meaning in an agreed-upon metric. Another CDN might be 
"best-effort" by nature and might just accept all advertisements 
regardless, not even establishing a metric. Yet another might be a slimy 
best-effort CDN that claims to support such a metric, but just always 
responds with "yep, we have space available" no matter what. :)

In short, I agree with what Kobus was saying, but I want to highlight it to 
make sure others agree as well... because I previously had the wrong 
idea... so maybe others did as well.

--
Phil Rzewski - Senior Architect - Inktomi Corporation
650-653-2487 (office) - 650-303-3790 (cell) - 650-653-1848 (fax)