Subject: [quicwg/base-drafts] HTTP/3 references QUIC Stream IDs directly, allowing illegal references (#3273)

From: ianswett <[email-masked]>
Date: Sat, 23 Nov 2019 11:25:25 -0800

Currently, HTTP/3 references QUIC Stream IDs directly in the case of requests.  However, requests are only 1 of the 4 stream types, so 3/4 of the values in GOAWAY are currently invalid, though we don't specify what happens if you receive one of those invalid values in the current draft(or I missed it).

QUIC transport has moved to a design for MAX_STREAMS(https://tools.ietf.org/html/draft-ietf-quic-transport-24#section-19.11) that specifies the allowed number of streams of a given type, rather than the Stream ID.

Currently, this is a very minor point, since it's only the GOAWAY frame that references Stream ID, but future frames, such as the PRIORITY_UPDATE frame from the HTTP priorities draft will also want to reference the Stream ID, as will future extension frames I expect.

So I suggest we call this a Request ID and it's the Stream ID of a client bidi stream right shifted 2 bits or however else we'd like to describe 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/3273

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 24 Nov 2019 16:59:42 -0800

While I agree that such a design is possible, I am in favor of using stream IDs as they are, because that is what we have done in HTTP/2.

To be precise, HTTP/2 has stream 0 (which is used for transmitting control messages), odd-numbered streams (for carrying requests), even-numbered streams (for carrying pushed requests).

To paraphrase, we have had these ID holes in HTTP/2, and we haven't had issues (I assume). We've already built our infrastructure around this design, for example, we simply log the stream ID and hope that that would be sufficient to identify the request, regardless of it being one initiated by the client or one being pushed by the server.

Introducing the concept of "request ID" would be a departure from this design in HTTP/2. As there would be a different number space for pushed requests, we'd be required to change the logging structure to convey a tuple of request-type and request-ID. While that is not impossible, I am not sure if that change is worth the cost.

-- 
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/3273#issuecomment-557949331

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 25 Nov 2019 12:05:20 -0800

I think this issue came up in Cupertino and the current approach was about as close to consensus as any of the alternatives. I don't feel strongly either way which makes me somewhat inclined to leave things alone.

-- 
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/3273#issuecomment-558319125

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 25 Nov 2019 17:03:04 -0800

> Introducing the concept of "request ID" would be a departure from this design in HTTP/2. As there would be a different number space for pushed requests, we'd be required to change the logging struc…

Not to mention having to maintain a Request ID -> Stream ID mapping.  I agree with @kazuho.

-- 
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/3273#issuecomment-558411240

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Nov 2019 17:09:23 -0800

This suggestion was considered and discussed already as part of the decision to add push identifiers.  I don't see any new information here.

-- 
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/3273#issuecomment-558412577

---

From: ianswett <[email-masked]>
Date: Tue, 26 Nov 2019 21:36:32 -0800

This seems a bit at odd with our design principles, since it requires the HTTP/3 implementation to understand the QUIC Stream ID numbering scheme.   In our implementation that's viable and it probably is in others.  The current text says:
  "A client MUST treat receipt of a GOAWAY
   frame containing a Stream ID of any other type as a connection error
   of type H3_ID_ERROR."

I don't remember us discussing this particular detail of GOAWAY in Cupertino, but I also wasn't very invested in the GOAWAY discussion, so I believe I missed it.

To be clear, the Request ID -> Stream ID mapping is multiplying by 4 in this case.  There is no state required.

TLDR: This seems weird, but I'm ok with closing with no action if others don't care to fix the oddity.

-- 
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/3273#issuecomment-558937211

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 27 Nov 2019 06:53:56 -0800

> I don't remember us discussing this particular detail of GOAWAY in Cupertino, but I also wasn't very invested in the GOAWAY discussion, so I believe I missed it.

I think it was on the last day:

https://github.com/quicwg/wg-materials/blob/master/interim-19-10/minutes.md#next-issue-goaway-see-above

-- 
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/3273#issuecomment-559120238

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 27 Nov 2019 07:17:05 -0800

I find it easier to refer to Stream IDs because that's what STOP_SENDING and RESET_STREAM use. Having some other value sent on the wire seems like a good way to get interop problems, especially because the first request would have stream ID 0 and 0*4 = 0.

-- 
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/3273#issuecomment-559129785