Query re request Routing

[Steve Rudkin <srudkin@jungle.bt.co.uk>]

Comments below

Steve

>From: owner-cdn@ops.ietf.org [mailto:owner-cdn@ops.ietf.org]On Behalf Of
>Tomlinson, Gary
>Sent: 06 March 2001 19:47
>To: Phil Rzewski; Steve Rudkin
>Cc: cdn@ops.ietf.org
>Subject: RE: Query re request routing
>
>...
>
>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.  

Maybe. If we follow this line it suggests that distribution and or
accounting peering necessitates some level of request routing peering. See
below.

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.  

I agree with this if we accept your initial statement.
>
>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.
>

I see at least two ways of  bypassing the Authoritative RRS:

a) The ACN does peer RRSs, but the authoritative RRS has delegated routing
decisions to the ACN's RRS for any request from the ACN's subscribers
b)The ACN does not peer Request Routing Systems.

This brings me to Eric's question. I originally wrote:
>> > >>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 internconnect RRS.
Eric wrote:
>Just because there is a single authoritative RRS for each request does not
>mean that RRSs should not interact. I need to understand, via some sort of
>interaction, why I should route content requests to a peered network. 

I will try to comment on this, by considering the implications for
authoritative RRSs in cases a  and b.

In case a) the ACN has received delegated authority or has seized authority
(depending on how you look at it) to locally route requests from its own
subscribers. To summarise this case we require that the ACN peers RRSs,
there remains a single authoritative RRS, but it can handover authority with
respect to certain requests to other RRSs.
In case b), with respect to any given content unit there are separate
islands of peered RRSs. Each island has an authoritative RRS. Note that
separate RRS islands may be peered in terms of distribution and accounting.
So each content unit may have multiple authoritative RRSs. 

The question to answer then is: should distribution and/or accounting
peering necessitate a basic level of request routing peering (namely the
ability to handover authority to route certain requests for given content
units)?

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

Just to check my understanding... In this case there is no Distribution,
Accounting or Request Routing peering between the ACN and other parties.

>
>Gary
>
BTexaCT,                                       Email: srudkin@jungle.bt.co.uk
Adastral Park,                                 Tel: +44 1473 640886
Martlesham Heath, IPSWICH, IP5 3RE, UK         Fax: +44 1473 640929