From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 5CAB43B29E; Fri, 26 Feb 2021 12:14:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1614359649; bh=awi8y7XIIH0yERG48VwNJaaDN1NzsWSWPRZgl+ftUxA=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=ReCTMxO/Z94jP9Cx/ATL+BL/QSS2mqXVNqEFKiTDRBPH4KfieFIJNLKisssYaLevz 1rsC6c4bo62hX98PKb698/5yaYjepBaCWFhGZnV9H6zBID/ux+/kndzGIKaEnV7rWu n7lvjaypvLrliVEcy7UnnxSpcOSp3XhVBZPHVoOk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.250.106] ([134.76.241.253]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MOiDd-1lS8bu05kd-00Q8Sp; Fri, 26 Feb 2021 18:14:09 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Sebastian Moeller In-Reply-To: <539a80fd-46d5-c373-a379-0c7b127714a2@kit.edu> Date: Fri, 26 Feb 2021 18:14:07 +0100 Cc: Nils Andreas Svee , =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , =?utf-8?Q?Dave_T=C3=A4ht?= , =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen_via_Cake?= , Make-Wifi-fast , bloat Content-Transfer-Encoding: quoted-printable Message-Id: 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> <539a80fd-46d5-c373-a379-0c7b127714a2@kit.edu> To: "Bless, Roland (TM)" X-Mailer: Apple Mail (2.3445.104.17) X-Provags-ID: V03:K1:93pJwFopfgnoCMJkjvVitcaY0+MK2U7ouRokgoHAL6lYRmeizVO 1159nMnus594w7Sc++XLwxmC8QUDReGwSems/lstoP/EQ9L9dGv/y84XCkzuc+g+viPErIY 3jt1fdRIzpd/BhYP3/3iMwH0hltHi9TaH6pb3xzuCC0zycXvTRTt2uOYr2L0K7Wgvycq3uC Regn/0CSL/rAtwJY+uO/g== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:jnipNeMcXLY=:oshXYvQhwfkR5fvP0HhvL+ 09NoC7vYb37wmzqMbmUdubbi19tXsQis0L4OL7/ci6Q1hSADOlwT2IYshxUu+kQvOvm8VtVsu GXkOZaOik852b9aQvM7kV4dMszxu0qnUNsHpT0yTNq9y8FzzeS6a8nn8P7ykgm0PCuBgyvKTd YPa2IlKQLZOqz1GjZJFJExR/GpQmb0hlgO1gYIx8/asldZdPgYXDy6diiM1OjGxKO7UxaRADf jFQLWlgnUeh6aCkw9bn1qhaiBL/yERKzvlDvcZUWpEvBL6KOreSzcsQ9jZvLWh3vneLAGYFbe xptOlR80v16tizD6Ay49r3VsowrggxiVGnTxl8Cn2GkPb5GD96WBJ9tXQsG76eCgX0TkFo+9V jY2xJo9tklaMXMtCSYiVfMcPjORPHc3eTsHF6G3vpTI0P528+xRRo39Pv/Gg4a9LS6gCUZNnD bAEABqy80UTpGxxgZPEgHx0QFU57QPsVp/YfAJ46REoO4P6H3cieqJha/KVYtFB2AmyIdmhUP 6Hl1GBErymuCbWn9s4P6HBAHVSbvtWUJwnMaILpwtWnKiQfKqVPcCG0N+Vu8TFQmFIuS52War zlWF+AnWFT7DC7WINQawqEOo5TVc9XQ2ZZ6oNhfJCbKzQXQ1N/BygcgSFk+AlyxUrQtxSzuta AFaP5V7ziq58pI541KOfczfj4U1YYv7cA5DtVE5V6nX+Va7Sz92RsIkolYkSjECLxhnWnqZz+ j3ERJdyNU/JRBSDlBo2l4TR6IQTUTshIaXhi359Y9a/KY+otkaCfRA/N10NRVFoQGgUgdK8gH yWjtZkvgfMbH330ylvdVEprE26rGsb6SD9JuUoidug4Unb6TL2V/fUeY5IksBjrUhytQP72S+ vGahwqz2hteObq7RwEaQ== Subject: Re: [Bloat] [Cake] Fwd: [Galene] Dave on bufferbloat and jitter at 8pm CET Tuesday 23 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: Fri, 26 Feb 2021 17:14:22 -0000 Hi Roland, are you sure that BBRv2 actually evaluates CE marks and responds to = them? As far as I understood, BBR is simply not rfc3168 compliant, there = was some talk about teaching BBRv2+ some still to be defined high = frequency (low amplitude) ECN signaling. The thing I fail to understand is, why BBR with its cavalier approach to = drops did not grow ECN support on day one. While a drop could have a lot = of reasons, including transient/stray wifi losses, a CE mark is less = ambiguous. Best Regards Sebastian > On Feb 26, 2021, at 17:59, Bless, Roland (TM) = wrote: >=20 > Hi, >=20 > On 26.02.21 at 16:27 Nils Andreas Svee wrote: >> On 2/26/21 12:47 PM, Toke H=C3=B8iland-J=C3=B8rgensen 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. >=20 > Regards, > Roland > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat