RE: Distribution CPG Protocol - Some Thoughts

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

At 04:52 PM 2001-01-04 -0800, Tomlinson, Gary wrote:
>On Wednesday, January 03, 2001 @7:03 PM Stephen Thomas wrote:
> >If providers advertise content, the protocol might say something like
> >"origin B has 50 GB of content". Now in the case of resource contention,
> >the resolution is strictly local. The surrogate picks and chooses from the
> >content that it wishes to cache. Sure, it's probably going to pick some
> >best-fit strategy (so providers that want first-come-first-serve lose
> >anyway), but look at the difference. In the first case (advertising
> >surrogates), the provider gets left with a bad taste in its mouth. (Hey,
> >that stupid surrogate said it had space available, but when I tried to use
> >it I was refused!) In the second case (advertising content), the provider
> >probably never even knows why it wasn't chosen. (I advertised, but the
> >surrogate decided not to pick up my content; I guess I'd better advertise
> >elsewhere.)
>
>There's a couple of subtle issues in this scenario that need to be
>addressed.  There are at least three kinds of replicating surrogates that
>I'm aware of, full set replica, demand driven caches and pre-populated
>(pinned) caches.  Additionally, surrogates can be categorized by the
>services they offer, HTTP, streaming media (Real, MMS, QuickTime, MPEG, etc)
>etc. What this means is, surrogates are not just generic delivery points,
>but rather are likely to be more specialized.  Given this complexity along
>with the implementation policy differentiators in CDNs, I've been working
>under the assumption surrogates would be represented in aggregate by their
>CDN as a set of service capabilities, such as capacity, proximity, delivery
>service modalities, etc.  With this in mind, the advertising of content
>isn't directed at specific surrogates but rather to CDNs who in turn manage
>their surrogates to meet the commitments the entire CDN signs up for.

Gary has said exactly what I was trying to, but much better. I, too, was 
thinking that a content provider signs up with a CDN (Or one CDN signs up 
with another CDN), and it was up to the CDN to manage/operate it's 
surrogates. I think the idea was that the CPG would actually be the one 
participating in the protocol, not the surrogates directly. In which case 
the CPG would probably represent an aggregate capacity and set of capabilities.

>On Thursday, January 04, 2001  @1:08 PM Oliver Spatscheck wrote:
> >I guess this question could be addressed in the redirection protocol which
> >opens up an interesting question: How does the redirection system learns
>which
> >surrogates are actually participating at each point in time? If for
>example, we
> >agree that we allow surrogates to cache content even if the content
>provider
> >knows that he will never select that surrogate in its redirection system we
> >can push the entire decision process into the redirection system and go
>with
> >a content advertising method.  (However, we will still need feedback to the
> >redirection system as to which surrogates or group of surrogates are
>willing to
> >accept redirections.)
>
>I don't see on-line (aka real-time) feed back as being true real-time
>granularity per transaction but rather batched and summarized on regular
>time intervals.  The summaries would include information such as reserve
>capacity in the CDN, current cost, QoS by service types {streaming media,
>HTTP, etc).  The thing I'm struggling with on the feed back is whether it
>belongs in distribution or accounting protocols.   What I mean here is,
>should distribution be involved in the operational support system at all, or
>should it be limited to service delivery only?

My assumption, FWIW (perhaps not much ;^) was that this would all be 
accounting. I suppose another alternative is the HTTP Meter header.



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