From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 869103B2A2 for ; Thu, 8 Dec 2016 17:31:17 -0500 (EST) Received: by mail-io0-x22d.google.com with SMTP id d9so26282340ioe.0 for ; Thu, 08 Dec 2016 14:31:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NhScFrpcvnU06zk04x2+GdKBWAQZEcVTi5CS7O8dJZI=; b=lhM5/IzTCDfN8ySJzBLu0V7XoV/8Ft9fEAg+0Ei4PLsDqApUXbPYvQS1arAWnIiN1C uheFO8qyFJw1fPqTRvV2lcmuAu8MV7SlyI7BVRHyx9kMEwKES+/W2EqP3CgbwCTfydDe Jq+WyP5aEJP8+0oRCRIaqM/8ZnRZrIdhamjW7Ot3v73+wd1Wh9y6JX/a1ugKslkuZRj7 6TEoSHRmSPwjnKfqzT8C4EiqL2gjQqyQk3HAcHrnkQpeg+eM2jE/wehbwQ2S8fdDY6WB YmW7+9Cffvq2G5N85YFtBZycmN3CVxOtnJwGFv6Vak9fpt7eJcfMHKti3uKh36o8mcmv buRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NhScFrpcvnU06zk04x2+GdKBWAQZEcVTi5CS7O8dJZI=; b=giDY5J8Fe4imTBtrkB6sSZ5LNXObpS1Bop1vtgFfGFoSV9IpjVF4TewTiQeJless1i MmqECkimBSWpE0d1Pg+9N9BxtgiRH36N5+Uv8clvU3EEm5wfliNoPmKJl39qafcXXU9J 90anLmLvG/5OJ0jFVnKpIANvzFv8T/TXPEHWHfWuhSZERPyYFwMIzPjRLHxJPnJob4WV o9kXEtVQ5tFJMMWFhnpPnEa9Lk5qOzbKDUt23aQ8gOmEs1zgKWAnO07l+7QmtS8qA7vJ j04p+XFazfNgF6bGCRm8om9k2p3EiWcUZTSsCrbJUvjoFEKXh8fQ6bUw/6wyrexTVIXV riFQ== X-Gm-Message-State: AKaTC02wblFGzvdoX9aiKd54XoYc2DpBdBYmb8Py/wCK9HQl4D6kGBu/HeD/x9uIRvAgImI9tmOT9aaCpqskdcGM X-Received: by 10.36.245.9 with SMTP id k9mr4021950ith.65.1481236276657; Thu, 08 Dec 2016 14:31:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Thu, 08 Dec 2016 22:31:06 +0000 Message-ID: To: Neal Cardwell , Mikael Abrahamsson Cc: bloat Content-Type: multipart/alternative; boundary=94eb2c03596e19aa1a05432d32ac Subject: Re: [Bloat] TCP BBR paper is now generally available X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 22:31:17 -0000 --94eb2c03596e19aa1a05432d32ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. 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. On Thu, Dec 8, 2016, 1:29 PM Neal Cardwell wrote: > Hi Mikael, > > 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. > > 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" sectio= n. > > In our recent talk at the ICCRG session at IETF 97 we were able to go int= o > more detail on the question of sharing paths with loss-based CC like Reno > and CUBIC (in particular please see slides 22-25): > > > https://www.ietf.org/proceedings/97/slides/slides-97-iccrg-bbr-congestion= -control-02.pdf > > There is also a video; the BBR section starts around 57:35: > https://www.youtube.com/watch?v=3DqjWTULVbiVc > > In summary, with the initial BBR release: > > o BBR and CUBIC end up with roughly equal shares when there is around 1-2= x > BDP of FIFO buffer. > > 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 tha= n > 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 dynami= c > in the passage from the ACM Queue paper you cited: "Even as loss-based > congestion control fills the available buffer, ProbeBW still robustly mov= es > 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".) > > 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 o= f > 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 ar= e > currently experimenting with are (1) explicitly trying to more fully drai= n > the queue more often, to try to get much closer to inflight=3D=3DBDP each= gain > cycle, and (2) estimate the buffer available to our flow and and modulate > the probing magnitude/frequency. > > 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 shari= ng > paths with loss-based congestion control like CUBIC/Reno. > > cheers, > neal > > > > On Thu, Dec 8, 2016 at 9:01 AM, Mikael Abrahamsson > wrote: > > On Thu, 8 Dec 2016, Dave T=C3=A4ht wrote: > > drop tail works better than any single queue aqm in this scenario. > > > *confused* > > I see nothing in the BBR paper about how it interoperates with other TCP > algorithms. Your text above didn't help me at all. > > How is BBR going to be deployed? Is nobody interested how it behaves in a > mixed environment? > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --94eb2c03596e19aa1a05432d32ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Also we are aware docsis pie is going to be deployed and we&= #39;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 r= easons.

But to set the expectation right, we are not going to make b= br prefectly flow level fair with cubic or reno. I am happy to argue why th= at makes no sense. We do want to avoid starvation of either.


On Thu, Dec 8, 2016, 1:29 P= M Neal Cardwell <ncardwell@googl= e.com> wrote:
Hi Mikael,

Thanks for yo= ur questions. Yes, we do care about how BBR behaves in mixed environments, = and particularly in mixed environments with Reno and CUBIC. And we are acti= vely working in this and related areas.

For the ACM Queue article= we faced very hard and tight word count constraints, so unfortunately we w= ere not able to go into as much detail as we wanted for the "Competiti= on with Loss-Based Congestion Control" section.

In our recen= t 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):

=C2=A0 https://www.ietf.org/proceeding= s/97/slides/slides-97-iccrg-bbr-congestion-control-02.pdf

There is also a video; the BBR section starts around 5= 7:35:
=C2=A0 https://www= .youtube.com/watch?v=3DqjWTULVbiVc

In summary, with the initi= al BBR release:

o BBR and CUBIC end up with roughly equal shares = when there is around 1-2x BDP of FIFO buffer.=C2=A0

o When a FIFO= buffer is deeper than that, as everyone on this list well knows, CUBIC/Ren= o 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 ve= ry 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 conges= tion control fills the available buffer, ProbeBW still robustly moves the B= tlBw estimate toward the flow's fair share, and ProbeRTT finds an RTPro= p estimate just high enough for tit-for-tat convergence to a fair share.&qu= ot; (I guess that last "to" should probably have been "towar= d".)

o When a buffer is shallower than 1-2x BDP, or has an A= QM 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 bottl= eneck to be underutilized; in such cases then BBR is merely using underutil= ized bandwidth, and its higher share is a good thing. In more moderately si= zed 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 exp= eriments in the lab and on YouTube. Basically the two approaches we are cur= rently experimenting with are (1) explicitly trying to more fully drain the= queue more often, to try to get much closer to inflight=3D=3DBDP each gain= cycle, and (2) estimate the buffer available to our flow and and modulate = the probing magnitude/frequency.

In summary, our #1 priority for = BBR right now is reducing queue pressure, in order to reduce delay and pack= et loss, and improve fairness when sharing paths with loss-based congestion= control like CUBIC/Reno.

cheers,
n= eal



O= n Thu, Dec 8, 2016 at 9:01 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On = Thu, 8 Dec 2016, Dave T=C3=A4ht wrote:

drop tail works better than any single queue aqm in this scenario.

 *confused*

I see nothing in the BBR paper about how it interoperates with other TCP al= gorithms. Your text above didn't help me at all.

How is BBR going to be deployed? Is nobody interested how it behaves in a m= ixed environment?


--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listin= fo/bloat


_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listin= fo/bloat
--94eb2c03596e19aa1a05432d32ac--