Re: [Doh] [Ext] DNS over HTTP/3?

[Paul Hoffman <[e-mail]>]

On Nov 19, 2018, at 7:12 AM, bert hubert <[e-mail]> wrote:
> 
> On Mon, Nov 19, 2018 at 02:12:18PM +0000, Paul Hoffman wrote:
>>> I've observed that the thousands of users of doh.powerdns.org (I also do not
>>> know how this happened) take around 22 packets per DNS query/response. 
>> 
>> It would be valuable to know if this is this because your DoH server kills
>> the entire connection after every DNS query, or because the clients are
>> doing so.
> 
> It does around 2 DNS queries per HTTPS connection on average dnsdist-doh
> keeps open an HTTP/2 connection for 10 seconds if it becomes idle.

Thanks, that seems to be your problem. Can the dnsdist DoH server package be configured to have an idle timeout that is more representative of typical browser use, such as on the order of minutes?

>>> Larger scale adoption of TLSv1.3 might improve this somewhat, but it is a
>>> big number.
>> 
>> DoH was designed for long-lived connections, so the number would normally be smaller after the initial connection.
> 
> I can only report what I measure based on several thousands of users.
> 
>>> I've also personally observed that a "slightly suboptimal" network
>>> absolutely kills browsing performance in Firefox Nightly using DoH.  A naive
>>> calculation shows that 0.5% packet loss turns into a 5% failure rate per DoH
>>> query, which then can cause Head of Line blocking for further queries, which
>>> cascades into "blank pages" getting rendered. 
>> 
>> When you say "naive calculation", do you mean this is observed in the
>> clients hitting your DoH server?  That would indeed be scary.  However,
>> the Mozilla numbers tell a very different story.  It would be good to know
>> which one is true.
> 
> My personal observation is that on a slightly bad network, turning off DoH
> speeds up things massively and makes the web useable again.  This naively
> makes sense, DoH uses way more packets and suffers from Head of Line
> blocking, unlike plain DNS.

Is that still true with a server timeout that is not so short?

> We have asked Mozilla to provide more details of their measurements, but
> these have not been forthcoming.

Noted. It would be *really* useful to the community if there was better communication from them.

> Note that the graph published on the blog misses the 95% and 99% bins,
> https://blog.nightly.mozilla.org/files/2018/08/DNS-over-HTTPS-Performance-Improvement.png
> and does not include details on timeouts.

Yep, and that would be useful too.

>>> And, perhaps somewhat more provocatively, should we maybe not start pushing
>>> DoH/2 if it leaves people with a sub-standard experience, causing them to
>>> disable DoH?
>> 
>> If the implementations on the client or server side make using DoH bad,
>> those implementations should be fixed.  If they don't get fixed, we'll
>> certainly hear about it.
> 
> There is already a Firefox ticket I think, but with Patrick and Daniel gone
> or gone soon, I am not sure who owns it now.

Hopefully he or she will decloak soon.

> 
>>> DoH/3 might be somewhat of a wait but it might prevent that
>>> sour taste from developing.
>> 
>> Without sufficient data, it's hard to say if there really is a sour taste.
> 
> Perhaps Mozilla can clarify further what they measured beyond the 7
> milliseconds slowdown.
> 
> I may do some induced packetloss experiments to see if the "experience" can
> be reproduced.

That would be grand, but it would also be good to have such experiments when the server has a more sensible timeout value.

--Paul Hoffman