Re: Fwd: New Version Notification for draft-duke-httpbis-quic-version-alt-svc-00.txt
Ryan Hamilton <rch@google.com> Fri, 11 March 2022 23:22 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4E53A130F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 11 Mar 2022 15:22:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.26
X-Spam-Level:
X-Spam-Status: No, score=-10.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 5y9C1m71LEgF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 11 Mar 2022 15:22:37 -0800 (PST)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4C23A1308 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 11 Mar 2022 15:22:37 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1nSoYC-0003cy-9o for ietf-http-wg-dist@listhub.w3.org; Fri, 11 Mar 2022 23:20:00 +0000
Resent-Date: Fri, 11 Mar 2022 23:20:00 +0000
Resent-Message-Id: <E1nSoYC-0003cy-9o@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <rch@google.com>) id 1nSoYA-0003cB-Al for ietf-http-wg@listhub.w3.org; Fri, 11 Mar 2022 23:19:58 +0000
Received: from mail-yb1-xb31.google.com ([2607:f8b0:4864:20::b31]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <rch@google.com>) id 1nSoY8-0008WR-NU for ietf-http-wg@w3.org; Fri, 11 Mar 2022 23:19:58 +0000
Received: by mail-yb1-xb31.google.com with SMTP id h126so19913638ybc.1 for <ietf-http-wg@w3.org>; Fri, 11 Mar 2022 15:19:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=glWuDkydT1McoguC9pDKyLDrmAv0fJwxpdPOfk+0mg4=; b=UfJDDZg296ilJK0iUTiIc+J/fBY27WsVqf6PjsjYMuohpRLx1EUwS6+YgKigLe5eKD KDHjn5obwCgImNIPm2F6nINbfW88waqHioEBp/9MPQ6rJRvTJVEEPmntvi5PEU21rDrD t4tCLp8PUIkMuxk44izK+zsHcK0YDgUyRGxEmxPLPRYC3QR8InBH2zDbyq4JUwftc8Cr ymmYuCZIH8mk4ikq3IHPT+Rvk/rXDl9+gPIm7m99BCueh4aUFRnpbLkmMiV7jWxEQR87 kyzZsFI+fSrEl7P5HZI9VJF3Asp1j/qbKOXIwPQIk88aVVw14jRli5Pu9dVmkmc9f4vf 1XYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=glWuDkydT1McoguC9pDKyLDrmAv0fJwxpdPOfk+0mg4=; b=Aa5sLvYKc7XkRBQaLa52o/NjhaZ74MIqa4HDw4SNyqWDT5KxzZ2qo5ibIyZPl/eK04 MqooXNjx5xbql09UCHoNGyduMGss8+GdgJzE08GlAEc4KQE0PJGHjqKCbV87ohE03OoE bEfI9W4y4LXuQCC4XeQBhiP4nFmWw2/aEhCAEkqkn5oXGa/n53wP43QnifvNlUKRX6pe sa2KVko6M1cr8nnUFwbBmwzewE90dTFeqglJpaRWB0FuNERJd0ecXjDKPiG1r2dtR1KI S10oYSNjd+RHGdC7ARifz/nOnTg+X6oZytgHDunWK8dYDRHkdWknBLSpKXnGub+yOckL Y9bQ==
X-Gm-Message-State: AOAM532BhuftCmEkfPvReqPZD3+OxnO/QNvKZQgz2R3xpJlE4vWBQnlP G35AXD1o9gY4wlqLlhlMQfKlkmwkNtrGoWNPoLp1bf/WfZpBxg==
X-Google-Smtp-Source: ABdhPJxKP1NmS2eIkDAI6rnVxZe631oHy0OG6TKS4nC4vzFhnskYoFj/MeAldBLgSI10P1LeHioOdKPqUHKjb2TQTpQ=
X-Received: by 2002:a25:30b:0:b0:62c:193:ebe9 with SMTP id 11-20020a25030b000000b0062c0193ebe9mr9673585ybd.159.1647040785702; Fri, 11 Mar 2022 15:19:45 -0800 (PST)
MIME-Version: 1.0
References: <164642784186.28316.13591675645652624288@ietfa.amsl.com> <CALGR9oauYKBC4P4u_g+j_tYmaO6e8zTk4CAAyPaTxdWxsa+WfQ@mail.gmail.com> <571555f7-bfb4-4da1-8e3a-2242ed0fcc8d@beta.fastmail.com> <CAJ_4DfQwJy7htpGjz8-YL_Xwi_JG7nykUrCaqG9rN4OUXM2grg@mail.gmail.com> <753038c1-b746-4899-9257-5f8f845e468d@beta.fastmail.com>
In-Reply-To: <753038c1-b746-4899-9257-5f8f845e468d@beta.fastmail.com>
From: Ryan Hamilton <rch@google.com>
Date: Fri, 11 Mar 2022 15:19:33 -0800
Message-ID: <CAJ_4DfSh70g1oc1K4DZambFXH8y3PrRim8kS4oifZhG5psNTYQ@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="000000000000f6ccbf05d9f9908a"
Received-SPF: pass client-ip=2607:f8b0:4864:20::b31; envelope-from=rch@google.com; helo=mail-yb1-xb31.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=rch@google.com domain=google.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-19.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1nSoY8-0008WR-NU 7ab769cc53133ae98b80957671904d88
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Fwd: New Version Notification for draft-duke-httpbis-quic-version-alt-svc-00.txt
Archived-At: <https://www.w3.org/mid/CAJ_4DfSh70g1oc1K4DZambFXH8y3PrRim8kS4oifZhG5psNTYQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/39889
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
On Wed, Mar 9, 2022 at 9:02 PM Martin Thomson <mt@lowentropy.net> wrote: > On Thu, Mar 10, 2022, at 10:46, Ryan Hamilton wrote: > > I don't think this is the case in Chrome. > > Ah, you whacky kids. :) > In a world where we have HTTPS records, I think that the need for Alt-Svc > goes back to its original intent: to manage how clients connect to > servers. It seems like Chrome has decided that this usage is not > interesting to it, a view to which you are entitled, but it means even less > interest in fixing Alt-Svc for this particular problem. > I'm not sure I understand what usage Chrome is not interested in? I'm super interested in making Alt-Svc as well designed as possible and am also a big fan of the HTTPS record. I *definitely* want to avoid extra round trips. Maybe I gave the wrong impression? > That doesn't mean that the problem is uninteresting. It just moves the > problem to HTTPS records. When an HTTPS RR says "h3", it would be really > nice if you could connect to the server without an extra round trip. For > that, there are several approaches we might consider. > > > A: Tight coupling > > If the one ALPN always identifies the QUIC version implicitly, then things > are fairly simple. This is awkward because QUIC v2 requires a new ALPN for > every protocol defined for QUIC v1. Practically speaking, this would > ensure that QUIC v2 is less practical to deploy, so I'd prefer not to go > here. > > > B: Baseline version > > If the ALPN identifies a baseline QUIC version and there is always a > compatible** version upgrade from that QUIC version to a newer one, then > you have to retain some support** for the baseline QUIC version in > perpetuity, but you don't pay a performance cost. > > This only works to the extent that the client and server both agree that > the new QUIC version can be used with the new QUIC version. Ben suggested > that new QUIC versions enumerate the protocols that can be used, which > seems awkward, but it might work (with the caveat that only important > protocols get the treatment, which might not create good dynamics). > > Here, by "compatible**", I mean that the versions support compatible > version upgrade as the QUIC version negotiation draft defines it, PLUS the > new QUIC version supports all the features in the baseline QUIC version > provides the application protocol. > > Here, by some "support**" it might be possible to only retain enough > support for the old QUIC version to perform a compatible version upgrade to > the new one. > > > C: Optimism > > If the ALPN label and QUIC version are just independent and the two could > be incompatible, then clients need to guess what is going to work and > potentially suffer a round trip if they guess wrong. > > This might sound crazy or haphazard, but I'm not sure that it is. This is > exactly the thinking that TLS uses with key shares. Clients guess what to > attempt and there is a process that takes an extra round trip for when they > guess wrong (HelloRetryRequest). In practice, that mechanism is basically > never used because everyone guesses X25519 and that guess is overwhelmingly > correct. > > The effect of this is that we don't have to specify anything really. > Let's say we do a QUIC v3 in a few years with some substantive changes. > That is either compatible** with QUICv2 or not. > > If QUIC v3 is compatible** with QUIC v1, then we can start deploying and > using it easily. Clients will probably stick to QUIC v1 most of the time, > but they will get QUIC v3 pretty often. At some point, when the usage of > QUIC v3 is high enough, clients might choose to start with that and risk a > version negotiation exchange if they guess wrong. That might take a while, > but at that point you can start to decommission QUIC v1. > > In the meantime, servers can make a call about how much QUIC v1 they > support. They could effectively disable QUIC v1 and only allow compatible > upgrades once all the clients they care about support QUIC v3. We've seen > that with older TLS versions; even though clients couldn't cut TLS 1.0 > support, some servers removed support a long time back. > > If QUIC v3 isn't compatible from a QUIC VN perspective, then clients won't > get QUIC v3 unless they start there. And there is a cost to guessing > wrong. That will probably dampen deployment prospects for QUIC v3, so I'm > not sure that I see this as a likely outcome. It might work if you follow > the asynchronous connection Alt-Svc paradigm, but we've established now > that not everyone does that, so the marginal utility is probably > questionable. > > If QUIC v3 starts out incompatible, but later develops QUIC VN > compatibility through an update, then it's somewhere between being > compatible** and incompatible: clients still risk an extra round trip by > attempting QUIC v3, but they won't always have to worry about paying that > cost. This too seems like a poor option; it's probably unlikely to happen. > > Note that if QUIC v3 isn't compatible from a feature-parity perspective, > then it won't be running HTTP/3, so this option isn't relevant. That's > option A, which means a new HTTP version and ALPN label. > > > D: Extra signaling > > This is where this draft is headed. I wasn't previously opposed to the > idea, but I'm much less sanguine about it after having written this all up. > In particular, it's hard to see an outcome where you can become reliant on > the signaling: HTTPS RRs are an essentially untrusted medium. While > Alt-Svc might be trustworthy, both mean that you have a tighter requirement > for coordination between server instances (across CDNs even). It > complicates processing and logic (a little). > > > Overall, I think that optimism is a reasonable strategy, at least for > now. We don't have to solve every problem with a specification; the sort > of loose coordination necessary to ensure that there is something clients > can use without extra round trips is totally achievable. So I can't see > much upside in doing extra signaling when doing nothing might just work out. > >
- Fwd: New Version Notification for draft-duke-http… Lucas Pardue
- Re: New Version Notification for draft-duke-httpb… Ben Schwartz
- Re: New Version Notification for draft-duke-httpb… Lucas Pardue
- Re: New Version Notification for draft-duke-httpb… Ben Schwartz
- Re: New Version Notification for draft-duke-httpb… Lucas Pardue
- Re: Fwd: New Version Notification for draft-duke-… Martin Thomson
- Re: Fwd: New Version Notification for draft-duke-… Ryan Hamilton
- Re: Fwd: New Version Notification for draft-duke-… Lucas Pardue
- Re: New Version Notification for draft-duke-httpb… Ben Schwartz
- Re: New Version Notification for draft-duke-httpb… Lucas Pardue
- Re: Fwd: New Version Notification for draft-duke-… Martin Thomson
- Re: Fwd: New Version Notification for draft-duke-… Ryan Hamilton
- Re: New Version Notification for draft-duke-httpb… Amos Jeffries
- Re: New Version Notification for draft-duke-httpb… Willy Tarreau
- Re: New Version Notification for draft-duke-httpb… Lucas Pardue
- Re: New Version Notification for draft-duke-httpb… Willy Tarreau
- Re: New Version Notification for draft-duke-httpb… Lucas Pardue
- Re: New Version Notification for draft-duke-httpb… Willy Tarreau