Subject: Re: [quicwg/base-drafts] Unclear what to do when QUIC Version Hints are missing (#3061)

From: Mike Bishop <[email-masked]>
Date: Fri, 04 Oct 2019 10:47:02 -0700

It's fine to omit this parameter.  As @Lekensteyn notes, if the client supports multiple versions of QUIC, this helps avoid the need to do Version Negotiation.  However, it's only an optimization -- in the absence of this information, the client does any version of QUIC it believes to be compatible with the ALPN token(s) it is offering.  If the server needs to do VN, it will.  (Details TBD, unfortunately.)

Is this critical to HTTP/3?  No, and it could reasonably be extricated to a separate document until such time that there are multiple QUIC versions.  Most stacks currently support only one version at a time, so this doesn't serve much purpose.  If HTTP/3 doesn't require breaking changes to keep up with QUICvN, this probably serves a purpose on the day there are several.

Personal opinion:  If anyone thinks this is half-baked, let's set it aside until we need it, with the rest of VN.  If we're fairly confident this is what we want, however, it saves us the trouble of defining another separate RFC later.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3061#issuecomment-538496167

---

From: David Schinazi <[email-masked]>
Date: Fri, 04 Oct 2019 16:31:21 -0700

I'm worried that relying on clients to "do the right thing" might cause serious performance issues down the road. I'd prefer to either have explicit guidance, or remove this mechanism until we understand it better as @MikeBishop suggests.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3061#issuecomment-538591213

---

From: Mike Bishop <[email-masked]>
Date: Mon, 07 Oct 2019 10:41:26 -0700

It was designed at a stage where QUIC had a fully-defined Version Negotiation mechanism.  The client could offer any version -- in fact, was *encouraged* to offer a grease version -- on the first flight, and would learn the server's list of versions in response.  But if you knew that list up front, either via Alt-Svc or because you've connected before, you could save a round-trip by selecting something that was on the list.  And if your information was wrong, or stale... oh well, you get a VN packet and learn the correct list.

Now, we don't have such a mechanism and receipt of a VN packet is fatal.  There are two ways to look at this:
- There is only one version, so we can define this mechanism once it can be paired with a version negotiation mechanism.
- Getting the server's version wrong is fatal, and therefore this mechanism is essential.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3061#issuecomment-539124679

---

From: Mike Bishop <[email-masked]>
Date: Fri, 18 Oct 2019 11:38:17 -0700

Closed #3061 via #3118.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3061#event-2725857663