Subject: comments on draft-mbelshe-httpbis-spdy-00

From: Eliot Lear <[email-masked]>
Date: Tue, 14 Aug 2012 16:35:06 +0200

I have a stack of comments and questions for the SPDY document.  This is
a taste of what needs to get done to get this document through the
standardization process.  Before I get to what's there, let me get to
what's not, first:

Most importantly, there needs to be clarity in the connection model, and
currently there is nothing.  The HTTP scheme implies use of port 80. 
What next?  Seems to me there are many choices:

1.  Try sending a 2.0 message and see what happens
2.  Wait for a response from the server that has the right version #
3.  Use some sort of DNS trickery to divine the appropriate version –
AND port.
4.  Go with a happy eyeballs approach and try BOTH 1.1 and 2.0
initially, perhaps with a slight delay on 1.1 with caching of state.

But we have to pick one.

Rinse and repeat for TLS, albeit the mechanism may be better advertised.

Speaking of advertising, it'd be nice if there was a capabilities
exchange.  SETTINGS sort of goes there but requires more round trips.

In Section 2.2.1:

With "Version" defined in Control frames, what are the semantics for a
mismatch?  Is an error generated?

There is discussion of a both a minimum and maximum frame size, but
there is no negotiation defined.

In Section 2.2.2:

Under "Data frame processing requirements", experience shows that it is
better to shut down a connection when the protocol goes awry, and no
more so is this the case than with multiplexed connections.

Section 2.3:

Nit: "Streams may be cancelled."  I think you meant closed.

2.3.1 (and elsewhere):

I think RST_STREAM should be removed in favor of dropping a connection
with an error when one side or the other just gets it wrong.  This is
not protocol school.  There should be enough diagnostics produced to
indicate what the problem is, and then go off.

2.3.2:

I don't know about anyone else, but first I laughed about the sentence
about streams not wrapping, and then I stopped, when I realized that
thus far we have stretched every possible HTTP parameter to its max, so
why not this too?  What I don't understand is why all the verbiage about
the ordering of streams in the first place.  What's the goal?  Again,
when sending protocol errors, best to shut down the connection afterwards.

This paragraph requires additional discussion:

>    Upon receipt of a SYN_STREAM, the recipient can reject the stream by
>    sending a stream error (Section 2.4.2) with the error code
>    REFUSED_STREAM.  Note, however, that the creating endpoint may have
>    already sent additional frames for that stream which cannot be
>    immediately stopped.

This means the sender MUST retain any data transmitted and accepted at
the TCP layer until the application sends "REFUSED_STREAM".

Finally a nit: do you really mean "monotonic" or do you mean "linearly"
or "in increments of two"?

Section 2.3.3:

Oh where to begin?  First of all, why not match nearly every other
network protocol out there, especially IP, and have at least the higher
value match higher priority?  But beyond this, experience shows that
stream priority behaviors have to be defined.  Also, once we have
streams some fool, quite possibly this one, will ask the question: and
is there a need for a mapping to DSCPs should someone try to tunnel IP
through one of these streams?

Section 2.3.6:

I like that in this particular instance you produce a specific error
STREAM_ALREADY_CLOSED where elsewhere you state a simple
PROTOCOL_ERROR.  However, in this case, since it *is* a protocol error,
as I've argued previously, the connection should be closed.

Section 2.4.1: This needs work.  You want to handle several different
types of errors:

1.  Protocol errors (shut down the connection and go away)
2.  Application errors (these are errors that occur above the framing
layer, but are NOT protocol errors).  An application error may be a
resource constraint, a permissions problem, or some other
application-layer error (e.g, "451 my boss is a jerk").

Each of these sorts of errors can happen at either the stream or session
level.  1 is easy: just shut down the connection.  2 is the one that
needs to be clarified, IMHO.  GOAWAY may not be the entirely correct
approach.  This is something that BEEP got right, IMHO.  There's a
pretty clean separation between the BEEP layer and the layer above.

