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 > [email protected] > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
