Subject: [dns-privacy] Fwd: New Version Notification for draft-huitema-dprive-dnsoquic-00.txt

From: Christian Huitema <[email-masked]>
Date: Thu, 5 Mar 2020 22:26:28 -0800

We just resubmitted the DNS over QUIC draft to DPRIVE. Thanks in advance
for the feedback!

-- Christian Huitema

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-huitema-dprive-dnsoquic-00.txt
Date: 	Thu, 05 Mar 2020 20:46:29 -0800
From: 	[email-masked]
To: 	Christian Huitema <[email-masked]>, Sara Dickinson
<[email-masked]>, Allison Mankin <[email-masked]>

A new version of I-D, draft-huitema-dprive-dnsoquic-00.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name: draft-huitema-dprive-dnsoquic
Revision: 00
Title: Specification of DNS over Dedicated QUIC Connections
Document date: 2020-03-05
Group: Individual Submission
Pages: 19
URL:
https://www.ietf.org/internet-drafts/draft-huitema-dprive-dnsoquic-00.txt
Status: https://datatracker.ietf.org/doc/draft-huitema-dprive-dnsoquic/
Htmlized: https://tools.ietf.org/html/draft-huitema-dprive-dnsoquic-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-huitema-dprive-dnsoquic

Abstract:
This document describes the use of QUIC to provide transport privacy
for DNS. The encryption provided by QUIC has similar properties to
that provided by TLS, while QUIC transport eliminates the head-of-
line blocking issues inherent with TCP and provides more efficient
error corrections than UDP. DNS over QUIC (DoQ) has privacy
properties similar to DNS over TLS (DoT) specified in RFC7858, and
performance characteristics similar to classic DNS over UDP.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Tony Finch <[email-masked]>
Date: Fri, 6 Mar 2020 14:12:11 +0000

> We just resubmitted the DNS over QUIC draft to DPRIVE. Thanks in advance

Looks promising! I have a few comments:

Is the ALPN "dq" or "doq"? 4.1 and 4.1.1 appear to disagree. 8.1 seems to
disagree with itself.

Section 4.3 (idle timeouts): it's clearly better to use QUIC's facilities
for this, but there could potentially be a conflict with DNS stateful
timeouts (RFC48490) so maybe there needs to be a bit more discussion about
how to resolve disagreements between two protocol layers.

Section 5.4 (response size): there was a HUGE discussion about this in the
context of DoH and the consensus was to retain the 65535 byte message
size limit. DoQ should do the same.

https://mailarchive.ietf.org/arch/msg/doh/fpJSGWI1YtHeTFvmrS7pvB7ZnDA/

The EDNS payload size limit only applies to Do53 UDP and should be ignored
in other transports.

Sections 5.7 and 4.3 seem to be restating the same things in different
ways. They should probably be merged into one.

Section 5.7.1 (connection reuse): possibly also worth stating that servers
should not send responses in order. Maybe refer to RFC7766 which has
similar requirements for TCP.

An editorial suggestion: when referring to RFCs, can you please make it
clear what the reference is about (e.g. the subject of the RFC or name of
protocol) in the paragraph containing the reference, so that readers
can understand the paragraph without having to bounce back and forth to
the references section.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dover, Wight: Northwest backing west 3 to 5. Slight or moderate. Showers at
first. Good.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Mar 2020 15:30:52 +0000

Thank you for continuing this interesting work. However, a reader might not realize that many other folks would prefer DNS/HTTPS/QUIC until the get all the way to Section 3.4. Also, the title of that section seems a bit unbalanced, given that the text says that people might prefer DNS/HTTPS/QUIC for reasons other than hiding from firewalls.

For a future version of this draft, please consider moving the comparison to DNS/HTTPS/QUIC, and the discussion of not knowing which one folks will prefer, up to the Introduction. That would leave Section 3.4 just about the stated design goal.

--Paul Hoffman

---

From: Christian Huitema <[email-masked]>
Date: Thu, 19 Mar 2020 15:51:09 -0700

> Is the ALPN "dq" or "doq"? 4.1 and 4.1.1 appear to disagree. 8.1 seems to

Blame my poor editing skills, and use "doq". Sorry.

> size limit. DoQ should do the same.

OK.

> The EDNS payload size limit only applies to Do53 UDP and should be ignored
OK, will fix.
> ways. They should probably be merged into one.
Will look.
> similar requirements for TCP.
Will do. This is indeed the intent.
> can understand the paragraph without having to bounce back and forth to

I just need to find the right way to do that with the markdown tools...

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Thu, 19 Mar 2020 15:52:47 -0700

> For a future version of this draft, please consider moving the comparison to DNS/HTTPS/QUIC, and the discussion of not knowing which one folks will prefer, up to the Introduction. That would leave…

