From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 CA2B63B2A2 for ; Thu, 8 Dec 2016 16:29:45 -0500 (EST) Received: by mail-oi0-x22e.google.com with SMTP id w63so466900709oiw.0 for ; Thu, 08 Dec 2016 13:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PrqSD0i8bMAC5qQzu7NvMFcZCg7eYoIFuI01WZN2JHE=; b=IzXsTH4sUzbDfQUw/xEmHgnN7qSF3GJN2UNEVCsx+NPKqBY4/W9t0ryvLBIM2+MuuF yIgJ7WnVr4Cew1sGDUmYYimHzAt8lhXtvL72zNX7vr4J6vArhyr25c/SEVeMwxDa5hhS 1mrQLv4sNpcqvHWNogZW8/KeWn6gLq1zKYSEs/3eog8mRzo97Y23SWNyP9lPCzBwbfOy NMBhWFqGZPach73Y1YsARb4weE7zhWyxpwACKZ/Eke2V+cEPBLeju89BovOKkHN5yDTZ AOESp+lJe1AJxNSQ/7b1t8U+jnIdC2CWy8nFGm1giNaKEmzGdcnfsYK4ZQGkUdkocINg KYIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PrqSD0i8bMAC5qQzu7NvMFcZCg7eYoIFuI01WZN2JHE=; b=dwhRS39Cw4Z7kFZ4nDMYU55f9wCwySkF9jPGUkcE3NSGouq/OJOxduE0cav1rtp95Z YcTMKg0Ot1voKSl8zLtd1F+LuOeuiZFebJDinnQJ3lAJaus7IuWP5mnASG+8v1UjyxOg HEYsNYk/CSQndgcQRyTP9CbmJqRJgQ/2mtBiNQ6uIcz4n1soJUTdFJofMUkwIBzAR0KT lSUoo0vLb8RVeEGNGttngkOhH0F8LDOJtBwwMPMT0jLC7e0H2mjENxvbNl49kpPYfPkI 0HThOQDtnvB6HMC8UKgUnkWFQIVFJJAPaa9y8sPImS1YZTxLIdlN+4gfBfT6Q9znsEEy QJgQ== X-Gm-Message-State: AKaTC00LmdhwgEfhlEhFy3b5EEK7s1YtrLr3DPIGufZLy55wdqF1Iu4PmzDSv/9L6NZjaCXQpsR+ZKWPUQaK7wJn X-Received: by 10.202.195.18 with SMTP id t18mr41693885oif.110.1481232585102; Thu, 08 Dec 2016 13:29:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.240.213 with HTTP; Thu, 8 Dec 2016 13:29:14 -0800 (PST) In-Reply-To: References: From: Neal Cardwell Date: Thu, 8 Dec 2016 16:29:14 -0500 Message-ID: To: Mikael Abrahamsson Cc: =?UTF-8?Q?Dave_T=C3=A4ht?= , bloat Content-Type: multipart/alternative; boundary=001a1134fbce10f6a105432c56ba 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 21:29:46 -0000 --001a1134fbce10f6a105432c56ba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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" section. 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): https://www.ietf.org/proceedings/97/slides/slides-97-iccrg-bbr-congestion-c= ontrol-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-2x 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 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".) 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=3D=3DBDP each g= ain 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 sharing 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 > > --001a1134fbce10f6a105432c56ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mikael,

Thanks for your question= s. Yes, we do care about how BBR behaves in mixed environments, and particu= larly in mixed environments with Reno and CUBIC. And we are actively workin= g in this and related areas.

For the ACM Queue art= icle 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 "Compe= tition with Loss-Based Congestion Control" section.

In our recent talk at the ICCRG session at IETF 97 we were able to g= o into more detail on the question of sharing paths with loss-based CC like= Reno and CUBIC (in particular please see slides 22-25):

There is also a video; the BBR section starts around 57:35:

In = summary, with the initial BBR release:

o BBR and C= UBIC 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/Reno will dump excessive = packets in the queue; in such bufferbloated cases BBR will get a slightly l= ower share of throughput than CUBIC (see slide 23-24). I say "slightly= " because BBR's throughput drops off only very gradually, as you c= an see. And that's because of the dynamic in the passage from the ACM Q= ueue paper you cited: "Even as loss-based congestion control fills the= available buffer, ProbeBW still robustly moves the BtlBw estimate toward t= he flow's fair share, and ProbeRTT finds an RTProp estimate just high e= nough 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 targ= eting less than 1-2 BDP of queue, then BBR will tend to end up with a highe= r share of bandwidth than CUBIC or Reno (I think the tests you were referen= cing fall into that category). Sometimes that is because the buffer is so s= hallow that the multiplicative backoff of CUBIC/Reno cause the bottleneck t= o be underutilized; in such cases then BBR is merely using underutilized ba= ndwidth, and its higher share is a good thing. In more moderately sized buf= fers 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 experiment= s 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=3D=3DBDP each gain cycle,= and (2) estimate the buffer available to our flow and and modulate the pro= bing magnitude/frequency.

In summary, our #1 prior= ity 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 co= ngestion control like CUBIC/Reno.

cheers,
neal


=
On Thu, Dec 8, 2016 at 9:01 AM, Mikael Abrah= amsson <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<= /a>
https://lists.bufferbloat.net/listinfo/bloat

--001a1134fbce10f6a105432c56ba--