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

[Mike Bishop <[e-mail]>]

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

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

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?

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

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:
 
 : A variable-length integer indicating the offset of the stream at which the

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