From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 D3FE83B29E for ; Wed, 3 May 2017 05:50:11 -0400 (EDT) Received: by mail-wm0-x22f.google.com with SMTP id u65so140386354wmu.1 for ; Wed, 03 May 2017 02:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=+5PfCwlQJvLvZRElV8EWpM5M2ihY1rp2z0KAjd70SuY=; b=lMcrONVRnZNmDQtTtHlFAVGguvyNPBAbDi5QTGfuF8ezpRsPWQUm/3hSuvsqF4c8Uo bPNRc+6uJu8ZFezGPa1xH5Mym1aVNnV2YScue3rfGGIrqB2N1dWdfYxrWcsGwbVqenEx fyi2fqmmbrG1pICaYKMYObbaMX5etcYnqNtsJXb2raNramXrS8Ecf12jzr+r/3WoXynK zL1VNhoYpy1M/oMrUFJcRo6ovRA/2BJ4oECYIqFnaDCXCjv1zOKSPtARnnwitw/5qJ1B PSJ5xZaUrfhMelYcIk6wdGpU4RyTIbJaXtwcm3B3c2pxZVRcjisoOftlvhq2tFpT2XC7 IEGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=+5PfCwlQJvLvZRElV8EWpM5M2ihY1rp2z0KAjd70SuY=; b=YnWI8uKiOdCYpoWfmB43+Dm6WSWewM4DKTb2573fPoo5gLLayzi7+5scWMA+zc2MuY Y3AC2Ermh/gCPIsy6ptBEtjfSCw0QHR6IUOJpIendB2UaP4XxpWlZpCNZq/GmZPUYRys F2pumkRylpfr3A1yuVQKuz3jSbJd4ZSOWeOm5kdpvJe76AOR336CxPwTFyZVrjcsKTlD 4PGu0tO048pQujSzDlhNBPvquHoHvrGMcv30R8vIAvgp8MdoKtv/MIAQ1Y0LI8eq3ZeR RApY7npivi4CFNypeUmXf2RJibImEOs7f2im/Yv5om/+ddLGGPkFv5fLxdhe+TocpAoA iL+w== X-Gm-Message-State: AN3rC/41X7gua4gHrUb2I7kM5Qnpn7zTWWtvVwD6QEq/L3GfJysjWysD DqaypRSfD61Fqw== X-Received: by 10.28.199.76 with SMTP id x73mr5890932wmf.95.1493805010839; Wed, 03 May 2017 02:50:10 -0700 (PDT) Received: from [192.168.0.3] (185.182.7.51.dyn.plus.net. [51.7.182.185]) by smtp.gmail.com with ESMTPSA id y126sm3311216wmg.29.2017.05.03.02.50.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 02:50:10 -0700 (PDT) From: Andy Furniss To: xnor , David Lang Cc: Cake@lists.bufferbloat.net References: <85386ca9-f0be-f60f-796a-e5aa3b8ee212@gmail.com> <5ca09d5c-e674-110a-72e4-b8fd434c7a5d@gmail.com> Message-ID: Date: Wed, 3 May 2017 10:50:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 SeaMonkey/2.51a2 MIME-Version: 1.0 In-Reply-To: <5ca09d5c-e674-110a-72e4-b8fd434c7a5d@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Cake] cake default target is too low for bbr? X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 09:50:12 -0000 Andy Furniss wrote: > Andy Furniss wrote: > >>> b) it reacts to increase in RTT. An experiment with 10 Mbps >>> bottleneck, 40 ms RTT and a typical 1000 packet buffer, increase >>> in RTT with BBR is ~3 ms while with cubic it is over 1000 ms. >> >> That is a nice aspect (though at 60mbit hfsc + 80ms bfifo I tested >> with 5 tcps it was IIRC 20ms vs 80 for cubic). I deliberately test >> using ifb on my PC because I want to pretend to be a router - IME >> (OK it was a while ago) testing on eth directly gives different >> results - like the locally generated tcp is backing off and giving >> different results. > > I retested this with 40ms latency (netem) with hfsc + 1000 pfifo on > ifb. So, as Jonathan pointed out to me in another thread bbr needs fq and it seems fq only wotks on root of a real eth, which means thay are invalid tests. I will soon (need to find a crossover cable!) be able to see using a third sender how cake varies shaping bbr in simulated ingress. I can test now how bbr fills buffers - some slightly strange results, one netperf ends up being "good" = buffer only a few ms. 5 netperfs started together are not so good but nothing like cubic. 5 netperfs started with a gap of a second or two are initially terrible, filling the buffer for about 30 seconds, then eventually falling back to lower occupancy. TODO - maybe this is a netperf artifact like bbr/fq thinks it is app limited. The worse thing about bbr + longer RTT I see so far is that its design seems to be to deliberately bork latency by 2x rtt during initial bandwidth probe. It does drain afterwards, but for something like dash generating a regular spike is not very game friendly and the spec "boasts" that unlike cubic a loss in the exponential phase is ignored, making ingress shaping somewhat less effective.