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: As such we should mention in the recommendations that intermediaries that coalesce connections either have very large buffers or try to group streams from a same client connection together on a server connection. Suggested by NAME
I'm not sure that I'm following the problem statement very well, so I'm not sure what sort of recommendation would go with it. Is the problem that when aggregating requests from multiple clients you expose all of those clients - and all of the requests on the corresponding connections - to head-of-line blocking on the shared connection? That doesn't seem quite right to me - though the requests that share that connection might suffer, the way that a stalled request on one connection might affect other requests on a different connection is limited. If a request affects others, is it because it would consume shared resources like flow control window and connection-level flow control? Keeping per-stream flow control relatively small relative to the connection limits would be the way to avoid that exposure, would it not? That said, larger connection-level buffers might reduce contention, but in general more buffering just means more latency. NAME am I chasing the right idea? Maybe you can provide a paragraph on the problem and I can try to massage it into shape for the draft.
The issue is that the intermediary that coalesces many client connections into a single H2 connection cannot have infinite resources to buffer store the response data for these clients, yet will have to advertise a significantly large stream window to the other end to maintain an acceptable bandwidth. In practice it most often goes well because your advertised window is lower than what can be stored into system buffers. But once a client stalls, all the chain stalls, and you quickly end up in a situation where the advertised stream window is ahead of what you're really able to store. Note that looking at how TCP buffers are filled in front is not always effective. You may very well be using H2 on the front with other streams making it hard to figure how much you could really push, you could have SSL under it having its own buffers, you could be applying compression in the middle, also making it hard to figure how much the output gives you on input, etc. In haproxy we've finally adressed this by deciding that by default multiple clients are not coalesced over a server-facing H2 connection. We have multiple strategies of connection reuse so this remains configurable, but this was the best compromise we could find.