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

From: Lucas Pardue <[email-masked]>
Date: Mon, 7 Mar 2022 22:21:46 +0000

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: <[email-masked]>
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 <[email-masked]>, Martin Duke <
[email-masked]>

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

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 9 Mar 2022 14:44:39 -0500

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?

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 9 Mar 2022 20:01:14 +0000

Hi Ben

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

A matching SVCB parameter sounds like a sensible design choice. From a
process perspective is HTTP WG a suitable venue to pursue that?

> Does the QUIC WG have consensus on these points?

Your two first points seem accurate, although I'll defer to the VN experts
in the room to state definitively.

On the third point I'm not sure I follow what you are saying. Imagine a
QUIC version ("bob") was defined that was incompatible with QUIC v1. Let's
say it removed client-initiated bidirectional streams. The "bob" version
can't support the predated "h3" ALPN because the HTTP/3 mapping onto QUIC
would be broken. Somebody could define a new mapping that used a pair of
uni streams for request and response, that mapping would need a different
ALPn value than "h3". In such a scenario don't think there is a hard
requirement on concurrent definitions. But what's needed I people
understanding what features of the QUIC transport version they use, and
what incompatible means.

Cheers
Lucas

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 9 Mar 2022 15:19:01 -0500

> process perspective is HTTP WG a suitable venue to pursue that?

I'm not a relevant WG chair but it seems fine to me, subject to DNSOP
cross-review.

> ALPn value than "h3".

QUICvBOB could be accompanied by a document defining this split-stream
mapping for "h3" under the existing ALPN.  That's fine.  My point is,
nobody can resurrect the "h3" ALPN for QUICvBOB if "h3" wasn't initially
supported by QUICvBOB, so it would need a new ALPN value as you describe.

My question is: is the QUIC WG willing to commit to this restriction?  If
the QUIC WG wants the ability to restore unsupported ALPNs for published
QUIC versions, that's possible, but it would require a different encoding
for QUIC version hints in Alt-Svc.

> In such a scenario don't think there is a hard requirement on concurrent
> definitions.
>

If Alice is writing a draft defining the "alice" ALPN, and Bob is writing a
draft defining QUICvBOB, it needs to be unambiguous whether they are
compatible.  If the drafts are racing, things could get confusing if either
says "supports all versions of QUIC" or "supports all QUICv1 ALPNs" or
similar.

I'm not actually worried about this.

But what's needed I people understanding what features of the QUIC
> transport version they use, and what incompatible means.
>

My point is that this understanding has to be frozen at the moment a QUIC
version is defined.

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 9 Mar 2022 22:48:54 +0000

Hi Ben,

> I'm not a relevant WG chair but it seems fine to me, subject to DNSOP

That makes sense to me.

>>> * 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
>> Your two first points seem accurate, although I'll defer to the VN
>> experts in the room to state definitively.
>>

Speaking with no hats: that sounds like a dependency inversion to me. The
QUIC WG is not the best venue for defining application protocols that use
QUIC. HTTP/3 is a notable exception, a shared responsibility between QUIC
and HTTP WGs that made sense while QUIC v1 and HTTP/3 were being developed
in tandem. HTTP/3 ownership is now back in HTTP WG hands. I would expect
future application mappings for QUIC to be defined in the most suitable
WG*. DNS over QUIC is a good example: the work has been done in DRPIVE and
they are responsible for defining their ALPN.

So I would not expect a QUICvBOB document to make any commentary about
application protocol specifics, especially not trying to port around
mappings from version to version. That sounds like it could easily go awry
and not fit the needs of the originators. Instead, I would expect QUICvBOB
gets developed with a driving use case that probably occurs concurrently
with another application mapping. Anything other application protocol that
exists would then have to do its own analysis to decide if writing a new
mapping is worth it.

> If Alice is writing a draft defining the "alice" ALPN, and Bob is writing
> a draft defining QUICvBOB, it needs to be unambiguous whether they are

> My point is that this understanding has to be frozen at the moment a QUIC

Coordination and phrasing is important here but I don't think we have
enough experience to make firm recommendations quite yet.

An "alice" ALPN doesn't represent an abstract concept, it is a real
bytes-on-the-wire and transport state dependent machination. I would
generally discourage anyone making a statement like "application mapping
$foo works for for all versions of QUIC" because that is easily
falsifiable.". Instead something like "this mapping is defined for QUIC v1,
and it is expected to work with other QUIC versions that are compatible
with v1" is more likely to hold true. Since the mapping _has_ to describe
how transport features are used, it doesn't seem too hard to predict what
would be incompatible. However, that depends on definitions of compatible
or incompatible to some extent.

