RE: distribution layer confusion

[DonE@activate.net]

> From: Lisa Amini February 08, 2001 7:55 AM
> ...
> I don't have a problem with having a protocol that could be used in
> common by the Distribution, Request Routing and Accounting, especially
> for the advertising components. However, by saying the CPGs of
> distribution CDNs must support RRS and Accounting protocols, I was
> trying to postpone specifying such until we had a better understanding
> of the requirements for each of the 3 components.  In other words,
> maybe it would be more clear to specify that the CPG of a distribution
> CDN must be able to send RRS info (i.e., 'I'm able to respond
> to requests for this content') and Accounting info (i.e., 'this the
> access info for this time period').  But, for the
> requirements docs, this info is defined in terms of RR requirements
> or Accounting requirements, not Distribution requirements. Since this
> seems to be a point of confusion, I will followup with a re-wording
> of that section.

Good.  I would think it would be sufficient to say that if an RRS and/or
Accounting exists at a distribution CDN, then Distribution must interface
with it.  If only proprietary intra-CDN RRS exists at a distribution CDN,
it can't be required that Distribution interface with that.

> Now I want to go back to something I had not noticed when I read
> Dan's response initially, which may represent a more significant
> difference than just whether one protocol supports sending info
> that communicates distribution, RR and accounting info...
> 
> The statement 'who wants to subscribe to what at what payment rate.'
> Indicates either,
> 
>  1.  The Content Source is specifying what it will pay to
>      have certain content distributed and expecting
>      those distribution CDNs wanting to provide service
>      to respond with an acceptance.
>  2.  A very different model than what I was considering in
>      that a Distribution CDN pays to subscribe (get content)
>      and then gets collects from those it sells access to.
> 
> Regarding Item 1, I think this is okay if considered in terms of the
> underlying requirements: the content source should be able to know
> what he will be paying for distribution services and should be able
> to inject content into a CDN.  But the wording is the reverse of
> what is currently being proposed -- that is,
> it is the Content Destination that advertises his capabilities (which
> may include pricing, but it is more likely that the pricing 
> issues will
> be negociated offline).  The Content Source "accepts" this service
> by then requesting Distribution Services from the Content Destination.

I agree the last wording is what would be used.  That is, as part of
advertisement, the destination CDNs specify how much they charge for
delivery services, then the Content Source can decide (probably among
more than one destination CDNs and based on other metrics) whether they
want to use that service.

> Item 2 is more like a Distributor model (as opposed to a distribution
> service provider model), that I thought we were not even considering--
> I just wanted to make sure.

Yes, this should be supported also.  I consider this a pay-per-view or
subscription model, where the destination CDN instead of the Content
Distributor does the billing.

I haven't quite finished reading all of your Distribution Requirements
document in detail, but I like it so far and have some comments.

Don