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).

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
>