openscreenprotocol
openscreenprotocol copied to clipboard
w3c
Add guidelines on how CBOR messages are mapped onto streams
Provisionally, each CBOR message gets mapped onto one QUIC stream. This allows the message to be delivered to the agent as soon as it is fully received. However, this is not made explicit in the spec.
In QUIC, there are per-connection limits on the number of simultaneous streams. We may need to group multiple messages into a single stream if the limits are too low. Need to research what the practical limits are in current implementation (i.e. QUICHE).
https://www.rfc-editor.org/rfc/rfc9000.html#section-4
MAX_STREAMS is negotiated between peers as a transport parameter. We should just tell agents to set MAX_STREAMS to a limit that is high enough so that it does not limit the protocol in practice.
An application sending 1 message/ms and allowing retransmissions for 10 seconds would have 10,000 concurrent streams. We can just set a minimum MAX_STREAMS of 2^17 to provide additional headroom.
Correction: MAX_STREAMS limits the cumulative number of streams that can be opened per connection. For long lived connections, we will need a higher value. For a year-long connection, that could be as high as 400M according to the math above.
In current Open Screen Library, QuicSteam is used as unidirectional stream, see CreateOutgoingStream and CreateIncomingStream. One endpoint can only use the incoming stream to read message. If it want to send message to peer, it need to create a new outgoing stream.
If we can change the QuicStream to bidirectional, then the incoming stream can also be used to send message and there is no need to create a new one. Beside, we can also call CloseWriteSide or CloseReadSide to turn a bidirectional stream to a unidirectional stream for scenario where unidirectional stream is really needed. WDYT?
For my understanding; what drove the original one message per stream design? Is it to avoid relying solely on the variable-length integer and CBOR for message framing?
After thinking about it more, I guess the stream-per-packet is done to avoid head-of-line blocking type issues. It seems RoQ also uses this approach. They have some notes on MAX_STREAMS as well.
Thanks for the background @bakkem. I went ahead and merged #336. The text is aligned with the more explicit guidance in RoQ, i.e. set a value to give headroom for the agent's anticipated message concurrency.