Section 2.5: Huh?  What is the actual meaning of "intelligently" here?

Section 2.6.1: how do you derive the size for "slot"?  Also, this should
be reviewed by the TLS folks.  How does it relate to the
SETTINGS_CLIENT_CERTIFICATE_VECTOR_SIZE setting?

Section 2.6.3:

Why is there a CANCEL and also FLAG_FIN?

Error code 10: Invalid credentials.  Is this best left to "permission
denied" without getting into the reasons in the protocol (just log them).

Section 2.6.5:

If either side can send this, then a server is open to any number of
resource attacks, especially as regards to persistent settings.

Section 2.6.9 needs to be reworked with the assumption that TLS may not
be there at all.

Section 3.1: Connection management

You might want to amend this to allow clients to open an additional
connection once all stream values are used. 

Skipping along...

In Section 3.3:

What does it mean: "Browsers MUST implement throttles to protect against
unreasonable push attacks"?  How shall browsers throttle?  By delaying
response?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Aug 2012 12:24:57 -0400

HTTP 2.0 is an optimization. It does not need to work with maximum
efficiency everywhere.

Protocol negotiation should really be a DNS function. The DNS is the
Internet infrastructure for publishing assertions about names. That is
where the primary information describing the HTTP connection should be
stored.

The DNS does have some legacy deployment issues, but 95% of Internet
connections have a perfectly well behaved DNS connection. Proposing a
scheme that will not work for the remaining 5% is an obvious non
starter. Proposing a scheme that will not work quite as well for the
remaining 5% is an incentive to upgrade infrastructure.

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.

If we combine DNS protocol signalling with DNSSEC we can also address
the biggest security loophole in HTTP which is that every connection
is subject to a downgrade attack.

The way it might work is that the Web Server for example.com might
have the following records

! Advertise the service
_http2._tcp.example.com  SRV 1 1 443 www1.example.com
_http2._tcp.example.com  SRV 1 1 443 www2.example.com

! Describe the service
_http2._tcp.example.com DESC "tls=required certpath=MDIGA1UEJQYJ"
            "YIZIAWUDBAIBBCAXzJgPaoT7Fe"
            "XaPzKv6mI2D0yilif+7WhzmhMGLe/oBA=="

Since most DNS lookups are for a Web site, most DNS servers would be
tuned to return the SRV and DESC records as additional records in
response to an A record lookup as a matter of course.

One consequence of this approach is that an SRV record becomes an
application specific redirect for the HTTP protocol.

SRV already exists, we just need to decide to use it. At the moment we
have a security policy signalling mechanism being developed inband for
HTTP that should really be carried in the DNS so that it can be
wrapped by DNSSEC and so provide security on first connect.

There is also the proposed URI record which is similar to SRV but the
payload is a URI instead of a domain name. I believe that we should be
using URI records as the basis for Web service discovery. Probably in
conjunction with a .ws registry.

Further tricks that can be played with this approach is that the
client can be told it has the option of using a 'compression' or
'tokenization' function through a DNS description record.

Having written a few Web Services and recently having written a
compiler for them, I am less than excited at the prospect of
compressing HTTP headers when what follows is JSON or XML bloat. Using
LZ compression does not give me warm feelings either. What I really
want is a space reduction scheme that provides a better balance
between space and complexity. Something I can implement on a PIC
controller.

A simple way to implement such a scheme is to use a BER-like binary
format with a tag set defined by dictionaries that MAY be exchanged in
band or predefined as is most convenient for the application.

ASN.1 is a pig and BER is overly complex, but there is no rule that
says that a binary format has to have more than one way to do
something, nor is there any need to support canonincalization or to do
so in a way that is as idiotic as the DER rules.

A description option that allows the service to advertise the
compression dictionary version(s) it supports would enable space
saving to be supported simply and efficiently without introducing the
opaqueness that LZ type approaches inevitably do.

-- 
Website: http://hallambaker.com/

