[Cake] A few puzzling Cake results

[Kevin Darbyshire-Bryant]

> On 18 Apr 2018, at 12:25, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> 
> 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?

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

Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20180418/8d18d8d6/attachment.sig>