Yes. I would like to end up with just a spec, and leave the discussion
about DoT vs DoQ vs DoH vs DoH3 to some other document...

-- Christian Huitema

---

From: Rob Sayre <[email-masked]>
Date: Thu, 19 Mar 2020 17:13:58 -0700

On Thu, Mar 19, 2020 at 3:53 PM Christian Huitema <[email-masked]>
wrote:

> > Thank you for continuing this interesting work. However, a reader might
> not realize that many other folks would prefer DNS/HTTPS/QUIC until the get
> all the way to Section 3.4. Also, the title of that section seems a bit
> unbalanced, given that the text says that people might prefer
> DNS/HTTPS/QUIC for reasons other than hiding from firewalls.
> >
> > For a future version of this draft, please consider moving the
> comparison to DNS/HTTPS/QUIC, and the discussion of not knowing which one
> folks will prefer, up to the Introduction. That would leave Section 3.4
> just about the stated design goal.
>

 The introduction says:

 "DNS over QUIC (DoQ) has privacy
  properties similar to DNS over TLS (DoT) specified in RFC7858, and
  performance characteristics similar to classic DNS over UDP."

I think you might want to drop this text on performance characteristics,
since it seems to imply DNS over UDP has better performance characteristics.

At least for DoH, some data seems to show that it vastly outperforms DNS
over UDP after the 80th percentile of latency, while being just slightly
slower below the 80th percentile.

Source: https://youtu.be/_ZoyxE0bLp8?t=4839 (Ekr talk at DNS-OARC).

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Mar 2020 19:03:36 -0700

As Rob says, the DoH versus DoT performance situation is complicated, and I
don't think that this text is a great summary of the situation. There are a
lot of factors to consider here (connection setup time, retransmission
algorithms, etc.) but I would not expect DoQ to have performance
characteristics much like Do53 at all.
-Ekr

On Thu, Mar 19, 2020 at 5:15 PM Rob Sayre <[email-masked]> wrote:

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: "Ralf Weber" <[email-masked]>
Date: Fri, 20 Mar 2020 08:42:51 +0100

Moin!

> since it seems to imply DNS over UDP has better performance 
Well DNS over UDP has better performance characteristics than DoT and 
DoH.
That is not up for discussion. That is a fact. You can get way above
a million of DNS queries using regular DNS on a vanilla box, which is
simply impossible with DoH/DoT no matter how good you tune your test or
box. Latency in lab tests of DNS server usually is measured in 
microseconds
and not milliseconds.

Simple common sense will tell you that an unencrypted protocol always 
will
be faster than an encrypted protocol and that a stateless protocol (UDP)
will be faster then a stateful protocol (TCP), because it doesn’t need 
to
have any code for checking state. QUIC BTW is based on UDP.

> slower below the 80th percentile.
All that this shows is network latency to different service providers, 
and
the cache implementation of those (DNS cached answers will always be 
faster
the non cached). This has nothing to do with protocol performance.

However protocol performance is very important when you have to 
size/scale
implementations for millions of users.

So long
-Ralf
—--
Ralf Weber

---

From: Christian Huitema <[email-masked]>
Date: Fri, 20 Mar 2020 00:51:47 -0700

> On Mar 20, 2020, at 12:43 AM, Ralf Weber <[email-masked]> wrote:
> 
> Moin!
> 
> Well DNS over UDP has better performance characteristics than DoT and DoH.
> box. Latency in lab tests of DNS server usually is measured in microseconds
> and not milliseconds.
> 
> Simple common sense will tell you that an unencrypted protocol always will
> will be faster then a stateful protocol (TCP), because it doesn’t need to

And common sense may or may not be right. For many implementations of Quic, encryptions is not the bottleneck. You can run AES GCM at 20 Gbps or more on a single CPU thread. The actual bottleneck is the cost of UDP socket operations.

-- Christian Huitema

---

From: "Ralf Weber" <[email-masked]>
Date: Fri, 20 Mar 2020 09:15:46 +0100

Moin!

On 20 Mar 2020, at 8:51, Christian Huitema wrote:
> And common sense may or may not be right. For many implementations of 
> Quic, encryptions is not the bottleneck. You can run AES GCM at 20 
> Gbps or more on a single CPU thread. The actual bottleneck is the cost 
> of UDP socket operations.
That is probably more kernel (socket) vs user space (encryption) and the 
needed context switches for that. If you do all things identically not 
encrypting will save you CPU cycles so always will be faster. Now I’m 
not saying that we should not encrypt, we certainly should, and I’m 
also not saying that it is impossible for a good implementation of an 
encrypted protocol to be faster then a bad implementation of an 
unencrypted protocol.

