Proposal: Subscriber Prioritization

[kixelated]

I know we're not allowed to talk about priorities any longer but I wanted to float another option.

The subscriber is in charge of prioritization:

• Add order to SUBSCRIBE: ASC or DESC
• Add priority to SUBSCRIBE: VarInt?
• Remove send_order from OBJECT.

The publisher prioritizes streams based on:

let order = subscribe.order == DESC ? 1 : -1;
subscribe.priority > object.group * order > -object.id

Depending on the QUIC API, publisher still needs to compute a send order for each stream. It can do this by inserting each stream into a priority queue based on the above comparison, using the resulting position in the queue as the send order. This was already a requirement for QUIC APIs that did not support a u64 send order.

Alternatively, a QUIC API could implement nested priority groups, perhaps something like sendGroup.

Pros: Order

The benefits of order=ASC are similar to the proposed FETCH API in #368.

• Supports HLS/DASH-like experiences, where playback buffers instead of skips.
• Supports VOD playback.
• Supports advertisement playback.

Note that you could perform head-of-line blocking today* by issuing a SUBSCRIBE per group. However this is quite verbose, and it creates an RTT at the end of each group where the network is not being utilized.

Pros: Priority

• Supports prioritizing unrelated tracks (from different encoders).
• Supports prioritizing based on focus state (sideline cam > main cam)
• Supports prioritizing high bitrate (main cam > sideline cam)
• The encoder is dumb, unaware of network priorities.

These could only be performed today by rewriting send order at a relay, which is impossible without catalog access.

Cons

• SUBSCRIBE is even more complicated.
• No interleaved prioritizes between tracks/groups. (who cares?)
• Publisher has to compute/update send order on each stream/datagram created.
• Relay has to deduplicate conflicting SUBSCRIBEs

The main challenge is the last one. For example, two viewers could issue:

SUBSCRIBE track=720p order=ASC priority=3
SUBSCRIBE track=720p order=DESC priority=9

What does the relay send upstream? The idea behind publisher prioritization was to avoid this dilemma, but maybe there's another way we can solve it.

[kixelated]

One dumb idea for the publisher prioritization dilemma is to put the "preferred" priority and order for each track in ANNOUNCE. A relay could choose to use this information when fetching upstream, instead of relying on the values provided by N subscribers.

However this would require switching ANNOUNCE to be per-track instead of per-namespace as it is currently.

[ianswett]

The FETCH/SUBSCRIBE split solves your largest CON above, because there can only be one active SUBSCRIBE for a track at once.

Otherwise this SGTM.

[ianswett]

I believe this was fixed by #470