Re: [Moq] Exploring HTTP/3

[Luke Curley <[e-mail]>]

Sorry, that was probably too in-depth. I meant to reply to Bernard saying
that STOP_SENDING during congestion is not good enough. The receiver has a
limited view of the network and thus responds slowly or incorrectly to
congestion. The sender, on the other hand, has direct access to both the
queued data and the congestion window.

On Thu, Feb 9, 2023 at 11:56 AM Luke Curley <[e-mail]> wrote:

> 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?
>>
>>>