Subject: Re: QUIC re-chartering: include DNS-over-QUIC?

From: Paul Vixie <[email-masked]>
Date: Sat, 11 Apr 2020 23:46:03 +0000

On Thursday, 6 February 2020 21:27:14 UTC Erik Nygren wrote:
> On Thu, Feb 6, 2020 at 4:16 PM Paul Vixie <[email-masked]> wrote:
> > i see DoQ as nec'y for QUIC's success but not relevant to DNS beyond the
> > fact that DNS is a convenient second example of how QUIC can be used. if
> > there are use cases or failure modes not handled well by DoT, i'd like
> > to learn more about those.
> 
> Some possible reasons (not comprehensive):

forgive the long delay in responding, please.

> * Reduce the impact of head-of-line blocking during loss.  If packets are
> lost, only the request(s) associated with the loss are impacted.

you're assuming that the loss isn't self-induced. sometimes slowing down is 
exactly what's needed. for example when a busy full resolver has a queue of 
hundreds or thousands of requests to be sent to a zone authority, rate 
limiting of UDP is necessary to prevent a meltdown. bandwidth is finite. we 
sometimes load-balance toward several of a zone's authority servers even 
including those known to not have low-ish RTT, just to avoid flooding one of 
them, or to avoid flooding our nearby links. moving to QUIC won't help with 
any of that.

> * Faster resumption and 0RTT behaviors (although you get some of these with
> TFO + TLS 1.3 0RTT).  But this substantially reduces the performance impact
> when new connections need to be established.

in DNS, new connections rarely need to be established. the reason RFC 6013 
permitted connections to go into a quiet (resumable) state and keep the 
learned cwin in compressed state so that the cost of that state would be no 
worse than what was needed for syn flood protection. since you mentioned TFO i 
want to say two things, first it was insecure and can't be used, exactly as we 
predicted (william simpson and i), and second TCPCT allowed for payloads as 
part of the initial or resumptive segments to get exactly the 0RTT benefit. 
but i don't want to drone on like a sore loser. the point is, in DNS, novel 
connections are rare, and careful statekeeping to support resumption (such as 
DNS cookies as defined in RFC 7873) is already present in pre-QUIC DNS.

> * The previous also means servers can be more aggressive about timing out
> connections to reduce the state they need to keep, but while minimizing
> perf impact, which can be critical at-scale.

this reduces to a noop because the statekeeping is subject to botnet attacks. 
just as all TCP listeners have to implement syn flood protection, so it is 
that all stateful endpoints (whether DNS, TCPCT, TFO, or QUIC) have to be 
aggressive about timing out connections they need not keep fully open. QUIC 
has no special capabilities or requirements in this regard.

> * Better ability for load balancers at-scale to do creative things,
> including being able to recover better when Anycast moves routes between
> data centers.  (The server-supplied Connection ID means that options become
> available to better recover without needing to reset re-establish
> connections and without needing to share state between clusters.)

while it's theoretically possible to share DNS cookie state (RFC 7873) across 
many instances of DNS Anycast, the cost:benefit of that complexity is less 
compelling than the cost:benefit of having to renegotiate during route changes 
either from mobile-ip or network-in-the-middle attacks. i don't think QUIC has 
different game theory than DNS cookies have in this regard. route changes are 
orders of magnitude less frequent than same-pair reuse, and always must be.

> * QUIC provides a framework for future extensions that may be useful in the
> DNS space.  For example, FEC might actually be useful for DNS in some cases.
> 
> I'm sure there are plenty more reasons...

i appreciate the time you put into listing these initial motivations. however:

> On Thu, Feb 6, 2020 at 4:16 PM Paul Vixie <[email-masked]> wrote:
> > i see DoQ as nec'y for QUIC's success but not relevant to DNS beyond the
> > fact that DNS is a convenient second example of how QUIC can be used. if
> > there are use cases or failure modes not handled well by DoT, i'd like
> > to learn more about those.

...my question seems to stand. if the potential motivations you've listed so 
far were actual, then we'd have had DNS over SCTP decades ago, or something 
like DTLS that actually worked at scale rather than just in a lab, or we would 
have been able to get TCPCT the code point we needed to experiment globally, 
or we would have had UDP options by now.

