Do tracks need their own publisher priority?

[ianswett]

In #517 and #512 we discuss details about how priority should work.

In https://github.com/moq-wg/moq-transport/pull/518/files#r1744303191 @afrind suggested that there be an explicit publisher priority.

Do we need one? It might make things simpler, despite adding another attribute to prioritization, because we could only consider subscriber and publisher priority when picking which track to prioritize, and then within a track, we can use group order and peep/object priority to decide what data to send.

@vasilvv may have thoughts as well?

[vasilvv]

The only reason I can imagine having a publisher priority attached to the subscription and not individual things on it is if we wanted to let publishers update it, including changing priority of previous objects. That is logistically complicated, and I don't think it's the desired behavior in any use cases I can think of.

[suhasHere]

Publisher specified priority on objects being published is needed to support the cases where there is uplink congestion from the publisher to the relays , home wifi(relays) to cloud relays , for example.

Also in cases where publishers and subscribers are in a controlled settings, only publisher set priority will ever be needed.

My thinking from our discussions in Seattle has been along the following lines

• objects carry publisher priority
• the algo to pick the next object when there are more than one object available to send, will consider publisher priority and per subscription priority.

[wilaw]

SVC transmission is another use-case where the publisher would want the ability to set priorities between tracks since it would be critical to their correct transmission between relays. A catalog can always be used for the publisher to communicate relative track priorities to a subscriber and hence have subscriber-only priorities, but these are not read by relays and hence we need some way to optimize the transmission between relays.

[kixelated]

In my opinion, priority should flows down through the object model.

track > group > object

• The track with the higher subscriber priority is sent first.
• If there's a tie, the track with the higher publisher priority (in SUBSCRIBE_OK) is sent first.
• If there's a tie, the group with the highest ID is sent first if the subscriber indicates DESC, reversed otherwise.
• If there's a tie, the group with the highest ID is sent first if publisher indicates DESC (via SUBSCRIBE_OK), reversed otherwise.
• If there's a tie, the object with the lowest ID is sent first.

I think SVC should be done via multiple tracks with different priorities. The most obvious reason why is so you can choose to unsubscribe to enhancement layers. But a secondary reason is that it prevents object priority from bubbling up and trumping track priority (publisher only?)

[ianswett]

We decided to go with Victor's proposal on priorities (#518), so I'm closing this.