Closed MaxF12 closed 2 years ago
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.)
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:
There might be a few others, but I think at least these?
RFC 9000, section 4.6: `Only streams with a stream ID less than "(max_streams * 4
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.