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

[Martin Thomson <[e-mail]>]

I want to acknowledge that this is a real problem.  At least in theory.

The reason that I'm not in favour of a fix here is largely down to an engineering trade-off.

Though a large BDP flow can stall, there are plenty of strategies available.  Whether that be a larger commitment, more aggressive transmission of the stream, or simply accepting the risk of stall or lower throughput.

That needs to be balanced against the cost to us of building a better option.  The solutions on the table are pretty awkward and would require fairly extensive analysis and discussion to make right.

Two things push me toward doing nothing about this (other than writing some text about the risk):

1. I'd like to ship WebTransport.
2. We can fix this in a nicer way later.

So I'm not going to ask for more evidence that this is a real problem.  That would delay shipping further.  It has already taken too long.  I'd prefer to ship something with this modest flaw than continue to delay that ship date.

Cheers,
Martin

On Tue, Mar 19, 2024, at 20:47, Marten Seemann 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