Subject: [quicwg/base-drafts] Need to clarify QUIC stream usage in HTTP/2 mapping (#1882)

From: Magnus Westerlund <[email-masked]>
Date: Thu, 18 Oct 2018 02:23:14 -0700

I tried reading the HTTP/2 mapping draft (-15) to answer a question regarding the QUIC stream usage by HTTP/2 over QUIC. And that failed misserably until I looked at the slides from Montreal IETF meeting. 

Where I think there are need for clarification are:

Section 3.: Here a general overview of the how the four streams per HTTP request are used and assigned. Currently it says that client bi-directional will be every fourth 0,4, 8 etc. Nothing more aobut which streams are which of the remaining three, not even which names are used for them. 

In Section 3.3.3 the first mention of the word "push stream" occurs. That appears to indicate that a unidirectional stream that starts with a 0x43 stream type is then barred from use by any other stream type. I think 3.3 has to be clearer that the usages of unidirectional streams are not necessarily connected to the HTTP request response happening on the bi-directional stream. And that implementations needing a new unidirectional stream simple takes the next free (X+2/3) mod 4 depending on direction. 

I think it would be good to exemplify in the HTTP draft that a connection for HTTP/2 will have a number of unidirectional streams that are used long term or some short term and then closed and that one can't rely on stream ID being in the group related to a particular request. 

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

---

From: Mike Bishop <[email-masked]>
Date: Thu, 18 Oct 2018 09:23:18 -0700

Can you take a look at the [reorganized version](https://quicwg.org/base-drafts/reorganize/draft-ietf-quic-http.html#rfc.section.3)?  I'm sure there's still room to improve, but I think the use of different stream types should be clearer.

I'm explicitly trying to avoid assuming which Stream IDs will be which stream types in the HTTP spec, because that could change in a future version of QUIC.  The place where I do, I should probably caveat it with "In version 1 of QUIC...."

-- 
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/1882#issuecomment-431073596

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 29 Oct 2018 10:24:21 +0000 (UTC)

Yes, the actual use of the different streams, especially the different unidirectional are clearer. What is not clear is how one determine which QUIC streams are bi-directional client (or server) initiated or unidirectional in a particular direction. The only indication of that is that client intiated bi-directional are the ones numbered as x mod 4 == 0. So that needs to be clarified. 

And isn't the stream usage defined by this document? From QUICs perspective it has bi-directional streams from 0 to 2^62-1 and that all. Either you define the pattern for which main class each QUIC stream has based on its steam ID or we need to add a explicit signalling for that also at stream start. 

-- 
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/1882#issuecomment-433859009

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 29 Oct 2018 03:41:49 -0700

IMO this is covered by the transport doc in [section 2](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.2).

```

Low Bits | Stream Type
-- | --
0x0 | Client-Initiated, Bidirectional
0x1 | Server-Initiated, Bidirectional
0x2 | Client-Initiated, Unidirectional
0x3 | Server-Initiated, Unidirectional
```

The theoretical HTTP implementation can ignore server-initiated bidirectional altogether. A server just needs to watch for incoming client-initiated streams, a client just needs to send them. Unidirectional streams are only TX or RX from the endpoint in the frame of reference.

-- 
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/1882#issuecomment-433864016

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Oct 2018 11:43:23 -0700

No, unidirectional/bidirectional is a QUIC concept.  I'm deliberately not stating the mapping, as it could change in a future version of QUIC.  The direction/initiator are properties of a stream, and the ID is a property of a stream.  Any correlation between those properties is QUIC's business, not HTTP's.

(Technically, the existence of streams could change in a future version of QUIC, but I'm content to take that much dependency.)

-- 
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/1882#issuecomment-434030672

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 31 Oct 2018 00:55:13 -0700

Okay, I had missed that this was added in -16. I am actually not thrilled that this went into QUIC, I might have missinterpreted the discussion as being all in the context of HTTP. Anyway, can you please adjust the text in Section 3, so that it clearer states that QUIC transport defines the terms and meaning of bidirectional and unidirectional streams and that there are two stream versions depending on who that initiates it. And please with a correct section reference into the transport draft. Pointing at section 9 when it is section 2 does not help. 

-- 
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/1882#issuecomment-434593243