From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 247F13B25E for ; Wed, 21 Sep 2016 05:39:40 -0400 (EDT) Received: by mail-qk0-x231.google.com with SMTP id t7so39949991qkh.2 for ; Wed, 21 Sep 2016 02:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sB8GymmGcbX7Jd9OFDJTOSb0u+ZUHbpUsRAtYFdSdH8=; b=OsLLWgR01Ogk6Pe6wfEyWScWhy4ZGtCyJwmANsv54gITcH4gRZ0FGIXLG9mQUMvjKD d/2pknVs57JcFVvzJ2S4DaEyaNfgZPj7b4q/wrdCkjPtlX1aD5EcrUbWF0kRrJpC7k6v s3IdP4f9fHd35ZBTTOIE8/WtAL3oh1fmA2c22t4s4ny3mW769KfGOhgERXCj5J9+R2gg M5vt4fjGScPxh3526kYFbrjVc1zGzdzKrpG0sLtsom9rqReEUrKd4uvBLRN+xr9BMcJr Oow7YcFGjSE1X35fsWtfTH24N9z9TEAS6Q0b3RDaJ5gogud/BBotuXv3lJ2HEwv6+kcB JJWA== 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:content-transfer-encoding; bh=sB8GymmGcbX7Jd9OFDJTOSb0u+ZUHbpUsRAtYFdSdH8=; b=a3edHBtxqivxjdrn2ppQMYv36qTAKYLsuUAcjyBOIqlJBGuklcman3krok5jgP9iIF 1jgSP7ivPVZKjG++imzuT9YkpEZRbwWvl9uctQqIUBFzNs99tUMjvzC8+K3MDmTLzig+ uWzuip+7SqiBNRP8hFt+w0+A81E7HSad8IFqbwppcM3eLmVOK8nUbhfVRwRq7Tvqodc6 5X2MVUycqRLDGWkk3s/uohfGO7/S9vEqCeHB99KI721wyPca0jFtOekMVvMWPHq5u9rP M27KQ82qD0g27WSn8C6p9D7AK9RnvihYssoDpcF8HAtDO6/DC6jBkmK+BtLeqg1JbL12 jQgg== X-Gm-Message-State: AE9vXwPp4TbdRg+bqUw/r9UIvKmlbNbNx6a9PkRHFDnFfX6bxbqxXRiAWe45rMov4Jgrl/pgttIU90ejikvocA== X-Received: by 10.55.165.135 with SMTP id o129mr41327541qke.196.1474450779698; Wed, 21 Sep 2016 02:39:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.137.214 with HTTP; Wed, 21 Sep 2016 02:39:39 -0700 (PDT) In-Reply-To: <92a6ae25-530f-1837-addd-8a9ef07dd022@gmail.com> References: <92a6ae25-530f-1837-addd-8a9ef07dd022@gmail.com> From: Dave Taht Date: Wed, 21 Sep 2016 02:39:39 -0700 Message-ID: To: Alan Jenkins Cc: Maciej Soltysiak , "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP in net-next X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 09:39:40 -0000 On Wed, Sep 21, 2016 at 2:06 AM, Alan Jenkins wrote: > On 17/09/16 19:53, Dave Taht wrote: >> >> BBR is pretty awesome, and it's one of the reasons why I stopped >> sweating inbound rate limiting + fq_codel as much as I used to. I have >> a blog entry pending on this but wasn't expecting the code to be >> released before the paper was... and all I had to go on til yesterday >> was Nowlan's dissertation: >> >> http://blog.cerowrt.org/papers/bbr_thesis.pdf > > > are we sure - that's a fairly different algorithm and different expansion= of > the acronym... Yes it is very different, but it appears to have had the germ of at least one of the good ideas in the soon to be published BBR. "BBR detects bufferbloat by comparing its calculated correlation to a configurable threshold (e.g., 90%) and declaring bufferbloat whenever the value exceeds the threshold." "Upon detecting bufferbloat, BBR immediately sets the TCP cwnd to the window estimate, rather than gradually reducing the sending rate as in, for example, Proportional Rate Reduction [19]. Immediately changing the cwnd has two advantages. 27 First, it stops packet transmissions immediately and prevents further exacerbating the delay. When the transmissions resume with the reduced cwnd, they should experience shorter queuing delay. *Second, drastic changes in sending rate should result in sharp differences in observed RTT, increasing the signal-to-noise ratio in the observations and improving the correlation calculation*." I dunno, I'm just reading tea leaves here! can't wait for the paper! >> video streaming experiments ran on a live, production CDN, where >> clients included real mobile and desktop users > >> large, multinational production network > > hmm, I suppose... > >> ## Acknowledgments ## >> >> Van >> ... >> Eric >> ... > > > ok, there's clearly some overlap here :-D. > > > >> which seemed closer to good than anything I'd read before, but still >> wrong in a few respects, which has taken a few years to sort out. I >> think reading the upcoming acm queue paper is going to be fun! >> >> I think they have identified the right variables to probe - RTT and >> bandwidth, in sequence - for modern congestion control to work much >> better. >> >> Still BBR makes a few assumptions that do not hold (or so I think) - >> with wifi in the control loop, and it needs wider testing in more >> circumstances than just google facing out - like on itty bitty nas's >> and media servers - and especially seeing what happens when it >> interacts with fq_codel and cake would be good to see. I've watched >> youtube be *excellent* for 2 years now, and only had the faintest >> hints as to why. >> >> It was quite amusing that the original patchset didn't compile on 32 >> bit platforms. >> >> And make no mistake - it still makes plenty of sense to apply >> fq_codel-like algorithms to routers, and the stuff we just did to wifi >> for fq_codel and airtime fairness. Had I thought BBR solved everything >> I'd have quit years ago. >> >> >> >> On Sat, Sep 17, 2016 at 11:34 AM, Maciej Soltysiak >> wrote: >>> >>> Hi, >>> >>> Just saw this: https://patchwork.ozlabs.org/patch/671069/ >>> >>> Interested to see how BBR would play out with things like fq_codel or >>> cake. >>> >>> "loss-based congestion control is unfortunately out-dated in today's >>> networks. On >>> today's Internet, loss-based congestion control causes the infamous >>> bufferbloat problem" >>> >>> So, instead of waiting for packet loss they probe and measure, e.g. whe= n >>> doing slow start (here called STARTUP) they don't speed up until packet >>> loss, but slow down before reaching estimated bandwidth level. >>> >>> Cake and fq_codel work on all packets and aim to signal packet loss ear= ly >>> to >>> network stacks by dropping; BBR works on TCP and aims to prevent packet >>> loss. --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org