RE: distribution layer confusion

[DonE@activate.net]

What the following suggests to me is that the default control channel
is defined by a protocol that is used in common by Distribution,
Request Routing and Accounting.  Then additional, more specialized,
protocols are used as needed.

From: Dan Li February 06, 2001 10:10 AM
 
> The content source (or whatever authoritative thing) operates 
> a number of 
> channels, while any contracted Distribution CDNs subscribe to those 
> channels when needed. First, all of them subscribe to a 
> default channel, 
> the "Control Channel". "Control Channel" will say which other 
> channels are 
> present and it wants who to subscribe to what at what payment 
> rate, etc., 
> and the subscriber(s) can reply back yes/no and why. The 
> other channels are 
> "invalidation channels", "delta encoding channel", "full replication 
> channel", "usage feedback channel", etc.
> 
> Each type of channel may be defined in a separate protocol 
> spec, basically 
> specifying its XML DTD and semantics of each components, like 
> what WCIP is 
> doing to define the "invalidation channel". This way, we allow 
> decentralized growth in different areas while having them 
> easily plugged 
> together.

Using such a protocol eliminates the need for dependencies such as
the following.

>From draft-cdnp-distreqs-2 02/02/01 11:16 Section 2, p. 4-5

> 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 would need to advertise the
> availability of content to the Request Routing CDN and send access
> information to the Accounting CDN.

The justification for this dependency was given as follows.

From: "Lisa Amini" 28 Jan 2001 10:00:14 -0500

> 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.

Once the Content Source is ready to start accepting requests, it could
notify an administrator to set up an appropriate link for end users to
get content from the Distribution CDN.  That is, it should be possible to
allow for the case where there is no RRS.

The default control channel protocol would handle such things as the
following, which shouldn't be unique to the RRS:

>From draft-ietf-cain-request-routing-req-00.txt 1/22/01 Sec. 3.3 p. 11

> For the discussion it is assumed that the RRS represents a logical
> node on a network that could be reached by another RRS node. For the
> purposes of this draft, each RRS must be able to be identified by a
> unique identifier (RRS node identity).

Having this common protocol isn't the only way to go, but it should be
considered.

Don