From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 7EB743B260 for ; Mon, 19 Sep 2016 16:26:20 -0400 (EDT) Received: by mail-qk0-x22e.google.com with SMTP id n185so22140780qke.1 for ; Mon, 19 Sep 2016 13:26:20 -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=pCJ4nLX0QhDQ8Rf+h5K1C4fD+u8SM1n2G3M6nfYP4qk=; b=ZCFCi8HVrz65E9aJjHWFjoz8O0FvXXNqlM/SU2wX3PT8PU6l9brLy0K1GAQVHbSE7X z+Y4/qnf3k2Kkz5E8ujLEXA8rwuakFhhUnCUHhnXLLQ4WuzgTW016XzQGwIo5AIOls7f itcqnfzehg8eJqZ0uox1v3txQZ7fM+xJ74Ach8x0We1rjaYHJ9TKADd4wxX1EVP2gtXC EyncQcZ6Yx8Lq6Dc7TsT9iGpEJB9TkVPixWfQ1I94TJInXkY/I1G52F179A1wXZgubnD T3279KJfL7HG/IpZtj0hUcFQZWTEL/Zp3dxMVOuAEBWF1iVe0lG3B8906k5tUiwVma/A o6Sg== 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=pCJ4nLX0QhDQ8Rf+h5K1C4fD+u8SM1n2G3M6nfYP4qk=; b=YZFikFsLCj93EvrcZCPuoj0xFZwY8WUb6df7toI/z/YHZWNaQuLg+iJsYedu5ow2Qr bNFQNkBvZRR+iZiNEKYHBcKG8fjt1sNKYTixiyw1XqETHreJi2SCz2wKLvaAPYJzjgHz myNleSoWLyzBJVcosK0gzzATOVHg0DhuBJtsfH18e9fM07UVt92vEGeV18oKEOCXSqd9 7NzPsl9cQQq8M2pmpbXGRADAaoL54JGSHNWEq3h3QM2xpnP+JqJM1QGeIb7BlRsc7tYq CBQ7RHtFat3VW4/nEThrMP/1Csju7OVaJ+/IpjITjQ3SteBjZ6BBjEElHE3OqZn49PPW 62BQ== X-Gm-Message-State: AE9vXwOW2YU1naJuEogvVkjomqAYpaxWWU/Rxz/V+KyGgeLXvgg0sRGPXDKSgps+TGyT06kwdjkF5tk4wTTh7w== X-Received: by 10.233.237.11 with SMTP id c11mr31663984qkg.118.1474316780108; Mon, 19 Sep 2016 13:26:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.137.214 with HTTP; Mon, 19 Sep 2016 13:26:19 -0700 (PDT) In-Reply-To: References: <1474146692.035424358@mobile.rackspace.com> From: Dave Taht Date: Mon, 19 Sep 2016 13:26:19 -0700 Message-ID: To: David Reed Cc: Jonathan Morton , "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 innet-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: Mon, 19 Sep 2016 20:26:20 -0000 ok, I got BBR built with net-next + v2 of the BBR patch. If anyone wants .deb files for ubuntu, I can put them up somewhere. Some quick results: http://blog.cerowrt.org/post/bbrs_basic_beauty/ I haven't got around to testing cubic vs bbr in a drop tail environment, my take on matters is with fq (fq_codel) in place, bbr will work beautifully against cubic, and I just wanted to enjoy the good bits for a while before tearing apart the bad... and staying on fixing wifi. I had to go and rip out all the wifi patches to get here... as some code landed to the ath10k that looks to break everything there, so need to test that as a baseline first - and I wanted to see if sch_fq+bbr did anything to make the existing ath9k driver work any better. On Sat, Sep 17, 2016 at 2:33 PM, Dave Taht wrote: > On Sat, Sep 17, 2016 at 2:11 PM, wrote: >> The assumption that each flow on a path has a minimum, stable RTT fails= in wireless and multi path networks. > > Yep. But we're getting somewhere serious on having stabler RTTs for > wifi, and achieving airtime fairness. > > http://blog.cerowrt.org/flent/crypto_fq_bug/airtime_plot.png > >> >> >> >> However, it's worth remembering two things: buffering above a certain le= vel is never an improvement, > > which BBR recognizes by breaking things up into separate bandwidth and > RTT analysis phases. > >>and flows through any shared router come and go quite frequently on the r= eal Internet. > > Very much why I remain an advocate of fq on the routers is that your > congestion algorithm for your particular flow gets more independent of > the other flows, and ~0 latency and jitter for sparse flows is > meaningful. > >> Thus RTT on a single flow is not a reasonable measure of congestion. ECN= marking is far better and packet drops are required for bounding time to r= ecover after congestion failure. > > Aww, give the code a chance, it's only been public for a day! I > haven't even got it to compile yet! > > I think it is a *vast* improvement over cubic, and possibly the first del= ay > sensitive tcp that can compete effectively with it. I'm dying to test > it thoroughly, > but have a whole bunch other patches for wifi in my queue. > >> >> The authors suffer from typical naivete by thinking all flows are for fi= le transfer and that file transfer throughput is the right basic perspectiv= e, rather than end to end latency/jitter due to sharing, and fair sharing s= tability. > > While I agree *strongly* that lots of short flows is how the internet > mostly operates, (I used to cite a paper on this a lot) > > a huge number of bulk flows exist that has been messing up the short > flows. I think the number was something 70% of internet traffic has > become netflix-like. *anything* e2e that can reduce the negative > impact of the big fat flows on everything else is a win. > > >> >> >> >> -----Original Message----- >> From: "Jonathan Morton" >> Sent: Sat, Sep 17, 2016 at 4:11 pm >> To: "Maciej Soltysiak" >> Cc: "Maciej Soltysiak" , "cerowrt-devel@lists.buff= erbloat.net" >> Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP in= net-next >> >> >>> On 17 Sep, 2016, at 21:34, Maciej Soltysiak wrote: >>> >>> 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 pack= et loss. >> >> By dropping, *or* by ECN marking. The latter avoids packet loss. >> >> - Jonathan Morton >> >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> >> >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > > -- > Dave T=C3=A4ht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org