i consider DoQ inevitable, but for QUIC's purposes ("proof of broader 
applicability"), not DNS's purposes ("working better"). DNS is old and warty 
but it does move and it has evolved.

-- 
Paul

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 12 Apr 2020 11:49:40 -0700

Late to the game. I support DoQ.
Maybe there are too many DNS transports, and maybe DNS as such does not
need it, but for all communication endpoints that invest in QUIC as the
sole transport it would be very convenient to have DoQ. DNS is a low-level
dependency for most QUIC application protocols so if you have a non-HTTP
based application, why would you want to drag in HTTP just for the sake of
DNS, disregarding attack surfaces? DoQ instead of UDP/TCP DNS handles
privacy / security and avoids another dependency.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 12 April 2020 at 01.46.25, Paul Vixie ([email-masked]) wrote:

including those known to not have low-ish RTT, just to avoid flooding one
of

in DNS, new connections rarely need to be established. the reason RFC 6013
permitted connections to go into a quiet (resumable) state and keep the
learned cwin in compressed state so that the cost of that state would be no
worse than what was needed for syn flood protection. since you mentioned
TFO i
want to say two things, first it was insecure and can't be used, exactly as
we
predicted (william simpson and i), and second TCPCT allowed for payloads as
part of the initial or resumptive segments to get exactly the 0RTT benefit.
but i don't want to drone on like a sore loser. the point is, in DNS, novel
connections are rare, and careful statekeeping to support resumption (such
as
DNS cookies as defined in RFC 7873) is already present in pre-QUIC DNS.

> perf impact, which can be critical at-scale.

this reduces to a noop because the statekeeping is subject to botnet
attacks.

> connections and without needing to share state between clusters.)

while it's theoretically possible to share DNS cookie state (RFC 7873)
across
many instances of DNS Anycast, the cost:benefit of that complexity is less
compelling than the cost:benefit of having to renegotiate during route
changes
either from mobile-ip or network-in-the-middle attacks. i don't think QUIC
has
different game theory than DNS cookies have in this regard. route changes
are
orders of magnitude less frequent than same-pair reuse, and always must be.

> I'm sure there are plenty more reasons...

i appreciate the time you put into listing these initial motivations.

> > to learn more about those.

....my question seems to stand. if the potential motivations you've listed
so
far were actual, then we'd have had DNS over SCTP decades ago, or something
like DTLS that actually worked at scale rather than just in a lab, or we
would
have been able to get TCPCT the code point we needed to experiment
globally,
or we would have had UDP options by now.

i consider DoQ inevitable, but for QUIC's purposes ("proof of broader
applicability"), not DNS's purposes ("working better"). DNS is old and
warty
but it does move and it has evolved.

-- 
Paul

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 12 Apr 2020 20:01:33 +0100

Mikkel, all,

Thanks for the healthy discussion on this thread. As suggested up thread,
this proposal was taken to the DPRIVE WG and presented at their interim
meeting last week.

DPRIVE have issued a call for adoption [1], I encourage continued
conversation over there.

Cheers
Lucas

[1]
https://mailarchive.ietf.org/arch/msg/dns-privacy/kXmy4lZ-MzUKCP5zrca9I4WmiVI/

On Sun, 12 Apr 2020, 19:49 Mikkel Fahnøe Jørgensen, <[email-masked]>
wrote:

> limiting of UDP is necessary to prevent a meltdown. bandwidth is finite..
> we

---

From: Erik Kline <[email-masked]>
Date: Sun, 12 Apr 2020 15:08:37 -0700

Tangent: is there already, or are there plans for, a document like BCP 56
but for QUIC?  I'm thinking generally about whether there should be
guidance for folks wanting to port Foo protocol to Foo-over-QUIC.

On Sun, Apr 12, 2020 at 12:01 PM Lucas Pardue <[email-masked]>
wrote:

>> Late to the game.. I support DoQ.
>> limiting of UDP is necessary to prevent a meltdown. bandwidth is
>> finite... we
>> ....my question seems to stand. if the potential motivations you've
>> listed so

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 14 Apr 2020 12:16:32 +1000

