Re: [quicwg/base-drafts] QUIC Transport: Flow Control (#3722)

[Martin Thomson <[e-mail]>]

I think that there are things that might be said about this point:

Unlike TCP, QUIC decouples flow control from congestion control.  This can release pressure on having a good flow control algorithm.  An endpoint can use flow control to constrain resource commitments without paying specific attention to tuning the algorithm.  

An endpoint might therefore implement a suboptimal flow control algorithm, up to the point where the BDP starts to approach the resources allocated to receiving data.  As BDP reaches this point, an endpoint needs to provide flow control updates in a timely fashion if it wishes to avoid flow control limiting throughput.  An endpoint that is unable to ensure that a peer has flow control credit in the order of the BDP will have their throughput limited by flow control and not congestion control.

(It's a little more complicated than that, as losses are discovered and repaired over a period larger than an RTT, and then you have to allow for flow control updates being lost.  The real value you need to target is therefore likely to be something more than 9/8 times the BDP.  But I think that gets the idea across.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3722#issuecomment-648521374