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

Re: distribution layer confusion



I agree that signaling is control plane and replication is data plane.
However, the protocol used to negotiate what needs to be replicated (as per
Brad's email) looks like signaling to me, which is then followed by the
actual replication (i.e. data plane transfer). And this signaling will look
similar to the content signaling described later on in Brad's email. (Except
that in his second example the signaling was not followed by an immediate
data transfer.) So with special case I refered to the signaling protocol
which I think is required in both examples.

Kobus

Dan Li wrote:

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