From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 363193B2A4 for ; Mon, 27 Nov 2023 19:12:58 -0500 (EST) Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-2851a2b30a2so3426023a91.3 for ; Mon, 27 Nov 2023 16:12:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701130377; x=1701735177; darn=lists.bufferbloat.net; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=D3IrpQ3n0PN2tcYhAI/nfuleGnD9rp9KWoUE/zw63Xg=; b=D0klTmVvHT2se2dsYE1yY9FxTi6qZ2n8JVzULIA7WPf0WSAOqjh5dCHRRv9+29vWvz iiRN1Tey7C4IHNS1wnaHTLKRdWfhBM2OXsxc7lmDyZiStF4lQW0r2dOSOVx6vIJQb0O5 kBd2aIwaba0cx9J7iM1stY7O62Q2ybUYnlpY50vuwmEMKeH4idGCyT4ozg5znEh+EYA7 zDDMfMiUFpcYgkvRDWIqL4DlIiNB0ywc8An3l5g44FGex91aPa2QGm9NLq5qYJXLjFNj LhxvCm7z+0XgDkWrJbLJ7I1/JCr3dg2MHNLXudG2Hg/nZ3Wz48b05khqElTBvD9YYzDq /m1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701130377; x=1701735177; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=D3IrpQ3n0PN2tcYhAI/nfuleGnD9rp9KWoUE/zw63Xg=; b=qzl63j7JrOBKCJOXluuN6mjcHRjZRLlt328N/5zIh1qJIuBSRcYg2AhxeG8r6Tvdo9 Spa8Pr25ppq+RZRuGL9WUEbjmKwmuoKYb4p2HAyHT/B4EEARbpV9Mdr3BPaEjEcW9cYq yN82fwX5m7EaiJ9Tj1ZmkSjJTr/wGShgPmFHP7BReGd5jtVyR3xru2Au4fblE1RfpOYf OiEkAdwgH4jZTZVFbZZJugzmbXzDHY7L5tlVt3V16Y4u9RKTmNgbGS0fHya+CbRj1jkz Zx+c33gPta70XfUkg9FukaiWYVEx+oM42BrYKz4gDvK4p6+kLmRp3wskL2F1Ts7OA4Tp ls2Q== X-Gm-Message-State: AOJu0Yx7SRB+hD4oBiCliDPA+5l7tCPUz0fJDFrsT0gWOpbjZHq5nhhB 0wahimObmPoVr09nZMst9MQsuPNeGZQ8G2BJKFDOyVXq X-Google-Smtp-Source: AGHT+IE0UyG+ozEQ7fR0LNatofcSjWrXjgnbo8uJgfHjRy+0No1/QIZdKOe1Fb1B4iOjOA+Xxl01sg5nwwGnFG+tCZU= X-Received: by 2002:a17:90b:17d0:b0:285:b3a8:40ac with SMTP id me16-20020a17090b17d000b00285b3a840acmr6758535pjb.19.1701130376624; Mon, 27 Nov 2023 16:12:56 -0800 (PST) MIME-Version: 1.0 References: <20180117015726.93632-1-ycheng@google.com> <20180119.143148.953873341015988293.davem@davemloft.net> In-Reply-To: <20180119.143148.953873341015988293.davem@davemloft.net> From: Dave Taht Date: Mon, 27 Nov 2023 19:12:42 -0500 Message-ID: To: ECN-Sane Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Ecn-sane] Fwd: [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 00:12:58 -0000 Was this ever resolved? ---------- 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: , , , From: Yuchung Cheng Date: Tue, 16 Jan 2018 17:57:26 -0800 > 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. > > 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. > > 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. > > Signed-off-by: Yuchung Cheng > Signed-off-by: Neal Cardwell > Acked-by: Yousuk Seung > Acked-by: Eric Dumazet Well, this is a bit disappointing. I'm having trouble justifying applying this. Why doesn't BBR react to ECN notifications? Is it because BBR's idea of congestion differs from the one ECN is likely indicating? 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. 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. 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. 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. Thanks. --=20 :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab Dave T=C3=A4ht CSO, LibreQos