Re: [Moq] Exploring HTTP/3

[Christian Huitema <[e-mail]>]

If we are exploring HTTP-3, we might as well explore "MoQ directly over 
QUIC", such as opening a QUIC connection with an ALPN=MoQ..

But back the discussion. Luke is worried that if media streams are not 
sent over a single connection, then it becomes harder to implement 
relative priorities between media streams. Indeed, when I look at my 
implementation of QUIC, it is basically doing round-robin between 
connections. Changing that would not be simple.

As for the way an MoQ node detects congestion, that tends to be 
implementation specific. In our prototype, we use the "just in time 
sending" of the Picoquic stack, which means the relay can assess at the 
time of sending the number of objects that have already arrived and have 
not yet been forwarded to the connection. That's working reasonably, and 
does not require diving into the internals of the congestion control 
algorithms.

-- Christian Huitema

On 2/9/2023 1:02 PM, Luke Curley wrote:
> 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] 
> <mailto:[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] <mailto:[e-mail]>> wrote:
> 
>         On Thu, Feb 9, 2023 at 09:56 Luke Curley <[e-mail]
>         <mailto:[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?
> 
>