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

> I think the key property in this scenario is that it's very sensitive to
loss of window updates, not necessarily the HOLB on the control stream.

Isn't that a general property of flow control?
In my QUIC stack, I solve this by sending ~5 window updates per RTT. Doing
it frequently is basically for free, as long as you bundle it with ACKs
that you would send anyway.
On WebTransport this doesn't work, since the 5 frames are not delivered
independently from each other.

On Wed, 27 Mar 2024 at 00:17, Victor Vasiliev <vasilvv@google.com> wrote:

> I think the key property in this scenario is that it's very sensitive to
> loss of window updates, not necessarily the HOLB on the control stream.
>
> One approach here is that whenever you send a new capsule on the control
> stream, you could retransmit all of the previous ones that aren't
> acknowledged; since those capsules are small, the resulting stream frame
> will normally fit into a single packet.  Now that I think about it, this
> approach can be applied to any latency-sensitive stream with a lot of small
> writes: you could have a flag that says "if this stream has less than an
> MTU worth of unacked data, send all of it every time".
>
>   -- Victor.
>
> On Tue, Mar 19, 2024 at 5:47 AM 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
>>
>