Re: [Bloat] Remarkably simple bloat managing use by a UK ISP

[Jonathan Morton <chromatix99@gmail.com>]

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

Going back to fundamentals, there's a clear distinction between traffic
which is latency sensitive and traffic which is bandwidth sensitive.
Perhaps surprisingly, web traffic tends to fall into the former category,
unless the link bandwidth is very low by current standards (analogue modem
territory).

It sounds like that router's default settings attempt to make that
distinction based on port number, and then perform strict prioritization.
The example of SSH demonstrates why that doesn't work; interactive shell
over SSH is latency sensitive, but SCP and rsync-over-SSH are bandwidth
sensitive, and they all use the same port. The need for explicit
configuration (a database of port numbers) is also a black mark against it,
especially since they managed to leave out such a common protocol as DNS.

Packet size is a better heuristic than port number. Most latency sensitive
protocols do tend to use small packets, and nearly all bandwidth sensitive
traffic uses the largest packets it can. SSH also naturally switches
between small and large packets depending on the type of traffic it's
carrying. If you simply sort your traffic by packet size, you don't even
need to configure it - but otherwise you just have a threshold to set and
forget. Cunningly, this also naturally performs ack and ping promotion.

The downside of packet size as a heuristic is that it's possible to game
it, especially with strict priority in force. All you have to do is send
packets below the threshold if there is one, or slightly smaller than the
competing traffic if there isn't one. The receiver can influence this by
setting the MSS low during TCP handshakes.

That is why fq_codel uses the sparse/saturating flow distinction for
priority. It's a much more robust heuristic than packet size, requires no
configuration at all, and is not so easy to game. The downside? It's only
available if you're already doing flow isolation, which basically solves
the core problem on its own. Still, making that distinction does help with
new flow startup and jitter reduction.

- Jonathan Morton

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