Re: [alto] ALTO and Content Delivery Networks

[Jiang Zhu <[e-mail]>]

Hi, Nicholas and Reinaldo,

DNS redirect is very limited because the DNS server only got the host
portion of the whole URL. Sometimes, in order to redirect to the right
destination, the full FQDN will be needed. For example,
www.abc.com/foo.mov will be redirected to
cdn.west.comcast.com/abc.com/qt/foo.mov while
www.abc.com/bar.wmv will be redirected to
cdn.east.comcast.com/abc.com/wmv/bar.wmv.

Also, in most of browser implementation, the redirected URLs are not visible
to the end users, thus I don't think the issue Nicholas mentioned may be a
problem. On the contrary, it has been usual practice to use 302 redirects to
load balance the HTTP requests to different web servers. The 302 redirect is
part of the HTTP transaction and the bookmarks should remain as the original
URL.

Thanks

-Jiang

On Tue, Jun 15, 2010 at 8:12 PM, Reinaldo Penno <[e-mail]> wrote:

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