Re: [Bloat] Bloat done correctly?

[Jonathan Morton <chromatix99@gmail.com>]

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

We have a test in Flent which tries to exercise this case: 50 flows in one
direction and 1 in the other, all TCP. Where the 50 flows are on the narrow
side of an asymmetric link, it is possible to see just what happens when
there isn't enough bandwidth for the acks of the single opposing flow.

What I see is that acks behave like an unresponsive flow in themselves, but
one that is reasonably tolerant to loss (more so than to delay). On a
standard AQM, the many flows end up yielding to the acks; on a
flow-isolating AQM, the acks are restricted to a fair (1/51) share, but
enough of them are dropped to (eventually) let the opposing flow get most
of the available bandwidth on its side. But on an FQ without AQM, acks
don't get dropped so they get delayed instead, and the opposing flow will
be ack clocked to a limited bandwidth until the ack queue overflows.

Cake ends up causing odd behaviour this way. I have a suspicion about why
one of the weirder effects shows up - it has to get so aggressive about
dropping acks that the count variable for that queue wraps around.
Implementing saturating arithmetic there might help.

There is a proposed TCP extension for ack congestion control, which allows
the ack ratio to be varied in response to ack losses. This would be a
cleaner way to achieve the same effect, and would allow enabling ECN on the
acks, but it's highly experimental.

- Jonathan Morton

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