From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [IPv6:2a00:1398:2::10:81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3CC783B29E; Fri, 26 Feb 2021 11:59:25 -0500 (EST) Received: from [2a00:1398:2:4006:f46f:aa70:3331:cc14] (helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 25 iface 2a00:1398:2::10:8 id 1lFgSX-0000yw-T8; Fri, 26 Feb 2021 17:59:21 +0100 Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 7E383420299; Fri, 26 Feb 2021 17:59:21 +0100 (CET) To: Nils Andreas Svee , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hy?= =?UTF-8?Q?gensen?= , Dave Taht Cc: =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen_via_Cake?= , Make-Wifi-fast , bloat References: <874ki24ref.wl-jch@irif.fr> <1e41ddf7-cd08-4fec-b31a-3021f8111dc6@www.fastmail.com> <87im6h4u2p.fsf@toke.dk> <369A70AB-3ADF-4211-8A09-E9FB77CEE59D@toke.dk> <90a13934-4ec7-4872-bbf8-c6c0f6304ce3@www.fastmail.com> <87wnuw1luc.fsf@toke.dk> <86692246-90d3-4b5b-bcb3-5a67a29d67f7@lochnair.net> <87mtvryrsi.fsf@toke.dk> <7513975f-9fba-f036-2037-f901e6c29af1@lochnair.net> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) Message-ID: <539a80fd-46d5-c373-a379-0c7b127714a2@kit.edu> Date: Fri, 26 Feb 2021 17:59:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <7513975f-9fba-f036-2037-f901e6c29af1@lochnair.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Checksum: v3zoCAcc32ckk X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1614358761.949523115 X-Mailman-Approved-At: Fri, 26 Feb 2021 16:08:59 -0500 Subject: Re: [Make-wifi-fast] [Bloat] [Cake] Fwd: [Galene] Dave on bufferbloat and jitter at 8pm CET Tuesday 23 X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2021 16:59:25 -0000 Hi, On 26.02.21 at 16:27 Nils Andreas Svee wrote: > On 2/26/21 12:47 PM, Toke Høiland-Jørgensen wrote: > >> Yeah, there would have to be some kind of probing to discover when the >> bandwidth goes up (maybe something like what BBR does?). Working out the >> details of this is still in the future, this is all just loose plans >> that I'll try to get back to once we have the measurement tool working >> reasonably well. Input and experiments welcome, of course! > > I've kept to maintaining CAKE binaries for the EdgeRouters, so I have a > lot to read up on if I'm gonna take a stab at this, should be fun though :) > > I'll have a look at how BBR does it, and see if I can't figure out how > that works at least. BBR increases its sending rate and looks whether the delivery rate increases. It assumes that the bottleneck limit hasn't been reached in case the delivery rate still increases. This is certainly true when it is the only flow at the bottleneck, but not true when multiple flows are present (the probing flow may simply steal other flows' shares adn thus get a higher delivery rate nevertheless). BBRv2 at least checks for packet loss and ECN signals and detects when it hits a hard limit. One could try to detect a correlated increase in RTT when probing for more bandwidth and then stop, because it seems that the queue is filled by the increased probing rate. However, getting that reliably detected out of the RTT measurement noise is sometimes difficult. Regards, Roland