RE: distribution layer confusion

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

DonE@activate.net writes
 >
 > 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.
 >

I am leary of starting on the protocol before we get more feedback
on the requirements, but having said that, perhaps we are at a point
where talking about options for the protocols will help draw out
better definition of the requirements -- so here goes.

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.

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.

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.



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

To clarify, even though there is no peered RRS, there is still an RRS. In
other words, the adminstrator who wants to operate in this mode still needs
to setup a CPG.  The request for distribution services would point to this
CPG so that it would receive the RRS advertisements from the Distribution CDN
to indicate it (the Distribution CDN) was ready to start receiving requests
for the accepted content.  The adminstrator would then be responsible for
setting the appropriate links to point to the content accessible through
the Distribution CDN.


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