Subject: [quicwg/base-drafts] Transport parameters are stream counts, not IDs (#1065)

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

Fixes #1023.

Adopts @huitema's suggestion from that issue.  Currently, we send transport parameters which encode max stream IDs for each type.  This forces the other side to then check that we picked an appropriate stream ID for the stream type associated to the parameter.

If you send an initial *count* rather than an initial ID, you not only save two bits, but it's impossible to encode an invalid value.

(Note that this does not in any way revert that we're using maximum stream IDs as our method of limiting open streams; we're not going back to max-concurrent.)
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1065

-- Commit Summary --

  * Transport parameters are stream counts, not IDs

-- File Changes --

    M draft-ietf-quic-transport.md (46)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1065.patch
https://github.com/quicwg/base-drafts/pull/1065.diff

-- 
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/pull/1065

---

From: Marten Seemann <[email-masked]>
Date: Tue, 23 Jan 2018 11:51:17 +0000 (UTC)

I like this change, since it's not possible to encode an invalid value.
I'd prefer to avoid talking about a count though, since this might lead to confusion which streams are counted (at the time that it receives the transport parameters, the client already initiated the crypto stream, and more streams in the 0-RTT case).

-- 
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/pull/1065#issuecomment-359767024

---

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

And those streams count.  Note that you can't encode a negative number, so it's valid to have initiated stream zero no matter what you do.  And if you're initiating streams in 0-RTT, it's because you have some cached value for these settings, and if the server isn't willing to give you at least that value it already MUST reject 0-RTT.

-- 
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/pull/1065#issuecomment-359768322

---

From: Marten Seemann <[email-masked]>
Date: Tue, 23 Jan 2018 03:59:41 -0800

I'm aware it doesn't make a difference, I just think this would be clearer if we avoided talking about a count, and instead call this a wire encoding of the respective stream ID.

-- 
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/pull/1065#issuecomment-359768908

---

From: Mike Bishop <[email-masked]>
Date: Tue, 23 Jan 2018 12:04:44 +0000 (UTC)

Something like "...contains the initial maximum bidirectional stream number the peer may initiate, encoded as an unsigned 32-bit integer containing the Stream ID minus the two least significant bits."?  I remain a little dubious that that's less confusing.

We encode Stream IDs elsewhere; if we're using a different encoding here, it feels clearer if that's because we're encoding a different thing.

-- 
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/pull/1065#issuecomment-359770030

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Jan 2018 23:48:58 +0000 (UTC)

martinthomson commented on this pull request.

This doesn't work as intended.  You can't say 0.  That's OK for client bidirectional, but not the others, where 0 should be the default.

-- 
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/pull/1065#pullrequestreview-91023981

---

From: Christian Huitema <[email-masked]>
Date: Tue, 23 Jan 2018 15:58:12 -0800

You *can* say 0. Just omit the 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/pull/1065#issuecomment-359973337

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Jan 2018 00:15:03 +0000 (UTC)

That was what caused #1023 to be opened in the first place, so this is really only addressing the validation concern.

-- 
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/pull/1065#issuecomment-359976664

---

From: Mike Bishop <[email-masked]>
Date: Wed, 24 Jan 2018 00:18:55 +0000 (UTC)

I went to add that to the PR, but it turns out that's what it already says:

> The maximum <type> stream ID is set to 0 if this parameter is absent, preventing the creation of new unidirectional streams until a MAX_STREAM_ID frame is sent.

However, there might be people who are sad about not being able to represent the default 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/pull/1065#issuecomment-359977363

---

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

I read the issue as being that if you actually send the default value, it's invalid.  This means that you can't encode something that's invalid, so it does feel like it addresses the root concern.

If people want a way to encode negative Stream IDs here, I think it gets a lot uglier.

-- 
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/pull/1065#issuecomment-359977787

---

From: Christian Huitema <[email-masked]>
Date: Tue, 23 Jan 2018 16:41:00 -0800

I would be fine with that suggestion:
~~~
Alternatively, you can subtract so that sending 0 actually means zero streams allowed. That would be more logical, but requires handling the underflow when subtracting.
~~~
It still has the property that all values are good. It just makes the processing a tiny bit more complicated.

-- 
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/pull/1065#issuecomment-359981376

---

From: Mike Bishop <[email-masked]>
Date: Wed, 24 Jan 2018 00:46:40 +0000 (UTC)

@MikeBishop pushed 1 commit.

b8c0832  Make zero special

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1065/files/7fa92184fcebcfbb489614efb92f6dc89b1bb1c6..b8c08326aa0d64778da1096f7468b94f6a41a307