Re: [alto] ALTO and Content Delivery Networks

Hello Nicholas,

Your feedback is greatly appreciated. I will incorporate your points in the
HTTP redirection section.

Originally our intention with 302 was targeted at streaming services. For
example, you visit YouTube and when you click on a Video Link you get 302
for the video alone (i.e., a single object). I think this needs to be
clarified.

I agree that a common use case going forward is where the DNS server queries
an ALTO Server. This is captured in sections 6.1 and 6.3. I believe they
need revisions for further clarification

> This would also allow the easy use of the mechanism to any OTHER latency
> sensitive application, eg, choice of VPN tunnel endpoint, etc.

This is a good point.

Thanks.

Reinaldo

On 6/4/10 9:44 AM, "Nicholas Weaver" <nweaver@ICSI.Berkeley.EDU> wrote:

> Unforutately on the use-case, 302 redirections are often regarded as
> significantly inferior to DNS-based redirection for CDNs...
> 
> HTTP redirections add latency, but thats not the big problem.
> 
> 
> The big problem with a 302 or similar HTTP redirection is HTTP redirection to
> a different IP will require a different hostname.
> 
> Thus for top level pages, user-visible URLs would become something like
> a235.www.mydomain.com, rather than www.mydomain.com, which pollutes bookmarks
> and reduces user experience.
> 
> 
> Yet for the "invisible" items within a page (eg, images loaded from
> img.mydomain.com), which actually compose the bulk of the items and latency,
> there is no redirection mechanism that says "all items from host
> img.mydomain.com should be instead fetched from a251.img.mydomain.com".
> 
> Thus instead this would require that the HTTP server dynamically rewrite all
> references to img.mydomain.com to be a251.img.mydomain.com, because
> redirecting individual components will eliminate the latency gains which most
> CDNs are concerned with.  (100ms better latency to the web server can easily
> translate to 1s or more improvements in page-load time since most browsers do
> NOT pipeline HTTP requests, making the process of fetching many small images a
> latency, not bandwidth limited, activity).
> 
> 
> Thus in either case, having the ALTO service be queried for HTTP redirection
> is probably not a happy solution for CDN applications where latency is a
> concern, not because of ALTO's limitations but because of the limitations of
> HTTP's redirection semantics and/or the need to do page rewriting.
> 
> To do the latency-centric CDN-type redirections cleanly in HTTP REQUIRES one
> of two NEW redirection semantics for HTTP (and therefore corresponding support
> in ALL browsers):
> 
> 1)  "For current HOST, contact system Y", basically overriding the DNS lookup
> 
> 2)  "For URL prefix X, rewrite the prefix as Y", basically providing a custom
> rewrite rule to the browser.
> 
> 
> 
> Rather, what would be better is a mapping from DNS IP (or EDNS-client-subnet
> if/when that gets deployed by 3rd party resolvers) -> probable host PID.  Thus
> rather than the HTTP server querying ALTO, it is the DNS authority servers for
> a domain that need to use ALTO, and therefore also need some rough mapping
> from DNS IP address to client IP region within ALTO.
> 
> This would also allow the easy use of the mechanism to any OTHER latency
> sensitive application, eg, choice of VPN tunnel endpoint, etc.
> 
> 
> Yes, Paul Vixie and some others in the DNS community would SERIOUSLY object,
> but as this is effectively established practice already (its how almost all
> major CDN's operate), if ALTO is to be useful to new CDN-type systems, it
> should integrate into the mechanisms that CDNs actually are able to use.
> 
> 
> 
> 
> 
> On Jun 4, 2010, at 9:09 AM, Reinaldo Penno wrote:
> 
>> We posted a new Internet Draft on ALTO and CDNs
>> 
>> http://www.ietf.org/id/draft-penno-alto-cdn-00.txt
>> 
>> Regards,
>> 
>> Reinaldo
>> 
>> _______________________________________________
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
> 