RE: Distribution CPG Protocol - Some Thoughts

["Greg King" <gking@UU.NET>]

It would seem difficult for the direction system to 
chose an alternate end to end path (i.e. a different
CDN) for a given source prefix if it didn't have at
least some semi real time measure of what a CDN was
willing to commit to for a given src prefix over a 
given time period.

CDN 1 represents an end to end path of quality A while
CDN 2 represents a different end to end path of quality
B.  Several things influence the quality of both end
to end paths including network topology, time of day
usage patterns, and available systems capacity and
capability at the CDN nodes. 

On the other hand if the directing is not based on
estimated congestion or capacity to a given src prefix
then it would seem relatively unimportant for the 
protocol to carry semi real time loading/quality info.
If this is the case, it seems that the CDN is designed to meet
an SLA that implies available capacity of defined quality
for given source prefixes no matter what.  In this case,
it doesn't seem as if the direction system is offering
the best available, most cost efficient, capacity over 
a given time interval where several end to end load 
dynamics may be at play.

Greg



-----Original Message-----
From: owner-cdn@ops.ietf.org [mailto:owner-cdn@ops.ietf.org]On Behalf Of
Stephen Thomas
Sent: Friday, January 05, 2001 10:18 AM
To: cdn@ops.ietf.org
Subject: RE: Distribution CPG Protocol - Some Thoughts


At 09:09 AM 2001-01-05 -0500, Oliver Spatscheck wrote:
>Overall it is a fine balance between allowing a CDN to manage/operate
>its surrogates by itself and to gather enough detailed information
>on the gateways to make any intelligent decision. I don't
>think a single number for all surrogates per CDN will cut it. I also
>agree that information on a per surrogate basis while desirable
>is probably unrealistic. However, aggregated information for
>meaningful network regions seems like a reasonable approach to me.


One thing that I don't have much of a handle on is how "real-time" this 
information has to be. If a CDN can adequately describe its network 
(capacity, regions covered, etc.) and provide a SLA that's acceptable to 
the content provider, can we get away with not carrying that kind of 
information in a protocol? And maybe if we ultimately want to make that 
information dynamic, as a simplifying matter could we tackle that as a 
follow-on?

I really don't have an opinion myself on what's feasible from a business 
standpoint, just a desire to keep things as simple as possible initially.



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