---

From: Patrick McManus <[email-masked]>
Date: Wed, 15 Aug 2012 09:00:02 -0400

> mechanism for use when the DNS records are blocked but that should be

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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Aug 2012 09:42:48 -0400

> upgrade/alternate-protocol over HTTP/1 as a slower fallback.

DNSSEC should be used if available but must not be a requirement.
HTTP2 will be doa if deployment of DNSSEC is a precondition.

Another problem with DNSSEC is deciding what a client should do when
the DNSSEC status is bad. If the answer is 'carry on anyway' then
there is very little value to DNSSEC. If the answer is 'stop' a lot of
stuff is going to break.

If people are going to propose using security, they need to come up
with a finite state machine that shows exactly how the client is
expected to behave on the available information and they have to use
the same FSM to address every use case. During the DKIM discussions we
had endless arguments when people suggested that the client address
corner case A by rejecting a message in a particular circumstance and
address corner case B by accepting it. I found that discussion
unhelpful.

That is why I am more interested in an architecture in which the
client does not attempt to use raw DNS data but may accept them
through some form of service which would curate the data. That does
not actually change the requirement for what needs to be stated in
HTTP or DNS, the service needs the same starting point information as
the client. But it does mean that corner cases can be left to the
service to cope with.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 15 Aug 2012 10:19:09 -0700

Can you elaborate how SRV would work here from a client perspective? Do you
propose making the client block on the SRV lookup? Or are you proposing
doing this out of band and switching to HTTP/2.0 if we discover support?

http://code.google.com/p/chromium/issues/detail?id=22423#c9 has some of our
thoughts on SRV in Chromium.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 15 Aug 2012 19:40:47 +0200

On 8/15/12 7:19 PM, William Chan (陈智昌) wrote:
> Can you elaborate how SRV would work here from a client perspective?
> Do you propose making the client block on the SRV lookup? Or are you
> proposing doing this out of band and switching to HTTP/2.0 if we
> discover support?

Block is the wrong word.  You're already doing A-Record queries.  Adding
another record in the question only adds latency if you must serially
query.  Also, I myself am not convinced that SRV records are sufficient
to the task.  For instance, what happens if there is a port # in the
URL?  How do you identify the version #? 

Paul Hoffman did some work on a draft that sort-of looked at this
problem.  I'm going to guess that he stopped short because of potential
downgrade attacks.

Eliot

---

From: Patrick McManus <[email-masked]>
Date: Wed, 15 Aug 2012 13:48:18 -0400

sorry - too much shorthand. This is for http:// urls of course..
https:// can just use npn on the A address.

race A and SRV queries.. make best practice to bundle SRV answers as
additional information in responses to A queries. Best experience
returns an A bundled with SRV. But if you get an A without a bundled SRV
then go ahead and use it immediately for HTTP/1 and allow a
upgrade/alternate-protocol to do the bootstrapping that less ideal way.

So its just an optimization.

On Wed, 2012-08-15 at 10:19 -0700, William Chan (陈智昌) wrote:
> http://code.google.com/p/chromium/issues/detail?id=22423#c9 has some
> of our thoughts on SRV in Chromium.
> 
> 
> 
> On Wed, Aug 15, 2012 at 6:00 AM, Patrick McManus
> <[email-masked]> wrote:

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Wed, 15 Aug 2012 10:56:31 -0700

In this scheme, perhaps you get a SRV record that tells you
example.comsupports HTTP/2.0. Great. Does HTTP/2.0 exist on port 80?
If so, although
you know the end target supports HTTP/2, you have no idea about whether
intermediaries support HTTP/2. If it's on a port other than 80/443 you can
presume that if you can establish a connection it will be to a
device/intermediary that understands HTTP/2, but experience shows we're
going to successfully be able to establish connections only ~80% of the
time. Perhaps we hope that firewalls adapt and open up whatever port gets
used, but that's stacking the deck against us already...

---

