From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c: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 3DD963B25E for ; Wed, 21 Sep 2016 05:06:53 -0400 (EDT) Received: by mail-wm0-x231.google.com with SMTP id b130so79648268wmc.0 for ; Wed, 21 Sep 2016 02:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:newsgroups:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=A7rXIB8H8c7oHZ0NDJL1zTe/QGjvMMUZRNr6t9taFRo=; b=l0CEtMTl93mFNA4NKTpngcyTiymep2hyaO1tiAr9ybIR3yhFLPqI2Bifu7O+gsAYR8 YjLQI6p1cZdtwINJQhFES2/PplBBLRVydTquRoxuVxIoNAu+aSUPbg7aJcBOWqZq8McN Ko+3SKiiUT5dly9FjmklB8h83+L8IykMNIct8BzQuMBonXVhvmJ8ddkS5pRdo9u+RpmU y25q5ShRHOaCbpneVSYNVJiW1lPBbY9+XoJR7j07MRVCMhJs8noLNLQ/2s8gjpCdyJOa 2F8Z30ZPe91KfNM1DtM/dFByyZ4HhOShIuB5gY1oACkWzwyOflb9hCr29mGeGKWYDEE3 2CFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:newsgroups:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=A7rXIB8H8c7oHZ0NDJL1zTe/QGjvMMUZRNr6t9taFRo=; b=SRtE0Bl/5U4564P1KbPJtK4SHFkb73zI9qt8SHd2S4msXWu5eDZKnqWu19R27ih54R A53gitkkJPuEEd5xUuI81sMEbMA0jptBcn2kkLgxvBkhKTH3yAks/3houEaKRpE4q2rM slG/+etA8n78dZ1yU59/zwUmMJIxieqzVXI+KNe5ZMJbIoLvIL/uW+EBIWC3b58Ixzfc tKiNeTgJsEL3GDnM/jhh16K+mNPC+GjiyvTb3l7bxinzXokA6TXp3Hu4yLHtyzpkyt4b 5h+eJBGsv6JNKA6h2J3yz6FW6/04ZGNv2iVFokLk6AnFEMu95LGiSoGRbb0P9GyfHM3s TdlA== X-Gm-Message-State: AE9vXwNy95SAWwXXHNPM9eF/6uublc+hr584/Vvso0ZY1uVuUhKKDXDPv3fCcX7lZoMHMA== X-Received: by 10.28.37.67 with SMTP id l64mr2009379wml.105.1474448811653; Wed, 21 Sep 2016 02:06:51 -0700 (PDT) Received: from localhost.localdomain (host-89-243-172-136.as13285.net. [89.243.172.136]) by smtp.googlemail.com with ESMTPSA id g17sm31474530wme.3.2016.09.21.02.06.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Sep 2016 02:06:50 -0700 (PDT) To: Dave Taht , Maciej Soltysiak References: Cc: "cerowrt-devel@lists.bufferbloat.net" Newsgroups: gmane.comp.embedded.cerowrt.devel From: Alan Jenkins Message-ID: <92a6ae25-530f-1837-addd-8a9ef07dd022@gmail.com> Date: Wed, 21 Sep 2016 10:06:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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:06:53 -0000 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... > 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. when >> 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 early to >> network stacks by dropping; BBR works on TCP and aims to prevent packet >> loss.