Re: QUIC re-chartering: include DNS-over-QUIC?
Paul Vixie <paul@redbarn.org> Sat, 11 April 2020 23:46 UTC
Return-Path: <paul@redbarn.org>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFF33A1ABE for <quic@ietfa.amsl.com>; Sat, 11 Apr 2020 16:46:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyXdZUAyA4-s for <quic@ietfa.amsl.com>; Sat, 11 Apr 2020 16:46:07 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CBA83A1ABD for <quic@ietf.org>; Sat, 11 Apr 2020 16:46:07 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 573A8B07D0 for <quic@ietf.org>; Sat, 11 Apr 2020 23:46:04 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: IETF QUIC WG <quic@ietf.org>
Subject: Re: QUIC re-chartering: include DNS-over-QUIC?
Date: Sat, 11 Apr 2020 23:46:03 +0000
Message-ID: <21444935.R3TQEuPsEl@linux-9daj>
Organization: none
In-Reply-To: <CAKC-DJjNbBYVzmN=KxnRKpxK_eJFcbGFvejx1Xms-X2iesBVrg@mail.gmail.com>
References: <CAKcm_gNf43tXizw9D2jdtTieh+=zS7PKVDiNNV-UEbP8Gw+mHg@mail.gmail.com> <de87e833-de54-ae5a-cd85-2f93565192f7@redbarn.org> <CAKC-DJjNbBYVzmN=KxnRKpxK_eJFcbGFvejx1Xms-X2iesBVrg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/7Uc1Bk5-IeneT-VvooDlRdiVnJI>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Apr 2020 23:46:09 -0000
On Thursday, 6 February 2020 21:27:14 UTC Erik Nygren wrote: > On Thu, Feb 6, 2020 at 4:16 PM Paul Vixie <paul@redbarn.org> 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 <paul@redbarn.org> 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
- Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Jana Iyengar
- RE: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work Martin Thomson
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Mark Nottingham
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Mark Nottingham
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Magnus Westerlund
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Salz, Rich
- RE: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work David Schinazi
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work David Schinazi
- Re: Re-chartering for extension work Olivier Bonaventure
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Lars Eggert
- Multipath (was: Re: Re-chartering for extension w… Lars Eggert
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Mikkel Fahnøe Jørgensen
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Mikkel Fahnøe Jørgensen
- Re: Multipath (was: Re: Re-chartering for extensi… Christian Huitema
- RE: Re-chartering for extension work Mike Bishop
- RE: Re-chartering for extension work Kuhn Nicolas
- Re: Re-chartering for extension work Ian Swett
- Re: [EToSat] Re-chartering for extension work Christian Huitema
- Re: Multipath (was: Re: Re-chartering for extensi… Jana Iyengar
- Re: Re-chartering for extension work Lars Eggert
- Re: Re-chartering for extension work Magnus Westerlund
- Re: Re-chartering for extension work Magnus Westerlund
- RE: Multipath (was: Re: Re-chartering for extensi… Florin Baboescu
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- RE: Re-chartering for extension work Roni Even (A)
- Re: Multipath (was: Re: Re-chartering for extensi… Ryan Hamilton
- RE: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work Jana Iyengar
- RE:(2) Multipath (was: Re: Re-chartering for exte… Madhan Raj Kanagarathinam
- Re: Re-chartering for extension work Lars Eggert
- Re: Re-chartering for extension work Lars Eggert
- RE: Re-chartering for extension work Roni Even (A)
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Lars Eggert
- Re: Re-chartering for extension work Magnus Westerlund
- RE: Re-chartering for extension work Kuhn Nicolas
- RE: [EToSat] Re-chartering for extension work Kuhn Nicolas
- Re: Multipath Gorry Fairhurst
- Re: Re-chartering for extension work Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Tommy Pauly
- Re: Multipath (was: Re: Re-chartering for extensi… Jana Iyengar
- RE: Multipath (was: Re: Re-chartering for extensi… tim.costello
- Re: Multipath (was: Re: Re-chartering for extensi… Mirja Kuehlewind
- Re: Re-chartering for extension work Dmitri Tikhonov
- Re: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work Martin Thomson
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Lucas Pardue
- Re: Re-chartering for extension work Dmitri Tikhonov
- Re: Multipath (was: Re: Re-chartering for extensi… Mirja Kuehlewind
- QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Tommy Pauly
- Re: QUIC re-chartering: include DNS-over-QUIC? Salz, Rich
- Re: QUIC re-chartering: include DNS-over-QUIC? Eric Rescorla
- Re: QUIC re-chartering: include DNS-over-QUIC? Ted Hardie
- Re: QUIC re-chartering: include DNS-over-QUIC? Jari Arkko
- Re: QUIC re-chartering: include DNS-over-QUIC? Magnus Westerlund
- Re: QUIC re-chartering: include DNS-over-QUIC? Stephen Farrell
- Re: QUIC re-chartering: include DNS-over-QUIC? Christian Huitema
- Re: QUIC re-chartering: include DNS-over-QUIC? Daniel Migault
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Salz, Rich
- Re: QUIC re-chartering: include DNS-over-QUIC? Christopher Wood
- Re: QUIC re-chartering: include DNS-over-QUIC? Ian Swett
- Re: QUIC re-chartering: include DNS-over-QUIC? Vidhi Goel
- Re: QUIC re-chartering: include DNS-over-QUIC? Paul Vixie
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Kline
- Re: QUIC re-chartering: include DNS-over-QUIC? Martin Duke
- Re: QUIC re-chartering: include DNS-over-QUIC? Paul Vixie
- Re: QUIC re-chartering: include DNS-over-QUIC? Mikkel Fahnøe Jørgensen
- Re: QUIC re-chartering: include DNS-over-QUIC? Lucas Pardue
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Kline
- Re: QUIC re-chartering: include DNS-over-QUIC? Martin Thomson
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Paul Vixie