Re: Distribution CPG Protocol

[Eric Dean <eric@crystalballinc.com>]

I also concur that QoS is an offline process...if even quantifed at all.  

On Wed, 10 Jan 2001, Oliver Spatscheck wrote:

> 
> 
> Phil,
> Alex,
> 
> 	as you might guess I disagree with this conclusion. Let me explain
> why. However, first let me clarify that we (I and others at AT&T) are mainly
> interested in: Peering between CDNs. Phil is writing about the content
> provider who unless he is also a CDN is not part of the peering process
> according to our architecture.
> 
> To continue Phil's online offline argument let me bring it to an
> extreme. Since we already negotiate capacity off line on a daily basis (we
> have to account for events like the superbowl, new customers of the CDNs
> etc..)  why do we have to negotiate which content goes where dynamically. Just
> after finishing our daily personal capacity conference call give your peers a
> printed list of URL's (maybe you can put it on a floppy ...). Oh yeah, and for
> accounting just give them the paper bill that day.  AT&T always encourages the
> use of long distance FAX.
> 
> Now somewhat more serious. The way our peering currently works is by making
> off line capacity arrangement with near real time (within minutes) load
> feedback. However, as the off line billing we use the off line capacity
> reservation will not scale. I think we are perfectly fine negotiating the
> more static nature of a peering SLA (like proximity, cost, ...) off
> line, but at least the capacity should be an online process since in a
> CDN to CDN peering arrangement we have to change the capacity we
> use very frequently (at least once a day).
> 
> I would also be perfectly happy if we use the proposed 3 stage approach (or
> something similar) in which a legal capacity value is "best effort". (This
> could be the only capacity value a CDN has to support to be compliant.)
> However, I strongly believe that the protocol should support a simple capacity
> reservation and I don't see why this would make the protocol overly complex if
> it is not the mandatory behavior. (I assume of course that all CDNs which
> want to peer with us will eventually support it ...)
> 
> Another note is that in many CDNs capacity reservations on the caches are
> already possible. Another observation is that for typical Web traffic
> the storage requirement on the cache is rarely the bottleneck on a CDN.
> This of course changes as soon as we talk about multimedia traffic.
> 
> 
> Oliver
> 

Eric Dean
President, Crystal Ball Inc.
W 703-322-8000
F 703-322-8010 
M 703-597-6921