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 8D9753B29E; Fri, 26 Feb 2021 12:50:41 -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 1lFhGB-0005qg-LE; Fri, 26 Feb 2021 18:50:39 +0100 Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 57798420299; Fri, 26 Feb 2021 18:50:39 +0100 (CET) To: Sebastian Moeller Cc: Nils Andreas Svee , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hy?= =?UTF-8?Q?gensen?= , =?UTF-8?Q?Dave_T=c3=a4ht?= , =?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> <539a80fd-46d5-c373-a379-0c7b127714a2@kit.edu> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) Message-ID: <913fe453-2644-558f-dc5e-585589555d91@kit.edu> Date: Fri, 26 Feb 2021 18:50:39 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Checksum: v3zoCAcc32ckk X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1614361839.715104261 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:50:41 -0000 Hi Sebastian, On 26.02.21 at 18:14 Sebastian Moeller wrote: > are you sure that BBRv2 actually evaluates CE marks and responds to the= m? 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. AFAIK, BBRv2 reacts not in an RFC3168 compliant (classic) manner, but=20 more in a DCTCP style manner. > The thing I fail to understand is, why BBR with its cavalier approach t= o drops did not grow ECN support on day one. While a drop could have a lo= t of reasons, including transient/stray wifi losses, a CE mark is less am= biguous. Yes, it is. But as I understand the motivation for BBR's design, they do not want to sacrifice throughput in case of non-congestion losses= =2E If you read the original BBR paper, one of its motivations was its use=20 in B4, where Google operates shallow-buffered switches. Because of their small=20 buffer size, they will cause occasional packet losses due to occurring short-term=20 traffic aggregation effects, which are different from persistent congestion. A traditional RED-based AQM may also generate CE marks in this case and the "strong" backoff may cost too much utilization in the end (esp. if you consider 100+Gbit/s links), so the DCTCP style is much more scalable in this respect. Regards, =C2=A0Roland >> On Feb 26, 2021, at 17:59, Bless, Roland (TM) w= rote: >> >> Hi, >> >> 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 t= he >>>> 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 worki= ng >>>> 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 thou= gh :) >>> I'll have a look at how BBR does it, and see if I can't figure out ho= w 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 >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat