Crisp definition of BLOCKING and friends

[martinthomson]

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.

[kazuho]

Same issue here.

I am afraid that the text might still imply the same thing; i.e. the maximum stream ID that the sender was permitted to open at the time the sender was unable to open the streams.

[martinthomson]

You are right, this fails to address the original issue. I will amend the definition of MAX_STREAM_ID to address that concern then - and use your "exclusive maximum" approach.

[martinthomson]

Hmm, that's a tricky one, changing the definition of MAX_STREAM isn't that easy.

With stream IDs, if I receive MAX_STREAM_ID of N, then the test for whether something is allowed is id <= N. With stream octets, the test is offset < MAX_STREAM_DATA. That makes this harder.

So with the latter, saying that you can't send offset is clean and simple (wording notwithstanding). With streams though, you would be saying "I can only send N (but want to send N+4)", which is awkward, I agree.

This is because we count octets on streams (and in total), but we don't use counts in MAX_STREAM_ID.

Is changing the definition of MAX_STREAM_ID worth it?

[kazuho]

That sounds like an excellent observation.

I think I'd agree to changing the definition of MAX_STREAM_ID to send the number of streams rather than the stream ID. We might also want to rename the frame to MAX_STREAM_COUNT.

There are certain aspects that are not elegant in the way MAX_STREAM_ID is defined now:

• we have two "maximum"s; one for unidirectional streams and the other for bidirectional streams. It sounds just strange.
• we exchange counts using TP but we transmit maximum in the frame

These issues will be resolved by sending the counts.

[nibanks]

If we changed it to MAX_STREAM_COUNT, we'd have to use one additional bit from the type to indicate unidirectional/bidirectional, right? To me, my favorite thing (if we made that change) would be that I no longer have to validate if the peer is trying to set my limit on them (i.e. ownership bit).

[marten-seemann]

Assuming that MAX_STREAM_COUNT is supposed to encode the number of streams since the beginning of the connection (and not the concurrently open streams, as we had in some earlier version of the draft), I think this would be a good change to make, since we'd use the same encoding for the transport parameters and the frame.
Not sure if MAX_STREAM_COUNT is the best name for this, maybe we can go with something analogous to the transport parameters (initial_max_{uni,bidi}_streams), and name it MAX_STREAMS frame?

[kazuho]

I actually prefer the old text, assuming that we do not have a clarification on what "limit" means here. In other parts of the transport protocol we represent the limit using "inclusive maximum." But here, we need a limit expressed as "exclusive maxmimum."

IMO the original text is clearer in stating that the offset is "maximum offset permitted by MAX_DATA + 1", by saying that the transmitted value is "the offset at which the blocking occurred."

[martinthomson]

Closing in favour of a bigger change.