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 1A1773CB37 for ; Tue, 28 Nov 2023 10:21:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1701184882; x=1701789682; i=moeller0@gmx.de; bh=NZFUSdnXc8I7GRtDuNPUqpXNkTNHp2qyW74zC7d6Fj4=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References: To; b=Hdxp1dJAuvcg3D+cHw+lPl1gg9zaF1jE0XlrbAq3/8B+GA7M59boCtyrTJRhNTB1 LVnBh/YjH0xvcHIBHir0sLXR/ta6cebk9wFTajEGtyVGrPwjQ8WdhBfEi8QGwFmte UpgwZ1KIPp/S4pr2LEUnW1LeUW/aBxpt6i43317zUHp3LjZ7a+AIbeP5pBzra/tKd K8GLiNH4pg/w7E59n6OWVjXoN4LsH2H4ZBLMxs+ItodKony6NCl9cp8sHh21Lz3Gp nS2JiYpdLB5eXqA29GwgRpbqJHtGLHuIAyFD3YbioJr5S+ce41WdUy3x9NCpf/GJw pjHSUcTsxUY7binOIw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MWih0-1qoKLJ3Xrs-00X3bd; Tue, 28 Nov 2023 16:21:21 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) From: Sebastian Moeller In-Reply-To: Date: Tue, 28 Nov 2023 16:21:21 +0100 Cc: ECN-Sane Content-Transfer-Encoding: quoted-printable Message-Id: <35C94031-C0B0-428B-822B-68AC0AB4A540@gmx.de> References: To: Pete Heist X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Provags-ID: V03:K1:yNVMsKytt2FOMnBbpsW/7LaBO17gYP+09xW/6WDm/Fb/X15qxz9 n986LaaiBYmjtx1B2ebjt0z3JmUziI7ou3O0kLgUhogRZyRxfD0J8wZGIhsKBi7UKs1NkIV j8eYvNmjLcEqbU86UA/240urQvUwCnJx/vbuYtAorKtgvuWc6JbBRmiPmV496MQSEz+r+5V XHX5tGh3PztDpzqe8Shwg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:58E7p8VyZdk=;RsJknGEv7REjFtmLEOK+czmvovn +Pn4eaW6P8QvxwvdbzWT+qc+KK5cIWjOGfGXvFn7GC1hLP3m5WOGjo7FSHZAdoxxubEfM2O2Q a6JEpn8TjKxgw/Ib20liVAOKnvgZ5v/szl/oyIfRV7E+pffO8o/j2QCqzzeTxid6sCRkdH2n3 btgLv8cCtqILSgPSdGq/epZpFfmw3vbt2vBOfz2v4nyeTN3ejnDWvr7cLuFrPq1zF5H5t+gB6 RiR3d9EyOOh/7rPvTDsl53G/7IKwRJCL6kLyamk8fdbnT6GwrGn4G/qxRudaD9XhsGhGtOvuH MxC4X0prST/aLSEdlpkGG0OHXcEVg6DGbeuVM/+5fufdiYWq3NPOToUSNBytEtOKYDbcyn72e GdCXbbUxLHZWPsizLzneg2ArxrFyTDE6hCYEA1mk9W9GkufxPR7FxLJgqsssejgAAnYvTP1RD /cdZ09CAoh+goLuuj5W1DAJfmIebb9yB31xO8IIZ3XGwRxnzdwgWnJGbliwIVazNhnK/QZhKU 8Gx7uoWhbX4q48TDhzpenUFQzdl9se0AuqBJBXYNMJ3J3+hwEia08QobUuyglUqeINaiN2Msl +ENcF0vbGxmyxz4zL+6RJVKlcBm9a0IS7o54HEuVSyEBf8ZpPr3ohi0NsXwEP/KbwD0WFfE7F mfvUeaS6NoxcXqProVXzpJvmTlDmL5FmY0G72krU5fbWPRLixYpbWsl6Qqw2sE1c7hALk5JcY XUcU32UKfRZPf/k33tb3KiCswOVI5va+vB25zXSoak7kQ26eJEdZBRFtoIw6XhFpuAjZuUgmW MnVlDKlLEFeGKco+tqlDPfvgQY0y/z1M7W0wIX6IiRj96xt0dYxwuTxMZGCU+N3uDt14jYOV9 sID+O241xuwGJIGTK/wQzf8gDovLmOx8Tl0Eukub/ysdD9H4h+r1UKc0QH9SP0faw+2OKv+dK pvzepYU4R57S9wu7muJLJGKyE3E= Subject: Re: [Ecn-sane] BBRv3 ecn_low per-route feature and the CE confusion X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2023 15:21:24 -0000 Hi Pete, > On Nov 28, 2023, at 13:57, Pete Heist via Ecn-sane = wrote: >=20 > Regarding the per-route ecn_low feature in BBRv3: > = https://github.com/google/bbr/blob/v3/README.md#introducing-the-ecn_low-pe= r-route-feature >=20 > When set, any incoming CE marks from an ecn_low flagged route will be > treated as an L4S/RFC9331 CE, while CE marks from routes without that > flag will be treated as a regular RFC3168 CE. I am probably blind, but looking at = https://github.com/google/bbr/blob/v3/net/ipv4/tcp_bbr.c I do not see this fall back to a rfc3168 compliant response, as far as I = read this this is DCTCP or nothing...=20 Or did you just mean that BBRv3 will treat CE just like BBRv1 and = silently ignore it? > Obviously this is > problematic, as the two CE marks mean very different things, and > outside of closed environments, there's no reliable way to know which > type of CE you're receiving. The consequences of confusing them range > from massive self-induced bloat, to driving competing traffic in the > same queue down to minimum cwnd. The solution here is to just punt, so > at least tests and demos can be made to work. The per-route feature looks like a desirable safety... as does = the default 5ms rtt "low-pass", where IIUC ECN will only be evaluated if = the RTT is below 5ms... > This isn't a problem with BBR. The problem is, we've started an > experiment [RFC9331] that redefines the meaning of CE in a way that's > incompatible with existing RFC3168 middleboxes. This feature in BBR is > just a reflection of that. CCA developers are now tasked with somehow > deciding which type of CE they're seeing. >=20 > Speaking of ecn "sane", does anyone else see this as not? :) and as a > problem that needs solving? Yes, however I assume this will solve it self, as is this usage = of CE is over-promising and under-delivering, so I do not see this = "winning the internet" in spite of the amount of thrust is put behind = it... Regards Sebastian >=20 > Pete >=20 > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane