Re: [Moq] Exploring HTTP/3

[Luke Curley <[e-mail]>]

If we assume the sender will round-robin, like is the case with HLS/DASH,
then the client has an unbelievably difficult task.


Let's suppose the client application is responsible for canceling requests
during congestion. The client has to decide if it should cancel a pending
request and/or it should make the next request.

1. The client doesn't know when data is buffered at the TCP/QUIC layer,
pending retransmission of a gap before the contents are flushed to the
application.
2.The client doesn't know what data should be forthcoming. It needs to make
assumptions about how much jitter exists in the video system (even
b-frames) so it can predict when a timestamp should have arrived.
3. The client can't determine where queuing occurs in the pipeline. If the
broadcaster is encountering congestion, that will appear like last mile
congestion to the client, so it will incorrectly cancel the previous
segment and degrade the experience.
4. The client doesn't know if a segment will be transferred at network
speed (ex. advertisement on disk) or encoder speed (ex. live stream). If
the next segment is transferred at network speed, then it will fight for
bandwidth.
5. The client doesn't know the congestion window. It doesn't know how many
simultaneous requests could be processed at once, similar to how it doesn't
know if it can switch to a higher rendition, without just trying it.
6. When the client decides to cancel a request, it takes at least
a round-trip to apply.
7. When the client decides to make a new request, it takes at least a
round-trip to start receiving the content.

All of these combined, a HLS/DASH client has a remarkably delayed response
to congestion. The slower the response to congestion, the larger the jitter
buffer required, and the higher the latency. It's extremely difficult to
build an optimal HLS/DASH client so most of them (Twitch included) just
download segments sequentially, cancelling them only in extreme situations.
This is a fundamental latency wall on networks with congestion, and why
Twitch is replacing LHLS (basically LL-DASH) with Warp.


The idea behind delivery order (prioritization) is that the sender has a
much better view of the network, can make faster decisions, and thus can
achieve lower latency. The sender iterates over streams in delivery order,
creating STREAM frames when there's data in the send buffer, until the
congestion window is hit. It's effectively a priority queue, and the end
result is that any number of segments can be transmitted in parallel
without the need to cancel during congestion.

Something does need to annotate each segment with a delivery order. It
could be the viewer in the case of HTTP/3 Warp, or it could be the
broadcaster in the case of WebTransport Warp. The nice thing about doing it
at the broadcaster is that it's consistent throughout multiple layers of
relays, so the response to congestion is the same regardless of the hop.
One of the warts with HTTP/3 Warp I alluded to earlier is that two viewers
could request the same segment with different delivery orders, and it's not
clear to the CDN which one it should use on a cache miss.


On Thu, Feb 9, 2023 at 10:18 AM Bernard Aboba <[e-mail]>
wrote:

> On Thu, Feb 9, 2023 at 09:56 Luke Curley <[e-mail]> wrote:
>
>>
> For example, suppose a client issues a request for segment 5 and segment
>> 6, asking that the newer segment is delivered first during congestion.
>>
>> If the two requests share a HTTP/3 or HTTP/2 connection, then the HTTP
>> server can prioritize. Any available bandwidth under the congestion window
>> is spent on STREAM frames for segment 6 first.
>>
>
> [BA] Couldn’t this be accomplished without priority, by having the
> receiver send a STOP_SENDING frame for segment 5, once it became clear it
> was taking too long?
>
>>