Change in publisher priority is underdefined

[vasilvv]

The current text says "When two or more subscriptions have equal subscriber priority, the original publisher priority is considered next and can change within the track, so subscriptions are prioritized based on the highest priority data available to send."

There are two issues here. The first is that "data available to send" is not well-defined for a protocol running over QUIC, in the sense that it's unclear as to when the data should be deemed "unavailable" (does it become unavailable after we put it into the QUIC buffer? after we send it? after it gets acked?). The second is that doing this requires extra bookkeeping to keep track of the current publisher priority per subscription (@martinduke implemented this in our MoQT prototype, and it was definitely quite a bit of complexity and overheard that seems unnecessary, to me at least).

(As an aside, I am not quite sure as to where the "publisher priority of a track is the max priority for all objects in the track" came from; I remember myself arguing for "publisher priority of a stream is the max priority for all objects in the track" at the interim, but that point was moot since we don't actually allow specifying different priorities on a single stream in the current wire format anyways.)

I can see at least two ways we can simplify this:

1. Make the publisher priority of a track to be equal to the priority of the latest (=highest sequence number) object in the track.
2. Make it so that the publisher priority of a peep/datagram is just what is in its header, and does not retroactively change priorities of other peeps and datagrams on that track. This effectively makes publisher priority have the same expressive power as peep priority, so we may want to merge those if we decide to go this way.

[ianswett]

I think option 1 doesn't accomplish what people want in some cases. For example, if you have a high priority peep and a low priority peep for a group, the intent is to deliver the high priority peep first. However, the low priority peep might have the highest Object Id. Also, couldn't this cause the priority of a track and hence the related streams to be constantly changing as new Objects arrive?

Option 2 seems sensible to me and I believe has much more consistent behavior.

[martinduke]

Under the status quo, the priority of a track can constantly change as new objects arrive.

A third option would be just to completely separate the concept of track-level and object-level publisher priority. A publisher can assign completely different values to each (and send the former in the SUBSCRIBE_OK)

[vasilvv]

Yeah, I think that option 2 makes more sense.

Let's take a real use case, let's say we have high priority for active speaker, and low priority for other audio tracks. Let's examine how it behaves when a speaker transitions from active to inactive (high -> low priority) under diferent approaches.

Current approach: the speaker's audio will remain at high priority for as long as there is any higher priority data in the buffer. This risks unnecessarily sending low-priority audio as high-priority.

Option 1: the speaker's audio will get to low priority as soon as the first low priority object is encountered. This risks unnecessarily sending high-priority audio as low-priority, causing it to be "truncated" at the end.

Option 2: the speaker's audio when active will he always treated as high-priority, and when inactive, as low-priority. That sounds like the desired outcome here.

[ianswett]

This is related to #512

[vasilvv]

Re option 2 -- I remembered that there is group ordering in between publisher priority, and the individual peeps, so merging them does not quite work.

So we get (subscriber priority) -> (publisher priority) -> (group ID) -> (peep priority) -> (object ID)

[fluffy]

I have no idea what the publish priority of a track is. Publisher are setting priorities for objects. I think the confusion on this may have crept in on how the quic priority for a quic stream is set when the stream is created.

I agree that subscriber priorities greatly increase the bookkeeping in a relay. They probably result in each subscriber needing a separate priority queue. I'd be fine with removing them but I recognize most the working group will wand to keep them. However for the use cases I care about, the publisher being able to set different priorities is critical.

I like the direction Victors PR is going so perhaps this thread does not matter as long as we agree on what ends up in the PR.