Re: Distribution CPG Protocol

[Dan Li <lidan@cisco.com>]

At 04:33 PM 1/12/01 -0800, Tomlinson, Gary wrote:
 >The fundamentals of advertising surrogates vs advertising content or both is
 >clouding my thought processes at the moment.

It's both. Take domain name as a simplified representation for content (URL 
is more elaborate but you see names like "images.foo.com" that encode a 
class of content into a name). Then, content routing is the task of mapping 
a name to a location, similar to routing a IP to a location. Then, a 
surrogate is mere a location for a *set* of names it supports.

So a route advertisement would have these two parts:

1. "route to content set X is via next hop M to content server A with 
metrics K", where A is chosen (based on metrics K) among other possible 
destinations B, C, D, which all advertise support for the same set X).

2. "X consists of abc.com, nbc.com, ...." The composition of X is fairly 
stable and may correspond to an entire data center's content (or one third 
of it). Changes to X are propagated among content routers via incremental 
"diff"s.

Therefore, there is no argument on whether to advertise surrogates (A) or 
advertise content (X). It has to be *both*. Just that X is what's being 
looked up and A is what's being found. It's always the pair that gets 
advertised.

As to content signaling, it's a mechanism far different than the route 
advertisement. It comes in *after* you know you have (or should get) this 
content, how do you keep the content up to date from its source (or whoever 
that's authorized). In that sense, you can think of content set X as a 
"content volume" that's being shift around and updated at various 
surrogates. Content signals are about signals of this volume. A surrogate 
advertising a volume means that it's willing to hand out signals for that 
volume. A surrogate subscribed to a channel which carries that volume means 
that it's willing to receive signals for that volume.

Dan

At 08:21 PM 1/12/01 -0500, Oliver Spatscheck wrote:


>Stephen,
>Phil,
>
>         first let me state that I think Phil provides a good summary
>in his two emails and personally I feel we are converging to a common approach
>(wasn't sure a few days ago).
>
>As to Stephen's comment I think there is value in the exchange protocol. The
>perl script approach is harder (and more time consuming) than you thinking.
>Getting those things working between the infrastructure of various CDNs to
>a point at which you feel comfortable offering it to paying customers takes
>time and effort.
>
>In addition I see an entire class of documents coming out of this:
>
>1. Basic exchange document (maybe with a basic 2 phase protocol
>    and an optional 3rd accept phase to accommodate both approaches proposed)
>2. A set of documents describing metrics used for the above
>    protocol.
>
>This approach keeps the basic protocol simple (Brad's comment) and allows us
>to introduce new metrics as need be without complicating the protocol
>description. It also gives the power to CDNs to use their own proprietary
>metric.
>
>I hope at the end of this process we have at least one document in category
>two. This would improve interoperability greatly and as stated in my earlier
>emails I think there would be great us for that.  However, I would still feel
>successful if we only define the protocol in category one. In addition
>separating the two seems to remove a lot of contention.
>
>Oliver
>
>
>
>Stephen Thomas writes:
>  >
>  > My turn to play devil's advocate.
>  >
>  > At 06:00 PM 2001-01-11 -0800, Phil Rzewski wrote: [re attributes of 
> surrogates]
>  >
>  > >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?
>  >
>  > At 06:38 PM 2001-01-11 -0800, Phil Rzewski wrote: [re IP address prefixes]
>  >
>  > >There's no law that says that the prefixes advertised through CDNP
>  > >protocols need to be the exact same prefixes advertised by the routers
>  > >speaking BGP. I see it as an advantage that someone COULD use the same
>  > >prefixes (especially for the purposes of getting this up and 
> running), but
>  > >they don't have to....
>  >
>  > Sounds to me like an argument for just shipping around a bunch of generic
>  > values. If that's the case we can just co-opt, say, SCSP [RFC 2334] 
> and be
>  > done with it. Or maybe the two parties could just hack together a 
> couple of
>  > CGI/Perl scripts and run them on a couple of Linux/Apache boxes. Any
>  > competent CDN operator ought to have folks that could whip that out in a
>  > couple of hours, which is a heck of a lot quicker than waiting for the 
> IETF
>  > to charter a WG, the WG to develop standards, vendors to implement the
>  > protocols, CDN operators to purchase the systems, operators to agree on
>  > their generic metrics, operators to configure their brand new CDN-peering
>  > boxes, etc..
>  >
>  > Seriously, though I appreciate Phil's reasoning, it's hard to convince me
>  > that there's any real value in creating a standard protocol that's merely
>  > transporting generic metrics around.
>  >
>  >
>  >
>  > ____________________________________________________________________
>  > Stephen Thomas                                       +1 770 671 1888
>  > TransNexus, Chief Technical Officer    stephen.thomas@transnexus.com
>  >
>  >