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

On Wed, Mar 9, 2022 at 3:32 PM Martin Thomson <mt@lowentropy.net> wrote:

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

I don't think this is the case in Chrome. Alt-Svc information is cached and
can be used after a period of quiescence. The QUIC connection is given a
head-start before starting the TCP connection attempt, so there is no
active connection open to the origin.

But maybe this was not the situation you were thinking of?

(There's also a detail in Chrome where if we have Alt-Svc information that
tells us a server can speak QUIC, but we don't have an existing QUIC
connection, we will attempt a QUIC connection. If the connection succeeds
in less than 1.25 RTT then the request will be sent over QUIC. Only if it
takes longer will it go over TCP. This behavior was somewhat accidental but
it is current behavior)

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