RE: Requirements for Content Distribution

[DonE@activate.net]

> -----Original Message-----
> From: Stephen Thomas [mailto:stephen.thomas@transnexus.com]
> Sent: Monday, January 15, 2001 11:09 AM
> To: cdn@ops.ietf.org
> Subject: Requirements for Content Distribution
> 
...
> 
>     +------------+   +-----------+   +-----------+   +------------+
>     |   CDN A    |   |   CDN B   |   |   CDN C   |   |  "CDN D"   |
>     |(surrogates)|<->|  (agent   |<->|  (agent   |<->| (content   |
>     |            |   |   for A)  |   |   for D)  |   |  provider) |
>     +------------+   +-----------+   +-----------+   +------------+
> 
>       CONTENT DST <-> CONTENT SRC
>                       CONTENT DST <-> CONTENT SRC
>                                       CONTENT DST <-> CONTENT SRC

This is just an example - a flat hierarchy, or anything in between, is
also supported.

Also I agree with your response about aggregation of all CDNs to the left
of a given CDN.

... 
>     Phase II - Distribution Request. In this phase the content source
>     asks the content destination to distribute its content.

Before beginning this phase, the content source has received destination
capabilities for all CDNs to the left, so that it can make a decision as
to if and which content destination(s) to distribute its content.

Also, the requirements should also allow this to be done off-line; that is,
a (content destination, content source) pair may decide to use the protocol
for Phase I, but want to do Phase II off-line.

>     Phase III - Distribution Confirmation. In this, the final
>     distribution phase, the content destination confirms its 
> acceptance
>     (or denial) of the distribution request. Note that this phase does
>     not provide any information about whether the distributed content
>     has been accessed by user agents; such information exchange is the
>     responsibility of CDN accounting. [Ed. Although there has 
> been some
>     discussion as to whether this phase is necessary, the editor feels
>     that such questions were due mainly to a misunderstanding of the
>     purpose of the confirmation. Corrections to this assumptions are
>     solicited.]

Again this phase should be allowed to be done off-line.

After this phase, the content distribution actually takes place, either
automated
or manually.  After this has happened (or perhaps as a result), I would
think that
the content source would want to know of success (so it could update the
status in
its content management database), so there may be another phase that is
needed.
 
...
 
>        Distribution Method: The distribution methods that the CDN
>           supports; one or more of push, pull, and on-demand.

Just to avoid confusion, it might be good to point out here that this is
inter-CDN
rather than intra-CDN distribution.

The use of the term "on-demand" may cause confusion.  (For streaming, we
talk about
on-demand delivery, which is entirely different.  It is even more confusing
because we
use the term "distribution" where you use "delivery", so we really say
"on-demand
distribution".)  To resolve this, how about "pre-fetch pull" instead of
"pull", which
you use below and I assume means the content destination decides it wants to
initiate
a distribution.  Then use "end-user-initiated pull" instead of "on-demand",
so the
content is not distributed until there are end users wanting to access it.

...
 
>     In the second phase of content distribution, the content source
>     requests distribution of its content. It describes that 
> content with
>     one or more of the following attributes [Ed: in no particular
>     order]:

I would think URI, or something like it, and Content ID would always be
required.

...
 
>        Distribution Method: Push, pull, on-demand, or 
> withdraw. How the
>           content destination should retrieve the content. 
> Withdraw is a
>           special case that indicates a content destination 
> should cease
>           distribution of previously accepted content.

Same comment about "on-demand" as above.

...

> From: Stephen Thomas [mailto:stephen.thomas@transnexus.com]
> Sent: Monday, January 15, 2001 12:12 PM 
>  
> At 12:42 PM 2001-01-15 -0700, Hilarie Orman wrote:
> >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.

I agree.

Don