Hi Paul,

These are good topics to talk through.

> them, or to avoid flooding our nearby links. moving to QUIC won't help with 

I guess it depends on what resource you are attempting to preserve.

The goal of a congestion controller is to avoid over-saturating the network.  But most controllers still assume that you still want saturation of a kind.  QUIC likely doesn't do anything to help here, unless you think that having a stateful context with good feedback about loss and delay is useful.  It seems like something far less sophisticated is what you are imagining.

If the goal is instead to avoid overloading a receiver, then QUIC definitely can help.  The flow control mechanisms in QUIC (limits on streams, per-stream limits on bytes) are all designed to avoid this situation by putting the receiver more in control.  If a resolver is busy handling lots of traffic and you want to avoid swamping it further with zone transfers or similar, then these flow control options allow it to limit the resources it has to commit to different connections. (Of course, that reduces the problem to the previously-unsolved one of prioritizing competing interests.)

If you have good flow control, you might not have to worry about the effect on congestion beyond choosing an appropriately-aggressive controller.
 
> permitted connections to go into a quiet (resumable) state

The resumption part is interesting in this context.  It depends on what you mean by "resume".

If you imagine very long periods of quiescence, but with (full) retention of state at endpoints, then QUIC should work.  Using connection IDs might mean that you can keep using a connection even in the presence of address translation.  

That's different than what TLS and QUIC refer to as "resumption", which is the feature that allows you to make new connections (more) cheaply.  QUIC does a lot to improve that, because the web needs it.  Maybe DNS will also benefit from that, but it might be that you can just use very long-lived connections instead.  I would recommend a regimen of key updates for that, but that's not critical.

Transport people keep saying that you can't save the congestion window.  But then I keep seeing that people do and nothing much breaks, so I guess this debate will just continue.

> orders of magnitude less frequent than same-pair reuse, and always must be.

You might find that sharing implementations with HTTP servers changes the dynamics there, but I don't know if the equivalent QUIC mechanisms are fundamentally different.  What I've observed with HTTP is that state is shared, sometimes globally, sometimes only at the same location, and sometimes not at all.  But I don't operate any of those services, so I can't speak to details.

> ....my question seems to stand. if the potential motivations you've listed so 

I think that my answer immediately above speaks to the potential difference here.  Wide deployment of infrastructure that supports the protocol might change the system dynamics sufficiently to make it worthwhile for DNS to use the new protocol.  I don't think that this is certain, but I also don't think that this is a question of serving QUIC more than it is serving DNS.

As you say, DNS has its own version of many (or all) of the same capabilities we're talking about.  It has them because it needs them.  The amount of operational experience with those capabilities is far greater than the experience people have with QUIC, and that will remain the case for a good while (read: more than 3 years, possibly quite a bit more).

However, if QUIC does manage to see wider adoption, it could be that the benefits of sharing infrastructure and experience is worthwhile.  Laying the groundwork for that possibility isn't necessarily a waste of the time of groups like DPRIVE/QUIC.  Recognizing the potential for that work to be unwanted is a good check on excessive ambition though.

I personally think that there is value in sharing a better transport layer, but the costs are pretty significant.  Even if you believe that there is some utopian end state in which everything uses the same protocol, the short- and medium-term costs are carrying around multiple protocols, some of which are awkwardly incompatible.

---

From: Erik Nygren <[email-masked]>
Date: Mon, 13 Apr 2020 22:55:31 -0400

Martin summarizes well below.  What changes things is the need for an
encrypted+authenticated transport.
If we could stick with DNS-over-53 (TCP and UDP) then QUIC buys us
nothing.  But if our choices are:

* DoH
* DoTLS
* DoDTLS
* DoQUIC
* Do{SomethingBespoke}

then from a large-scale server operator perspective DoQ has lots going for
it.
There was a good comparison of some of these for what they mean from a
protocol
stack elements perspective in DPRIVE.

Especially for operators who will be building QUIC support into Load
Balancers,
Anycast forwarders, and the like for HTTP/3, it would be great to be able
to reuse some of this for DNS as well.  QUIC has nice features that may
make it easier
to operate than DoTLS or DoDTLS, and DTLS is a weird worst-of-all-worlds
for people
already operating TLS-over-TCP and QUIC at scale.  And for
recursive-to-authoritative I don't see
that DoH buys us the complexity it adds.

    Erik

