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

From: David Schinazi <[email-masked]>
Date: Mon, 23 Sep 2019 16:49:29 -0700

[draft-quic-http defines QUIC Version Hints](https://tools.ietf.org/html/draft-ietf-quic-http-23#section-3.2.1). This allows the server to indicate which versions of quic-transport it prefers. However, there is no guidance as to what to do in the absence of such hints.

If a client receives `Alt-Svc: h3=":443"` (without any hints), is it expected to start with QUIC version 1, or with the client's preferred QUIC version?

If a client receives `Alt-Svc: h3-23=":443"`, is it expected to start with `0xff000017` (draft-ietf-quic-transport-23)?

We may want to provide guidance in draft-quic-http to ensure everyone's on the same page.

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

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 23 Sep 2019 17:20:28 -0700

I happy to be proven wrong but it seems like noone uses this parameter and it raises all sorts of questions. I'm leaning towards killing it off. 

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

---

From: Peter Wu <[email-masked]>
Date: Mon, 23 Sep 2019 17:23:46 -0700

The Version Hints presumably exist to avoid one roundtrip for the [Version Negotiation packet](https://tools.ietf.org/html/draft-ietf-quic-transport-23#section-17.2.1). Thus without hints, a client could probably decide to use any version it supports (1 or whatever latest version it desires to use).

FWIW Google uses alt-svc, but I do not remember seeing the version hint *parameters*. For example:
```
$ curl -sI https://google.com | grep alt-svc
alt-svc: quic=":443"; ma=2592000; v="46,43,39"
```

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

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 23 Sep 2019 17:25:23 -0700

in this case the "v" parameter is comparable to the "quic" parameter

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

---

From: Peter Wu <[email-masked]>
Date: Mon, 23 Sep 2019 17:27:52 -0700

Right, but that `v` is a parameter on its own whereas `quic` is a parameter value in the current -http draft.

Removing the `quic` parameter was previously suggested in #297, but that did not seem to proceed.

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

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 23 Sep 2019 17:37:34 -0700

@LPardue I also lean towards killing it off. However, that would prevent us from doing something like:

h3=":443", quic="1,2"

At some future date when we have QUICv1 and QUICv2 and we want to support HTTP/3 over either of them. Does that seem problematic?

Of course, if the alpn continues to imply the transport version and HTTP+QUICv2 == HTTP/4 then we wouldn't ever need to advertise this.

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

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 23 Sep 2019 17:51:34 -0700

That's a compelling argument, I'm just concerned that we aren't seeing this used much today and so when the time comes that you'll need it, it won't work as we all hoped. Perhaps we could _defer_ the quic parameter until v2 - similar to other VN related issues.

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 23 Sep 2019 18:09:50 -0700

> Perhaps we could _defer_ the quic parameter until v2 - similar to other VN related issues.

I think the question is if we expect changes in the application protocol (i.e. HTTP/3) when we define QUIC v2.

If we suspect that H3 would remain as-is for QUIC v2 (I'd assume that would be the case if v2 is going to be greasing or multi-path), then it would be reasonable to define the transport version identifier of the Alt-Svc header in H3.

If we are uncertain, I do agree that it might be a good idea to defer it.

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

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 23 Sep 2019 18:22:12 -0700

We also have a hard time testing this today - there is no standard legal valid combination of "h3-N" and quic versions that would allow a client to select one QUIC version over another. Perhaps this was a motivator for https://github.com/quicwg/base-drafts/issues/3062?

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