Subject: [quicwg/base-drafts] Why do control streams need to be typed? (#2224)

From: ekr <[email-masked]>
Date: Thu, 20 Dec 2018 15:04:13 -0800

S 3.2.1.

```
Each side MUST initiate a single control stream at the beginning of the
connection and send its SETTINGS frame as the first frame on this stream.  If
the first frame of the control stream is any other frame type, this MUST be
treated as a connection error of type HTTP_MISSING_SETTINGS. Only one control
stream per peer is permitted; receipt of a second stream which claims to be a
control stream MUST be treated as a connection error of type
HTTP_WRONG_STREAM_COUNT.  If the control stream is closed at any point, this
MUST be treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM.
```

Rather than having this rule, wouldn't it be easier to just require
a specific stream number for this stream? Then it would not be possible to have >1.

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 20 Dec 2018 15:09:14 -0800

Using specific stream numbers goes against the transport/app isolation principle of not depending on specific stream numbers. I believe there was a long discussion on this. What if you suddenly choose to add an optional sub-control stream as an extension or future version, e.g. for a new kind of header compression? It gets messy quickly.

-- 
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/2224#issuecomment-449166191

---

From: ekr <[email-masked]>
Date: Thu, 20 Dec 2018 15:12:13 -0800

There's no such actual isolation, because of the implicit opening and the rules about which stream numbers are unidirectional and bidirectional, etc.

-- 
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/2224#issuecomment-449167341

---

From: Nick Banks <[email-masked]>
Date: Thu, 20 Dec 2018 15:28:37 -0800

@ekr I'd argue that depends on the implementation. With WinQuic there is no reason for the app layer to ever deal with a stream ID. Our API has a different flag for unidirectional/bidirectional streams. If the transport receives a high stream ID frame that ends up implicitly opening a number of streams, the app layer gets a callback indicating all those new streams have now been opened, with each callback containing the flag indicating unidirectional/bidirectional.

-- 
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/2224#issuecomment-449173046

---

From: MikkelFJ <[email-masked]>
Date: Thu, 20 Dec 2018 15:34:22 -0800

Is this isolation principle formulated anywhere btw., transport, or a companion governance'ish draft?

-- 
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/2224#issuecomment-449175126

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 20 Dec 2018 16:00:10 -0800

I'm working to implement the non-push HTTP/3 unidirectional streams at the moment, and it's really annoying to not know the "type" of a stream based only on the stream ID. Having to wait for the first byte of the payload to arrive has resulting in a bunch of implementation complexity. Different implementations may find difference experience, but I would LOVE it if we could just use stream ID to identify the http/3 control and qpack streams.

-- 
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/2224#issuecomment-449181949

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 20 Dec 2018 16:07:04 -0800

That train has sailed and the horse has left the station. We already had this discussion.

-- 
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/2224#issuecomment-449183121

---

From: ekr <[email-masked]>
Date: Thu, 20 Dec 2018 16:12:49 -0800

> That train has sailed and the horse has left the station. We already had this discussion.

That's not the way this process works.

-- 
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/2224#issuecomment-449184044

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 20 Dec 2018 16:21:25 -0800

There are reasons behind the current design. They were presented and discussed in Kista. I was against typed streams, but since the consensus had been reached, it's time to move on. Otherwise, we'll keep on arguing in circles and never be done.

-- 
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/2224#issuecomment-449185533

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 20 Dec 2018 17:46:59 -0800

Except that we now have new information, namely implementation (and soon deployment) experience.

-- 
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/2224#issuecomment-449209764

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 20 Dec 2018 17:59:59 -0800

IIUC using type byte gives us
the flexibility to have extensions that uses dedicated streams.

In H3, it is reasonable to assume that some extensions would use their own streams to avoid HoLB (consider the fact that QPACK uses dedicated streams compared to HPACK that does not).

We cannot pre-assign stream IDs to each extension, because the streams ID is something aasigned by the transport in the order they are being created.

Therfore, we need the type byte.

-- 
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/2224#issuecomment-449213755

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 20 Dec 2018 18:24:52 -0800

@RyanAtGoogle writes:
> Except that we _now_ have new information, namely implementation (and soon deployment) experience.

Now? I've had it for some time: the type byte has caused me exactly zero problems.

-- 
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/2224#issuecomment-449218934

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Dec 2018 20:09:56 -0800

Oh, if we're having this discussion again, I'd like to point out that the type byte simplified my implementation considerably.  That was all part of the discussion last time around though.  I'm not seeing new information.

-- 
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/2224#issuecomment-449239697

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 20 Dec 2018 21:21:23 -0800

We've also implemented this and it has not been a problem.

-- 
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/2224#issuecomment-449256998

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 21 Dec 2018 14:34:27 -0800

I implemented this in nghq with minimal fuss.

The stream space is already most stolen by HTTP/3 core behaviour. Client bidi streams are for request/response only. Server bidi streams are useless. Unidi streams are the only escape valve for anyone want to to anything interesting without horrible hacks like the CONNECT method.

-- 
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/2224#issuecomment-449514960