Implement Subscriber and Publisher Priority Scheduling

[OkutaniDaichi0106]

Implement Subscriber and Publisher Priority Scheduling

Description

This issue focuses on implementing a scheduling mechanism in the library that supports Subscriber Priority and Publisher Priority, as inspired by the MoQ transport protocol. The implementation enables dynamic control over the transmission order of Objects, ensuring compliance with both subscriber and publisher-defined priorities.

Background

The library introduces two types of priorities to control scheduling:

1. Subscriber Priority:

   • Included in the SUBSCRIBE, SUBSCRIBE_UPDATE, FETCH, and FETCH_UPDATE messages.
   • Determines the relative priority of Objects from a subscription or fetch request.
   • Higher numerical values represent higher priority (i.e., 255 is the highest).

2. Publisher Priority:

   • Included in the GROUP message header, which applies to all Objects within the group.
   • Specifies the importance of the group relative to other groups in the same track.
   • Higher numerical values represent higher priority (i.e., 255 is the highest).

Scheduling Rules:

1. Subscriber Priority takes precedence over Publisher Priority.
2. If Subscriber Priorities are equal, Publisher Priority determines the order.
3. When both priorities are equal, additional attributes like Group Order and Object ID are used for ordering.
4. Control messages are always given the highest priority for transmission.

Acceptance Criteria

• Implement logic to handle Subscriber Priority and Publisher Priority during scheduling.
• Ensure Subscriber Priority is parsed from SUBSCRIBE, SUBSCRIBE_UPDATE, FETCH, and FETCH_UPDATE messages.
• Parse Publisher Priority from GROUP message headers.
• Adhere to the scheduling rules outlined above, with higher values indicating higher priority.
• Provide support for dynamic updates to Subscriber Priority via SUBSCRIBE_UPDATE and FETCH_UPDATE.
• Create unit and integration tests to validate priority-based scheduling under various scenarios.

Tasks

1. Priority Parsing:

   • Extend handlers to process Subscriber Priority from SUBSCRIBE, SUBSCRIBE_UPDATE, FETCH, and FETCH_UPDATE messages.
   • Parse Publisher Priority from GROUP message headers.

2. Scheduling Algorithm:

   • Implement a scheduler with the following priority order:
     1. Subscriber Priority (higher is higher priority).
     2. Publisher Priority (higher is higher priority).
     3. Group Order (Ascending or Descending).
   • Ensure control messages are prioritized above all other Objects.

3. Dynamic Updates:

   • Handle updates to Subscriber Priority from SUBSCRIBE_UPDATE and FETCH_UPDATE messages.
   • Apply changes to in-flight and queued Objects as best as possible.

4. Testing:

   • Write unit tests for parsing and priority calculations.
   • Conduct integration tests under congestion scenarios to validate priority-based scheduling.

5. Relay Considerations:

   • Relays must respect Subscriber and Publisher Priority but not use Subscriber Priority directly for upstream subscriptions.

6. Documentation:

   • Update protocol documentation to reflect the implementation of Subscriber and Publisher Priority.
   • Provide examples showing the impact of priorities during scheduling.

References

• MoQ Transport - Priorities

Additional Notes

• When unspecified, priorities should default to a middle value (e.g., 128).
• Handle edge cases such as Objects arriving with identical priorities predictably.

Priority

High