From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 8CB3A3B2A0; Wed, 21 Sep 2016 07:19:38 -0400 (EDT) Received: by mail-qt0-x22f.google.com with SMTP id l91so20491946qte.3; Wed, 21 Sep 2016 04:19:38 -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=yr0IVxy/QxSP2YAOc4xoLngYhT68Fi/jx3d/DP+UZEo=; b=0JlSfiQpjXP5U01z6fa3XLCjbg2+A2ZmnWt+fxCcuopAzlpm/TEF+SxAEMbpPylMSz N969Ai3Owjg0uwS5olMh52p9qZ3WacPrvNDLiiu763SGpcDWXWuoP34MZwUoG/JHT6qf WZWcxUXrgiZ+KL9O3/jBiQE4BbSK/OVoaQBqTQ8PUnqW9vAuHUXc5SiYjYAfz34vDuid 5lKkYSAmt5oo8a1W7GtI7v+umShxGtYUl+lrM9XLSIoVcgDgmw9r8b+axh7MCQIL0UaY z5ThVqYRtmap8YIYu6ae502QY7EnTFSYwehjjEc9BCNCvsCxux+RixElY8ujQjOkSoRo 8lAg== 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=yr0IVxy/QxSP2YAOc4xoLngYhT68Fi/jx3d/DP+UZEo=; b=IrRb1kKsSOoF4rLqd0QJ5yuQGVEwf4IV9E1yDhA2x9p1FoAPkm+5+r0msRi3YulGR5 GwNf1MqDbjY82C5kQjxBjg/ws3xMY1V7GcWzFxGYScqGuW6vmUzzcR8t0e3PxivKe2Yv Wjjm/8E88i1x0D0ePZZiO0fmCXg+q7ptxvrGxKxrVdAt6nlIqTKz1n1VGmQqf025ubeH 1tF7BKLOu7IvGX+YVsLydOWqIWXjc3R0drPqg153sDFWOGq0BxqWVENaH/jKl/KZsUZf 6YvWwSk9dTUkvv2SCVUO4KOC+W0MjJLLksZhhszlxOeqlVNmxqHROPrj4Uwxh97QEyGn yZZg== X-Gm-Message-State: AE9vXwOAiFekKLLCnHNUv+rpnwUYGOE03+FnRh0Ea+uXATVSvaUk7569v0oteiE0EypBNCn/+v0mcsn7yrq8aA== X-Received: by 10.200.44.16 with SMTP id d16mr39771930qta.58.1474456778133; Wed, 21 Sep 2016 04:19:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.137.214 with HTTP; Wed, 21 Sep 2016 04:19:37 -0700 (PDT) In-Reply-To: References: <92a6ae25-530f-1837-addd-8a9ef07dd022@gmail.com> From: Dave Taht Date: Wed, 21 Sep 2016 04:19:37 -0700 Message-ID: To: Mikael Abrahamsson , bloat Cc: "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] [Cerowrt-devel] BBR congestion control algorithm for TCP in net-next 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: Wed, 21 Sep 2016 11:19:38 -0000 On Wed, Sep 21, 2016 at 3:15 AM, Mikael Abrahamsson wrot= e: > On Wed, 21 Sep 2016, Dave Taht wrote: > >> I dunno, I'm just reading tea leaves here! >> >> can't wait for the paper! > > > +1. > > I would like to understand how BBR interacts with a window-fully-open > classic TCP session and FIFO induced delay that is in steady-state before > the BBR session starts. I did a fairly comprehensive string of tests today, comparing it at 20Mbits, 48ms RTT, to cubic and competing with cubic, against a byte fifo of 256k, pie, cake, cake flowblind, and fq_codel. The flent datasets are now at: http://blog.cerowrt.org/flent/bbr-comprehensive.tgz You will need the latest flent from git to plot the new tcp_4up_squarewave test. That test starts 1 BBR flow, then 3 seconds later, cubic, 3 seconds after that, bbr again, 3 seconds after cubic again. It's 4am here, and we've also been busy with something else due today, but some observations: * respecting ecn appears unimplemented, so if you compare cubic with ecn against bbr not respecting it, bad things happen. I bug reported this to the bbr mailing list. To some extent cake's and pie's overload on ecn drop mechanism helps. fq_codel/cake with fq is fine, so long as there are no collisions. * It seriously outcompetes cubic, particularly on the single queue aqms. fq_codel is fine. I need to take apart the captures to see how well it is behaving in this case. My general hope was that with fq in place, anything that was delay based worked better as it was only competing against itself. * It does the right things against bfifo when multiple streams are present, but in the presence of reverse traffic, cubic starves. (the dataset for this is kind of wrong in that the legend of the "smackdown" chart claims BBR is on on the download, but it was unimplemented in that direction, I only had it running on the upload.) Did I mention fq* was fine? :) I'm going to bed. > So let's say I have 100ms of lightspeed-in-fiber RTT, and I am then runni= ng > a file transfer with some other TCP algorithm which is sitting there, win= dow > fully open, creating an additional 100ms of stupid-router-FIFO-buffering > delay. > > So new BBR TCP session comes along, sees 200ms of RTT, and starts sending= . I > guess the classic TCP algorithm still keeps its window fully open, and > doesn't care that RTT now increased to 210ms by the BBR flow packets. I see evidence of the classic latecomer advantage but it subsides in 10-20 = sec: http://blog.cerowrt.org/flent/bbr-comprehensive/latecomer_advantage.svg > > Now what? BBR flow sees increased latency, and backs off, right? So how m= uch > of the bandwidth will each flow get? How do these interact? Plot it in flent. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org