Mapping of media to QUIC Streams/Datagrams - Rush/QuicR/Warp

[huitema]

The current draft only considers two encodings, "reliable" and "datagram". Early work on MOQ shows interest for a "multi stream" structure, in which a media stream is published as a series of QUIC streams, each containing a group of objects -- this structure was pioneered in the RUSH implementation. In case of congestion, the multi-stream structure allows clients or server to drop old "group of objects" and either jump on the very last one, or maybe adopt a sampling strategy in which some group of objects are completely transmitted and others are completely ignored. This seems superior to simple streams, in which congestion will cause increased delays, and also superior to datagrams, in which congestion will cause random losses.

The QUICR protocol could easily be adapted to support RUSH like encodings. The consumer subscribes to a media stream, and then the server opens a set of QUIC streams as group of objects become available. On each of those QUIC streams, the server sends first a "stream header" explaining the origin, name, and position of the Group of Objects in the overall media stream, followed by a set of media objects in the group. Effectively, the main requirement is to define this mapping and the stream header.

[suhasHere]

QuicR is multistream be default, Each group of object belongs to a stream.

On a diff note, we need to explain what does that mean when we use Datagrams.

[huitema]

Yes, there are multiple streams, such as one for Alice and one for Bob. But the "Rush" bit is a bit different. The sequence would be something like:

• client Subscribes to media-x
• relay opens QUIC stream 1, pushes media-x, GOB-1, marks FIN when done.
• relay opens QUIC stream 5, pushes media-x, GOB-2, marks FIN when done
• relay opens QUIC stream 9, pushes media-x, GOB-3, marks FIN when done
• ...
• relay opens stream QUIC S, pushes media-x, GOB-N..
• client unsubscribes from media-x

This is particularly interesting in case of congestion. We could see something like:

• relay opens stream QUIC S1, pushes media-x, GOB-N, marks FIN when done.
• relay opens stream QUIC S2, pushes media-x, GOB-N+1, marks FIN when done.
• relay opens stream QUIC S3, pushes media-x, GOB-N+2, marks FIN when done.
• client receives beginning of S3 when S1 and S2 have not finished arriving yet, deduces congestion
• client tells relay to drop S1 and S2, using "stop sending S1", "stop sending S2" QUIC commands.
• client skips ahead to playing S3

Or alternately:

• relay opens QUIC stream S1, pushes media-x, GOB-N, marks FIN when done.
• relay opens QUIC stream S2, pushes media-x, GOB-N+1, marks FIN when done.
• relay opens QUIC stream S3, realizes that S1 and S2 are stalled.
• relay tells client to abandon S1, S2, using "reset S1" and "reset S2" QUIC commands

[suhasHere]

Yes, there are multiple streams, such as one for Alice and one for Bob. But the "Rush" bit is a bit different. The sequence would be something like:

I need to clarify on this, QuicR is one stream per Group of Objects and not per participant. May be it's not clearly said that way, that's a good one to clarify. In that way QuicR GoB and Warp Segments are closely related.

RUSH supports one stream per frame but it can be easily extended to GoB

[huitema]

Great. So the mapping from GoO to QUIC stream is obvious. We should definitely add that to the prototype. What is the relation between a GoO and the names in the headers for SUBSCRIBE and PUBLISH in the draft?

[huitema]

I think if we standardize on Rush/Warp for the stream mapping, then we can do something parallel for the datagram mapping.

That means evolving the prototype a little:

• break the current relation between QUIC streams and QUICR Subscribe operations. Treat the subscribe operation as basic RPC objects, using query/response mappings similar to DNS over QUIC, which each operation creating or refreshing a subscription context.
• break the current relation between Subscribe and Publish. There would be one "publish" per Group of Object.
• split the current "Publish" command by a datagram source between a "Publish promise", and then a series of "publish" per GoO
• read he GoO value from the media segments passed by the source.
• Publish GoO easier as Rush/Warp style stream, or as datagrams
• Change the datagram format to include delineation of subscriptionID, GoO, object or object part within GoO.

[TimEvens]

Any updates on this?