- From: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Date: Mon, 7 Mar 2022 22:21:46 +0000
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Martin Duke <martin.h.duke@gmail.com>
- Message-ID: <CALGR9oauYKBC4P4u_g+j_tYmaO6e8zTk4CAAyPaTxdWxsa+WfQ@mail.gmail.com>
Hello HTTP WG, We published draft-duke-httpbis-quic-version-alt-svc [0], please see the forwarded email for more details. To jog your memories, HTTP/3 [1] chose the "h3" ALPN name and linked it to QUICv1. This value is used for Alt-Svc adverts and the real ALPN extension in a QUIC handshake. HTTP/3 punted on defining how endpoints might agree on the use of other QUIC versions. Over in the QUIC WG we have continued to think about transport-level version negotiation, and something that has come up a few times is the effect on HTTP/3. While different solutions have been thrown around, the common set of goals appears to be 1) avoid having to support QUIC v1 forever 2) avoid a version-negotiation-triggered-roundtrip. To address these goals, draft-duke-httpbis-quic-version-alt-svc opts to define a new "quicv" Alt-Svc parameter that contains a preference ordered list of QUIC versions supported by the alternative. Clients that understand the parameter stand a better chance of selecting a more desirable QUIC version without triggering a negotiation. Using an Alt-Svc parameter for QUIC version hinting isn't particularly novel; older revisions of HTTP/3 [2] [3] tried different styles until the matter was punted. However, given how QUIC version matters are evolving, and that the HTTP WG has RFC 7838bis open currently, now seems like a good time to consider formalizing a parameter and lock down the format. Cheers, Lucas On behalf of the draft authors [0] - https://datatracker.ietf.org/doc/html/draft-duke-httpbis-quic-version-alt-svc [1] - https://tools.ietf.org/html/draft-ietf-quic-http-34 [2] - https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-00 #section-2 [3] - https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-02#section-2.1 ---------- Forwarded message --------- From: <internet-drafts@ietf.org> Date: Fri, Mar 4, 2022 at 9:04 PM Subject: New Version Notification for draft-duke-httpbis-quic-version-alt-svc-00.txt To: Lucas Pardue <lucaspardue.24.7@gmail.com>, Martin Duke < martin.h.duke@gmail.com> A new version of I-D, draft-duke-httpbis-quic-version-alt-svc-00.txt has been successfully submitted by Martin Duke and posted to the IETF repository. Name: draft-duke-httpbis-quic-version-alt-svc Revision: 00 Title: An Alt-Svc Parameter for QUIC Versions Document date: 2022-03-04 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/archive/id/draft-duke-httpbis-quic-version-alt-svc-00.txt Status: https://datatracker.ietf.org/doc/draft-duke-httpbis-quic-version-alt-svc/ Html: https://www.ietf.org/archive/id/draft-duke-httpbis-quic-version-alt-svc-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-duke-httpbis-quic-version-alt-svc Abstract: HTTP Alternative Services (Alt-Svc) describes how one origin's resource can be accessed via a different protocol/host/port combination. Alternatives are advertised by servers using the Alt- Svc header field or the ALTSVC frame. This includes a protocol name, which reuses Application Layer Protocol Negotiation (ALPN) codepoints. The "h3" codepoint indicates the availability of HTTP/3. A client that uses such an alternative first makes a QUIC connection. However, without a priori knowledge of which QUIC version to use, clients might incur a round-trip latency penalty to complete QUIC version negotiation, or forfeit desirable properties of a QUIC version. This document specifies a new Alt-Svc parameter that specifies alternative supported QUIC versions, which substantially reduces the chance of this penalty. The IETF Secretariat
Received on Monday, 7 March 2022 22:22:11 UTC