<p dir="ltr">Also we are aware docsis pie is going to be deployed and we'll specifically test that scenario. With fq this issue is a lot smaller but we understand it is not preferred setting in some aqm for other good reasons.</p>
<p dir="ltr">But to set the expectation right, we are not going to make bbr prefectly flow level fair with cubic or reno. I am happy to argue why that makes no sense. We do want to avoid starvation of either.</p>
<br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 8, 2016, 1:29 PM Neal Cardwell <<a href="mailto:ncardwell@google.com">ncardwell@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">Hi Mikael,<br class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Thanks for your questions. Yes, we do care about how BBR behaves in mixed environments, and particularly in mixed environments with Reno and CUBIC. And we are actively working in this and related areas.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">For the ACM Queue article we faced very hard and tight word count constraints, so unfortunately we were not able to go into as much detail as we wanted for the "Competition with Loss-Based Congestion Control" section.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">In our recent talk at the ICCRG session at IETF 97 we were able to go into more detail on the question of sharing paths with loss-based CC like Reno and CUBIC (in particular please see slides 22-25):</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> <a href="https://www.ietf.org/proceedings/97/slides/slides-97-iccrg-bbr-congestion-control-02.pdf" class="gmail_msg" target="_blank">https://www.ietf.org/proceedings/97/slides/slides-97-iccrg-bbr-congestion-control-02.pdf</a><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">There is also a video; the BBR section starts around 57:35:</div><div class="gmail_msg"> <a href="https://www.youtube.com/watch?v=qjWTULVbiVc" class="gmail_msg" target="_blank">https://www.youtube.com/watch?v=qjWTULVbiVc</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">In summary, with the initial BBR release:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">o BBR and CUBIC end up with roughly equal shares when there is around 1-2x BDP of FIFO buffer. </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">o When a FIFO buffer is deeper than that, as everyone on this list well knows, CUBIC/Reno will dump excessive packets in the queue; in such bufferbloated cases BBR will get a slightly lower share of throughput than CUBIC (see slide 23-24). I say "slightly" because BBR's throughput drops off only very gradually, as you can see. And that's because of the dynamic in the passage from the ACM Queue paper you cited: "Even as loss-based congestion control fills the available buffer, ProbeBW still robustly moves the BtlBw estimate toward the flow's fair share, and ProbeRTT finds an RTProp estimate just high enough for tit-for-tat convergence to a fair share." (I guess that last "to" should probably have been "toward".)</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">o When a buffer is shallower than 1-2x BDP, or has an AQM targeting less than 1-2 BDP of queue, then BBR will tend to end up with a higher share of bandwidth than CUBIC or Reno (I think the tests you were referencing fall into that category). Sometimes that is because the buffer is so shallow that the multiplicative backoff of CUBIC/Reno cause the bottleneck to be underutilized; in such cases then BBR is merely using underutilized bandwidth, and its higher share is a good thing. In more moderately sized buffers in the 0-2x BDP range (or AQM-managed buffers), our active work under way right now (see slide 22) should improve things, based on our experiments in the lab and on YouTube. Basically the two approaches we are currently experimenting with are (1) explicitly trying to more fully drain the queue more often, to try to get much closer to inflight==BDP each gain cycle, and (2) estimate the buffer available to our flow and and modulate the probing magnitude/frequency.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">In summary, our #1 priority for BBR right now is reducing queue pressure, in order to reduce delay and packet loss, and improve fairness when sharing paths with loss-based congestion control like CUBIC/Reno.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">cheers,</div><div class="gmail_msg">neal</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div></div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Thu, Dec 8, 2016 at 9:01 AM, Mikael Abrahamsson <span dir="ltr" class="gmail_msg"><<a href="mailto:swmike@swm.pp.se" class="gmail_msg" target="_blank">swmike@swm.pp.se</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="gmail_msg">On Thu, 8 Dec 2016, Dave Täht wrote:<br class="gmail_msg">
<br class="gmail_msg">
<blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
drop tail works better than any single queue aqm in this scenario.<br class="gmail_msg">
</blockquote>
<br class="gmail_msg"></span>
*confused*<br class="gmail_msg">
<br class="gmail_msg">
I see nothing in the BBR paper about how it interoperates with other TCP algorithms. Your text above didn't help me at all.<br class="gmail_msg">
<br class="gmail_msg">
How is BBR going to be deployed? Is nobody interested how it behaves in a mixed environment?<div class="m_7485398032734941259HOEnZb gmail_msg"><div class="m_7485398032734941259h5 gmail_msg"><br class="gmail_msg">
<br class="gmail_msg">
-- <br class="gmail_msg">
Mikael Abrahamsson email: <a href="mailto:swmike@swm.pp.se" class="gmail_msg" target="_blank">swmike@swm.pp.se</a></div></div><br class="gmail_msg">_______________________________________________<br class="gmail_msg">
Bloat mailing list<br class="gmail_msg">
<a href="mailto:Bloat@lists.bufferbloat.net" class="gmail_msg" target="_blank">Bloat@lists.bufferbloat.net</a><br class="gmail_msg">
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br class="gmail_msg">
<br class="gmail_msg"></blockquote></div><br class="gmail_msg"></div>
_______________________________________________<br class="gmail_msg">
Bloat mailing list<br class="gmail_msg">
<a href="mailto:Bloat@lists.bufferbloat.net" class="gmail_msg" target="_blank">Bloat@lists.bufferbloat.net</a><br class="gmail_msg">
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br class="gmail_msg">
</blockquote></div>