[Cake] A few puzzling Cake results

[Toke Høiland-Jørgensen]

Toke Høiland-Jørgensen <toke at toke.dk> writes:

> Jonathan Morton <chromatix99 at gmail.com> writes:
>
>>> On 17 Apr, 2018, at 12:42 pm, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>>> 
>>> - The TCP RTT of the 32 flows is *way* higher for Cake. FQ-CoDel
>>>  controls TCP flow latency to around 65 ms, while for Cake it is all
>>>  the way up around the 180ms mark. Is the Codel version in Cake too
>>>  lenient, or what is going on here?
>>
>> A recent change was to increase the target dynamically so that at
>> least 4 MTUs per flow could fit in each queue without AQM activity.
>> That should improve throughput in high-contention scenarios, but it
>> does come at the expense of intra-flow latency when it's relevant.
>
> Ah, right, that might explain it. In the 128 flow case each flow has
> less than 100 Kbps available to it, so four MTUs are going to take a
> while to dequeue...

OK, so I went and looked at the code and found this:

	bool over_target = sojourn > p->target &&
	                   sojourn > p->mtu_time * bulk_flows * 4;


Which means that we scale the allowed sojourn time for each flow by the
time of four packets *times the number of bulk flows*.

So if there is one active bulk flow, we allow each flow to queue four
packets. But if there are ten active bulk flows, we allow *each* flow to
queue *40* packets.

This completely breaks the isolation of different flows, and makes the
scaling of Cake *worse* than plain CoDel.

So why on earth would we do that?

-Toke