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

[Martin Thomson <[e-mail]>]

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.