Priorities for low latency streaming

[rmarx]

Following some discussions in Singapore, the use case of low latency (video) streaming came up (cc @c-taylor, @TigerToes, Roberto Peon). I just wanted to write this down here so we get a better view into the pain points for this use case, not really because I'm thinking we should tackle this (yet).

I'm not an expert on this, but from what I understand:

• At a given time, the client might want to switch to a new media quality level
• For H2, they simply send out requests for the new level and inject them in the H2 tree exclusively at the top, interrupting other in-flight requests for the "old" quality level. It's unclear whether they actively reset those old streams at the same time.

For H3 with the current scheme, this type of "interrupting" in-flight requests wholesale with exclusive priorities is no longer possible. You would need to reset or reprioritize the older streams. However, this happens on their own streams or on the control stream, while the new requests are given an initial priority on their own streams. Given H3's lack of HOLblocking, this creates race conditions. In the case of very specific packet loss, the reprioritization/reset messages might be lost, while the new requests do come through, In that case, you end up with ~1RTT of round robining (best case) or FIFOing (worst case) with the older requests. On high BDP networks, this might have some impact for the low latency case.

Then again, question is: when would you move to new media levels: if you go lower, won't your congestion window have dropped as well? If you go higher, does the RTT delay matter?

Refs:
https://developer.apple.com/documentation/http_live_streaming/protocol_extension_for_low-latency_hls_preliminary_specification
https://developer.apple.com/videos/play/wwdc2019/502/

[kazuho]

Thank you for opening the issue. It is an interesting issue, though I wonder if we need to fix.

Consider the case where the probability of packet loss is L, and assume that a HTTP request is sent using a single packet, and that the PRIORITY_UPDATE frame is sent using another packet.

The problem statement is about the request packet getting delivered but the PRIORITY_UPDATE getting lost. Something that happens at the probability of L², causing mis-prioritization for 1-PTO.

If that is a concern, I'd argue that stacks should have already fixed the case where the request gets lost, which happens at the probability of L. Which means that it is doing FEC (where the dumbest form of FEC being sending the request frame twice). Such endpoints can use FEC for the control stream carrying PRIORITY_UPDATE frames too.

[c-taylor]

Thank you for raising: However I don't think this needs a fix unless my understanding of #94 is incorrect.

Downshifting: You have limited opportunity to interact with priority, a reset if in time is probably more appropriate. There are race conditions here that are being worked out, but the machinery is adequate.

Upshifting: The proposed scheme is fine.

[LPardue]

I'd like to close this soon, but giving a small window of opportunity to @c-taylor and @rmarx to add new information.

[c-taylor]

Nothing to add here: Support closure.