Subject: HTTP redirect (was Re: [dnsext] client-subnet - questions for the authors, and outside-the-box brainstorming)

From: Brian Dickson <[email-masked]>
Date: Wed, 2 Jun 2010 12:26:42 -0300

(Guys - please don't hijack other peoples threads, i.e. discussing
tangential issues without changing the Subject: line)

2010/6/2 Masataka Ohta <[email-masked]>

> Nicholas Weaver wrote:
>
> >> But, the reality is that initial several RTTs are acceptable.
> >
> > They are not, because if they were, people would be using
> > HTTP redirects if they were.  They aren't.
>
> The reality is that they are, because:
>
> >> If initial RTTs were the problem, never use DNS for extra several
> >> RTTs. Instead, use:
> >>
> >>      http://273.51.152.23/URL
>
> As you can see, such URLs are not used very often.
>
> > An HTTP redirect, even excluding the DNS transfer, is uncacheable,
> > uncached,
>
> Cache?
>
> As cache is not helpful to reduce latency for the initial query,
> we have agreed that initial RTTs are not a problem.
>
> Or, are you just asking for something impossible?
>
> >> If you use "www.yahoo.com", you'll see a lot of "a.l.yimg.com"
> >> etc. used.
> >>
> >> Try it to see the reality of HTTP.
> >
> > These are NOT externally visible URLs to the title bar,
>
> They are visible at the status bar, which is why I noticed "yimg".
>
> > The reality of HTTP is that 302 redirects are a far inferior
> > solution to minimizing latency compared with the stupid DNS tricks.
>
> Though I have been considering 300, feel free to use 302. Or, you
> may modify HTTP. They are minor implementation issues of HTTP.
>
> Anyway, initial RTTs are not a problem, especially because use of
> open resolvers increases RTTs.
>
> Shorter RTTs may be useful for large contents, because shorter RTTs
> often mean less backbone load.
>
> Thus, HTTP redirect just works.
>
>                                        Masataka Ohta
>