When an MOQT publisher has multiple schedulable objects it can choose between, the objects SHOULD be selected as follows:
-
If two objects have different subscriber priorities associated with them, the one with the highest subscriber priority is scheduled to be sent first.
-
If two objects have the same subscriber priority, but different publisher priorities, the one with the highest publisher priority is scheduled to be sent first.
-
If two objects in response to the same request have the same subscriber and publisher priority, but belong to two different groups of the same track, the group order of the associated subscription is used to decide the one that is scheduled to be sent first.
-
If two objects in response to the same request have the same subscriber and publisher priority and belong to the same group of the same track, the one with the lowest Subgroup ID (for objects with forwarding preference Subgroup), or the lowest Object ID (for objects with forwarding preference Datagram) is scheduled to be sent first. If the two objects have different Forwarding Preferences the datagram is sent first.
The definition of "scheduled to be sent first" in the algorithm is implementation dependent and is constrained by the prioritization interface of the underlying transport. For some implementations, it could mean that the object is serialized and passed to the underlying transport first. Other implementations can control the order packets are initially transmitted.
This algorithm does not provide a well-defined ordering for objects that belong to different subscriptions or FETCH responses, but have the same subscriber and publisher priority. The ordering in those cases is implementation-defined, though the expectation is that all subscriptions will be able to send some data.
A publisher might not utilize the entire available congestion window, session flow control, or all available streams for lower priority Objects if it expects higher priority Objects will be available to send in the near future or it wants to reserve some bandwidth for control messages.
Given the critical nature of control messages and their relatively small size, the control streams SHOULD be prioritized highest, followed by the bidi request streams and then all subscribed Objects. Bidi request streams MAY be prioritized within themselves by Subscriber Priority if specified.