[Cake] Testing variants of the MTU latency scaling

Toke Høiland-Jørgensen toke at toke.dk
Sun Apr 22 17:31:51 EDT 2018

On 22 April 2018 23:09:54 CEST, Jonathan Morton <chromatix99 at gmail.com> wrote:
>> Takeaways (see attached plots):
>> - The MTU scaling does indeed give a nice benefit in egress mode
>>  "tcp-download-totals" plot. From just over 6 Mbps to just over 8
>>  of goodput on the 10 Mbit link. There is not a large difference
>>  between 2MTU and 4MTU, except that 4MTU hurts inter-flow latency
>>  somewhat.
>> - The effect for upload flows (where Cake is before the bottleneck;
>>  10mbit-upload.png) is negligible.
>> - The MTU scaling really hurts TCP RTT (intra-flow latency;
>>  tcp-upload-tcprtt-10mbit.png and rrul-tcprtt.png).
>> - For bidirectional traffic the combined effect is also negligible.
>> Based on all this, I propose we change the scaling mechanism so that
>> is only active in egress mode, and change it from 4 MTUs to 2. I'll
>> merge Kevin's patch to do this unless someone complains loudly :)
>> If you want me to run other tests, let me know.
>I'm not actually sure what you've measured here - unless you've somehow
>managed to swap "ingress" with "egress" mode in a strange manner.  I
>don't see any systematic measurement of the different MTU scales in
>ingress mode in your results, which makes your assertion that it should
>only be active in egress mode rather odd.

Ah, that was a typo. I meant that it should only be active in *ingress* mode. 

As for the results, as I wrote in my original email, all download flows go through cake in ingress mode (the device running cake is between the client and the bottleneck).


More information about the Cake mailing list