[Cake] Testing variants of the MTU latency scaling
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
>> - 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