However regular DNS over UDP has been around so long and optimised so 
heavily, that I think it is safe to say that we need more capacity 
(hardware, network, etc) to achieve the same throughput/performance via 
DoT or DoH.

So long
-Ralf
—--
Ralf Weber

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Mar 2020 06:56:15 -0700

n Fri, Mar 20, 2020 at 12:43 AM Ralf Weber <[email-masked]> wrote:

> That is not up for discussion. That is a fact.

It turns out that there is more than one way to measure performance.

The performance you are talking about is the performance of the server, but
the performance this document is talking about is the network performance
of the protocol when the server is not the bottleneck.

You can get way above
> box. Latency in lab tests of DNS server usually is measured in

Yes, but measurements in the field are what matter to users.

> the non cached). This has nothing to do with protocol performance.

Actually, it's not clear what the source of the difference is. The Princeton
study by Hounsel et al. found a similar effect in bad network conditions,
even when controlling for the server. IIRC their theory was that TCP
retransmission
was more aggressive and therefore handled loss better. In reality, it's
probably
a combination of things.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 20 Mar 2020 13:57:19 +0000

On Mar 20, 2020, at 12:42 AM, Ralf Weber <[email-masked]> wrote:
> That is not up for discussion.

Yes it is, and efforts to stop other WG participants (particularly those with collected data) from discussing it are not appropriate.

--Paul Hoffman

---

From: "Ralf Weber" <[email-masked]>
Date: Fri, 20 Mar 2020 15:15:07 +0100

Moin!

On 20 Mar 2020, at 14:57, Paul Hoffman wrote:

> Yes it is, and efforts to stop other WG participants (particularly 
> those with collected data) from discussing it are not appropriate.
I don’t know what to say. Are we at the point were we create alternate 
facts? If the hardware and the location of the client and server are 
identical it is impossible to get more throughput, better latency using 
DoT or DoH, then DNS over UDP/53 given two similar written servers. Sure 
there are stuff like special chips to enhance that, but if you would do 
the same to regular DNS you could increase that even more. For the same 
effort it is impossible to get the same throughput and latency simply 
because there is more work to do.

Now there are other, more service oriented tests that again measure 
something else (mostly network latency and cache behaviour), where stuff 
is up for discussion, but for the performance case I described, which 
matters to people who have to buy and operate these servers, I don’t 
see how we can get the same bang for the buck for DoT/DoH.

So long
-Ralf
—--
Ralf Weber

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Mar 2020 07:55:31 -0700

> > On Mar 20, 2020, at 12:42 AM, Ralf Weber <[email-masked]> wrote:
...

> see how we can get the same bang for the buck for DoT/DoH.

I think this is the key point: there are multiple constituencies here and
they each have a different view of performance. As you say, server
operators are very concerned with CPU on the server [0], however,
what users are principally concerned with is end-to-end performance,
which is generally not dominated by server CPU. This seems especially
true for servers which are run by entities which already have high
performance TLS (or QUIC) serving capacity.

I think it's clear that the latter is the kind of performance that this
draft
is talking about. However, as I said initially, agreeing with Rob, I think
it would probably be easier to drop this text.

-Ekr

[0] It's worth noting that CPU performance used to be a big concern for
encrypted Web traffic, but that's become a much smaller concern due
to a variety of technical improvements.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 20 Mar 2020 09:07:46 -0700

On Fri, Mar 20, 2020 at 7:16 AM Ralf Weber <[email-masked]> wrote:

> Moin!
>
> If the hardware and the location of the client and server are
> DoT or DoH, then DNS over UDP/53 given two similar written servers.
>

Hi Ralf,

A trivial example in which this is not true is in the case where one or
more routers in the network path maintain different queues for UDP and TCP
traffic.  When this is the case, a robust queue for TCP and a meager one
for UDP can easily mean that the end-to-end performance for the client is
better for DoT (or DNS over TCP/53), simply because the loss on the UDP
path is high.  This is especially true if you measure over a flight of
queries (say, all the DNS queries a web page needs to resolve) and DoT
keeps an open session for the whole flight.  To put this another way,
if what you are measuring is the DNS component of page load time,  DNS
timeouts for the lost UDP packets  in a queue-starved path can kill the
performance.

As Eric points out, we have to be careful to describe what we're measuring
here, and there are definitely different views of what we're optimizing
for.

regards,

Ted Hardie

---

From: Brian Dickson <[email-masked]>
Date: Fri, 20 Mar 2020 10:57:09 -0700

> here, and there are definitely different views of what we're optimizing

What may have been overlooked and/or erroneously given too much weight, is
the single report being used to compare performance.
(I don't have the original report URI handy, but I'm sure many participants
here do.)

