<p dir="ltr">I think you may be conflating several different buffers which exist in different places and are controlled by different means.  I'll try to illustrate this using a single scenario with which I'm personally familiar: a half megabit 3G connection without AQM.</p>
<p dir="ltr">Status quo is that loading a web page with many resources on it is unreliable. Early connections succeed and become established, the congestion window opens, the buffer in the 3G tower begins to fill up, inducing several seconds of latency, and subsequent DNS lookups and TCP handshakes tend to time out. End result: often, half the images on the page are broken.</p>
<p dir="ltr">Status quo is also that a single big, continuous download (such as a software update) is capable of inducing 45 seconds of latency on the same connection, making it virtually impossible to do anything else with it concurrently. This corresponds to several megabytes of dumb buffering in the tower AND several megabytes of TCP receive window AND several megabytes of TCP congestion window. Lose any one of those three things and the induced latency disappears. But it's there, with a single connection.</p>
<p dir="ltr">As far as bufferbloat is concerned, HTTP 2 just converts the first situation into the second one. If images and other resources are loaded from the same server as the base page, as they should be, then they'll load more reliably. But any resource loaded externally (even just sharded off) will become less reliable (if anything) in the presence of bufferbloat, because a separate connection still has to be made per host server.</p>
<p dir="ltr">If the queue in the tower was less dumb, then TCP would be given congestion signals when it began to fill up. In that situation, HTTP 2 helps because there are fewer connections that need to receive that signal to be effective.</p>
<p dir="ltr"> - Jonathan Morton<br>
</p>