Re: distribution layer confusion

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

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