Change:
an entire round trip, and potentially for longer if the peer chooses not to send STREAMS_BLOCKED frames. <ins> 4.6. An endpoint that is unable to ensure that a peer has flow control credit on the order of the current BDP will have receive throughput limited by flow control.  Lost packets can cause gaps in the receive buffer, delaying the application from consuming data and freeing up flow control window. Sending timely updates of flow control limits can improve performance.  Sending packets only to provide flow control updates can increase network load and adversely affect performance.  Sending flow control updates along with other frames, such as ACK frames, reduces the cost of those updates. </ins> 5. QUIC's connection establishment combines version negotiation with the

Discussion:
QUIC doesn't really address the question of tuning flow control very well. This just admits that fact. It also indicates why: which essentially boils down to "RAM is cheap".
Hi Martin. I stumbled across this. I don't know if you are joking, but if not I'd like to disagree. There are a significant class of devices, commodity streaming devices, which are very large volume but for which the trend is to shave as much RAM budget as possible, HD video devices in markets like India, Brazil, etc. In aggregate, these devices consume a significant amount of overall internet traffic. RAM is cheap is most definitely not true there, and they certainly don't ship with TCP receive windows anywhere near as large as other device segments. This is not a legacy issue either, for the foreseeable future it looks like the amount of RAM in newer devices will be lucky to stay stable as opposed to even decrease.
Section: Flow Control {#flow-control} The present text only states the reasons why flow control limits are needed, and resource commitments. It does not yet motivate the use of adding credit when this is needed - which is also an important design consideration for a user of QUIC transport, as it is for http. That is, the section should also state the performance implications of too little credit - i.e. the tradeoff, by explaining: “Advertising too little credit will cause the stream to become blocked and can limit performance when it constrains a stream path using a path that has large bandwidth delay product”. Section: Flow Credit Increments The following could be taken as a general guidance, when the ID says: “As an optimization, an endpoint could send frames related to flow control only when there are other frames to send or when a peer is blocked, ensuring that flow control does not cause extra packets to be sent.” I do not agree. This appears an optimisation for minimising resource use. It will I expect have a serious negative impact on performance where the path RTT is large, and that case also needs to be mentioned. This is an area where guidance is needed, since the way TCP operates is not described in the RFC series and mistakes in this part of the code can have very serious impacts on the performance and dynamics of applications, as well as the patterns of traffic on the wire.

Section: Flow Credit Increments The following could be taken as a general guidance, when the ID says: “When a sender receives credit after being blocked, it might be able to send a large amount of data in response, resulting in short-term congestion; see Section 6.9 in {{QUIC-RECOVERY}} for a discussion of how a sender can avoid this congestion.” I think this sentence may be well-intended but can be read as encouraging an unsafe practice. There is considerable latitude in how to design flow control, but read the current words as suggesting that the induced congestion from large updates are actually OK - which I do not think the IETF should say. To me this requires words of caution to avoid the large bursts.
The following could be taken as a general guidance, when the ID says: “As an optimization, an endpoint could send frames related to flow control only when there are other frames to send or when a peer is blocked, ensuring that flow control does not cause extra packets to be sent.” Even if RTT < 40ms we saw a negative impact of this optimization in our quic implementation
NAME Can you clarify what conditions you're testing, as there are are a lot of variables in flow control. We send flow control updates much less frequently than anytime there's free credit and a packet is already being sent, and very rarely see flow control blockage, despite doing dynamic window tuning on the server side. So I'd expect if we did more proactive updates with better bundling, it'd only help. Bundling flow control updates with ACK frames makes a large amount of sense, because ACK frames free up congestion window space and window updates free up flow control.
NAME We used simply conditions: sender is not app-limited, we tested FC for different bottleneck links e.g. 100Mbps, 1Gbps and different FC Limits, RTT was between 1ms und 100ms with step 10. We do not used dynamic window tuning as it’s not defined in draft as a MUST. I think it’s an interesting idea to bundle FC updates with ACK frames (if ACK must be sent every other packet). But in the case of bundling, I expect, that ackRatio parameter (e.g. equal to 10) would influence the frequency of FC-updates and thereby QUIC performance. I can implement und explore it in our implementation.

In order to have a possibility to test FC appropriate and provide comparable results, I wish, that the FC algorithm would be better defined in QUIC transport draft e.g. with a pseudocode.
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 without incurring performance penalties, up to the point where the BDP approaches the size of buffers the endpoint allocates for receiving data. If buffers are not significantly larger than the BDP, 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 other limiting factors like 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.)
I've just opened an editorial PR that fixes this. This is based on my previous comments here. However, I think that we should try to achieve consensus on the views contained therein. Though the alternative is scary, I want to make sure that we are intentionally choosing not to document "good" flow control algorithms.
Would folks please comment (here) on whether addresses this issue?
I think explicitly calling this out as a trade-off that implementations will need to experiment with, but which does not affect protocol interoperability is the correct path here. Flow control is a mechanism, not an algorithm.
I believe addresses the issue and long ago we agreed not to document an exact algorithm.