Cheers,
Lucas

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 10 Mar 2022 10:29:17 +1100

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.
>
>
> 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.
>
>
> 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. 
>
>
> 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
>
> [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
>
>
>
>
> To: Lucas Pardue <[email-masked]>, Martin Duke 
> <[email-masked]>
>
>
>

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 9 Mar 2022 15:46:06 -0800

On Wed, Mar 9, 2022 at 3:32 PM Martin Thomson <[email-masked]> wrote:

> 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
>
> > [2] -
> https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-00#section-2
> >
> > [3] -

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 10 Mar 2022 00:57:37 +0000

Hi,

Responding to Martin and Ryan in one swoop

On Wed, Mar 9, 2022 at 11:49 PM Ryan Hamilton <[email-masked]> wrote:

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

This is an important consideration and I'd like to poke at it more.

I increasing feel that Alt-Svc is in the eye of the beholder. That's to
say, the client implementation details drive how the interaction with QUIC
services actually play out, with sometimes very unfortunate and opaque
consequences as we've mentioned in the "Alt-Svc and Multi-CDN" issue [1]
filed against 7838bis.

The async upgrade case masks some pitfalls and tends to works only on the
first visit. In cases where a return visit nrequires the user agent to
create a new connection and it uses a cached entry, or it would try to use
information from HTTPS / SVCB, the client is more likely to have to pay the
extra round trip.

Cheers,
Lucas

[1] - https://github.com/httpwg/http-extensions/issues/1673

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 9 Mar 2022 21:30:22 -0500

On Wed, Mar 9, 2022 at 5:49 PM Lucas Pardue <[email-masked]>
wrote:
...

> QUIC.

Agreed, that's not what I meant.

> DNS over QUIC is a good example: the work has been done in DRPIVE and they
> are responsible for defining their ALPN.
>

Sure.  QUICvBOB comes out, and then the DPRIVE working group says "great,
here's a draft showing how to do DoQ on QUICvBOB".  If we
publish draft-duke-httpbis-quic-version-alt-svc*, DPRIVE cannot use "doq"
as the ALPN for this, because "doq" predates QUICvBOB and QUICvBOB did not
support "doq" at inception.  Someone might already have deployed a server
that supports QUICv1 and QUICvBOB, and supports "doq" on QUICv1 but not on
QUICvBOB, because the latter combination was not  yet defined.

* and extend this logic to other discovery modes such as SVCB

The negotiation pattern implied by draft-duke-httpbis-quic-version-alt-svc
requires a restriction on how ALPNs and QUIC versions interact.  This
restriction is fine with me, but (1) I want to make sure it's fine with
QUIC WG, and (2) I think it should be written down somewhere.

> exists would then have to do its own analysis to decide if writing a new

In this sequencing, ALPN values will never be reused across QUIC versions,
so (paradoxically) there is no need for
draft-duke-httpbis-quic-version-alt-svc.

I would prefer a norm that new QUIC version drafts enumerate all the
pre-existing ALPNs that are supported, and new ALPN drafts enumerate all
the pre-existing QUIC versions that are supported.  (But we're on the wrong
mailing list for that discussion.)

...

> enough experience to make firm recommendations quite yet.

I'm making a purely logical claim: if the client is only provided with
information about the server's supported ALPNs and QUIC versions
(independently), the QUIC handshake is only guaranteed to complete
successfully if the client and server agree on which ALPNs can be used on
which QUIC versions.  That means that this information cannot ever change
(unless _all_ servers can be updated before _any_ clients).

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 10 Mar 2022 04:08:48 +0000

On Thu, Mar 10, 2022 at 2:30 AM Ben Schwartz <[email-masked]> wrote:

>>> My question is: is the QUIC WG willing to commit to this restriction?
>>> If the QUIC WG wants the ability to restore unsupported ALPNs for published
>> DNS over QUIC is a good example: the work has been done in DRPIVE and

The model I have, and others might disagree  (and which might not be
expressed well in the draft and as such we'd need to address), is that
these version hints are for compatible versions of QUIC related to the
Alt-Svc entry that has a single ALPN. For example, QUIC v1 and v2 are
compatible and as far as the H3 mapping is concerned, identical. The
example given in the spec is

Alt-Svc: h3=":443"; quicv="709a50c4,1"

If we publish QUICvBOB and it is incompatible, then H3 on QUICvBOB IMO
needs new application mapping and a new ALPN. For example "h3bob". Trying
to overload ALPN IDs for all version of QUIC whatever might come is
dangerous. On the other side of the coin, defining new ALPNs for *every*
variant of a QUIC version is a great way to DoS the IETF and IANA
processes.

In this scenario, if we defined QUICvBOBthesecond, as compatible with
QUICvBOB but incompatible with QUIC v1 and v2, then I might expect an
Alt-svc like

Alt-Svc: h3bob=":443"; quicv="b0b2,b0b1", h3=":443"; quicv="709a50c4,1"

> mailing list for that discussion.)

That seems an intrinsic quality of declaring a version to be compatible
with another QUIC version. Listing things out doesn't seem useful in a QUIC
version document itself. New ALPN drafts are really the application mapping
documents I mentioned, there it does seem more useful to declare a set of
incompatible versions of QUIC that are known to be explicitly targeted by
the mapping.

There is value in the IETF community coordinating on these things, we
should try to make affordances for that. But the QUIC WG is not best placed
to run continued analysis on application protocols that it didn't develop
and doesn't maintain.

Cheers
Lucas

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 10 Mar 2022 15:59:06 +1100

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.  

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

Indeed not.

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.

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.

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 11 Mar 2022 15:19:33 -0800

> > I don't think this is the case in Chrome.

:)

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

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 13 Mar 2022 00:48:43 +1300

