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

From: Marten Seemann <[email-masked]>
Date: Thu, 01 Mar 2018 19:34:12 -0800

marten-seemann approved this pull 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/pull/1065#pullrequestreview-100669047

---

From: janaiyengar <[email-masked]>
Date: Wed, 14 Mar 2018 16:40:35 +0000 (UTC)

janaiyengar commented on this pull request.

> -  ({{frame-max-stream-id}}) immediately after completing the handshake.  The
-  maximum bidirectional stream ID is set to 0 if this parameter is absent,
-  preventing the creation of new bidirectional streams until a MAX_STREAM_ID
-  frame is sent.  Note that a default value of 0 does not prevent the
-  cryptographic handshake stream (that is, stream 0) from being used.
+initial_max_streams_bidi (0x0002):
+
+: The initial maximum streams parameter contains the initial maximum number of
+  bidirectional streams the peer may initiate, encoded as an unsigned 32-bit
+  integer.  The maximum bidirectional stream ID is set to 0 if this parameter is
+  absent or zero, preventing the creation of new bidirectional streams until a
+  MAX_STREAM_ID frame is sent.  Note that a value of 0 does not prevent the
+  cryptographic handshake stream (that is, stream 0) from being used. Non-zero
+  values are converted to a valid bidirectional stream ID for a peer-initiated
+  stream (that is, after shifting two bits to the left, clients subtract 0 and
+  servers subtract 3).  Setting this parameter is equivalent to sending a

in addition to this algorithm, can you have an example? that ought to 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/pull/1065#pullrequestreview-103900815

---

From: Mike Bishop <[email-masked]>
Date: Wed, 14 Mar 2018 16:42:07 +0000 (UTC)

@MikeBishop pushed 1 commit.

808465e  16 bits instead of 32

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 14 Mar 2018 16:59:06 +0000 (UTC)

f6157a0  Replace algorithm with example

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 14 Mar 2018 10:00:16 -0700

MikeBishop commented on this pull request.

Added -- see what you think?

-- 
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#discussion_r174534352

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Mar 2018 15:02:04 -0700

martinthomson commented on this pull request.

 initial_max_stream_id_uni (0x0008):
 
-: The initial maximum stream ID parameter contains the initial maximum stream
-  number the peer may initiate for unidirectional streams, encoded as an
-  unsigned 32-bit integer.  The value MUST be a valid unidirectional ID for the
-  recipient (that is, the two least significant bits are set to 2 by a server
-  and to 3 by a client).  If an invalid value is provided, the recipient MUST
-  generate a connection error of type TRANSPORT_PARAMETER_ERROR.  Setting this
-  parameter is equivalent to sending a MAX_STREAM_ID ({{frame-max-stream-id}})
-  immediately after completing the handshake.  The maximum unidirectional 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.
+: The initial maximum streams parameter contains the initial maximum number of
+  application-owned unidirectional streams the peer may initiate, encoded as an
+  unsigned 16-bit integer.  If this parameter is absent or zero, unidirectional
+  streams cannot be created until a MAX_STREAM_ID frame is sent.  For example, a
+  value of 0x05 would be translated to a value of 18 by a client or 19 by a

s/translated to a value/is equivalent to a MAX_STREAM_ID frame containing 18 when received by a client or 19.../

It's not clear what "value" is from context.  The same applies above.

-- 
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-104014979

---

From: Mike Bishop <[email-masked]>
Date: Thu, 15 Mar 2018 03:54:13 +0000 (UTC)

@MikeBishop pushed 2 commits.

26e395d  Improve example
3630fdf  Parameter naming

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 15 Mar 2018 06:31:41 +0000 (UTC)

martinthomson approved this pull request.

Just a nit.

>    MAX_STREAM_ID frame is sent.  Note that a value of 0 does not prevent the
-  cryptographic handshake stream (that is, stream 0) from being used. For
-  example, a value of 0x05 would be translated to a bidirectional stream ID of
-  20 by a client or 17 by a server.  Setting this parameter is equivalent to
-  sending a MAX_STREAM_ID ({{frame-max-stream-id}}) immediately after completing
-  the handshake containing the resulting Stream ID.
+  cryptographic handshake stream (that is, stream 0) from being used. Setting
+  this parameter is equivalent to sending a MAX_STREAM_ID
+  ({{frame-max-stream-id}}) immediately after completing the handshake
+  containing the resulting Stream ID. For example, a value of 0x05 would be

"resulting" doesn't make sense, because you don't describe a process that might produce a result.  Try "corresponding".

-- 
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-104086781

---

From: Marten Seemann <[email-masked]>
Date: Thu, 15 Mar 2018 01:54:13 -0700

marten-seemann commented on this pull request.

> -  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, the two least significant bits are set to 0 by
-  a server and to 1 by a client).  If an invalid value is provided, the
-  recipient MUST generate a connection error of type TRANSPORT_PARAMETER_ERROR.
-  Setting this parameter is equivalent to sending a MAX_STREAM_ID
-  ({{frame-max-stream-id}}) immediately after completing the handshake.  The
-  maximum bidirectional stream ID is set to 0 if this parameter is absent,
-  preventing the creation of new bidirectional streams until a MAX_STREAM_ID
-  frame is sent.  Note that a default value of 0 does not prevent the
-  cryptographic handshake stream (that is, stream 0) from being used.
+initial_max_streams_bidi (0x0002):
+
+: The initial maximum bidirectional streams parameter contains the initial
+  maximum number of application-owned bidirectional streams the peer may
+  initiate, encoded as an unsigned 16-bit integer.  If this parameter is absent

I'd prefer 32 bit here.

-- 
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-104115407

---

From: Mike Bishop <[email-masked]>
Date: Thu, 15 Mar 2018 02:56:37 -0700

Can you explain why?  Is there a situation in which you'd like to allow that many streams without receiving a MAX_STREAM_ID frame?  @martinthomson suggested reducing the size, and 16 bits still seems quite large for an initial 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#discussion_r174727977

---

From: Mike Bishop <[email-masked]>
Date: Thu, 15 Mar 2018 09:59:53 +0000 (UTC)

e80bc34  Corresponding

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

---

From: Marten Seemann <[email-masked]>
Date: Thu, 15 Mar 2018 10:28:33 +0000 (UTC)

You're right. I thought that there's no point in saving bytes here, because I overlooked that the transport parameters are sent by the server as well. So it actually makes sense to shave of 4 bytes (in total) here.

-- 
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#discussion_r174736523

---

From: Martin Thomson <[email-masked]>
Date: Thu, 15 Mar 2018 12:23:40 +0000 (UTC)

Merged #1065.

-- 
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#event-1523142060