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

[Martin Thomson <[e-mail]>]

Sacrilegious thought: maybe we shouldn't care about solving for latency with Alt-Svc.

Alt-Svc connections are made asynchronously, while there is an active (and usable) connection open to the origin.  We can afford the extra round trips here.

Spending extra round trips while doing Alt-Svc (that is while we can afford it) might ensure that the system is capable of supporting all of the mechanisms we have built for the purpose of robustness: QUIC Version Negotiation packets, QUIC retry, TLS HelloRetryRequest, TLS ECH fallback, version negotiation greasing, address validation, massive PQ-capable handshake messages, etc...  While I wouldn't want to pile all of those things on at the same time (10 RTT handshake anyone?) it seems like exercising those mechanisms in a no-pressure situation might be a good thing.

Now, as to whether we might optionally have a smoother path, rather than essentially forcing additional round trips in some situations, that's where this work might come in.  But I'm far less clear on the virtues of a save-every-round-trip policy in light of the above.

Cheers,
Martin

On Tue, Mar 8, 2022, at 09:21, Lucas Pardue 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: <[e-mail]>
> 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 <[e-mail]>, Martin Duke 
> <[e-mail]>
>
>
>
> 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