RE: Query re request routing

["Phil Rzewski" <philr@inktomi.com>]

At 04:17 PM 3/5/01 -0800, Reinaldo Penno wrote:
>Hi Phil,
>
>I disagree that the first hop will always the owned by the ACN. The first
>hop might be within the ACN premisses, but not owned but the ACN. Or the
>first hop might not even be within the ACN premisses. I have seen examples
>where the ISP forbids the ACN do perform caching on their content by
>contract. The first hop in this example must be a cache within the ISP
>premises.

I'll take this as an indication that I should be clearer in the draft, but 
really, what I was hoping to get across is just that: An ACN is, by 
definition, a Content Network that owns that first "content hop". The first 
hop does not HAVE to always be owned by an ACN, but if a single party 
always owns a given client's first content hop, that party is (by my 
definition) an ACN.

I am inventing "content hop" as a rough term for this discussion, but if 
we're going to speak of an overlay "content layer", I think it's 
appropriate. For the purposes of whatever application I am using (HTTP, 
RTSP, etc.) the first "content hop" is the first device (avatar, surrogate, 
etc.) that I communicate with in that application-layer protocol. So if my 
browser is configured to point at an HTTP proxy, that HTTP proxy is my 
first content hop. If my ISP is doing interception, the avatar they direct 
me to is my first content hop. If there's no explicit or interception 
proxy, but a CDN Request-Routing system directs me to a nearby surrogate, 
that surrogate is my first content hop. If there's no proxy, avatar, or 
surrogate, the origin server is my first content hop.

In an attempt to be clear, I'll name names. I am an @Home cable modem 
subscriber. They have HTTP proxies in every cable head end. When they 
signed me up as a new subscriber, they gave me the IP address of the 
caching proxy in my local head end so they could own my first content hop 
for HTTP. If they enable their caching proxies for CDI, they effectively 
become an Access Content Network for their users who point at them (they 
assume all their customers do, since installers typically modify client 
browser configs when they install the modems). If you choose not to point 
at the proxies, then a nearby CDN surrogate may be your first content hop, 
but only when you're accessing sites that are affiliated with that CDN. 
That the difference in a nutshell: As my ACN for HTTP, @Home delivers all 
HTTP content to me from that local avatar. As far as I can tell, no CDN can 
technically stop that from happening.

>In other words, in a brodband access network if you are a subscriber of ISP
>A, you will redirected to ISP A surrogates, midia caches and application
>server sitting or not within the ACN premises or to a set of caches owned by
>the ACN and shared by all ISPs and ASPs.

I guess this is a reason why it's important to get terminology straight, 
and I hope I'm not making things worse by trying to introduce these new 
terms. I think I see the point you're trying to make. If by "broadband 
access network" you're thinking of someone like a DSL provider that is 
mapping layer 2 VCs into various layer 3 ISPs, then sure, each ISP may very 
well have their own avatars. By my definition, those ISPs are therefore 
ACNs. If the word "Access" in ACN is a bad word because it makes people 
think more of the layer 2/3 mappings such as for DSL, then I need to make a 
new term.

>regards,
>
>Reinaldo
>
>
>-----Original Message-----
>From: owner-cdn@ops.ietf.org [mailto:owner-cdn@ops.ietf.org]On Behalf Of
>Phil Rzewski
>Sent: Monday, March 05, 2001 3:57 PM
>To: Steve Rudkin
>Cc: cdn@ops.ietf.org
>Subject: Re: Query re request routing
>
>In summary, the ACN is doing some form of "edge caching" for their user
>base today, and they're going to keep doing it. Since that "first content
>hop" is always going to be owned by that ACN, that will always be a
>potential bottleneck to the user experience (though it won't be if the ACN
>does their job). So the publisher might as well accept that fact and
>leverage the fact that it's there (make the most out of it: leverage it for
>distribution, milk it for accounting data).
>
>
>
>--
>Phil Rzewski - Senior Architect - Inktomi Corporation
>650-653-2487 (office) - 650-303-3790 (cell) - 650-653-1848 (fax)

--
Phil Rzewski - Senior Architect - Inktomi Corporation
650-653-2487 (office) - 650-303-3790 (cell) - 650-653-1848 (fax)