[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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