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 4B74E3B2A4 for ; Thu, 4 May 2017 06:22:28 -0400 (EDT) Received: by mail-wm0-x22f.google.com with SMTP id u65so13678928wmu.1 for ; Thu, 04 May 2017 03:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=yKN7+OH43lwO808+IzmB9g8RqwqhFgryc32SJ5mbp18=; b=stcznXd+7gsN5SnDDVzYdcyL40WLBYjtyiwmnT6XKkBwsBPAq7+fa1uDDkob7fWnEN 7uY6NgXB9TbGiH8zAZNcIcuLUEyXR6BkeheUOUzrRGbMVBzwPuj2/yklSTKcr4cpAspl zL2U6zY3T8FrLa5GkJoAfGc1YqPV3j76mNtCum2/R4+PfqYZTpRFypYxIH2JjX7m6pdX AsIhOLc2m0kwv09xpowrQfuw8arItVZr/slFLuZYwruOmEcI+a0/5YfsJAN7TUwoH0AJ /kp48p8V65+FhHgW/LxqgBUb8L4F+Xk+mGoLy0Ou4ZhTq7X5wzLsF7SBFmit7uVJ0JcN lDYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=yKN7+OH43lwO808+IzmB9g8RqwqhFgryc32SJ5mbp18=; b=UMFUkBh5P4BhyTU5zKJkBLyP6fX84MsRMRMN6/cY+7JGk1KoQaNWSQdcd/44DX/k8E CKjCu2p2CAvy89L5eHFxSMUYCFiclXTPUd/WW9G/adHfJbPZwjzJfwZNqcct2ZGF+mk5 U6cePvFhNG3qXbZXkayGDB3VyMPiK4K6+TeF2ReEFSzOsl85qBasyYYQJyMWlBW1k99c nD9rTl/5N6eDMEZwL5JLV1PLhHrszC792vcii8W6gj3BBM3YHMUag3xNJUL893yL8ogJ dAJDIjEUEMjZ+hSlPXK3hR2YlMAHcj/lFbPIFG/i6BlkNH+38Ub83vggxc8CE5+VtnzK JdwA== X-Gm-Message-State: AN3rC/7b7zXkGWRfJYfVC3ma2bPG5zYPt9gDght0dkOE2Mxc1Dl8lnUE N/xkzV3AvpocgA== X-Received: by 10.28.125.195 with SMTP id y186mr1197625wmc.32.1493893346954; Thu, 04 May 2017 03:22:26 -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 p104sm2422026wrc.66.2017.05.04.03.22.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 May 2017 03:22:25 -0700 (PDT) To: Jim Gettys Cc: xnor , David Lang , Cake@lists.bufferbloat.net References: <85386ca9-f0be-f60f-796a-e5aa3b8ee212@gmail.com> <5ca09d5c-e674-110a-72e4-b8fd434c7a5d@gmail.com> From: Andy Furniss Message-ID: <5e76ed9f-7eae-f309-2d64-3ed34f19d3d4@gmail.com> Date: Thu, 4 May 2017 11:22:25 +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: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Thu, 04 May 2017 10:22:28 -0000 Jim Gettys wrote: > On Wed, May 3, 2017 at 5:50 AM, Andy Furniss > wrote: > >> 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. >> > > ​Specifically, BBR needs packet pacing to work properly: the > algorithm depends on the packets being properly paced. > > Today, fq is the only qdisc supporting pacing. > > The right answer would be to add packet pacing to cake/fq_codel > directly. Until that is done, we don't know how BBR will work in our > world. - Jim​ I guess you mean so cake could be used on egress of sender (in place of fq)? That's not really the test that I intend to do, which is more like - [boxA bbr+fq] -> [boxB simulate ISP buffer] -> [boxC cake ingress shape] a bit lower than "line" rate and see how much "ISP" buffer gets filled. Also compare bbr, cubic and netem different rtts etc. >> >> 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.