Re: distribution layer confusion

[Dan Li <lidan@cisco.com>]

My denotation wasn't clear who generates the input. I agree with you. 
Forgive me for jumping to implementations, but I tend to think that way:

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. For unicasts, all these channels can be implemented as BEEP 
(multiplexed and thus consuming just one TCP connection). For multicast, 
these can be any protocol/products people choose to use. Channel naming 
ought to facilitate interoperability.

Thanks!
Dan

At 10:32 AM 1/28/01 -0500, Lisa Amini wrote:

>I thought the question of "does the content source advertise content or
>does the content destination advertise capabilities?" had been settled with
>"destination advertises capabilities, but it should be optional since this
>may be handled with other mechanisms, e.g., offline contracts."  If you
>think it should be the reverse, please help me understand why.
>
>If it is that the Distribution CDN advertises capabilities, then a Content
>Source would request services (of the Distribution CDN) and the
>Distribution CDN would accept or reject.  This 'signaling' to request
>distribution services should provide the ability to either tell the
>Distribution CDN where to get the content (a replication channel) or it
>could (say, for very small objects), just include the data in the request.
>
>I agree with your statement on content advertisement in the case of the
>"routing table," which is part of the RRS.
>
>
>--Lisa
>
>Dan Li <lidan@cisco.com> on 01/27/2001 11:39:54 PM
>
>To:   Kobus van der Merwe <kobus@research.att.com>, brad cain
>       <bcain@mediaone.net>
>cc:   cdn@ops.ietf.org, Lisa Amini/Watson/IBM@IBMUS,
>       stephen.thomas@transnexus.com, markday@cisco.com
>Subject:  Re: distribution layer confusion
>
>
>
>I'm not sure it's a special case. Signaling is the "control" plane, while
>"replication" is the data plane. Signaling is supposed to be real-time,
>small amounts of data, while replication is typically bulk data and may be
>either preload or on-demand.
>
>My view, considering both request routing and content distribution, is
>this:
>
>content advertisement: like BGP
>          input="what content is where",
>          output="view of the content peers" & "routing table"
>
>request routing: like IP forwarding.
>          input="routing table" and a customer request,
>          output="where to go"
>
>content replication:
>          input="need what" and "view of the content peers"
>          output="where to get it" and go get it
>
>content signaling:
>          input="what content needs what updates"
>          output="content updated"
>
>Thanks!
>Dan
>
>At 10:49 PM 1/27/01 -0500, Kobus van der Merwe wrote:
> >Is content replication not a special case of content signaling as
> >you described it? Special because in addition to telling the CDN
> >about the content (i.e. expiration times, origin server etc), you want the
> >content to be replicated immediately. For example, in the streaming
> >CDN example you used you could conceivably only tell the CDN
> >where to obtain the media files from and then have it "replicated"
> >on-demand. (Unless of course the CDN is working in an exclusive
> >push model in which case you have to replicate it beforehand.)
> >
> >Kobus
> >
> >brad cain wrote:
> >
> > > 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
> > >
> > > 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.
> > >
> > > 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.
> >
>
>
>