Re: [Webtransport] Flow Control for high-throughput Streams

(I'm speaking as individual contributor)

I'd like to see data showing that this is a problem in practice. If it
appears to be an issue, I'm not sure that changing the wire format is the
best solution. This issue can be solved by having the QUIC stream layer
retransmit all of the unacked data on the WebTransport stream every time it
tries to send a subsequent flow control frame. That would provide very
similar performance properties without complicating flow control for
everyone.

David

On Tue, Mar 19, 2024 at 7:47 PM Marten Seemann <martenseemann@gmail.com>
wrote:

> After the discussion we had in yesterday’s session, I’ve spent some more
> time thinking about how and in which situations the HoL blocking introduced
> by putting flow control capsules on a control stream might hurt
> performance. Unfortunately, this is not an edge case, but a fairly common
> scenario.
>
> Consider an application transferring a large amount of data on a single
> stream. In QUIC, the receiver would select or auto-tune the stream receive
> window to slightly exceed the connection's BDP, assuming it sends
> MAX_STREAM_DATA frames multiple times per RTT. This ensures that
> flow-control doesn’t block the transfer. If MAX_STREAM_DATA is sent less
> frequently, a window slightly larger than the BDP is needed to be able to
> fully utilize the available bandwidth.
>
> For connections not terminating at a CDN's edge, BDPs can be quite large
> due to the longer RTTs. For instance, a 200ms RTT connection with a
> bandwidth of 1 Gbps has a BDP of 25 MB.
>
> When packet loss occurs on the WebTransport control stream (in upstream
> direction), no capsules can be read until this packet loss is repaired,
> which takes at least (since loss detection might take some time as well) 1
> RTT. This applies even if the control stream is given the highest priority
> when sending. For a BDP-sized flow control window, this means that the
> high-throughput stream (in downstream direction) is now blocked on flow
> control until the retransmission arrives (i.e. for at least 1 RTT).
>
> The solution suggested in yesterday's session, "just use higher flow
> control limits," would mean increasing the stream flow control window to
> (at least!) 50 MB from 25 MB for our example. This approach seems
> unappealing from a resource allocation standpoint.
> --
> Webtransport mailing list
> Webtransport@ietf.org
> https://www.ietf.org/mailman/listinfo/webtransport
>