Code change:
timely fashion.  Failure to do so could lead to a deadlock when critical frames, such as WINDOW_UPDATE, are not read and acted upon. <ins> 5.2.3. If an endpoint cannot ensure that its peer always has available flow control window space that is greater than the peer's bandwidth-delay product on this connection, its receive throughput will be limited by HTTP/2 flow control.  This will result in degraded performance. Sending timely WINDOW_UPDATE frames can improve performance. Endpoints will want to balance the need to improve receive throughput with the need to manage resource exhaustion risks, and should take careful note of dos in defining their strategy to manage window sizes. </ins> 5.3. In a multiplexed protocol like HTTP/2, prioritizing allocation of

Related discussion:
text: Probably that we could propose something like this: Also, please note that the same situation happens the other way around, with multiple uploads over a single H2 connection to multiple servers behind working at different speeds. It's generally less of an issue though, but the large windows necessary to permit fast POST uploads may very well block the retrieval of small objects by the same client within the same connection.
Is this just an over-commitment of flow control then? That is, you advertise a window of N when you only really have space for M < N? What is interesting is the implication here that you might be forced to advertise the larger window because if you don't you can't get decent throughput, but to do so you are betting that most of that capacity will be used by in-network state (data that is on the wire or in routers and whatnot, along with all the in-system buffers you don't see). Of course, if that stalls, all that stuff in those buffers will all be forced into your buffers. That can affect all connections that are somehow entangled with the affected stream. That means all requests on the same connection, but it could affect other connections. All that said, that's much more involved than your text here. You appear to be looking for something much simpler. We should have advice about the connection-level flow control credit being backed by real resources. You say stream, but the purpose of connection-level flow control is to limit resource allocation. While the stream-level values more directly determine stream-level throughput, the general idea is that they can be set with minimal regard to resource management if there is a good connection-level limit (the main consequence of not jointly managing these is a range of complicated priority issues). The current document is not very good about saying much about any of this. So any addition along these lines, including a version of that text, would be worth adding.
When flow-control is set to values that the endpoint will respect, it minimizes retransmits due to buffer overruns. Minimizing retransmits does not always guarantee highest bandwidth; The more conservative one is with respect to preventing retransmits or buffer overruns, the more probable it is that some resources will be unused. This is similar to the tradeoff space of congestion control, however the buffers here are visible to the endpoints.