Max streams

[MaxF12]

RFC 9000, section 4.6: `Only streams with a stream ID less than "(max_streams * 4

• first_stream_id_of_type)" can be opened`

Since each session has its own stream ID space a different restriction might need to be specified to make sure the combination of all streams across all sessions does not exceed the limit set by max_streams.

[GrumpyOldTroll]

I don't think each session has its own stream ID space necessarily. In particular, I think missing data from a stream can be retransmitted by the unicast connection by using the same stream ID that was used in the , so I think the space is shared across the connection.

But it does probably have to say something to clarify the point, and the server has to do something to ensure the stream IDs don't collide if there's any unidirectional streams used for unicast. I think what that is can be left up to the server. (It could for instance use only IDs with ID % 8 == 7, leaving those for ID % 8 == 3 for unidirectional, for instance, or it could use the same internal signaling channels on the server side that ensure the servers all have access to all the session data.)

[GrumpyOldTroll]

There's some text relevant to this already in section 4.4:

"However, since clients can join later than a channel began, clients supporting the multicast extensions to QUIC should be prepared to handle stream IDs that do not begin at early values, since by the time a client joins a channel in progress the stream id count might have been increasing for a long time. Clients should therefore begin with a high initial_max_streams_uni or send an early MAX_STREAMS type 0x13 value (see Section 19.11 of [RFC9000]) with a high limit.

MC_CHANNEL_PROPERTIES can provide a recommended value for max_streams_uni to allow for uninterrupted transport using the multicast channel."

I think in general we still need to abide by the max_streams limits, but there's a few more tweaks and guidance we should have, including:

• If a channel will exceed the max_streams of a client, the server MUST send a MC_CHANNEL_LEAVE asking for a leave at or before the packet number that will exceed it
• A server MUST NOT tell a client to join a channel that will imminently exceed the MAX_STREAMS of the client. A server MAY (or SHOULD?) send a STREAMS_BLOCKED if it is prevented from asking a client to join a channel by this constraint.
• Add some flexibility on the error response from section 4.6 of RFC 9000--if a client sees a stream id exceeding its max streams that was delivered on a channel, it SHOULD (or MAY?) drop the packet and leave the channel (with a new reason?) instead of closing the connection. (This can happen with a correct server if the LEAVE the server sent was lost and so the client didn't receive it in time.)

There might be a few others, but I think at least these?