{{ message }}
Repository navigation
Describe message delivery semantics independent of QUIC #343
Description
The message delivery/ordering semantics depend on QUIC streams. Rewrite to be less specific, but in a way that can be mapped to QUIC easily.
Related: #334
Activity
backkem commentedon Sep 18, 2024
For the controlling protocols (meaning non real-time, including presentation, remote playback & session management) the requirement of a reliable, ordered stream-multiplexed protocol seems adequate. It seems possible to allow for both message (SCTP) and byte-steam based protocols (QUIC) as we're only sending manageable size CBOR messages.
For the more real-time sensitive (media streaming) protocols more flexibility may be wanted. The stream-per-packet trick is a way to augment unordered delivery for the media transport. I'm not sure if it would be safe to assume this to work with any stream-multiplexer. The requirement may have to be even less specific but I'm not sure how far to open that up yet.
At the risk of this being blasphemous, another option would be to outsource the media transport. The requirement for media streaming could be: the transport can carry RT(C)P streams. For example: deferring to RoQ in case QUIC is used as the transport. One way to look at this latter idea: it re-scopes the 'streaming' protocol to an in-protocol alternative to SDP-based session negotiation.