Re: Distribution CPG Protocol

[Eric Dean <eric@crystalballinc.com>]

Nice multiple choice.  I wish the rest of the WG would operate this way
8-)

There are really two different cases where a metric could be considered:
1) In the initial capabilities exchange between CDN's
2) In the specific advertising of content URI's

Per item 1) I don't believe that "B" will convey much information..."I
need to reserve '22' units of your CDN" doesn't really tell me much.  "C"
is a bit more interesting, especially if I am a customer that pays for a
specific amount of your CDN resources.  For two competitive-ish peering
CDN's, "A" is what will most likely be implemented but that doesn't mean
that we can't give options for "B" or "C" within a protocol framework.
Just because CDNs may not use certain feature is not entirely a
justifiable reason to not make them optionable.
 
Per item 2) I could potentially see such a use for traffic engineering
though I'm not quite sure how.  It's often difficult to upload and purge 
CDN operations in my head 8-)
 



On Wed, 10 Jan 2001, Oliver Spatscheck wrote:

> Eric,
> 
> 	I am not sure if I am just slow here, but I am still not sure what
> your answer is.
> 
> Do you mean:
> 
> A.) No exchange of any information regarding resources is required
> 
> B.) Simple reservations and advertisements of resources are allowed,
>     however, detailed properties of the resources advertised are
>     negotiated off line.
> 
> C.) Full QoS negotiation.
> 
> As stated before I believe in B.) . As to the metric of the resources
> I would go as far as to say it could be a simple integer. The
> meaning of the integer would be defined off line by an SLA.
> 
> Also as stated before. The reason for my support of B.) is not that
> I want to ensure QoS. The reason is that as of today many CDNs make
> reservations for their customers. If my demand changes I have to change
> this reservation. This can be either done by a phone call or
> by a protocol. In our current case the contract specifies exactly
> how this capacity changes are performed.
> 
> Oliver
> p.s. I completely agree with your assessment of disk capacity as
> a metric.
> 
> Eric Dean writes:
>  > 
>  > I believe that capacity management is a function of the CDN provider.  If
>  > a CDN peer consistently is unable to deliver content with sufficient QoS
>  > then you stop peering with them...or with that portion of the CDN.
>  > 
>  > QoS mechanisms have been hammered out within the IETF and rarely
>  > implemented except for some internal traffic engineering.  I have never
>  > seen a bilat (contract or protocol) that has QoS properties.  
>  >  
>  > Exchanging capabilities and exchanging capacity are two completely
>  > different considerations.  It will also make for extremely chatty
>  > protocols because content will continuously shift.  
>  >  
>  > In addition, disk capacity is rarely a determining factor.  I/O, CPU,
>  > memory are much more of a determining factor and are micro-dynamic.
>  >    
>  > On Wed, 10 Jan 2001, Oliver Spatscheck wrote:
>  > 
>  > > 
>  > > 
>  > > 
>  > > Eric Dean writes:
>  > >  > 
>  > >  > I also concur that QoS is an offline process...if even quantifed at all.  
>  > >  > 
>  > > 
>  > > 
>  > > Eric,
>  > > 
>  > > 	please clarify for me. Do you mean with QoS something as simple
>  > > as space or bandwidth reservation or do you mean something as complicated
>  > > as the detailed properties reserved bandwidth has to adhere to?
>  > > 
>  > > I am in complete agreement with you that the "properties of reserved
>  > > bandwidth" should be negotiated off line. However, the availability
>  > > and reservation should be an online process.
>  > > 
>  > > Oliver
>  > > 
>  > 
>  > Eric Dean
>  > President, Crystal Ball Inc.
>  > W 703-322-8000
>  > F 703-322-8010 
>  > M 703-597-6921 
>  > 
>  > 
> 

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