<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr"> - Jonathan Morton<br>
</p>