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

[Bernard Aboba <[e-mail]>]

Victor said:

"the key property in this scenario is that it's very sensitive to loss of
window updates, "

[BA] I think that is an important point, WebTransport API provides close
coupling between application consumption of incoming data and window
updates.

This was an issue with the WebSockets and WebRTC data channel APIs, where
incoming data is considered "received" when it is removed from the receive
buffer and placed onto the event queue.  Unfortunately, data moved to the
event queue has only been "received" by the browser, not by the
application. If the application's omessage event handler cannot keep up,
the event queue grows but the receive window does not constrict.  For
low-end devices (such as inexpensive mobile devices or game consoles), this
can result in event queue bloat, stuttering audio/video and high observed
e2e latency.

This shouldn't happen with WebTransport, as long as the feedback loop
remains operational.  Throughput may be constricted, but as the application
consumes data and window updates arrive at the sender, data will continue
to be sent.  It doesn't seem like this is susceptible to "deadlock", only
degraded performance.  Or am I missing something?



On Tue, Mar 26, 2024 at 4:18 AM Victor Vasiliev <vasilvv=
[e-mail]> 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 <[e-mail]>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/webtransport
>>
> --
> Webtransport mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webtransport
>