Closed kixelated closed 2 months ago
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.
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.
I believe this was fixed by #470
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:
order
to SUBSCRIBE:ASC
orDESC
priority
to SUBSCRIBE:VarInt
?send_order
from OBJECT.The publisher prioritizes streams based on:
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 proposedFETCH
API in #368.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
These could only be performed today by rewriting send order at a relay, which is impossible without catalog access.
Cons
The main challenge is the last one. For example, two viewers could issue:
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.