I think that this discussion is about trying to solve an almost impossible problem. When the link is in overload, and this is the case, there is nothing one can do with flow queuing or AQM. It is just too late to make something useful. Overload means that the number of active backlogged flows is just too large and the fair-share is too low for application in the first place and for the transport too. Jonathan tries to make TCP work in a desperate situation. In real life what would happen is that applications would just stop and so the number of flows would dicrease to normal numbers. For those apps that don’t stop the best approach would be to just kill in a selective manner, best if driven by a policy that is set by the user. This is why I think that any fix that tries to solve this problem in the queueing system should be avoided. It does not solve the real problem (overload) and introduces latency. My2c Luca On Wed, Apr 18, 2018 at 6:25 PM, Dave Taht wrote: > I would like to revert this change. > > On Wed, Apr 18, 2018 at 9:11 AM, Toke Høiland-Jørgensen > wrote: > > Jonathan Morton writes: > > > >>> On 18 Apr, 2018, at 6:17 pm, Sebastian Moeller > 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 >