On 10/03/22 17:08, Lucas Pardue wrote:
> needs new application mapping and a new ALPN. For example "h3bob". 
> Trying to overload ALPN IDs for all version of QUIC whatever might come 
> is dangerous. On the other side of the coin, defining new ALPNs for 
> *every* variant of a QUIC version is a great way to DoS the IETF and 
> IANA processes.
> 

AIUI, HTTP assigns a new version to each unique transport mapping. So 
QUICvBOBthesecond by virtue of needing a new mapping gets a new HTTP 
version number and ALPN assigned anyway.

I for one support the draft-duke-httpbis-quic-version-alt-svc proposal.

Though I punt/abstain from having an opinion on whether it should be 
added to rfc7838bis.

Amos Jeffries

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 12 Mar 2022 17:39:52 +0100

Hi Lucas,

On Thu, Mar 10, 2022 at 04:08:48AM +0000, Lucas Pardue wrote:
> dangerous.

I disagree with this. The upper-level protocol indeed defines a mapping,
but that mapping is not exclusive. We didn't rename HTTP/1.1 to 1.2 when
its mapping over TLS was clarified for example. Instead a new RFC would
be emitted to explain how to map H3 to QUICvBOB. This is far more desirable
because it allows preservation of all the protocol details from end to end
when only the mapping changes. Imagine for example a QUICv1 to QUICvBOB
gateway. It would only have to deal with the change of mapping but does
not need to redefine a new protocol. Encoding, flow control, compression
etc wouldn't need to change. I the worst case an updated protocol spec
would be emitted, listing the various known mappings, and would take
that opportunity to fix errata and that would be all.

Given that QUICvBOB wouldn't know "h3" ALPN by default, it would make
sense to reuse the same ALPN precisely to indicate that it's exactly the
same protocol but mapped differently (the mapping being dependent on the
protocol stack).

> On the other side of the coin, defining new ALPNs for *every*

Indeed ;-)

Willy

---

From: Lucas Pardue <[email-masked]>
Date: Sat, 12 Mar 2022 17:23:46 +0000

Hey Willy,

