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