Subject: [quicwg/base-drafts] Define stream limits as counts (#1906)

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Oct 2018 18:27:20 -0700

The problems we've been having with stream limits turned out to be
intractable without a larger shift.  This aligns stream limits with flow
control limits.  To do that, it takes two frame types, both for
increasing the limit and for signaling blocking.

Note that these frame types will be renumbered afterwards.  I realize
that this is a terrible arrangement, but it's temporary.  Ideally all
this limiting stuff is in a contiguous block.

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

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

-- Commit Summary --

  * Define stream limits as counts
  * but, but, but (fix to existing text)

-- File Changes --

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

-- Patch Links --

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

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 24 Oct 2018 20:00:19 -0700

Looks awesome. In addition to fixing #1850, the change simplifies the QUIC stack as pointed out by @nibanks in  
https://github.com/quicwg/base-drafts/pull/1889#discussion_r226653712.

One editorial question: are we also going to rename `initial_max_(bidi|uni)_streams` to `initial_max_streams_(bidi|uni)` for having consistency between TP names and stream names?

-- 
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/1906#issuecomment-432897415

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Oct 2018 20:09:35 -0700

@martinthomson pushed 1 commit.

fcf2a6d  Rename transport parameter to match

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1906/files/d582e98b98086bc52b4b06d234ab7c886e6fefa4..fcf2a6d52e4e651fe1658195936e1b8386ad497a

---

From: Marten Seemann <[email-masked]>
Date: Wed, 24 Oct 2018 20:23:57 -0700

marten-seemann approved this pull request.

 : The initial maximum bidirectional streams parameter contains the initial
   maximum number of bidirectional streams the peer may initiate, encoded as an
   unsigned 16-bit integer.  If this parameter is absent or zero, bidirectional
-  streams cannot be created until a MAX_STREAM_ID frame is sent.  Setting this
-  parameter is equivalent to sending a MAX_STREAM_ID ({{frame-max-stream-id}})
-  immediately after completing the handshake containing the corresponding Stream
-  ID. For example, a value of 0x05 would be equivalent to receiving a
-  MAX_STREAM_ID containing 16 when received by a client or 17 when received by a
-  server.
+  streams cannot be created until a MAX_STREAMS frame is sent.  Setting this

what about: s/streams cannot be created/the peer cannot open bidirectional streams/

 : The initial maximum unidirectional streams parameter contains the initial
   maximum number of 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.  Setting this
-  parameter is equivalent to sending a MAX_STREAM_ID ({{frame-max-stream-id}})
-  immediately after completing the handshake containing the corresponding Stream
-  ID. For example, a value of 0x05 would be equivalent to receiving a
-  MAX_STREAM_ID containing 18 when received by a client or 19 when received by a
-  server.
+  streams cannot be created until a MAX_STREAMS frame is sent.  Setting this

same here

-The MAX_STREAM_ID frame (type=0x06) informs the peer of the maximum stream ID
-that they are permitted to open.
+The MAX_STREAMS frame (type=0x1c and 0x1d) informs the peer of the number of
+streams they are permitted to open.  A MAX_STREAMS frame with a type of 0x1c

s/they are/it is/

-A peer MUST NOT initiate a stream with a higher stream ID than the greatest
-maximum stream ID it has received.  An endpoint MUST terminate a connection with
-a STREAM_ID_ERROR error if a peer initiates a stream with a higher stream ID
-than it has sent, unless this is a result of a change in the initial limits (see
-{{zerortt-parameters}}).
+A peer MUST NOT initiate a stream with a higher stream ID than the largest limit
+it has received permits.  For instance, a server that receives a unidirectional
+stream limit of 4 is permitted to open stream 15, but not stream 19.  An

Maybe it's clearer if we enumerate the streams, e.g. "... is permitted to open streams 3, 7, 11 and 15, but not stream 19".

 : The initial maximum bidirectional streams parameter contains the initial
   maximum number of bidirectional streams the peer may initiate, encoded as an
   unsigned 16-bit integer.  If this parameter is absent or zero, bidirectional
-  streams cannot be created until a MAX_STREAM_ID frame is sent.  Setting this
-  parameter is equivalent to sending a MAX_STREAM_ID ({{frame-max-stream-id}})
-  immediately after completing the handshake containing the corresponding Stream
-  ID. For example, a value of 0x05 would be equivalent to receiving a
-  MAX_STREAM_ID containing 16 when received by a client or 17 when received by a
-  server.
+  streams cannot be created until a MAX_STREAMS frame is sent.  Setting this
+  parameter is equivalent to sending a MAX_STREAMS ({{frame-max-streams}}) of
+  the corresponding type immediately after completing the handshake.

Since you removed the example for the encoding here, should we say "equivalent to sending a MAX_STREAMS of the corresponding type with the same value..."?

 : A variable-length integer indicating the offset of the stream at which the
   blocking occurred.

-## STREAM_ID_BLOCKED Frame {#frame-stream-id-blocked}
+## STREAMS_BLOCKED Frame {#frame-streams-blocked}
+
+A sender SHOULD send a STREAMS_BLOCKED frame (type=0x1e or 0x1f) when it wishes
+to open a stream, but is unable to due to the maximum stream ID limit set by its
+peer (see {{frame-max-streams}}).  A STREAMS_BLOCKED frame of type 0x1e
+indicates a problem with the limit on bidirectional streams; a STREAMS_BLOCKED

s/a problem with the limit on/reaching the limit of/g

-- 
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/1906#pullrequestreview-168195382

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Oct 2018 20:29:52 -0700

1d5d157  marten makes it better again

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1906/files/fcf2a6d52e4e651fe1658195936e1b8386ad497a..1d5d157d17372e009e001b8eef3ce17930514c5b

---

From: MikkelFJ <[email-masked]>
Date: Thu, 25 Oct 2018 05:44:48 +0000 (UTC)

mikkelfj commented on this pull request.

Much better - but we are close to the point where distinguishing stream types by frame type variant only makes more sense.

-The maximum stream ID is specific to each endpoint and applies only to the peer
-that receives the setting. That is, clients specify the maximum stream ID the
-server can initiate, and servers specify the maximum stream ID the client can
-initiate.  Each endpoint may respond on streams initiated by the other peer,
-regardless of whether it is permitted to initiate new streams.
+The stream limit is specific to each endpoint and applies only to the peer that
+receives the setting. That is, clients limit the number of streams the server

Mixing plural clients with singular server. And vice versa below.

-- 
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/1906#pullrequestreview-168213030

---

From: Nick Banks <[email-masked]>
Date: Thu, 25 Oct 2018 07:20:31 -0700

nibanks approved this pull request.

LGTM 👍 

-- 
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/1906#pullrequestreview-168407935

---

From: ianswett <[email-masked]>
Date: Thu, 25 Oct 2018 08:38:48 -0700

ianswett commented on this pull request.

-The STREAM_ID_BLOCKED frame ({{frame-stream-id-blocked}}) can be
-used to signal a shortage of available streams. Implementations will likely
-want to increase the maximum stream ID as peer-initiated streams close.
+The STREAMS_BLOCKED frame ({{frame-streams-blocked}}) can be used to signal a
+shortage of available streams. Implementations could use this as a signal to

I think shortage is not quite specific enough.  To me, that might mean "I only have 5 available" which I don't believe is the intent?  How about "The STREAMS_BLOCKED frame ({{frame-streams-blocked}}) signals that a new stream could not be created.  Implementations can use this as a signal to the peer to send a MAX_STREAMS frame with a larger limit."

-- 
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/1906#pullrequestreview-168450360

---

From: ianswett <[email-masked]>
Date: Thu, 25 Oct 2018 15:39:50 +0000 (UTC)

> @@ -2878,15 +2876,15 @@ containing that information is acknowledged.
   endpoint SHOULD stop sending MAX_STREAM_DATA frames when the receive stream
   enters a "Size Known" state.
 
-* The maximum stream ID for a stream of a given type is sent in MAX_STREAM_ID
+* The limit on streams for a stream of a given type is sent in MAX_STREAMS

```suggestion
* The limit on streams of a given type is sent in MAX_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/pull/1906#pullrequestreview-168450817

---

From: ianswett <[email-masked]>
Date: Thu, 25 Oct 2018 15:41:28 +0000 (UTC)

-Loss or reordering can mean that a MAX_STREAM_ID frame can be received which
+Loss or reordering can mean that a MAX_STREAMS frame can be received which

```suggestion
Loss or reordering means that a MAX_STREAMS frame can be received which
```

-- 
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/1906#pullrequestreview-168451725

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 25 Oct 2018 22:17:31 +0000 (UTC)

kazuho commented on this pull request.

Are we fine with removing this sentence?

I ask this because it is the only reliable way the things would work. Adding a sentence below about an optimization (i.e. using STREAMS_BLOCKED as a signal to send to MAX_STREAMS; it is merl) at the same time removing the required interaction might confuse the readers.

-- 
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/1906#pullrequestreview-168609440

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 25 Oct 2018 15:30:14 -0700

RyanAtGoogle commented on this pull request.

Hm I'm not in love with the "number of streams" terminology. With "maximum stream ID" it was very obvious what was being limited. If the max stream ID was X, you clearly could not open a steam with ID X+1 (or X+4 but whatever :>).

With a limit on the "number of a streams" this is less clear. If a server limits the client to 10, presumably the idea is that this is equivalent to a max stream id limit of the 10th client initiated stream ID. But it also seems like you could read this limit to permit the client to open any 10 steams. Like 0, 40, 80, 120, ... I think this is not the intent, but the terminology makes this much less clear to me.

For example, the text below:

"A peer MUST NOT initiate a stream with a higher stream ID than the largest limit
maximum stream ID it has received. "

Clearly the limit applies to stream ID, but using "number of streams" seems to obscure that.

-- 
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/1906#pullrequestreview-168612858

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 16:55:21 -0700

martinthomson commented on this pull request.

I agree that this isn't great, but it's an artifact of encoding stream type in the ID.  A decision I really don't want to revisit, BTW.

Given that the number of streams can be very easily determined from the ID with `(id+3)/4`, or the test for whether an stream can be opened is `id/4 >= limit`, I think that this is quite workable.

I've tweaked the text you point at.  Hopefully this is clearer.

Thanks.  I struggled with that.

Yeah, I think that I might restore this, but attach it to the paragraph above.

Fixed better, also used "endpoint" rather than 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/1906#discussion_r228369685

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 23:55:41 +0000 (UTC)

@martinthomson pushed 7 commits.

00bf51c  Plural/non-plural inconsistencies
03d729d  Let's stick with counting as much as possible
7c6f963  Clearer explanation of STREAMS_BLOCKED
28e3e63  lines
2f95581  Restore text on updating MAX_STREAMS
12f0a85  word whack-a-mole
1a7a66e  Reword reordering text

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1906/files/1d5d157d17372e009e001b8eef3ce17930514c5b..1a7a66e92b84f68359eb6f966139c5398b348e45

---

From: MikkelFJ <[email-masked]>
Date: Thu, 25 Oct 2018 17:01:11 -0700

> @@ -4247,11 +4247,11 @@ Loss or reordering can mean that a MAX_STREAMS frame can be received which
 states a lower stream limit than the client has previously received.
 MAX_STREAMS frames which do not increase the stream limit MUST be ignored.
 
-A peer MUST NOT initiate a stream with a higher stream ID than the largest limit
-it has received permits.  For instance, a server that receives a unidirectional
-stream limit of 3 is permitted to open stream 3, 7, and 11, but not stream 15.
-An endpoint MUST terminate a connection with a STREAM_LIMIT_ERROR error if a
-peer opens more streams than was permitted.
+A peer MUST NOT open more streams than the limit it received permits.  For

Is that a sentence?

-- 
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/1906#pullrequestreview-168631803

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Oct 2018 17:53:00 +0000 (UTC)

MikeBishop approved this pull request.

> @@ -317,23 +317,23 @@ lower-numbered streams of the same type in the same direction.
 
 QUIC allows for an arbitrary number of streams to operate concurrently.  An
 endpoint limits the number of concurrently active incoming streams by limiting
-the maximum stream ID (see {{stream-limit-increment}}).
+the number of streams (see {{stream-limit-increment}}).

...of each type.

-The maximum stream ID is specific to each endpoint and applies only to the peer
-that receives the setting. That is, clients specify the maximum stream ID the
-server can initiate, and servers specify the maximum stream ID the client can
+The stream limit is specific to each endpoint and applies only to the peer that
+receives the setting. That is, the client limits the number of streams the
+server can initiate, and the server limits the number of streams the client can

Probably want to mention "of each type" in this paragraph as well.

>  initiate.  Each endpoint may respond on streams initiated by the other peer,
 regardless of whether it is permitted to initiate new streams.
 
 Endpoints MUST NOT exceed the limit set by their peer.  An endpoint that
 receives a STREAM frame with an ID greater than the limit it has sent MUST treat
-this as a stream error of type STREAM_ID_ERROR ({{error-handling}}), unless this
-is a result of a change in the initial limits (see {{zerortt-parameters}}).
+this as a stream error of type STREAM_LIMIT_ERROR ({{error-handling}}), unless
+this is a result of a change in the initial limits (see {{zerortt-parameters}}).

Existing text, but....  We don't allow reductions in TPs after accepting 0-RTT, so how would it be the result of a change in the initial limits?

-The STREAM_ID_BLOCKED frame ({{frame-stream-id-blocked}}) can be
-used to signal a shortage of available streams. Implementations will likely
-want to increase the maximum stream ID as peer-initiated streams close.
+The STREAMS_BLOCKED frame ({{frame-streams-blocked}}) signals that a new stream

Ugh.  So we now have STREAM_BLOCKED and STREAMS_BLOCKED?  No one is *ever* going to get those backward, no....

And since I see the text above, you've presumably done this.

-The MAX_STREAM_ID frame (type=0x06) informs the peer of the maximum stream ID
-that they are permitted to open.
+The MAX_STREAMS frame (type=0x1c and 0x1d) informs the peer of the number of
+streams it is permitted to open.  A MAX_STREAMS frame with a type of 0x1c
+applies to bidirectional streams; a MAX_STREAMS frame with a type of 0x1d
+applies to unidirectional streams.

Would it be clearer to frame this as a flag?

Yes, a correct albeit awkward one.  Perhaps "A peer MUST NOT open more streams than permitted by the current stream limit."?

> @@ -4341,36 +4334,40 @@ Stream ID:
 
 : A variable-length integer indicating the stream which is flow control blocked.
 
-Offset:
+Data Limit:

Should we also use the term "stream-level limit" here?

-A sender SHOULD send a STREAM_ID_BLOCKED frame (type=0x0a) when it wishes to
-open a stream, but is unable to due to the maximum stream ID limit set by its
-peer (see {{frame-max-stream-id}}).  This does not open the stream, but informs
-the peer that a new stream was needed, but the stream limit prevented the
-creation of the stream.
+A sender SHOULD send a STREAMS_BLOCKED frame (type=0x1e or 0x1f) when it wishes
+to open a stream, but is unable to due to the maximum stream ID limit set by its

s/ID//

-A sender SHOULD send a STREAM_ID_BLOCKED frame (type=0x0a) when it wishes to
-open a stream, but is unable to due to the maximum stream ID limit set by its
-peer (see {{frame-max-stream-id}}).  This does not open the stream, but informs
-the peer that a new stream was needed, but the stream limit prevented the
-creation of the stream.
+A sender SHOULD send a STREAMS_BLOCKED frame (type=0x1e or 0x1f) when it wishes
+to open a stream, but is unable to due to the maximum stream ID limit set by its
+peer (see {{frame-max-streams}}).  A STREAMS_BLOCKED frame of type 0x1e is used
+to indicate reaching the bidirectional stream limit; a STREAMS_BLOCKED frame of
+type 0x1f indicates reaching the unidirectional stream limit.

Again, flag might be cleaner.

-- 
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/1906#pullrequestreview-169428100

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 15:21:16 -0700

Not detecting any objections, and lots of approval, I think that I'm going to merge this one.  I'll mail the list first though.

Cutting that.  I didn't think much on it before, but you are right that it's nonsensical.

I had exactly the same thought.  It's just that I can't think of a better name.

I just tried this.  Describing using a flag means more words, and I think that it's a small regression in terms of clarity.

-- 
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/1906#pullrequestreview-169541747

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 22:21:25 +0000 (UTC)

@martinthomson pushed 4 commits.

dded3aa  ... of each type
22a1951  This was just wrong
20b1f3e  Stream limit can apply to an endpoint
04a3fa3  s/ID//

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1906/files/1a7a66e92b84f68359eb6f966139c5398b348e45..04a3fa33316e79c2ffb3dd5443b636bb2d812640

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Oct 2018 15:38:15 -0700

MikeBishop commented on this pull request.

Perhaps, in the interest of consistency....
- MAX_DATA => DATA_BLOCKED
- MAX_STREAMS => STREAMS_BLOCKED
- MAX_STREAM_DATA => STREAM_DATA_BLOCKED

-- 
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/1906#discussion_r229123321

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 18:06:18 -0700

\o/ thanks.

-- 
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/1906#discussion_r229148102

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 18:14:57 -0700

68ac057  Rename all BLOCKED frames

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1906/files/04a3fa33316e79c2ffb3dd5443b636bb2d812640..68ac057c195dc70d6a67663e43391358701235f3

---

From: janaiyengar <[email-masked]>
Date: Mon, 29 Oct 2018 19:34:05 -0700

janaiyengar commented on this pull request.

Looks great. Just one thought on the UNI/BIDI frame types.

Yeah, I'm not thrilled with this either. How about we separate the frame types in the description? These are different frames, and I think it might be clearer to simply call them MAX_STREAMS_UNI and MAX_STREAMS_BIDI.

Similarly, UNI_STREAMS_BLOCKED and BIDI_STREAMS_BLOCKED.

-- 
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/1906#pullrequestreview-169591740

---

From: janaiyengar <[email-masked]>
Date: Mon, 29 Oct 2018 19:51:17 -0700

janaiyengar approved this pull request.

After having a look at #1900, I think its going to be hard to avoid this clunkiness. This PR is a net positive and combining these frames does improve readability, so I'll drop my suggestion.

Drop this suggestion too.

-- 
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/1906#pullrequestreview-169594720

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 20:08:49 -0700

Thanks Jana.  There's no truly good way of dealing with this, but I think that we've at least hit a local minimum.

-- 
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/1906#discussion_r229163844

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 20:10:21 -0700

ae8f7f3  Stream data limit is more words, but clearer

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1906/files/68ac057c195dc70d6a67663e43391358701235f3..ae8f7f3da9a5d83362fe8833040d86df6c4bb863

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Oct 2018 03:58:17 -0700

Note to self, check the names of these transport parameters in the HTTP doc.

-- 
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/1906#issuecomment-434256574

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Oct 2018 11:00:19 +0000 (UTC)

9995e08  Merge remote-tracking branch 'origin/master' into max-streams

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1906/files/ae8f7f3da9a5d83362fe8833040d86df6c4bb863..9995e08f2b56ae66b75ec1ddb03b6290090046a9

---

From: ianswett <[email-masked]>
Date: Tue, 30 Oct 2018 13:19:43 -0700

-Maximum Stream ID:
-: ID of the maximum unidirectional or bidirectional peer-initiated stream ID for
-  the connection encoded as a variable-length integer. The limit applies to
-  unidirectional steams if the second least signification bit of the stream ID
-  is 1, and applies to bidirectional streams if it is 0.
+Maximum Streams:
+: A count of the number of streams that can be opened.

```suggestion
: A count of the total number of streams of a given type that can be opened over the course of the connection.
```

This is potentially ambiguous, because it could be read as "100 = 100 open streams at once."

-- 
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/1906#pullrequestreview-169980379

---

From: ianswett <[email-masked]>
Date: Tue, 30 Oct 2018 13:20:15 -0700

+An endpoint MUST NOT open more streams than permitted by the current stream

```suggestion
An endpoint MUST NOT open more total streams than permitted by the current stream
```

-- 
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/1906#pullrequestreview-169980619

---

From: ianswett <[email-masked]>
Date: Tue, 30 Oct 2018 13:21:24 -0700

-Stream ID:
+Stream Limit:
+
+: A variable-length integer indicating the stream limit at the time the frame

```suggestion
: A variable-length integer indicating the limit on the total number of streams that may be opened in this connection.
```

-- 
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/1906#pullrequestreview-169981085

---

From: ianswett <[email-masked]>
Date: Tue, 30 Oct 2018 13:22:05 -0700

I made some suggestions to try to clarify concerns about ambiguity @RyanAtGoogle mentioned.  PTAL.

-- 
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/1906#pullrequestreview-169981366

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Oct 2018 16:21:32 -0700

58a1e16  Handle the ambiguity between max and concurrent stream better

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1906/files/9995e08f2b56ae66b75ec1ddb03b6290090046a9..58a1e16935ca85a6975613f21901d23c3bd11547

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Oct 2018 16:22:56 -0700

I've chosen a slightly different approach to fixing the problem than suggested, but thanks for catching that Ian.  People coming from HTTP/2 will expect this to be "concurrent streams", which - while it clearly doesn't work - could work long enough to cause real damage.

-- 
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/1906#issuecomment-434506441

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Oct 2018 17:19:09 -0700

Merged #1906 into master.

-- 
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/1906#event-1936625608

---

From: ianswett <[email-masked]>
Date: Tue, 30 Oct 2018 18:53:37 -0700

I still find this potentially confusing and misleading.  I think we should clarify total number during the lifetime of the connection, at least in the MAX_STREAMS Frame.

-- 
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/1906#pullrequestreview-170067488

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 30 Oct 2018 20:22:46 -0700

So does MAX_STREAMS limit the total number of streams opened by the client, but does not restrict the IDs of those streams? If MAX_STREAM=3, can I open stream 300?

-- 
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/1906#issuecomment-434547868

---

From: Marten Seemann <[email-masked]>
Date: Tue, 30 Oct 2018 21:00:11 -0700

@RyanAtGoogle Section 2.1 says

> Streams of each type are created in numeric order. Streams that are used out of order result in opening all lower-numbered streams of the same type in the same direction.

I agree with @ianswett that we should be more explicit with what we mean by "total 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/pull/1906#issuecomment-434553271

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Oct 2018 16:42:07 -0700

Not sure how this is inadequate:

> Note that these frames (and the corresponding transport parameters) do not describe the number of streams that can be opened concurrently.  The limit includes streams that have been closed as well as those that are open.

-- 
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/1906#issuecomment-434884346