Re: [Cake] A few puzzling Cake results

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:

>> On 18 Apr 2018, at 12:25, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> 
>> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>> 
>>> Jonathan Morton <chromatix99@gmail.com> writes:
>>> 
>>>>> On 17 Apr, 2018, at 12:42 pm, Toke Høiland-Jørgensen <toke@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?
>
> The thread that lead to that change:
>
> https://lists.bufferbloat.net/pipermail/cake/2017-December/003159.html
>
> Commits: 0d8f30faa3d4bb2bc87a382f18d8e0f3e4e56eac & the change to
> 4*bulk flows 49776da5b93f03c8548e26f2d7982d553d1d226c

Ah, thanks for digging that up! I must not have been paying attention
during that discussion ;)

Well, from reading the thread, this is an optimisation for severe
overload in ingress mode on very low bandwidths. And the change
basically amounts to throwing up our hands and saying "screw it, we
don't care about the intra-flow latency improvements of an AQM". Which
is, I guess, technically a valid choice in weighing tradeoffs, but I
maintain that it is the wrong one.

Incidentally, removing the multiplication with the number of bulk flows
restores TCP intra-flow latency to be on par with (or even a bit better
than) FQ-CoDel, and no longer scaling with the number of active flows.

-Toke