Re: [Bloat] http/2

[Jonathan Morton <chromatix99@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

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.

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.

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.

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.

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.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 1931 bytes --]