Fwd: RE: Distribution CPG Protocol - Some Thoughts

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

From: "Tomlinson, Gary" <gary.tomlinson@cacheflow.com>
Date: Thu, 4 Jan 2001 16:52:34 -0800

This response covers the entire thread beginning December 19, 2000 and is
condensed to pertinent excerpts.

General comment:  I think this thread scope is beyond the narrow design team
and should be posted to general list cdn@ops.ietf.org.

On Thursday, December 28, 2000 @8:44 AM Oliver Spatscheck wrote:
 >.... .  And why do you
 >have to push content if you select surrogates? You only have to let the
 >surrogate know where the content is if need be.

We need to be careful here and distinguish between the need for
pre-population and the mechanism(s) employed to do it.  The pushing of
content is a form of pre-population, however it can be achieved in other
ways such as signaling content that includes the request to have it
pre-populated via a pull operation.  This is a requirement in my mind for
Video on Demand as one example.

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.

On Thursday, January 04, 2001  @1:08 PM Oliver Spatscheck wrote:
 >I think your summary covers my concerns fairly well. One case in which
 >on line decisions seem necessary is the case in which two CDN
 >have a possible surrogate in the same region. In this case eliminating
 >the entire CDN will not work since in some regions one of the two
 >CDNs is better than the other but in the region in question concerns
 >like cost are used to select the surrogate.

Agreed. We need more scenarios (use cases) to help drive our perspectives
and requirements.

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?

On Thursday, January 04, 2001  @1:08 PM Oliver Spatscheck wrote:
 >Another example is a little bit more far fetched. I always had in mind that
 >in the future there would be a spot marked for CDN services (similar
 >to electricity). In this case it becomes more obvious that CDNs
 >are bidding for capacity in particular regions.

This doesn't sound far fetched to me.  I'm aware of several organizations
who have identified this as a desirable use case.


My $.02 so far.  I'm glad to see us digging deeper, its going to be fun now.
Gary