From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 7FD5A3B2A4 for ; Tue, 28 Nov 2023 04:14:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1701162852; x=1701767652; i=moeller0@gmx.de; bh=oBkQURTabWoesz2Vtl/oGi3NTeGf4H4RMqhkJKccRKs=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References: To; b=ncXdYbWGsJqUR+UGHQFNxI1T56dwLjWeop+mEkJwwxSkZWglqCJLDOmgNhZrRRxS NWcdnF3oF9NNt4w0lUBBZedjr5YkW33tQvtRax5LxAyrN4kx+itX4kX54wYfnO4q6 nDvRQEUIbYu0XhqE7gmJau5uYkJtT5YnwBKw/ckhfByBYhgLoUBgLKdWKlqI831Yc uSmpw2ubsfECAtIja4p/6I+2sHLRz9JZ3h9iLN7gLyGXGP82qMQVDrIdIAbL9mmUR fHd2A3u2UQY7zoga7+ciF8i23tPDNXSzf8cUot7oHmzNcyWMTqtEtKn5lb6LH0JqV wvn/0KUOpFE0q/tUlg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mw9UK-1rOKae1e8y-00s2QO; Tue, 28 Nov 2023 10:14:12 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) From: Sebastian Moeller In-Reply-To: <158a2dcff6c508998dbda044b4505146d0916dbb.camel@heistp.net> Date: Tue, 28 Nov 2023 10:14:11 +0100 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , ECN-Sane Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180117015726.93632-1-ycheng@google.com> <20180119.143148.953873341015988293.davem@davemloft.net> <158a2dcff6c508998dbda044b4505146d0916dbb.camel@heistp.net> To: Pete Heist X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Provags-ID: V03:K1:xRj/2KBofuKMnk3ER0W0tTE68hhK3bLSpM7LNVp+kxqw+0Qrb2V egCf+RvDmKQ6J6GC3rIMs7pJo1eCf0cYgRNW+d4iKRv4A3LiK3FOlQ0X69qJhkFp9ZACP93 4ePYhaomyok17Y124D48cZ0PBCLSaTN2vAbFae8RtVTdKD66chD+K5JrmqWu2GGKHJjy89V a8WCjsCimdBtLFUxRhfrg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:yA6R70VS0Ac=;2EaCNdIR/mrrCJS0PvlzgVZs5/0 rdUKxLnKvAK+X8tANHqh3x0TTvU/k+SzxuWNoXr+x9x8Cl2z0r48DRW7Moo4UbTDStJhs2Bf4 l29Jb864qqJDUXKJxaucNTmXfOOqBzgzY0Yh0jutZXIAUZw5h/zfU+OwZAEFX35qeY0xDpmNc +WBv8NP9hT5t7dpaZglknzmnzbfFxpisGR5Jjw8DYN046W0uv+yfft7BW7S945sJJskQMB8fZ c9LietETwLjBy9bnxAGJ9/7n1D4pxmG9jJhiiPKg9dYthJaNNXlNWt0nCZQv2Kz8ZB8XftNSr SOOJmKqO6lfqKTxXL1ByLT4EhqmaAG5GD8cVhrbNGwj2sirX72HsSbhqEybX4bUYLHz/IdfnN 4tyE0adKcrmxigEPOTS0l/ma0J7Si+n3GsINYiKugl+IEYCTeKTI+Zg2spAEHnPGHHlgzRkp1 +luUBeK5HToKAF6zd64XgK+Hznt+bNKQhaYlDXeE9Ue877rNV7JsJLySdMXnfe9lohiGsQjos iT2lwRHibgp4siNZs6W5t9oZzETKQVhfaCN/+fbq72uTTTPVx3AZXcgdA5LtbVdz6DzxpdzEF 1+Ec4XXBbnk8MZUTSB1gKEwuLStQmN5ygj3Ro9oOr9vHi8RMvD7/C+I1zle8AjBrNTHbg4gm+ tmg4FCp25DieAw4MDhH+RTRSjq7yQ/dgFXtHFRnsoYzVpCjHVoK/9H3ItTbnGUd+TYBSJ8fex Q31uPFm3lYOEVqvyLdqLE0C7F71Itw7vZME+Gzm9YZQwb8zpsMcRvCU5hzTLyN8xPtCvDJGTS f5QyYC5M0uZlv5+bN5sNGkXdrpuOoQbHOcKz0oRf2Uyx4/caExB9NdF+goCvhtAQEF+H8iEJs F0w2xW+Xev2NWt6ZxOBZHCIk62iDGg62kNuQGhC+hFnjPLe6WGtBBwCIMO9AlAyTR2wck8Ije MsP20GHah5Zy3Nu+xdZn66ZwnW0= Subject: Re: [Ecn-sane] [PATCH net-next] tcp: avoid negotitating ECN for BBR 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 09:14:15 -0000 Hi Pete, > On Nov 28, 2023, at 09:43, Pete Heist via Ecn-sane = wrote: >=20 > It doesn't look like the patch to set TCP_CONG_DONT_USE_ECN in BBRv1 > was ever applied, but it also doesn't look like v1 was ever modified = to > react to CE, whereas BBRv3 appears to: >=20 > https://github.com/google/bbr/blob/v3/README.md#enabling-ecn-support >=20 > I'll post something about ecn_low separately. The way I read this is that BBR still does ignore rfc3168 ECN, = but allows to use DCTCP style ECN on a route by route base... this at = least seems to acknowledge that currently no randomly selected path is = likely to support DCTCP style ECN... this seems far more cautious than I = had feared. I still think that BBR did itself a disservice to ignore = rfc3168 style ECN, but that is water down the bridge... Regards Sebastian >=20 > Pete >=20 > On Mon, 2023-11-27 at 19:12 -0500, Dave Taht via Ecn-sane wrote: >> Was this ever resolved? >>=20 >> ---------- Forwarded message --------- >> From: David Miller >> Date: Fri, Jan 19, 2018 at 2:33=E2=80=AFPM >> Subject: Re: [PATCH net-next] tcp: avoid negotitating ECN for BBR >> To: >> Cc: , , >> , >>=20 >>=20 >> From: Yuchung Cheng >> Date: Tue, 16 Jan 2018 17:57:26 -0800 >>=20 >>> This patch keeps BBR from negotiating ECN if sysctl ECN is >>> set. Prior to this patch, BBR negotiates ECN if enabled, sends >>> CWR upon receiving ECE ACKs but does not react to them. This can >>> cause confusion from the protocol perspective. Therefore this >>> patch prevents the connection from negotiating ECN if BBR is the >>> congestion control during the handshake. >>>=20 >>> Note that after the handshake, the user can still switch to a >>> different congestion control that supports or even requires ECN >>> (e.g. DCTCP). In that case, the connection can not re-negotiate >>> ECN and has to go with the ECN-free mode in that congestion >>> control. >>>=20 >>> There are other cases BBR would still respond to ECE ACKs with CWR >>> but does not react to it like the behavior before this patch. >>> First, >>> when the user switches to BBR congestion control but the connection >>> has already negotiated ECN before. Second, the system has >>> configured >>> the ip route and/or uses eBPF to enable ECN on the connection that >>> uses BBR congestion control. >>>=20 >>> Signed-off-by: Yuchung Cheng >>> Signed-off-by: Neal Cardwell >>> Acked-by: Yousuk Seung >>> Acked-by: Eric Dumazet >>=20 >> Well, this is a bit disappointing. I'm having trouble justifying >> applying this. >>=20 >> Why doesn't BBR react to ECN notifications? Is it because BBR's >> idea of congestion differs from the one ECN is likely indicating? >>=20 >> This is really unfortunate, because if BBR does become quite >> prominent >> (that's what you want right? :-) then what little success there has >> been deploying working ECN will be for almost nothing, and there >> will be little incentive for further ECN deployment. >>=20 >> And the weird behavior you list in your last paragraph, about how if >> the user switches to BBR then ECN will be active, is just a red flag >> that shows perhaps this is a bad idea overall. >>=20 >> ECN behavior should not be so tightly bound to the congestion control >> algorithm like this, it's a connection property independant of >> congestion control algorithm. >>=20 >> I'm not applying this for now, sorry. Maybe if you significantly >> enhance the commit message and try to do something sane with the >> algorithm switching case it is work a respin. >>=20 >> Thanks. >>=20 >>=20 >=20 > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane