Re: issue 381: Discovery of the support of the HTTP2 protocol: DNS-based Upgrade

On 28/02/2014 10:52 a.m., Josh Goodall wrote:
> On 28 Feb 2014, at 6:34 am, William Chan (ι™ˆζ™Ίζ˜Œ) <willchan@chromium.org> wrote:
>> It'd be curious to see which client would respect this MUST and the preference ordering you described.
> 
> The game-theoretic view of browser competition was an illuminating
> unpack, thank you. It especially applies in the case where a user
> has an unreliable connection and/or ISP DNS resolver. Then they
> will choose a browser that minimises the pain. So browser vendors
> will implement for that. I get it.
> 
>> Note that none of what I've said necessarily applies to optionally doing SRV and using it when the results are available. It's mostly the MUST requirement and the serial behavior you've outlined that looks troubling from an actual deployment viewpoint. 
> 
> Logically - this is similar but faster than serial and safer/more
> deterministic than the current lookup race - how about allowing a
> parallel query (as a MAY) but requiring the SRV (or SVCINFO) answer
> to be NXDOMAIN before proceeding to use address records?



Squid has for the past year or so been using pretty much this algorithm
of parallel queries with a response barrier to reduce latency over the
IPv6 rollout. In our case the response barrier is having both A and AAAA
back instead of a SRV response.

For overall latency reduction and the common case it has been a great
benefit compared to serial lookups.

However, we are still facing complaints that for some URLs a whole
timeout span (seconds/minutes) is waited for even though one of the
results has been returned in a few ms. This has been directly tracked
down to DNS resolvers simply not responding to one query out of the
pair. Usually the IPv6 response from broken DNS resolvers.

In practice the barrier waiting makes this algorithm *worse* in
performance than the happy-eyeballs algorthim for the case where the
timing difference of lookups matters most.


Of course that is not going to be the whole story for your proposal
since the overhead latency from determining HTTP version is also varying
between each query type.


/2c
Amos

Received on Friday, 28 February 2014 06:46:47 UTC