[Webtransport] Flow Control for high-throughput Streams

[Marten Seemann <[e-mail]>]

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.