IIRC, the measurements were done exclusively from AWS locations, and
further cherry-picked by AWS location.

So yes, we need to be careful not only on what we are measuring, but how we
are performing that measurement.

IMNSHO, that report would be better characterized as anecdotal rather than
statistically representative of the real world.

I'm definitely not against productive discussions, but we should get good
data first.

An example of good data, are the experiments conducted by Geoff Huston and
George Michaelson from APNIC.
I'd encourage those asserting performance claims to work with them to get
reliable data that can be analyzed in this forum.

Brian

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Mar 2020 11:17:13 -0700

These all seem to show a broadly similar pattern in which DoH/DoT are
marginally slower in fast settings. Where people have looked at slower
settings, it seems like there is some evidence that

-Ekr

On Fri, Mar 20, 2020 at 10:58 AM Brian Dickson <
[email-masked]> wrote:

>> As Eric points out, we have to be careful to describe what we're
>> measuring here, and there are definitely different views of what we're
>> optimizing for.
>>
>
> (I don't have the original report URI handy, but I'm sure many
> participants here do.)
>

I don't believe this is a singly report. To my knowledge there are at least
three separate measurements that have been taken here:

- The Hounsel et. al measurements which were taken from a single vantage
point.
- The measurements by B\"{o}ttger et al. published at IMC'19, which also
appear to be from a single vantage point.
- The measurements we published which were taken from a sample of Firefox
users

I believe there is also some new work using SamKnows but I don't think the
results have been published yet.

These seem to all show roughly comparable results of DoH/DoT being slightly
slower in fast settings. Both our results and Hounsels suggest that in bad
network conditions, DoH and DoT can be faster.

> George Michaelson from APNIC.

Certainly the type of measurements conducted by APNIC are useful, but I
don't believe that their techniques can actually measure this because they
are unable to cleanly access the DNS API via an advertisement. However, our
experimental design (sampling Fx users) offers a broadly similar type of
measurement, and, as I said above, shows that DoH is slightly -- but not
materially --slower than the system resolver up to about the 80th
percentile at which point DoH outperforms the system resolver [0].

-Ekr

[0]
https://blog.nightly.mozilla.org/2018/08/28/firefox-nightly-secure-dns-experimental-results/

---

From: Rob Sayre <[email-masked]>
Date: Fri, 20 Mar 2020 11:39:21 -0700

On Fri, Mar 20, 2020 at 1:15 AM Ralf Weber <[email-masked]> wrote:

> needed context switches for that.

Yes, at which point one can switch to user space networking if really
necessary.

I've never studied DNS server implementations closely (I was talking about
protocol performance), but I have seen web servers that do this.

> If you do all things identically not

What level of throughput would that be? Web server benchmarks have to be
designed to avoid saturating a 10gE NIC. (e.g.
https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=json).

thanks,
Rob

---

From: "Ralf Weber" <[email-masked]>
Date: Sun, 22 Mar 2020 10:46:48 +0100

Moin!

> Yes, at which point one can switch to user space networking if really
Which has been done for DNS, but usually with special cards that did
offload other UDP functions also.

> protocol performance), but I have seen web servers that do this.
They have, but all of this is again effort to be done.

> https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=json).
Web throughput is vastly different from DNS throughput. While the typical
web page or picture usually is a couple of kilobytes or megabytes, the
typical DNS question/answer is around 100 bytes on the wire. Even with
DNSSEC  enabled it usually is below 500 bytes. So the parameter you look
at is packets per seconds and not saturation. You can easily saturate
whatever link size you desire with large packets, even with DNS, which is
what amplification attacks do.

When I now look at DoH packets on the wire, even with discounting the
initial TLS setup they are for the same questions/answers between 40% and
100% bigger. Now of course that overall means they have 40 to a 100 bytes
more which is not much in the overall traffic, but a protocol that has
to put more bits on the wire has to do more work, which is the point I
was trying to bring across.

So long
-Ralf
—--
Ralf Weber

---

From: Rob Sayre <[email-masked]>
Date: Sun, 22 Mar 2020 10:29:36 -0700

> offload other UDP functions also.

I was thinking of software solutions. The ones I've used are closed source,
but there is a nice open example now:
http://www.f-stack.org/

Tencent uses it for a fairly large service called "HttpDNS":

https://cloud.tencent.com/product/hd
https://mc.qcloudimg.com/static/qc_doc/0921907717d6d7604293f2636524f91f/doc-HttpDNS-Product+Introduction.pdf

which, of course, skips the local resolver in favor of a centralized DNS
service (non-DoH protocol)...

> was trying to bring across.

And DNS over UDP is indeed faster up until the 80th percentile of latency,
at which point the data shows DoT/DoH outperform it.

thanks,
Rob