Re: Requirements for Content Distribution

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

Many good questions. In some cases I have a tentative opinion; in all more 
discussion would be helpful.

At 12:42 PM 2001-01-15 -0700, Hilarie Orman wrote:
>In section 3, does the protocol indicate that CDN B is an agent for CDN A, or
>does CDN B aggregate messages from its "lefthand" CDN's of surrogates
>and promote them rightward as if they originated from CDN B?

In the interest of simplicity, I was assuming that CDN B would aggregate 
all information it receives from other content destinations and advertise 
those capabilities as its own. At least, I think that simplifies the 
protocol. (I also think that's how it would work in practice, as, in a 
business relationship, CDN B may not want to reveal that the capabilities 
its advertising are really "outsourced" from someone else.) That 
conclusion, however, was a personal assumption not necessarily justified by 
any discussion on the list. Further comments, anyone? (Subsequent drafts 
will address this point explicitly, one way or the other.)

>There appears to be no required relationship between the capabilities
>advertisement and the distribution request.  So the capabilities are
>simply advisory?

Again, that was my assumption, but I should have noted it as such in the 
draft. I think trying to tie distribution requests to specific capabilities 
advertisements moves us down the negotiation/n-phase-commit rathole. 
Comments appreciated.

>Are the capabilities useful?  Presumably the content destination
>cares more about hit rate, size, expiration time, etc. than the
>content type itself?  There's no mention of latency or cost,
>the only two bottom line charateristics, when you come right
>down to it.  Live streaming media probably needs some
>different characteristics, which you allude to.

Personally, I'm not a big fan of the capabilities exchange phase as a 
protocol. I think that it will most likely be handled off-line. However, 
that is definitely not a consensus opinion; it may well be a minority 
opinion. The problem with cost and latency is coming up with meaningful, 
objective measures of both. I'm not adverse to trying, though, if someone 
wants to give it a shot.

>For the "push" URL, can an intermediate agent of the
>CDN change this in forwarding it rightward through the
>diagram in section 3?  If the agent can aggregate,
>then the advertisements could get completely rewritten
>in passage.

Yes, at least in my opinion.

>In the confirmation, if there is no limited acceptance, then the
>request must exactly match the capabilities of the distribution
>network, for which there is no required pre-announcement.  This
>makes it difficult to get the distribution request right.  The more
>parameters, the worse it gets.

Yes. But I'm not sure if this is a problem. (I.e. if you pre-negotiate 
distribution of streaming media and the content destination keeps rejecting 
your distribution requests, you have something to resolve with your 
provider/peer.) That does suggest we ought to have meaningful error codes 
for the rejection messages.

>Presumably a "hash" in the distribution request a bitstring derived
>from the (static) content.  The hash lets you identify the content
>irrespective of location.  This would allow the distribution network
>to retrieve the content from a non-authoritative source).
>Would this be useful?

I dunno.

>This leads to a related point: can the authoritative source be a list?

Again, I don't know.