Each dot is a single netalyzr test; it’s a lot of samples!

Note that the top speed for the test is around 20Mbps; there are problems at higher bandwidths not plotted. And the white area down and to the right is caused by the termination of the test at around 5 seconds of buffering; there are problems down there too!

Anything that causes a single process to send a large number of line rate packets back to back onto the wire is just making burstiness in the Internet worse (and there are already phenomena that tend to coalesce packets into bursts as it is). So such bursts cross the Internet, where they enter their customer’s single, bloated, stupid broadband device.

Part of why we like fq_codel so much is that its natural behavior is to break up such bursts at any bottleneck, reducing the burst problem.

Needless to say, this is not good for latency, and may cause collateral damage of all sorts.

Note that the people are not watching latency (particularly from the customer’s end). That is as important/more important than bandwidth per CPU cycle: web sites are “stickier” the faster they are *to the user of that web site*. Getting packets out of your data center with the least CPU cycles may not achieve that goal, but sometimes the opposite.

We’ve been around the mulberry bush many times on offloading TCP itself since the 1980′s. But this means you get two maintenance headaches: both your OS, and the firmware in the NIC. Not a good idea.

It is also a classic example of “if a little is good, a lot must be better”. Any of these techniques may be helpful at scale 2 or 4 (they provide most of their benefit). But then people seem to think “it must be even better to turn the knob to 11″… It seldom is… But then the knob gets turned anyway.

See https://datatracker.ietf.org/wg/rmcat/charter/ for more information.