From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 B4B593B25E for ; Sat, 17 Sep 2016 17:33:47 -0400 (EDT) Received: by mail-qt0-x230.google.com with SMTP id 38so57603176qte.1 for ; Sat, 17 Sep 2016 14:33:47 -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=XArYfajgELA1UcYljfg0S6TcsUX70PrXzmfptsjiHy4=; b=BMOGWj1TwHcRM4KvVqRBHc3O+Sg9pdeOGtKsrZW/ajC+vY+7d5BCeLWH3MRo4iD3j1 ByDmG7Yum7jSUPVWE98Z9O4G/88BRCvJBNLkp1XXFL5L/+5E0ErX+Wgmez/DBsOwVudW a9YCLKZGYkkbOqDEYANcf4MoYfhUkLZid3MfvlJ++WwrYbwcTdiOCY/QUmkaE/BRcySV 5oqxkjg4L9o683+reH7wlm8DQ3LjAa59ysLAg/RO5sPWB5I0AmqjGWOYTGHWiAEcdkFn ZZAxcY5cokbZhz6OSE3IaOJ8yKOyvLCRdP7EPTqF/9/FILSRZsZox9sgjQIISoSuLr0G ns/w== 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=XArYfajgELA1UcYljfg0S6TcsUX70PrXzmfptsjiHy4=; b=PZDRB+Nt6BH0mynn81c6g/ZSje3RyZY5APbUMUJk6hlopBFBYXkKcH1mvTk4bsyCV+ BiA16pbiwGMRRPunAxubQ1PcfWnxMneJ00v+fN6PGXggmOn9Vt/EdjfVe0V5H3UoPMvf LVaujEaqvRjn8OpYYvDbT1s2U5F1ikFqyo2iQF85LdlSKSt/EX3u8MN7M2XRyPGM10Vx TCIsJ//voJ3bfXaVJBYfSSy+QvwEzODvZ34S0Zv1gCNcR3iD4hHRX91VzutalV4Whsjl Sy/rr8iLraCExTefkwt+rXYukSEXukMtRi+TwIYAWKd4kAew/vteB9qsfFFeoeIu4DmX w3Pw== X-Gm-Message-State: AE9vXwO+NVOgMuC5RAEWusZOktjTYOVHIL5EBKTir+i7uCmrU6/JSyxb1O7pJFYiAI8huJuddoFFCnUsKOJeuA== X-Received: by 10.237.34.122 with SMTP id o55mr23042349qtc.15.1474148027306; Sat, 17 Sep 2016 14:33:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.137.214 with HTTP; Sat, 17 Sep 2016 14:33:46 -0700 (PDT) In-Reply-To: <1474146692.035424358@mobile.rackspace.com> References: <1474146692.035424358@mobile.rackspace.com> From: Dave Taht Date: Sat, 17 Sep 2016 14:33:46 -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: Sat, 17 Sep 2016 21:33:47 -0000 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 lev= el 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 re= al 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 re= cover 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 delay 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 fil= e transfer and that file transfer throughput is the right basic perspective= , rather than end to end latency/jitter due to sharing, and fair sharing st= ability. 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.buffe= rbloat.net" > Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP inn= et-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 earl= y to network stacks by dropping; BBR works on TCP and aims to prevent packe= t 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 --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org