Subject: [Hls-interest] FYI: new LL-HLS over HTTP/3 prioritization proposal

From: Roger Pantos <[email-masked]>
Date: Mon, 12 Oct 2020 09:31:57 -0700

I wanted to give everyone a heads up about a development related to LL-HLS. As you may (or may not) know, HTTP/3 https://tools.ietf.org/html/draft-ietf-quic-http <https://tools.ietf.org/html/draft-ietf-quic-http> eliminates the prioritization scheme employed by HTTP/2, replacing it with a new optional hinting mechanism https://tools.ietf.org/html/draft-ietf-httpbis-priority <https://tools.ietf.org/html/draft-ietf-httpbis-priority>.

This means that we need to redo how LL-HLS prioritization works over H3 connections. Our current proposal for that is https://github.com/httpwg/http-extensions/issues/1274#issuecomment-706281840 <https://github.com/httpwg/http-extensions/issues/1274#issuecomment-706281840> — essentially a static prioritization for LL-HLS resources declared by the origin, plus some level of mandatory support for Extensible Priorities on the part of CDNs (or whatever the ultimate delivery server happens to be).

Comments welcome.

regards,

Roger Pantos
Apple Inc.

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 12 Oct 2020 20:54:20 +0100

Hi Roger and LL-HLS folks,

I'm one of the editors of the Extensible Priorities document. Roger's given
a salient and accurate description but I thought I might provide a little
bit more color.

HTTP/2 provided a very expressive scheme to communicate priorities:
dependencies and weights. A server can use this to schedule resources,
typically bandwidth allocation of concurrent responses. But they also have
to trade off what a client wants against local operator concerns like
preventing DoS.

Getting prioirites right is hard and some implementations never really got
it right with HTTP/2. HTTP/3 made things harder because QUIC provides no
ordering across streams; that breaks dependencies in fun ways.

This lead the QUIC and HTTP WGs to Extensible priorities, a simplified
scheme that can be applied to both HTTP/2 and HTTP/3.

Both tree priorities and extensible priorities focus on signalling, and
leave a lot of details about scheduling to the server. I think Roger's
proposal is equally applicable to either priority scheme. Detailing
effective, application-specific ordering and bandwidth allocation
recommendations for servers irrespective of client signals.

I do encourage comments here or on the issue.

Cheers
Lucas