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

> -----Original Message-----
> From: willchan@google.com [mailto:willchan@google.com] On Behalf Of
> William Chan (???)
> Sent: Friday, August 17, 2012 2:45 PM
> To: Dan Wing
> Cc: William Chan (³ÂÖDzý); Patrick McManus; Phillip Hallam-Baker; ietf-
> http-wg@w3.org
> Subject: 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.

You missed my point, which is that if the application is currently
pacing getaddrinfo() to 6 outstanding requests, that will cause
6 A queries on an IPv4-only host, and will cause 12 queries on an
dual-stack host.  If the underlying problem is the CPE, which 
can only handle 6 outstanding queries, the pacing will need to
be adjusted to accommodate the doubling of DNS queries on a dual-
stack host. 

> 	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.

NAT routers are upgraded all the time -- equipment fails, users
add IPv6, users add 802.11n, or simply a faster model to deal with
their FIOS speeds.


> 	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.

Yes, I would be interested in knowing the devices causing the problem.
If they are 10 year old NATs, it isn't terribly interesting.  If they
are modern NATs, we have a real problem that the industry needs to 
fix.


> 
> 	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.

It may also point to a need to do DNS differently, such as with a 
long-lived TCP connection to the DNS server with a clear standard
for sending multiple queries over that TCP connection.  Because,
as you point out, we may well be stuck with deficient NAT gear.

-d



> 
> 	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.
> 	>
> 	>
> 	>
> 	>
> 	>
> 	>
> 
> 
>

Received on Friday, 17 August 2012 23:56:20 UTC