From: Patrick McManus <[email-masked]>
Date: Wed, 15 Aug 2012 14:13:24 -0400

On Wed, 2012-08-15 at 10:56 -0700, Ian Fette (イアンフェッティ) wrote:
> example.com supports HTTP/2.0. Great. 

I would think example.com would publish srv records that indicate they
speak service=http2-tls on port 443 which would be used to execute
http:// transactions.

It just cuts out, hopefully most/all the time, the
alternate-protocol-over-http-1-port-80 middleman we have now that
requires extra handshakes, less private communications, etc to get
bootstrapped.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 15 Aug 2012 11:23:38 -0700

I'm confused by this comment. My understanding is that multiple questions
per query does not work in practice. Also, how does the response work? If
the A record is cached, but the SRV record is uncached, does the server not
respond to the client until the SRV record comes back? Or does it stream
the records back somehow and have the client block on responses?

Patrick's explanation makes more sense to me.

On Wed, Aug 15, 2012 at 10:40 AM, Eliot Lear <[email-masked]> wrote:

> Can you elaborate how SRV would work here from a client perspective? Do
> you propose making the client block on the SRV lookup? Or are you proposing
> query.  Also, I myself am not convinced that SRV records are sufficient to
> the task.  For instance, what happens if there is a port # in the URL?  How
> do you identify the version #?
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 15 Aug 2012 20:41:36 +0200

Patrick's idea is the happy eyeballs approach (see related work on IPv6
by Dan Wing et al).  You're right, tho, that you probably can't do it in
a single packet, but multiple rapid fired.  That solves the issue you
raise below.

Eliot

On 8/15/12 8:23 PM, William Chan (陈智昌) wrote:
> I'm confused by this comment. My understanding is that multiple
> questions per query does not work in practice. Also, how does the
> response work? If the A record is cached, but the SRV record is
> uncached, does the server not respond to the client until the SRV
> record comes back? Or does it stream the records back somehow and have
> the client block on responses?
>
> On Wed, Aug 15, 2012 at 10:40 AM, Eliot Lear <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>>     Can you elaborate how SRV would work here from a client
>>     perspective? Do you propose making the client block on the SRV
>>     lookup? Or are you proposing doing this out of band and switching
>>     to HTTP/2.0 if we discover support?
>
>     Block is the wrong word.  You're already doing A-Record queries. 
>     Adding another record in the question only adds latency if you
>     must serially query.  Also, I myself am not convinced that SRV
>     records are sufficient to the task.  For instance, what happens if
>     there is a port # in the URL?  How do you identify the version #? 
>
>     problem.  I'm going to guess that he stopped short because of
>     potential downgrade attacks.
>
>     Eliot
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Aug 2012 15:12:38 -0400

It is not necessarily even a separate query.

DNS has these things called 'additional records'. When you do an
A-record lookup you typically get back a lot more than the A-record.

You can also fire off the A-record and SRV record queries in parallel
and then wait for both to arrive. This is what is almost always done
for IPv6.

Another approach is soft caching. DNS records have a set TTL of course
and that has to be respected as far as the semantics of DNS go. But a
client is entirely in their rights to use stale DNS data to inform
optimizations. Roughly 80% of my Web browsing involves a small set of
sites I visit every day. An even larger fraction are sites I visit
every week. It is really not a problem to do a combi A/SRV lookup the
first time and then remember how the site was configured for future
reference. Then when you make the next request you choose the strategy
most likely to be optimal based on past behavior.

On Wed, Aug 15, 2012 at 1:40 PM, Eliot Lear <[email-masked]> wrote:
> another record in the question only adds latency if you must serially query.
> Also, I myself am not convinced that SRV records are sufficient to the task.
> For instance, what happens if there is a port # in the URL?  How do you
> identify the version #?
>
> Paul Hoffman did some work on a draft that sort-of looked at this problem.
> I'm going to guess that he stopped short because of potential downgrade
> attacks.
>
> Eliot

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 15 Aug 2012 23:40:52 +0000

