change the STREAM_ID_BLOCKED frame to encode stream 0 #1851
Conversation
draft-ietf-quic-transport.md
Outdated
| : A variable-length integer indicating the highest stream ID that the sender | ||
| was permitted to open. | ||
| : A variable-length integer indicating the stream ID of the stream that the | ||
| sender was not able to open due to the maximum stream ID limit. |
There was a problem hiding this comment.
To avoid ambiguity, would it make sense to clarify that the value is "the maximum stream ID among the streams that the sender is willing to open"?
Consider the case of a client that received from server a initial_max_bidi_stream of zero. If the client wants to open two bidirectional streams (i.e. streams with ID 0 and 4), what is the stream ID to be encoded in the STREAM_ID_BLOCKED frame? My intent is to clarify that sending 4 in allowed such case.
|
I’d argue that sending 4 in that case is not correct. Streams are opened sequentially, so you’re blocked on opening stream 0, not on opening stream 4. |
|
The original reason for adding the Stream ID was to deduplicate and tell whether a frame was delayed or if the peer is still blocked. Including that you'd like to open "up to" Stream 4 is actually more informative, since it tells the recipient that merely allowing a single additional stream doesn't unblock you. |
|
You’re right. This is how it should work. This goes beyond the intent of this PR, which was supposed to just fix an encoding issue. I’ll update it. |
Yes, but that creates a new manner in which this frame differs from the other frames. If we make this change, then we need to be clearer about the semantics of this and the other |
|
@martinthomson: Would it help if I deleted the last commit to move this PR forward? |
That makes it closer to the effective definition of the other limits. Then we need to modify the others to match. |
| @@ -3254,8 +3254,8 @@ The STREAM_ID_BLOCKED frame contains a single field. | |||
|
|
|||
| Stream ID: | |||
|
|
|||
| : A variable-length integer indicating the highest stream ID that the sender | |||
| was permitted to open. | |||
| : A variable-length integer indicating the maximum stream ID of the streams that | |||
There was a problem hiding this comment.
nit: I would remove "of the streams that" because I think it makes this sentence less clear.
Recent discussion around the use of BLOCKING frames highlighted some inconsistency - and even disagreement - about what the purpose of the frames are. If you read through all the text for the flow control-related frames, it is clear that the frame carries the *limit* at the time the frame is sent. > These frames always include the limit that is causing blocking at the > time that they are transmitted. This enacts that change more consistently, especially for STREAM_ID_BLOCKED, which was the most unclear. The discussion on #1851 suggested that there was value in knowing what the sender (or stream opener) wanted to get to. That is, the frames would carry a higher value. If the limit was X and the sender wanted to send octet X+Y (or open stream X+Y), they would convey that information instead. The theory here is that the larger value (X+Y) would be sent, allowing the receiver to make those resources available. The problem with this alternative approach is that the value advertised changes over time and it is difficult to connect the signal (a BLOCKED frame), with the limit that was in force at the time. I suspect that there is value in signaling the desired limits as well, but that would require greater justification. It also entails a change and I'm leery of feature creep at this stage. Closes #1851, #1850.
|
OBE. See #1906. |
Fixes #1850.