[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Query re request routing
Since I'm the one that has been keeping this thread alive, let me say, for
the record, that I totally agree with everything you just said. :)
--
Phil
At 11:46 AM 3/6/01 -0800, you wrote:
>On Monday, March 05, 2001 @3:57 PM Phil Rzewski wrote:
>
> >At 09:00 AM 3/5/01 +0000, Steve Rudkin wrote:
> >> [Omitted text]
> >>Whilst there is a need to interconnect distribution systems of the source
> >>and destination CDNs (and any intermediaries) and to do the same for
> >>accounting systems, is it necessary for the RRS of the destination CDN to
> >>interact with other RRSs? If so, why? If not, should the statement that
> >>there is a single authoritative RRS for each *content unit* be
> >>modified/qualified in some way. Would it be better to say there is a
>single
> >>authoritative RRS for each *request* ?
>
> >I agree with this distinction. It's one of the types of things I am trying
> >to capture in Scenarios by enumerating something called an "Access Content
> >Network" (ACN).
>
> >[Omitted text]
>
> >There's still plenty of room for the CDI model we've worked with up until
> >today (that the Authoritative Request-Routing system, near the publisher,
> >has ultimate control). That's because there's going to be plenty of
> >Internet "edge" that won't be covered by avatars, but will be covered by
> >CDNs. There might be two CDNs with surrogates in that neighborhood, it's
> >just a case of choosing the "best" at that moment.
>
>I need to clarify and reaffirm the requirement "Single AUTHORITATIVE
>REQUEST-
>ROUTING SYSTEM for PUBLISHER object URI name space". What this means, is
>there
>only one authoritative party for the URI name space containing objects being
>distributed. All Content Networks in the distribution chain MUST have
>authority to operate on the name space granted to them by this AUTHORITATIVE
>REQUEST-ROUTING SYSTEM. The granting of this authority is done via
>delegation, which can be done either on-line via protocols or off-line via
>SLAs or something contractually equivalent. For the ACN model, in order for
>ACN network elements to participate in the REQUEST-ROUTING SYSTEM, the ACN
>must have received this delegated authority.
>
>That said, there are a couple of cases that come to mind here;
>1) ACN delivers the content acting as a SURROGATE;
>In this model, the ACN is peering {DISTRIBUTION & ACCOUNTING} with one or
>more CDNs to extend the reach to its own SURROGATES. Since is a priori
>knows that it will be delivering from one of its own SURROGATES, it can
>bypass the AUTHROITATIVE REQUEST-ROUTING SYSTEM and use its own internal
>mechanisms to select the correct SURROGATE.
>
>2) ACN delivers the CONTENT acting as a AVATAR;
>In this model, the ACN is not peering with any CDN and simply providing
>AVATAR services to its CLIENTS. What this means is, the AVATARs are acting
>as caching proxies, outside the transitive administrative domain scope of
>ORIGINs and thus are not authorized to act in behalf of ORIGINs; which is to
>say, they are not within the CDN distribution boundary. Thus, the AVATARs
>assume the CLIENT role as proxies and MUST use the AUTHORITATIVE
>REQUEST-ROUTING SYSTEM to select the correct CDN SURROGATE for delivery of
>content to the AVATAR. Logically, the distribution from the ORIGINs point
>of view has terminated at the SURROGATE and delivery has been performed to
>the AVATAR acting as a CLIENT.
>
>Gary
--
Phil Rzewski - Senior Architect - Inktomi Corporation
650-653-2487 (office) - 650-303-3790 (cell) - 650-653-1848 (fax)