> same protocol but mapped differently (the mapping being dependent on the

I don't agree with this position. We have come a long way in refining our
concepts and terminology of semantic HTTP and wire specific messaging. I'm
very excited for when we get all the HTTP RFCs published soon and we have a
consistent set of documents.

Before ALPN we had schemes and port numbers. Those things have become moot,
we will likely always expect semantic HTTP over QUIC to use https and be on
UDP 443. Having a way to signal the mapping onto a specific version is
important. We started out calling it HTTP/2 over QUIC but that was
confusing. I think it might be similarly confusing HTTP/3 over QUICvBOB,
rather than just HTTP/4 (this speaks to Amos' reply  elsewhere).

I think domenof how this will play put will depend exactly on what change
future QUIC versions bring. I think most forms of change will turn out to
be completely invisible to applications and they can live without the
worry. What I mean by this is changes that affect transport behaviour or
performance can affect applications but the API presented to the
application layer (connection lifetime, reliable streams lifetime) is
untouched.

Cheers
Lucas

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 12 Mar 2022 19:10:43 +0100

On Sat, Mar 12, 2022 at 05:23:46PM +0000, Lucas Pardue wrote:
> concepts and terminology of semantic HTTP and wire specific messaging.

But note that what we usually call "wire" really has nothing to do with
the wire but rather with the immediate next layer when going down the
stack. Similarly H3 is not renamed when QUIC is transported over IPv6
(or possibly even datagram UNIX sockets) and those are different
"on-wire" representations as well.

If the next version of QUIC is incompatible with V1 (say different
packet format) but provides similar streams, there's no reason why H3
would have to be mapped differently and it will certainly remain H3. But
then if more substantial changes happen, for example let's say that like
in H2, QUICvBOB starts to expose the stream number as a preambule of the
stream frames, and that nothing else changes, it's perfectly possible
that we'll just see an updated RFC saying "H3 frames are prefixed with a
32-bit stream ID when mapped on QUICvBOB and for the rest, please refer
to RFCxxxx".

And after all there's HTTP/0.9 on top of QUIC which wasn't renamed 2.9
or stuff like that.

I think it's important to plan for the possibility to have to rename
the protocol if it's not possible to map it (or if it doesn't make
sense for efficiency reasons), but I don't think we'd need to make this
mandatory at all.

Cheers,
Willy

---

From: Lucas Pardue <[email-masked]>
Date: Sat, 12 Mar 2022 19:05:58 +0000

Hey Willy,

> 32-bit stream ID when mapped on QUICvBOB and for the rest, please refer

Right now, QUIC stream abstractions are available for applications to use.
It doesn't really matter so much how streams are framed or packetized. If
something changes the abstraction in a way that requires a change in the
application mapping, that sounds like a breaking change.

> And after all there's HTTP/0.9 on top of QUIC which wasn't renamed 2.9

That's not a formally standardised protocol, it was used mainly for interop
in the early days with success, and continues to drive transport oriented
testing in e.g. the interop runner. But it does use QUIC streams according
to the abstraction that v1 provides. Because the streams themselves and the
bytes-on-stream format have special meaning it is indeed an application
mapping and it has a few ALPNs "hq", "hq-interop" that help endpoints
figure out what they are doing.

Maybe we could take a leaf put of user,agent strings and call it "hq (like
HTTP/0.9)" :-)

> sense for efficiency reasons), but I don't think we'd need to make this

Totally agreed! Apologies if it appeared i was making blanket statements
about the future.

ALPN tokens are not the easiest wat to articulate the nuances that we have.
The application protocol is HTTP, yet we use ALPN to describe the
intermediate representation in between. It's a sticky situation. We will
have to consider these questions as the transport layer changes and make
our best determination at the time.

This is also part of why I think asking QUIC WG to make judgement calls
about how future versions will affect applications is a bit futile. They
should inform but not dictate.

Cheers
Lucas

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 13 Mar 2022 06:04:39 +0100

Hi Lucas,

> application mapping, that sounds like a breaking change.

Yes seen like this I agree. I mean that there's always one form of
encapsulation or representation for a protocol to be carried inside
another (except when dealing with purely infinite byte streams), and
that often the adaptations required when the lower one changes can be
seen as part of the mapping that comes from the new one.

> Totally agreed!

OK then I think we're on the same line and possibly you're thinking
about more breaking changes than I was envisioning, which is why we both
have different appreciations on this.

> Apologies if it appeared i was making blanket statements about the future.

No need to apologize :-)

> ALPN tokens are not the easiest wat to articulate the nuances that we have.

Indeed! It's even more difficult in QUIC because there's one extra layer
that was not visible before and it's easy to make the confusion between
each layer and their respective mapping. Even in haproxy we made the
mistake, the other day I noticed "proto quic" on a "bind" line, and I
said the guys "it should be h3 here, not quic since that's the same
name as the one that comes from ALPN", and they said "hmmm indeed you're
right" :-)

> intermediate representation in between.

It's not "just" HTTP because with different versions come different
possibilities even at the application level. For example, HTTP/1.1
brought 100-continue and new methods, H2 brought push and initially
lost websocket (before 8441), etc. Thus the application layer is
interested by the version, and the version is not simply a matter of
mapping to a transport layer, even if we all know that usually they
come together.

> It's a sticky situation. We will

Most likely yes. And I'm pretty sure we'll see H4 on top of the next QUIC
anyway because we'll want to address newly discovered shortcomings in an
incompatible way.

> should inform but not dictate.

I agree. Eventhough I'm a low-level networking guy, I'm well aware that
lower layers are here to serve the upper ones, not the opposite.
Limitations and suggestions ought to be communicated upstream but that's
all.

Willy