------ Original Message ------
From: "Patrick McManus" <[email-masked]>
>returns an A bundled with SRV.
>
problem with this, is that now you need to wait for your DNS server 
vendor to give you a new DNS server you can use to do this.

I think making an additional requirement to deploy a new DNS server 
will be a bit of a show-stopper.

I think it would be easier to just request both, and wait for both 
responses.  That's if we decide SRV is the way to go.

But like Elliot, I'm not convinced SRV is right for this problem.  It 
provides a port number and a weight.  There may be some use for the 
weight, but the port number is problematic, since we're talking about 
using 80/443.  Which port number is used?  What if the URL contains a 
port number etc?

Maybe it would be simpler to just do an optimistic A record lookup.  
E.g. prepend some well-known token, such as 

_http2.www.example.org.

if you get a record back, you know it supports http 2.  If you don't 
you just look up www.example.org.  these 2 requests can be fired off in 
parallel.

That makes it a lot easier to deploy on the server and client side as 
well, since the domain operator only needs to publish additional A 
records, and client doesn't need to do SRV lookups.

I'm pretty sure most people will hate that idea though.

Adrien

>But if you get an A without a bundled SRV

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 15 Aug 2012 23:42:48 +0000

whether or not intermediaries support 2.0, if it's server-side 
intermediaries (accelerators and reverse proxies), then you can rely on 
the site operator to sort it out.

If it's client-side, the proxy either supports 2.0 or it doesn't, and 
some deterministic (OOB) way for the proxy to determine whether a 
server supports 2.0 could be really useful.

If it's some other sort of intermediary, then.... if it's to be truly 
transparent, it will need to be updated to handle 2.0.

Adrien

------ Original Message ------
From: "Ian Fette (イアンフェッティ)" <[email-masked]>
To: "Patrick McManus" <[email-masked]>
Cc: "William Chan (陈智昌)" <[email-masked]>;"Phillip Hallam-Baker" 
<[email-masked]>;"[email-masked] Group" <[email-masked]>
Sent: 16/08/2012 5:56:31 a.m.
Subject: Re: comments on draft-mbelshe-httpbis-spdy-00
>In this scheme, perhaps you get a SRV record that tells you example.com supports HTTP/2.0. Great. Does HTTP/2.0 exist on port 80? 
>If so, although you know the end target supports HTTP/2, you have no 
>idea about whether intermediaries support HTTP/2. If it's on a port 
>other than 80/443 you can presume that if you can establish a 
>connection it will be to a device/intermediary that understands 
>HTTP/2, but experience shows we're going to successfully be able to 
>establish connections only ~80% of the time. Perhaps we hope that 
>firewalls adapt and open up whatever port gets used, but that's 
>stacking the deck against us already...
>
>On Wed, Aug 15, 2012 at 10:48 AM, Patrick McManus <[email-masked]> wrote:
> >         > HTTP/2.0 should be some form of statement in a DNS record 
> to
> >         tell the
> >         > mechanism for use when the DNS records are blocked but 
> that
> >         should be
> >         > a fallback.
> >
> >

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Aug 2012 19:50:00 -0400

As a general principle I suggest:

* HTTP/2.0 discovery MUST be at least as good at establishing a
connection as the current protocol in every network situation
including cases where access is restricted by intermediaries and the
server only supports HTTP/1.1 or 1.0.

* HTTP/2.0 SHOULD be at least as fast in the overwhelming majority of
cases but MAY be less performant in corner case situations, provided
the performance penalty is not too great.

We are NOT going for Pareto optimal here. It is quite OK for some
connections to be slower, provided that this is not a constant issue.

