Re: distribution layer confusion

["Lisa Amini" <aminil@us.ibm.com>]

brad cain <bcain@mediaone.net> writes:
 >
 >
 >
 > The comments below are really an attempt to better describe what
 > I believe the distribution architectural layer is really about.  I think
 > there has been some confusion between what we have been calling
 > request routing and distribution.  [Note that these comments are not
 > about protocols but about the architecture]
 >
 > Please comment as I think we should iron this out soon...
 >
 > -brad
 >
 >
 >
 >
 > My belief is that the "distribution layer" is really divided into
 > two straightforward parts:
 >   1. content replication
 >   2. content signaling
 >

I agree that we need to clear the architectural/requirements before
moving on to the protocols.  However, I also think there a third
requirement and that is the advertisement of distribution
capabilities. This will need to come in a couple of forms to
enable the explicit, off-line, and inline models.  That is,

  explicit - the CPG of Distribution CDNs should have a
    way to identify capabilities to potential Content Sources (i.e.,
    other CDNs that want their content distributed).  However,
    explicit distribution advertising should not be a required
    step (hence, offline, and inline).  This information
    should include a (profile) identifier so that it can
    later be referenced when the content is injected.

  offline - contracts negotiated offline (or even retreived
    from some (say, UDDI) exchange; just as for explicit, it
    would be advisable to assign these contracts some identifier
    which is later used by the CPG to inject/accept content.

  inline - in the case of en-route proxies, the proxy, when
    it retrieves a piece of content, should identify that
    it is willing to offer distribution services, it should
    be able to specify a channel where the Content Source,
    if desired, can retrieve explicit, more detailed
    distribution advertisements. The Content Source
    could also just skip directly to requesting
    services.

Another way of looking at the inline version is to say that
with HTTP hit-metering and cache control, we have a way to
do best-effort, weak consistency distribution.  The accounting
peering mechanism should (I believe the draft does) provide a
way to specify a format in which info should be returned. The
content signalling should provide a way that content can
be transported as part of the message (allow content signaling
mechanisms to include HTTP GET and it's response).

But we also move beyond this best-effort model to enable
CDI--give content providers the ability to better specify how
their content is distributed/delivered; potentially for a fee.
To do so, distribution requires: content signaling (minimally
for consistency); replication mechanisms (some media types are
not reasonable carried in the content signal (streaming media),
push is required, ...); and the ability for the content
source to make informed decisions which CDNs can best meet their
distribution requirements (capabilities advertising).


 > Content replication: this is the actual replication of specific
 > pieces of content between CDNs through distribution peering.
 > A protocol is used to negotiate and advertise which content
 > should be replicated between the peers. [note: There may
 > be a negotiation phase but I'm a little worried about a complicated
 > request response model.  A simple negotiation may be needed to
 > negotiate content types.]  The key thing here is that this is
 > about copying content from one CDN to another.
 >

Instead of negotiation, would it be sufficient to have the source
request service from a Distribution CDN and the Distribution CDN
accepts or rejects.  (If the source wants to know the details on
the capabilities, it tunes into the distribution capabilities
advertisements of the relevant CDNs and then uses this info
to make his decision of which to ask for service.)  In addition
to the info we've already discussed, i.e.:
 -uri
 -content id
 -the content or it could tell the distribution CDN where to get
  it (using some replication protocol),
 -content type
 -service type (dist method(push,pull,...),proto(rtsp+rtp,ftp,...))
 -optionally, a profile identifier

we will also need info that ties this into the overall CDI structure:
 -optionally, an content signal channel and an indication of whether
  the distribution CDN is required to abide by it
 -the RRS type and optionally, an RRS channel to which the Distribution
  CDNs CPG must be able to advertise it's ability to service requests
  for given objects**
 -optionally, a feedback/accounting channel.

**with inline, a separate RRS channel may not be required.

I assume a model where, unlike the CPGs for CDNs offering only Accounting
and Request Routing services, the CPGs for Distribution-only CDNs must
support Accounting and Request Routing peering protocols, in addition
to Distribution Peering protocols. That is, the CPG of a Distribution-only
CDN must interface with the CPGs of the Accounting and Request Routing CDNs,
and optionally, other Distribution CDNs.

For example, a Distribution-only CDN respond positively to a request
by the Content Source to accept/service his content.  Then once it
is ready to start accepting requests for the content (i.e., probably
after it fetched the content) it would advertise the availability of
the content to the Request Routing CDN and send access
information to the Accounting CDN.  The requirements for these
last 2 protocols, while they are closely tied to the operation of each
Distribution System, IMO are not considered part of the Distribution
Peering System -- I think they should be covered in the RRS and
Accounting requirements drafts.



 > Example:
 >
 > CDN A is peered with CDN B.  CDN A advertises a set of URIs
 > which should be replicated on CDN B.  In this advertisement
 > a location is sent as to where the content should be obtained
 > from (i.e. a surrogate or origin server).  A real world example
 > would be for distribution of streaming media files: CDN A
 > would advertise to CDN B which files should be copied and
 > from where.
 >
 >
 >
 >
 > Content signaling: This is the distribution of content freshness
 > information between CDNs.  An example would be the WCIP protocol.
 > These signals are used to purge content or to update the expiration
 > times of the content.  Content signals may also be used to update
 > other metadata associated with the content (this is probably more
 > future oriented).
 >
 > Example:
 >
 > CDN A is the "root" or main CDN for content provider B.  CDN A is
 > peered with CDN C.  When content from provider B is changed, CDN A
 > relays a content signal to CDN C so that it is expired from its
 > surrogates.