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

[Erik Nygren <[e-mail]>]

On Thu, Feb 6, 2020 at 4:16 PM Paul Vixie <[e-mail]> 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):

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

     Erik