frequent DNS queries RE: comments on draft-mbelshe-httpbis-spdy-00

On Thursday, August 16, 2012, Dan Wing wrote:

> > -----Original Message-----
> > From: willchan@google.com [mailto:willchan@google.com] On Behalf Of
> > William Chan (???)
> > Sent: Wednesday, August 15, 2012 9:50 PM
> > To: Patrick McManus
> > Cc: Phillip Hallam-Baker; ietf-http-wg@w3.org Group
> > Subject: Re: comments on draft-mbelshe-httpbis-spdy-00
> >
> > Can you clarify the reason to prefer srv over something like an
> > Alternate-Protocol response header? I can see that Alternate-Protocol
> > is suboptimal in that it requires waiting for a response first, but I
> > have concerns about adding yet another DNS lookup. Chromium has already
> > lowered our concurrent getaddrinfo() calls to 6 due to problems with
> > home routers not being able to handle too many concurrent DNS queries.
>
> I've heard of that problem.  I am guessing most of those problems are
> on IPv4-only hosts, so the underlying DNS code is generating 6 DNS
> queries.  When the host supports IPv6, you'll have to drop that to 3
> (A and AAAA queries).


Actually, not totally true. Most getaddrinfo() implementations will issue
the A and AAAA queries in serial =/ but yes, newer OSes are starting to
issue them in parallel (OS X Lion for example). And there is no evidence
the problem is with IPv4 only hosts.


>
> Or, do we hope to identify the problem and encourage vendors to fix
> it?


Long term, yes. Short term, we can't upgrade the existing deployment of NAT
routers, so we're stuck for now and clients will make the best trade offs
possible to improve user experience.


>
> In the past, ICE (RFC5245) ran into similar problems which seemed to
> be caused by rapidly sending UDP packets from different source
> addresses, which forces a NAT to create a new mapping.  Some NATs
> apparently can't do that very quickly.
>
> With many (but not all) NATs configured to do local DNS proxying,
> the problem may not be too severe.  But I understand cable operators
> don't like DNS proxying in CPE, which we may have exchanged for
> dropping rapid-fire DNS queries instead.  That would not be good.
>
> We tested some of our Linksys gear a week ago, after a discussion
> at IETF, and couldn't repeat the problem.  So, I would sure like
> to understand it better and try to see where things break and
> what configuration is causing this problem.


We have many Chromium bug reports for this. If you're interested in
studying some of the devices, I can gather a list of busted ones and send
them your way. We're working on getting a lab of these devices for our own
testing purposes.


>
> Then we can figure out if the best workaround is in the getaddrinfo()
> code, in the application, or elsewhere.  But I would rather solve
> the problem, especially for something as critical as DNS queries.


Yes, by all means, we should solve it. I'm just pointing out relevant
concerns with reliance on DNS in the short-term.


>
> DNSSEC, DANE, and IPv6 being hopefully around the corner, we need
> to fix problems with DNS queries and keep DNS working fast.
>
> -d
>
>
> > Adding more DNS lookups per hostname will further exacerbate the
> > problem.
> >
> > In any case, FWIW, I hope websites simply transition to https:// URIs
> > instead :)
> >
> >
> > On Wed, Aug 15, 2012 at 6:00 AM, Patrick McManus <pmcmanus@mozilla.com>
> > wrote:
> >
> >
> >       On Tue, 2012-08-14 at 12:24 -0400, Phillip Hallam-Baker wrote:
> >
> >       > If we take architecture seriously, the primary signaling
> > mechanism for
> >       > HTTP/2.0 should be some form of statement in a DNS record to
> > tell the
> >       > client 'I do HTTP 2.0'. We might also have some sort of upgrade
> >       > mechanism for use when the DNS records are blocked but that
> > should be
> >       > a fallback.
> >
> >
> >       This is my current thinking as well though I'm not tied to it..
> > srv in
> >       the base case (with the possibility of dnssec) and something like
> >       upgrade/alternate-protocol over HTTP/1 as a slower fallback.
> >
> >
> >
> >
> >
> >
>
>
>