On Mon, Apr 13, 2020 at 10:17 PM Martin Thomson <[email-masked]> wrote:

> The goal of a congestion controller is to avoid over-saturating the
> network.  But most controllers still assume that you still want saturation
> of a kind.  QUIC likely doesn't do anything to help here, unless you think
> that having a stateful context with good feedback about loss and delay is
> useful.  It seems like something far less sophisticated is what you are
> imagining.
>
> If the goal is instead to avoid overloading a receiver, then QUIC
> definitely can help.  The flow control mechanisms in QUIC (limits on
> streams, per-stream limits on bytes) are all designed to avoid this
> situation by putting the receiver more in control.  If a resolver is busy
> handling lots of traffic and you want to avoid swamping it further with
> zone transfers or similar, then these flow control options allow it to
> limit the resources it has to commit to different connections. (Of course,
> that reduces the problem to the previously-unsolved one of prioritizing
> competing interests.)
>
> If you have good flow control, you might not have to worry about the
> effect on congestion beyond choosing an appropriately-aggressive controller.
>
> If you imagine very long periods of quiescence, but with (full) retention
> of state at endpoints, then QUIC should work.  Using connection IDs might
> mean that you can keep using a connection even in the presence of address
> translation.
>
> That's different than what TLS and QUIC refer to as "resumption", which is
> the feature that allows you to make new connections (more) cheaply.  QUIC
> does a lot to improve that, because the web needs it.  Maybe DNS will also
> benefit from that, but it might be that you can just use very long-lived
> connections instead.  I would recommend a regimen of key updates for that,
> but that's not critical.
>
> Transport people keep saying that you can't save the congestion window.
> But then I keep seeing that people do and nothing much breaks, so I guess
> this debate will just continue.
>
> You might find that sharing implementations with HTTP servers changes the
> dynamics there, but I don't know if the equivalent QUIC mechanisms are
> fundamentally different.  What I've observed with HTTP is that state is
> shared, sometimes globally, sometimes only at the same location, and
> sometimes not at all.  But I don't operate any of those services, so I
> can't speak to details.
>
> I think that my answer immediately above speaks to the potential
> difference here.  Wide deployment of infrastructure that supports the
> protocol might change the system dynamics sufficiently to make it
> worthwhile for DNS to use the new protocol.  I don't think that this is
> certain, but I also don't think that this is a question of serving QUIC
> more than it is serving DNS.
>
> As you say, DNS has its own version of many (or all) of the same
> capabilities we're talking about.  It has them because it needs them.  The
> amount of operational experience with those capabilities is far greater
> than the experience people have with QUIC, and that will remain the case
> for a good while (read: more than 3 years, possibly quite a bit more).
>
> However, if QUIC does manage to see wider adoption, it could be that the
> benefits of sharing infrastructure and experience is worthwhile.  Laying
> the groundwork for that possibility isn't necessarily a waste of the time
> of groups like DPRIVE/QUIC.  Recognizing the potential for that work to be
> unwanted is a good check on excessive ambition though.
>
> I personally think that there is value in sharing a better transport
> layer, but the costs are pretty significant.  Even if you believe that
> there is some utopian end state in which everything uses the same protocol,
> the short- and medium-term costs are carrying around multiple protocols,
> some of which are awkwardly incompatible.
>
>

---

From: Paul Vixie <[email-masked]>
Date: Tue, 14 Apr 2020 03:01:29 +0000

> encrypted+authenticated transport.

DNS has an authenticated transport -- SIG(0) -- which is rarely needed.

DNS has authentication end-to-end -- DNSSEC -- which is where it's needed.

DNS has an encrypted transport -- DoT.

> it. There was a good comparison of some of these for what they mean from a
> protocol stack elements perspective in DPRIVE.

i think it's clear you have all the excuses needed to drive DoQ. however, 
before you move on, remember that DNS has solved its own problems w/o QUIC, 
and QUIC's need for DNS is about something else than "large-scale operator 
perspective".

-- 
Paul