Re: [Cake] Testing variants of the MTU latency scaling

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

On 22 April 2018 23:09:54 CEST, Jonathan Morton <chromatix99@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
>Mbps
>>  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
>it
>> 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).

-Toke