[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Distribution CPG Protocol - Some Thoughts
- To: firstname.lastname@example.org
- Subject: Re: Distribution CPG Protocol - Some Thoughts
- From: Stephen Thomas <email@example.com>
- Date: Fri, 05 Jan 2001 14:01:54 -0500
- Delivery-date: Fri, 05 Jan 2001 11:04:34 -0800
- Envelope-to: firstname.lastname@example.org
At 12:26 PM 2001-01-05 -0500, brad cain wrote:
> >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'm rapidly turning into a broken record, here, (and I'll really try to
shut up on this), but it is necessary for CDNs to advertise prefixes, or
can a CDN just post its list on its Web site? Potential customers (or
peering partners) have a look at this list before they sign up with the
CDN. I'm not trying to be a pest because I have any particular notion of
what the market will or will not accept. I'm just trying to push back on
anything that might complicate the initial protocol. (And I am only
worrying about the initial protocol; there's always ng, or, as folks have
taken to lately, bis.)
> >Proposal 2: The protocol need not support aggregation.
>Disagree here... If a URL is a single content unit then content
>such as http://www.blah.com or http://www.blah.com/images could
>represent many URLs and make the protocol more scalable.
As is common, I didn't do a very good job explaining this proposal. By
aggregation I meant to refer to the process, within a CPG, of taking two
(or more) different advertisements and combining them into a single
advertisement for re-distribution. That, I think, just flat doesn't work.
It's probably so obvious to everyone else that I kind of confused the issue
by even bringing it up.
> >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"
I definitely agree that we need loop detection. Could be path vectors (like
the HTTP Via header). Could also be by unambiguously identifying each
advertisement (e.g. Entity tag + origin server + sequence number). That's
for example, how OSPF handles the problem in its flooding stage. Since I
think we'll need an unambiguous advertisement ID anyway, my guess is that
add path information solely for loop detection would be redundant. But then
I haven't really thought too much about a specific mechanism, so my brain
could definitely be off in left field here.
Stephen Thomas +1 770 671 1888
TransNexus, Chief Technical Officer email@example.com