[Low-Latency] HTTP 2/3 Connection Priority Mechanisms

[technogeek00]

Use Case Description

When operating in a low latency use case, distribution systems and players may wish to utilize the connection priority mechanisms of more advanced transfer protocols

Working Notes

• This is a transport layer equivalency description

Open Questions

• Are constraints placed in DASH or HLS on HTTP 2/3 that would dictate priority behavior? If so do they conflict?
• What's the positives and negatives of having formats not aligned in priority definition?

[technogeek00]

HLS specification latest draft still references HTTP 2 priorities / weights, but IETF HTTP 2 changes deprecating priority behavior, may be difficult to align these at the moment.

[technogeek00]

Discussion Notes:

• Working group released potential new RFC status (https://github.com/httpwg/http-extensions/labels/priorities)

Question	Answer
Does the feature relate to an industry streaming use-case?	Yes
- What is the commonality of this case?	Uncommon
- Is this an established or emerging practice?	Emerging
Does this feature have related mechanisms in both DASH and HLS?	No
- What is the maturity of support in both specifications?	HLS - Immature (see above), DASH - Missing
- What is the maturity of implementation support for both specifications?	HLS - Incomplete, DASH - N/A
- Are there known interoperability issues between specs?	Yes
- Has anyone implemented this interoperably?	No
- Are there features missing in a specification with open proposals for it?	Missing in DASH, no proposal
Has the industry defined defacto mechanisms not present in both DASH and/or HLS?	No
- Why was functionality defined outside of the main specifications?	N/A
- Has the functionality been standardized elsewhere (DASH-IF, CTA, SVA)?	N/A
- Is the functionality proprietary or openly developed?	N/A
- Could the functionality be incorporated into specifications with evangelism?	N/A

[piersoh]

The HTTP Priorities IETF Draft has entered Working Group Last Call - Which ends 20 Oct.

The draft "defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing the responses".

[piersoh]

The IETF has now released "Extensible Prioritization Scheme for HTTP" as RFC9218.

[technogeek00]

Conversation has continued with the iOS 17 seeds: https://mailarchive.ietf.org/arch/msg/hls-interest/RcZ2SG8Sz_zZEcjWnDKzcM_-TJk/

[piersoh]

To summarise the current state of the discussion on HLS-interest:

A new version of the HLS spec is imminent which will contain some yet to be finalised text on the use of signaling of priorities, primarily using RFC9218 with HTTP/3 and HTTP/2, which will be used in preference to the old now-deprecated HTTP/2 priority signalling.
RFC9218 specifies two priority parameters; urgency(u) which indicates a numeric priority between 0 (highest) and 7 (default u=3), and incremental (i) which is a boolean that indicates whether a response can be processed incrementally or not (default i=0(false)).
Roger Pantos said that "Playlists must be delivered at priority 1 while (partial) segments must be in the lower-priority band from 2 to 6, with higher bit rate renditions having equal or lower priority than lower bit rate renditions. These priorities must be signaled in the H3 response headers, or iOS 17 will play the stream in regular-latency mode”.
The server would be expected to add the priority headers to responses, but these may be overriden if a client’s request contains priority signalling.
With respect to discontinuities and interstitials - according to Roger they "should be considered separately. Interstitials are simple: they are separate VOD assets that are not delivered over LL-HLS. So they don’t need any special treatment.
For discontinuity-based ad insertion, where the ad server is responsible for modifying the primary playlist to serve ads as partial segments and implementing the client’s delivery directives, the ad server will also be responsible for setting priority headers for its (partial) ad segments. If ad segments served via LL-HLS do not carry prioritization then yes, that will cause the client to abandon low-latency playback.
(It’s worth noting that pretty much every content vendor I’ve spoken to who wants to deliver low-latency streams with ads has run into significant barriers trying to get discontinuity-based ad insertion to work, and now plan to use interstitials instead. At this point discontinuity-based ad insertion in LL-HLS seems to be an option more in theory than in practice.)"