On Wed, Aug 15, 2012 at 7:40 PM, Adrien W. de Croy <[email-masked]> wrote:
> problem with this, is that now you need to wait for your DNS server vendor
> to give you a new DNS server you can use to do this.
>
> I think making an additional requirement to deploy a new DNS server will be
> a bit of a show-stopper.
>
> provides a port number and a weight.  There may be some use for the weight,
> but the port number is problematic, since we're talking about using 80/443.
> Which port number is used?  What if the URL contains a port number etc?
>
> Maybe it would be simpler to just do an optimistic A record lookup.  E.g.
> prepend some well-known token, such as
> _http2.www.example.org.
>
> if you get a record back, you know it supports http 2.  If you don't you
> just look up www.example.org.  these 2 requests can be fired off in
> parallel.
>
> That makes it a lot easier to deploy on the server and client side as well,
> since the domain operator only needs to publish additional A records, and
> client doesn't need to do SRV lookups.
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 15 Aug 2012 21:50:10 -0700

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. Adding more DNS
lookups per hostname will further exacerbate the problem.

In any case, FWIW, I hope websites simply transition to https:// URIs
instead :)

---

From: Eliot Lear <[email-masked]>
Date: Thu, 16 Aug 2012 15:10:00 +0200

On 8/16/12 6:50 AM, William Chan (陈智昌) wrote:
> 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. Adding more DNS lookups per hostname will
> further exacerbate the problem.

And whatever mechanism is used has to work with the http: schema, which
includes a port.

Eliot

---

From: Patrick McManus <[email-masked]>
Date: Thu, 16 Aug 2012 09:17:47 -0400

On Wed, 2012-08-15 at 21:50 -0700, William Chan (陈智昌) wrote:
> Alternate-Protocol response header?

bootstrapping with a-p on http/1 means that while you're making the
http/2 connection you're using http/1 (or waiting idly). Obviously, we
want to be using http/2 (or we wouldn't be having the FUN FUN FUN of
this whole project) so this is suboptimal. That seems kind of self
evident. Doing the direction with DNS addresses that.

This is no doubt unavoidable in a bunch of scenarios - and people won't
setup non-{a,aaaa} records in droves out of the gate. But if we give
better performance with a srv record than without one, then that will
become a driver for seeing them deployed.

>  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. Adding more DNS

I know you guys see more problems with that than we do - and I certainly
acknowledge that the difference might just be that you have better
visibility into it. Hard to know if its insurmountable at this point.
But given the racy nature of what we're talking about - what to do
might be more of an implementation choice than anything else.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Aug 2012 09:47:28 -0400

The advantage of SRV is that is supports multiple hosted services
properly and eliminates the need for hacks like round robin DNS. It
also allows the port number to be specified separately for each
service. This allows two instances of a service on the same host which
is nice for testing.

If we are doing HTTP2 for performance we should support load balancing
and fault tolerance which is what SRV is for.

I suggest:

* If the URL specifies only the host name, use SRV lookup for _http2
first. If it is found, use http2.0

* if the URL specifies a port then use http/1.1

For testing purposes, it may be convenient to have a http2: scheme so
that the SRV thing can be separated from the protocol upgrade. In fact
that might be useful for signaling anyway..

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 16 Aug 2012 22:21:14 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> William Chan (???)
> Sent: Wednesday, August 15, 2012 9:50 PM
> To: Patrick McManus
> Cc: Phillip Hallam-Baker; [email-masked] Group
> 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).  

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

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.  

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.

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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 17 Aug 2012 17:44:37 -0400

> queries.  When the host supports IPv6, you'll have to drop that to 3

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

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.

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

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 17 Aug 2012 16:55:51 -0700

> Sent: Friday, August 17, 2012 2:45 PM
> To: Dan Wing
> Cc: William Chan (陈智昌); Patrick McManus; Phillip Hallam-Baker; ietf-
> [email-masked]
> Subject: frequent DNS queries RE: comments on draft-mbelshe-httpbis-
> spdy-00
> 
> 
> 
> already
> 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. 

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

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

> 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

> 	>       > 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
> 	>       This is my current thinking as well though I'm not tied
> to it..
> 	> srv in