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

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

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


:)


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