Subject: Re: [quicwg/base-drafts] Is zero a valid stream-ID in Transport Parameters? (#1023)

From: martinduke <[email-masked]>
Date: Mon, 08 Jan 2018 04:05:48 +0000 (UTC)

It seems harder to check the stream_id is not zero than just write the value in regardless.

-- 
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/1023#issuecomment-355881080

---

From: Christian Huitema <[email-masked]>
Date: Mon, 08 Jan 2018 06:13:43 +0000 (UTC)

@martinduke with the current spec, we are supposed to check that the stream ID corresponds to a legitimate value for that class of stream, e.g. "unidir server initiated". If you do the check without also testing for 0, then a value 0 fails for anything but "bidir client initiated". And per spec, this is supposed to trigger a connection close.

-- 
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/1023#issuecomment-355890233

---

From: Martin Thomson <[email-masked]>
Date: Sun, 07 Jan 2018 22:25:09 -0800

Let's say that I have a limit of 3 unidirectional streams as a (these are type: 2).  If I wanted to express that, I might write this code:

```c
add_parameter(parameters, max_unidirectional, limit * 4 - 2 + is_server);
```
You will note that a limit of 0 goes negative here and so you need special logic anyway, so that might as well be something like:
```c
if (limit)
  add_parameter(parameters, max_unidirectional, limit * 4 - 2 + is_server);
```
The drawback is that you can no longer just construct the transport parameters using a fixed-size template where you just fill in certain gaps.

The problem with encoding a 0 is as Christian describes, you need to create a check that exempts a zero from being marked as invalid.

I could remove the zero if that confuses people and say instead that omitting the transport parameter means that no streams of that type are permitted until a MAX_STREAM_ID frame is sent.  In other words, not indicate a specific value for the default and let people deal with that as they choose.

-- 
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/1023#issuecomment-355891247

---

From: Christian Huitema <[email-masked]>
Date: Mon, 08 Jan 2018 06:39:07 +0000 (UTC)

Or, we could say that the transport parameter encodes the "limit" in @martinthomson 's formula. That would probably be the cleanest solution, because that way no value could be wrong.

-- 
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/1023#issuecomment-355892511

---

From: martinduke <[email-masked]>
Date: Mon, 08 Jan 2018 10:44:11 -0800

OK, I see now that this is a wash. I would have to check for zero in either case, either to reject it (if the spec disallows it) or let it through.

Stepping back, it seems nonsensical that our default value is an invalid one. So either we should make it a limit with no invalid values, or change the defaults.

-- 
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/1023#issuecomment-356056329

---

From: janaiyengar <[email-masked]>
Date: Fri, 12 Jan 2018 14:09:51 -0800

I'm fine with any resolution -- I think this is a minor issue, but it should be resolved. I like @huitema's proposal of encoding the actual max number of 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/1023#issuecomment-357368317

---

From: martinduke <[email-masked]>
Date: Tue, 16 Jan 2018 04:19:26 +0000 (UTC)

@janaiyengar actually I'd prefer we stick with a max ID. Otherwise both ends have to agree on how many streams are open, which is another thing to screw up.

-- 
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/1023#issuecomment-357849814

---

From: Mike Bishop <[email-masked]>
Date: Tue, 23 Jan 2018 03:19:52 -0800

@martinduke, I don't think the suggestion was that we go back to a maximum number of open streams at a time.  Rather, the idea is that you can both get a smaller encoding and make invalid values impossible by encoding the max stream ID as an initial stream count.

That is, if a client sends `initial_max_streams_bidi=0x20`, the server would expand that as `0x20 << 2 + 0x00` and always produce a valid stream value.

-- 
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/1023#issuecomment-359760019

---

From: Mike Bishop <[email-masked]>
Date: Tue, 23 Jan 2018 11:46:21 +0000 (UTC)

In fact, we could bifurcate MAX_STREAM_ID in the same way; this would save a byte off each MAX_STREAM_ID frame for Stream IDs which currently use only the low two bits of the most significant byte.  (64-255, 16K-64K, etc.)    It would also similarly make it impossible to send MAX_STREAM_ID with an invalid Stream ID (i.e. one that you're supposed to be initiating).

That's somewhat appealing.  Frame types are cheap; the inability to send something invalid is valuable.

-- 
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/1023#issuecomment-359765931

---

From: MikkelFJ <[email-masked]>
Date: Tue, 23 Jan 2018 15:26:01 +0000 (UTC)

Aren't we half there where it makes sense to not encode the stream id in lower bits, and make a specific frame type instead?

-- 
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/1023#issuecomment-359825310