<div dir="ltr">Hi Dave,<div><br></div><div>We are able to reproduce the cubic starvation issue with codel (but not fq_codel), regardless of ECN. So clearly ECN isn't the issue but the single-queued AQM is. We didn't notice that earlier even though you've clearly indicated that in your report. But Cubic and BBR loss response functions are nonlinear so that's expected.</div><div><br></div><div>We are curious why you choose the single-queued AQM. Is it just for the sake of testing?</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 27, 2016 at 2:30 PM, Yuchung Cheng <span dir="ltr"><<a href="mailto:ycheng@google.com" target="_blank">ycheng@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Oct 27, 2016 at 11:14 AM, Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br>
> On Thu, Oct 27, 2016 at 10:57 AM, Yuchung Cheng <<a href="mailto:ycheng@google.com">ycheng@google.com</a>> wrote:<br>
>> On Thu, Oct 27, 2016 at 10:33 AM, Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br>
>>> On Thu, Oct 27, 2016 at 10:04 AM, Steinar H. Gunderson<br>
>>> <<a href="mailto:sgunderson@bigfoot.com">sgunderson@bigfoot.com</a>> wrote:<br>
>>>> On Fri, Oct 21, 2016 at 10:47:26AM +0200, Steinar H. Gunderson wrote:<br>
>>>>> As a random data point, I tried a single flow from my main server in .no<br>
>>>>> to my backup server in .nl and compared CUBIC (with sch_fq) to BBR (naturally<br>
>>>>> also in sch_fq) on the sender side. The results were quite consistent across<br>
>>>>> runs:<br>
>>>><br>
>>>> Another datapoint: A friend of mine had a different, worse path (of about 40 ms)<br>
>>>> and tested with iperf.<br>
>>>><br>
>>>> CUBIC delivered 20.1 Mbit/sec (highly varying). BBR delivered 485 Mbit/sec.<br>
>>><br>
>>> I mostly live in a world (wifi) where loss is uncommon, unless forced<br>
>>> on it with a AQM.<br>
>>><br>
>>> At the moment my biggest beef with BBR is that it ignores ECN entirely<br>
>>> (and yet negotiates it). BBR is then so efficient at using up all the<br>
>>> pipe that a single queued aqm "marks madly" and everything else<br>
>>> eventually starves. Watch "ping" fade out here...<br>
>>><br>
>>> <a href="http://blog.cerowrt.org/flent/bbr-comprehensive/bbr_ecn_eventually_starving_ping.png" rel="noreferrer" target="_blank">http://blog.cerowrt.org/flent/<wbr>bbr-comprehensive/bbr_ecn_<wbr>eventually_starving_ping.png</a><br>
>><br>
>> Thanks Dave for this issue. We design BBR with CoDel in mind b/c Van<br>
>> co-designs both :)<br>
><br>
> It works pretty darn good with codel without ecn. I'm pretty darn happy with it.<br>
><br>
> fq_codel is even more lovely, especially when competing with cubic.<br>
><br>
> There are issues with single queued aqms with BBR vs cubic<br>
><br>
> <a href="http://blog.cerowrt.org/flent/bbr-ecncaps/bandwidth-share-creaming-cubic-flowblind-aqm.svg" rel="noreferrer" target="_blank">http://blog.cerowrt.org/flent/<wbr>bbr-ecncaps/bandwidth-share-<wbr>creaming-cubic-flowblind-aqm.<wbr>svg</a><br>
><br>
>> We have tested BBR with CoDel before and it works.<br>
><br>
> Well, against cubic on the same link in single queue mode, even<br>
> without ecn, life looks like this:<br>
><br>
> <a href="http://blog.cerowrt.org/flent/bbr-ecncaps/bandwidth-share-creaming-cubic-flowblind-aqm.svg" rel="noreferrer" target="_blank">http://blog.cerowrt.org/flent/<wbr>bbr-ecncaps/bandwidth-share-<wbr>creaming-cubic-flowblind-aqm.<wbr>svg</a><br>
><br>
> but fq_codel is fine, so long as there is no ecn vs nonecn collission<br>
><br>
> <a href="http://blog.cerowrt.org/flent/bbr-ecncaps/bandwidth-share-ecn-fq.png" rel="noreferrer" target="_blank">http://blog.cerowrt.org/flent/<wbr>bbr-ecncaps/bandwidth-share-<wbr>ecn-fq.png</a><br>
><br>
>> Could you share your tcpdump traces with us (maybe<br>
>> you already did but no sure) or suggest how to reproduce this.<br>
>><br>
>> This is 2 bbr flow or bbr + ecn-cubic? (I am guessing based on caption<br>
>> in your graph)<br>
><br>
> That's two BBRs with ecn enabled, going through cake in the single<br>
> queue aqm mode "flowblind". I have similar plots with pie and codel<br>
> with ecn enabled somewhere.<br>
><br>
> The emulation is 48ms RTT, 20Mbit down, 5Mbit up.<br>
><br>
> Regrettably I'm on a couple deadlines (a talk tomorrow, and next<br>
> thursday), and can't look harder, I do have caps comparing ecn vs<br>
> noecn here<br>
><br>
> <a href="http://blog.cerowrt.org/flent/bbr-ecncaps/" rel="noreferrer" target="_blank">http://blog.cerowrt.org/flent/<wbr>bbr-ecncaps/</a><br>
</div></div>Thanks for the data (and sorry for ignoring that before). Neal and I<br>
think the behaviors you are observing matches BBR's top issue we are<br>
actively pursuing: with N>1 flows, BBR may build 1.5BDP of queue. But<br>
let's separate that from ECN negotiation. Besidethe implementation<br>
complication Eric pointed out, even if BBR refrains from ECN<br>
negotiation, and the test result wouldn't change much I suspect.<br>
<br>
We'll get back soon.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
><br>
>><br>
>>><br>
>>> somewhat conversely in fq_codel, this means that it ignores codel's<br>
>>> marking attempts entirely and BBR retains it's own dynamics, (while<br>
>>> the non-BBR flows are fine) which is kind of neat to watch.<br>
>>><br>
>>>> /* Steinar */<br>
>>>> --<br>
>>>> Homepage: <a href="https://www.sesse.net/" rel="noreferrer" target="_blank">https://www.sesse.net/</a><br>
>>>> ______________________________<wbr>_________________<br>
>>>> Bloat mailing list<br>
>>>> <a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
>>>> <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Dave Täht<br>
>>> Let's go make home routers and wifi faster! With better software!<br>
>>> <a href="http://blog.cerowrt.org" rel="noreferrer" target="_blank">http://blog.cerowrt.org</a><br>
>>> ______________________________<wbr>_________________<br>
>>> Bloat mailing list<br>
>>> <a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
>>> <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>
><br>
><br>
><br>
> --<br>
> Dave Täht<br>
> Let's go make home routers and wifi faster! With better software!<br>
> <a href="http://blog.cerowrt.org" rel="noreferrer" target="_blank">http://blog.cerowrt.org</a><br>
><br>
> --<br>
> You received this message because you are subscribed to the Google Groups "BBR Development" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bbr-dev%2Bunsubscribe@googlegroups.com">bbr-dev+unsubscribe@<wbr>googlegroups.com</a>.<br>
> For more options, visit <a href="https://groups.google.com/d/optout" rel="noreferrer" target="_blank">https://groups.google.com/d/<wbr>optout</a>.<br>
</div></div></blockquote></div><br></div>