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: :wink: Instead, I'll say that I think the current text covers this. Specifically, the text says "bigger windows improve performance, but you need to bear in mind the resource exhaustion concerns elsewhere in this document". Should we be saying anything else more specific?
Well, I only partially agree, in that it's not exactly a resource exhaustion in the pure sense of the term as there can be plenty of resources available (socket buffers everywhere), but more a matter of difficulty/complexity to reliably measure available resources at any instant (i.e. the TCP buffer you have on one side is not necessarily dedicated to a single stream, so what is doable during a POST upload can suddenly change before you even have the option to advertise a window size change). I agree that this could be discussed elsewhere in the doc in more details, but my point was to at least put a short warning like the one I proposed to raise awareness of implementors against the risk of pushing this setting too far because "it seems to work much better". For the record, in haproxy what we've done to mitigate this on the download side is to avoid mixing multiple client connections over a single outgoing H2 connection. This way a slow client cannot block a fast one and it remains possible to advertise slightly larger stream windows that more realistically take into account available room on the path. For uploads, users generally consider that an uploading browser doesn't perform other operations in parallel over the same connection so it's okay to increase the advertised stream as well. But all these mitigations resulted from experience, were not obvious and will not necessarily apply to other implementations, which is why I thought a small warning could be useful.
Great, so do you think the current text covers it?
Looks great like this, thank you :-)
Thanks for the constructive discussion. No doubt we missed something (that's a constant risk here), but this looks like this change is a useful one. We'll track further improvements with new issues as the opportunity arises.
H2 strongly suffers from head-of-line blocking when streams do not progress at the same spead, typically when they come from coalesced connections from different clients. Per-stream flow control is generally ineffective against this as practical window sizes matching a BDP often require impractical buffering between the intermediary and the client.