Re: New Version Notification for draft-duke-httpbis-quic-version-alt-svc-00.txt

I would like to see this draft define a matching SVCB parameter as well.

This draft seems to be predicated on several assumptions about QUIC
versioning:
* The QUIC handshake will always be downgrade-resistant.
* There will soon be QUIC versions whose Initial cannot be parsed as QUICv1.
* After a QUIC version is defined, it will never gain support for an ALPN
that predates it.  (Otherwise, the client and server might disagree on
whether QUICvN supports the given ALPN.)  In principle, this requires that
definitions of new QUIC versions and new ALPNs do not occur concurrently.

Does the QUIC WG have consensus on these points?



On Mon, Mar 7, 2022 at 5:25 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> 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
>
>
>