Re: [Moq] Track Bundles and priorities

[Christian Huitema <[e-mail]>]

On 3/17/2023 11:22 PM, Luke Curley wrote:

... a fairly long message about bundles, so let's look a the
specific issue of how to apply priorities across multiple tracks.

> ...
> *How does prioritization work?*
> The QUIC library transmits the next stream in ascending send order. During
> congestion, the streams with the highest send orders are starved and
> eventually reset. Many QUIC libraries already support this via the
> stream.SetPriority(int
> order) API as used in the HTTP Priority
> <https://datatracker.ietf.org/doc/html/rfc9114> header.


There is not just one QUIC Library. Different browsers and different 
server stacks use different QUIC libraries, with their own 
implementation choices. See for example R. Marx et al, "Same Standards, 
Different Decisions: A Study of QUIC and HTTP/3 Implementation 
Diversity", which shows how some stack deliver streams in sequence if 
stream creation, while other deliver them using round robin logic. 
https://qlog.edm.uhasselt.be/epiq/files/QUICImplementationDiversity_Marx_final_11jun2020.pdf

The June 2020 study is already dated. Since that, many stacks -- but not 
all -- have implemented support for the priorities defined in RFC9114. 
The priority API has two components, specifying both a priority level 
and a scheduling behavior. Within a QUIC connection, streams will higher 
priority will be scheduled before streams of lower priority.

Streams of the same priority can be declared as "incremental" or not. 
For example, images that support "progressive rendering" will be sent in 
an incremental faction, so the all images in a web page are rendered in 
parallel. QUIC stacks that implement an API compatible with RFC9114 
typically translate the "incremental" requirement by processing stream 
of the same priority level as Round Robin if incremental is set, and 
FIFO if it is not set.

The recently submitted transport draft 
(https://datatracker.ietf.org/doc/draft-nandakumar-moq-transport/) 
provides example of using these priorities to implement different 
transport strategy, such as combining priorities and FIFO to implement 
"one stream per object" strategies, or combining priorities and Round 
Robin to implement "one stream for all objects of a given priority 
object in a group".

These two example were specifically designed with bundling in mind. Of 
the two examples, the "stream per group and priority" supports bundling 
best, because the round robin scheduling will naturally allocate 
resource in a fair way to different tracks. The "stream per object" 
strategy is more fragile, as it requires the application to do its own 
"poor man round robin" by interleaving the creation of streams for 
different tracks.

Note that the transport draft specifies using priorities, instead of a 
delivery order. I understand how delivery order could work within a 
group, but I don't believe the concept works in a bundle of tracks as 
the group delimitation is different for each track.

Also, if an application coordinates multiple sources, it is easy to 
impose coordinated priorities such as "audio before video" or "low def 
before high def", but I just don't see how the distributed sources could 
pre-compute a synchronized delivery order.

-- Christian Huitema