<div><div>I think that this discussion is about trying to solve an almost impossible problem.<div>When the link is in overload, and this is the case, there is nothing one can do with flow queuing or AQM.</div></div></div><div dir="auto"><br></div><div dir="auto">It is just too late to make something useful.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Jonathan tries to make TCP work in a desperate situation. </div><div dir="auto"><br></div><div dir="auto">In real life what would happen is that applications would just stop and so the number of flows would dicrease  to normal numbers.</div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">My2c</div><div dir="auto"><br></div><div dir="auto">Luca </div><div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 18, 2018 at 6:25 PM, Dave Taht <span><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would like to revert this change.<br>
<div class="m_-7156252960869917399HOEnZb"><div class="m_-7156252960869917399h5"><br>
On Wed, Apr 18, 2018 at 9:11 AM, Toke Høiland-Jørgensen <<a href="mailto:toke@toke.dk" target="_blank">toke@toke.dk</a>> wrote:<br>
> Jonathan Morton <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>> writes:<br>
><br>
>>> On 18 Apr, 2018, at 6:17 pm, Sebastian Moeller <<a href="mailto:moeller0@gmx.de" target="_blank">moeller0@gmx.de</a>> wrote:<br>
>>><br>
>>> Just a thought, in egress mode in the typical deployment we expect,<br>
>>> the bandwidth leading into cake will be >> than the bandwidth out of<br>
>>> cake, so I would argue that the package droppage might be acceptable<br>
>>> on egress as there is bandwidth to "waste" while on ingress the issue<br>
>>> very much is that all packets cake sees already used up parts of the<br>
>>> limited transfer time on the bottleneck link and hence are more<br>
>>> "precious", no? Users wanting this new behavior could still use the<br>
>>> ingress keyword even on egress interfaces?<br>
>><br>
>> Broadly speaking, that should indeed counter most of the negative<br>
>> effects you'd expect from disabling this tweak in egress mode. But it<br>
>> doesn't really answer the question of whether there's a compelling<br>
>> *positive* reason to do so. I want to see a use case that holds up.<br>
><br>
> What you're saying here is that you basically don't believe there are<br>
> any applications where a bulk TCP flow would also want low queueing<br>
> latency? :)<br>
><br>
> -Toke<br>
> _______________________________________________<br>
> Cake mailing list<br>
> <a href="mailto:Cake@lists.bufferbloat.net" target="_blank">Cake@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/cake</a><br>
<br>
<br>
<br>
</div></div><span class="m_-7156252960869917399HOEnZb"><font color="#888888">-- <br>
<br>
Dave Täht<br>
CEO, TekLibre, LLC<br>
<a href="http://www.teklibre.com" rel="noreferrer" target="_blank">http://www.teklibre.com</a><br>
Tel: 1-669-226-2619<br>
</font></span><div class="m_-7156252960869917399HOEnZb"><div class="m_-7156252960869917399h5">_______________________________________________<br>
Cake mailing list<br>
<a href="mailto:Cake@lists.bufferbloat.net" target="_blank">Cake@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/cake</a><br>
</div></div></blockquote></div><br></div>
</div>