<div dir="auto">Would making it active only for the 'ingress' mode be an option?<div dir="auto"><br><div dir="auto">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).</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 18, 2018, 12:25 PM Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br></div><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>
<br>
On Wed, Apr 18, 2018 at 9:11 AM, Toke Høiland-Jørgensen <<a href="mailto:toke@toke.dk" target="_blank" rel="noreferrer">toke@toke.dk</a>> wrote:<br>
> Jonathan Morton <<a href="mailto:chromatix99@gmail.com" target="_blank" rel="noreferrer">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" rel="noreferrer">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" rel="noreferrer">Cake@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/cake</a><br>
<br>
<br>
<br>
-- <br>
<br>
Dave Täht<br>
CEO, TekLibre, LLC<br>
<a href="http://www.teklibre.com" rel="noreferrer noreferrer" target="_blank">http://www.teklibre.com</a><br>
Tel: 1-669-226-2619<br>
_______________________________________________<br>
Cake mailing list<br>
<a href="mailto:Cake@lists.bufferbloat.net" target="_blank" rel="noreferrer">Cake@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/cake</a><br>
</blockquote></div>