Re: QUIC re-chartering: include DNS-over-QUIC?
Erik Nygren <erik+ietf@nygren.org> Tue, 14 April 2020 02:55 UTC
Return-Path: <nygren@gmail.com>
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 1765F3A0876 for <quic@ietfa.amsl.com>; Mon, 13 Apr 2020 19:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.402
X-Spam-Level:
X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 wiFKShvtkKG4 for <quic@ietfa.amsl.com>; Mon, 13 Apr 2020 19:55:45 -0700 (PDT)
Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6B63A0874 for <quic@ietf.org>; Mon, 13 Apr 2020 19:55:44 -0700 (PDT)
Received: by mail-wr1-f46.google.com with SMTP id u13so12081453wrp.3 for <quic@ietf.org>; Mon, 13 Apr 2020 19:55:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=APxQL5rjMli3mrOnJjZABjpVbkqP8D6cS84fy51lrFU=; b=svmLeayMyZA886F6apWXMExNInScltKskAqd/0njCkJJYrRGCFk+BiwGVjYCMPaymf 6ialLPoOiVCk1XJ9wO0Kuz7YoZvAmhVQCipORDfGJ4ZrX3vfEZi991kw247YrtyQIGJ9 ZrSvDfpVn6hGuAWREEeTSr1oMuRRSuB4WHfNBO+F0JeVDNaGo0RS7VentRaReA+niVht +SYfmTmpehUoA5I8WV1ajEsVgUPWALonlhbXU/pi0SgL6MEk5raxlNTYA7oAEJ5GJxi6 U27ZU8a7oJWZrlIBjvI6PgjO82NB2ahIx2L4mOGoUrr3iI/kVE3FgfkRFnlnJ+XBak1+ kIEw==
X-Gm-Message-State: AGi0PuY/yJyKLdJbbjA+C9mQf7vkyjRf/6kIGnpXwP/FSxcrk2bq7CQZ 52AqY2l9aJo3kfW9+dYb8fG0Vxul7dnGRJ2xR3bmjgWW
X-Google-Smtp-Source: APiQypKQZzqt3WWjKbNhDg0wuwT4OLy6Qp9FEC7ZUtBXS+/o6UtUlW637aKncdZd4MQcJM+Fit4zV5Tma09X+hb6cLQ=
X-Received: by 2002:a5d:6310:: with SMTP id i16mr8684063wru.177.1586832943157; Mon, 13 Apr 2020 19:55:43 -0700 (PDT)
MIME-Version: 1.0
References: <CAKcm_gNf43tXizw9D2jdtTieh+=zS7PKVDiNNV-UEbP8Gw+mHg@mail.gmail.com> <de87e833-de54-ae5a-cd85-2f93565192f7@redbarn.org> <CAKC-DJjNbBYVzmN=KxnRKpxK_eJFcbGFvejx1Xms-X2iesBVrg@mail.gmail.com> <21444935.R3TQEuPsEl@linux-9daj> <ad2ae8b8-ba2d-4839-a07d-f57f475b43dc@www.fastmail.com>
In-Reply-To: <ad2ae8b8-ba2d-4839-a07d-f57f475b43dc@www.fastmail.com>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Mon, 13 Apr 2020 22:55:31 -0400
Message-ID: <CAKC-DJhYroROaDTur1F+7W6+JJAUgSCWP_0ty_jj0cPaP8xjHw@mail.gmail.com>
Subject: Re: QUIC re-chartering: include DNS-over-QUIC?
To: Martin Thomson <mt@lowentropy.net>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e5188605a33755fd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/y3UuUemyTE_bdOJrwB2YByqizN4>
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: Tue, 14 Apr 2020 02:55:47 -0000
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 <mt@lowentropy.net> wrote: > Hi Paul, > > These are good topics to talk through. > > On Sun, Apr 12, 2020, at 09:46, Paul Vixie wrote: > > 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. > > 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. > > > > * 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 > > 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. > > > 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. > > 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 > > 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 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. > >
- 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