Subject: [quicwg/base-drafts] Add separate transport parameter for unidirectional stream limit (#958)

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Nov 2017 01:05:04 +0000 (UTC)

Closes #909.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Add separate transport parameter for unidirectional stream limit

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/958.patch
https://github.com/quicwg/base-drafts/pull/958.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/958

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 24 Nov 2017 11:01:24 +0000 (UTC)

LPardue commented on this pull request.

 : The initial maximum stream ID parameter contains the initial maximum stream
-  number the peer may initiate, encoded as an unsigned 32-bit integer.  This is
-  equivalent to sending a MAX_STREAM_ID ({{frame-max-stream-id}}) immediately
-  after completing the handshake.
+  number the peer may initiate for bidirectional streams, encoded as an unsigned
+  32-bit integer.  This value MUST be a valid bidirectional stream ID for a
+  peer-initiated stream (that is, a server includes a value that have the least

/s/have/has

-- 
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/958#pullrequestreview-78885505

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 24 Nov 2017 11:08:41 +0000 (UTC)

The slight niggle that I have is the phrase "this is equivalent to sending a MAX_STREAM_ID". In spirit I think this is true, in practical terms, the closest MAX_STREAM_ID gets is a 30-bit varint. Transport params cannot express the full range streams IDs permitted by MAX_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/958#issuecomment-346804124

---

From: ianswett <[email-masked]>
Date: Tue, 28 Nov 2017 19:49:35 +0000 (UTC)

ianswett approved this pull request.

One small suggestion, but looks good.

I think the phrasing below is a bit cleaner, so I'd copy that.  "that is, the two least significant bits are set to 0 by a server and to 1 by a client"

-- 
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/958#pullrequestreview-79634019

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Nov 2017 00:39:50 +0000 (UTC)

@martinthomson pushed 1 commit.

920d0e5  Phrasing copy

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/958/files/b66c8314491d4572d100eb5853847510351091c9..920d0e5837362e4a1031a36878754d306eaf11bc

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Nov 2017 00:43:08 +0000 (UTC)

Merged #958.

-- 
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/958#event-1362585899

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 29 Nov 2017 14:26:39 +0000 (UTC)

Sorry for late, but I think initial_max_stream_id_bidi and initial_max_stream_id_uni should allow 0.
The current text says 0 is not valid.

And also I'm wondering why initial_max_stream_id_uni must be sent by server.  And there is no indication for client although the text says about client case.
Should it put after ack_delay_exponent, I mean, its transmission is MAY.

-- 
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/958#issuecomment-347875754

---

From: Marten Seemann <[email-masked]>
Date: Wed, 29 Nov 2017 16:29:07 +0000 (UTC)

I agree with tatsuhiro-t. Not every QUIC implementation might want to support both uni- and bidirectional streams, so having a way to effectively disable each of the types would be really helpful.
I suggest making 0 a valid value in both cases.

-- 
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/958#issuecomment-347915937

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Nov 2017 21:02:40 +0000 (UTC)

I have what might be a better suggestion: define these values to default to zero and make them optional.

-- 
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/958#issuecomment-347995213

---

From: janaiyengar <[email-masked]>
Date: Thu, 30 Nov 2017 00:22:16 +0000 (UTC)

I prefer to have explicit intent with 0, but either 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/pull/958#issuecomment-348041680

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Nov 2017 00:47:27 +0000 (UTC)

I would also, but I think that this is better for two reasons:

* 0 is hard because it is only valid for client-initiated bidirectional streams, and you would have to create an exception in any validation checks.

* Now that we have multiple types, it is more onerous to explicitly signal for every type, especially if you never plan to use certain type (as we will for server-initiated bidirectional streams in hq).

-- 
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/958#issuecomment-348045972