From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 CFA2E3B2A3 for ; Fri, 28 Apr 2017 18:26:03 -0400 (EDT) Received: by mail-wm0-x235.google.com with SMTP id r190so58605548wme.1 for ; Fri, 28 Apr 2017 15:26:03 -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=pMPJ7DBoXQ8YAF6l2pgLmzbw/cA0/PDmqG0QFNUyJEU=; b=a6zW+jWriYhca41cFdUuZJGbkvT3z1Ur7SOHRIUagbU5Zfn+8KN6b/ZUlPfjYm1aQc E7lWpTimK7rZ5XKZhSzifdRtnf+t1PajyMKYUutXVggNq/Xsa8yLeB0Ofd/zow07agux EyGNWx3UGgPVNnykFSYAxtndUX2swRt0IjyBnEUoE06UebSstIP87mWA0CjjsCtfaFgo 7ewpVZm1gZPJN5pWEE9IdOvOc6QwPIAvKaGTNZbF+Apf8G0KBTavdsoDjgawzJ2R20U1 eK4vOySv9XRxMcZ0CkRkamwvCw97+l1WGpYzzoXqtA0Gv/sQy0Zc8BDgo59AH5dDqjZD 1Byw== 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=pMPJ7DBoXQ8YAF6l2pgLmzbw/cA0/PDmqG0QFNUyJEU=; b=l0lgPFd7k5h5NpPbSFi2fHRbhIt1lKvYjxoMKNZZFZozaPYbWGGYpeRUoAt79rXCtt swtnxkNHekiXCGiWCdd+3diuQ4CPG6+BO6pY0idQbaeUHKSZb7YogPix3mejBWzWB04W 9BwlbaC2G9IiuqolIRsUSfpfV6ZEMZHJCtutCqT8c8prRcPo1Yeiqm98eGNoBf8FtoGR bJezGjHShsz57gsb0q1c9hnFgmfZ+fyYrLRWLprxyu0nrmR4J6w2dMtYr/rbD+P69dw9 iyQgwOyraJqPaSrWsWxTFVedc0oPcWFKxglCvlnj8ij421UfWnr7ycqtGHOoVe3xcoUy FC5w== X-Gm-Message-State: AN3rC/4Ld5O2PRiMN/S8NssY3v8H90EjNU86CI7vx6Cm/NHag0kx9K78 Z7umRBIYAK9DnA== X-Received: by 10.28.27.134 with SMTP id b128mr222520wmb.67.1493418362873; Fri, 28 Apr 2017 15:26:02 -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 75sm3203704wmp.2.2017.04.28.15.26.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 15:26:02 -0700 (PDT) To: xnor , David Lang Cc: Cake@lists.bufferbloat.net References: From: Andy Furniss Message-ID: <85386ca9-f0be-f60f-796a-e5aa3b8ee212@gmail.com> Date: Fri, 28 Apr 2017 23:26:01 +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: 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: Fri, 28 Apr 2017 22:26:04 -0000 xnor wrote: > >> On Fri, 28 Apr 2017, xnor wrote: >> >>> As I understand it, increase in RTT due to queueing of packets is >>> the main feedback mechanism for BBR. So dropping packets, which I >>> already consider harmful, is really harmful with BBR because >>> you're not telling the sender to slow down. >> >> If BBR does not slow down when packets are dropped, it's too >> hostile to use on a public network. The only way for a public >> network to respond to a flood of traffic higher than what it can >> handle is to drop packets (with a possible warning via ECN shortly >> before packets get dropped). If BBR doesn't slow down, it's just >> going to be wasting bandwidth. > No it isn't. Packet loss does not equal conguestion - it never did. > Dropping packets to signal congestion is an ugly hack for > implementations that are too dumb to understand any proper congestion > control mechanism. Hmm, I bet a lot of carrier links are policed rather than smart queue. It also seems (OK one quick possibly flawed test), that bbr ignores ECN as well as drops in the sense that marked is just as high as dropped. > Dropping due to queues being full normally doesn't happen before the > RTT has significantly increased. Not so good on ingress though - where normaly (ie. non bbr) a drop is handy to signal early to back off - letting a buffer fill up too much is also somewhat going to fill the remote buffer that you would like to keep empty. > > BBR fixes both of these problems: a) it ignores packet loss on > unreliable links and therefore achieves much higher throughput than > conventional congestion control algorithms (that wrongly assume > congestion on packet loss) An experiment with 10 Gbps bottleneck, 100 > ms RTT and 1% packet loss (as described in the net-next commit) > showed ~3000x higher throughput with BBR compared to cubic. So on a congested policed link it will make matters worse for "normal" tcp users - maybe everyone will need to use it soon. > 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.