Re: [Cake] A few puzzling Cake results

[Sebastian Moeller <moeller0@gmx.de>]

On April 18, 2018 6:34:47 PM GMT+02:00, Georgios Amanakis <gamanakis@gmail.com> wrote:
>Would making it active only for the 'ingress' mode be an option?
>
>Otherwise it has to be documented that when using ingress mode with
>lots of
>bulk flows on <20mbit/s the actual goodput is going to be less than the
>set
>one (eg for 9.8mbit/s set, 5.3 mbit/s actual).

That seems to be not the best way to think about this IMHO.
Normal mode will restrict the gross rate of packets leaving cake while ingress mode tried to restrict the gross rate of incoming packets. The effect on a net measure like to/up goodput seems like it should just be a secondary goal. Again, I might be off my rocker here, but I really think that cake should make sense on the gross rate level first...

>
>On Wed, Apr 18, 2018, 12:25 PM Dave Taht <dave.taht@gmail.com> wrote:
>
>> I would like to revert this change.
>>
>> On Wed, Apr 18, 2018 at 9:11 AM, Toke Høiland-Jørgensen
><toke@toke.dk>
>> wrote:
>> > Jonathan Morton <chromatix99@gmail.com> writes:
>> >
>> >>> On 18 Apr, 2018, at 6:17 pm, Sebastian Moeller <moeller0@gmx.de>
>> wrote:
>> >>>
>> >>> Just a thought, in egress mode in the typical deployment we
>expect,
>> >>> the bandwidth leading into cake will be >> than the bandwidth out
>of
>> >>> cake, so I would argue that the package droppage might be
>acceptable
>> >>> on egress as there is bandwidth to "waste" while on ingress the
>issue
>> >>> very much is that all packets cake sees already used up parts of
>the
>> >>> limited transfer time on the bottleneck link and hence are more
>> >>> "precious", no? Users wanting this new behavior could still use
>the
>> >>> ingress keyword even on egress interfaces?
>> >>
>> >> Broadly speaking, that should indeed counter most of the negative
>> >> effects you'd expect from disabling this tweak in egress mode. But
>it
>> >> doesn't really answer the question of whether there's a compelling
>> >> *positive* reason to do so. I want to see a use case that holds
>up.
>> >
>> > What you're saying here is that you basically don't believe there
>are
>> > any applications where a bulk TCP flow would also want low queueing
>> > latency? :)
>> >
>> > -Toke
>> > _______________________________________________
>> > Cake mailing list
>> > Cake@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/cake
>>
>>
>>
>> --
>>
>> Dave Täht
>> CEO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-669-226-2619
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.