From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6664AC54FCE for ; Mon, 23 Mar 2020 19:04:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3AB0E2051A for ; Mon, 23 Mar 2020 19:04:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="YNued+Ik" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727664AbgCWTEH (ORCPT ); Mon, 23 Mar 2020 15:04:07 -0400 Received: from mail-vs1-f65.google.com ([209.85.217.65]:38725 "EHLO mail-vs1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727468AbgCWTEH (ORCPT ); Mon, 23 Mar 2020 15:04:07 -0400 Received: by mail-vs1-f65.google.com with SMTP id x206so9540451vsx.5 for ; Mon, 23 Mar 2020 12:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NDYOXFTMDWIdsCkfyyirGcOsGcwZtinXqJlRoDSoqTo=; b=YNued+IkDlOLvZGJuYI1titjTXU2zN02Oe5Xt+lLRBOnsagazRi+5torcb9UcgRvP+ Bhn8OKR5qSK0o3VYkPH3sKWwUKyp1dpOydpbkNbIxJaEw7ljU1wLBdHw+abLd0E6vTHc 1PC9n4iFll/L0aR+NNIAqglYSHxdFwo7P9DTLi6O+KviZsHw+vn5+BljoUl4d/eu09Az z9MYR+m1ckdq38eyaUOdSMc3X72vI2fsZt8XJtqV0htBG3MJpIbiNt9NOyi6ap0MeBw5 XHB1oEIM6kehU/ZSyUjAwjHoK1KmNgFT6bltH+O/fmSigAs18KPy9Z3h4NLh66g7nyBq mnlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NDYOXFTMDWIdsCkfyyirGcOsGcwZtinXqJlRoDSoqTo=; b=WeRYejLQb1U4nLuL+A/gR7RHxzFgQYmOzqV7EpFhifWAJNGKV+/saPn/lLj2xMpgjf OxQeCV8OXSNhhdYDUUCpvtqiK3VVxJtdRnbg2ofPkKumw1GqWkwIPY/Qnv6m36K5MsOn 37qbA/u1LFtkBsiapuhad0NqCWkFgZjPQHSjXkUhhaqEORrZ/upmw46a6OzFAJPPlZCE GmMjr/QQBODVzbSj1mfpBMEgmv8Ryw1LAIr3PgNSu0mCdkgeso8TC1TDVFe88gEFkTKl VAiTai0aSi9mEaM1CMxaECDfeZYRLoEW6w5bzlcNpDt+G4QoMTW2iQxoJA9yuyDqY3mj ZGyw== X-Gm-Message-State: ANhLgQ0rxlPHrV6+UouHgjVaf9ek/Fr1Nh8aRf9CrNgVRbSfnYGblcG5 eiZMfoBHfA9AzNJXBgq1RR4a1PayJ2HrBT8J38862Q== X-Google-Smtp-Source: ADFU+vtzYXgtcShoih79dwSCyf4uy/B4YvUs9zTgh3btpuUpChoUKIr6zYLUYEP7ynwvFy4m9Hk38dc0rzQ8GoScTPc= X-Received: by 2002:a67:cb07:: with SMTP id b7mr15906739vsl.104.1584990245584; Mon, 23 Mar 2020 12:04:05 -0700 (PDT) MIME-Version: 1.0 References: <1584524612-24470-1-git-send-email-ilpo.jarvinen@helsinki.fi> <1584524612-24470-29-git-send-email-ilpo.jarvinen@helsinki.fi> In-Reply-To: From: Yuchung Cheng Date: Mon, 23 Mar 2020 12:03:29 -0700 Message-ID: Subject: Re: [RFC PATCH 28/28] tcp: AccECN sysctl documentation To: =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= Cc: Dave Taht , Linux Kernel Network Developers , Neal Cardwell , Eric Dumazet , Olivier Tilmans Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Mar 23, 2020 at 6:34 AM Ilpo J=C3=A4rvinen wrote: > > On Fri, 20 Mar 2020, Yuchung Cheng wrote: > > > On Fri, Mar 20, 2020 at 3:40 PM Ilpo J=C3=A4rvinen > > wrote: > > > > > > On Thu, 19 Mar 2020, Dave Taht wrote: > > > > > > > On Wed, Mar 18, 2020 at 2:44 AM Ilpo J=C3=A4rvinen wrote: > > > > > > > > > > From: Ilpo J=C3=A4rvinen > > > > > > > > > > Signed-off-by: Ilpo J=C3=A4rvinen > > > > > --- > > > > > Documentation/networking/ip-sysctl.txt | 12 +++++++++--- > > > > > 1 file changed, 9 insertions(+), 3 deletions(-) > > > > > > > > > > diff --git a/Documentation/networking/ip-sysctl.txt b/Documentati= on/networking/ip-sysctl.txt > > > > > index 5f53faff4e25..ecca6e1d6bea 100644 > > > > > --- a/Documentation/networking/ip-sysctl.txt > > > > > +++ b/Documentation/networking/ip-sysctl.txt > > > > > @@ -301,15 +301,21 @@ tcp_ecn - INTEGER > > > > > 0 Disable ECN. Neither initiate nor accept ECN. > > > > > 1 Enable ECN when requested by incoming connectio= ns and > > > > > also request ECN on outgoing connection attempt= s. > > > > > - 2 Enable ECN when requested by incoming connectio= ns > > > > > + 2 Enable ECN or AccECN when requested by incoming= connections > > > > > but do not request ECN on outgoing connections. > > > > > > > > Changing existing user-behavior for this default seems to be overly > > > > optimistic. Useful for testing, but... > > > > > > I disagree. > > > > > > The kernel default on ECN is/has been "do nothing" like forever. Yet, > > > passively allowing ECN on servers is a low risk operation because not= hing > > > will change before client actively asks for it. However, it was obvio= us > > > that the servers didn't do that. The servers could have set tcp_ecn t= o 1 > > > (before 2 was there) which is low risk for _servers_ (unlike for clie= nts) > > > but only very very few did. I don't believe servers would now > > > intentionally pick 2 when they clearly didn't pick 1 earlier either. > > > > > > Adding 2 is/was an attempt to side-step the need for both ends to mak= e > > > conscious decision by setting the sysctl (which servers didn't want t= o > > > do). That is, 2 gives decision on what to do into the hands of the cl= ient > > > side which was the true intent of 2 (in case you don't know, I made t= hat > > > change). > > What can a server configure to process only RFC3168 ECN if it prefers t= o? > > That's why I suggested the flag-based approach? That's assuming an admin that has control of sysctls can also change individual applications (easily). In reality it often is not the case. The default sysctl choices in this patch seem risky to me. > > > > If "full control" is the way to go, I think it should be made using f= lags > > > instead, along these lines: > > > > > > 1: Enable RFC 3168 ECN in+out > > > 2: Enable RFC 3168 ECN in (default on) > > > 4: Enable Accurate ECN in (default on) > > > 8: Enable Accurate ECN in+out > > > > > > Note that I intentionally reversed the in and in/out order for 4&8 > > > (something that couldn't be done with 1&2 to preserve meaning of 1). > > It should address any except "out" but no "in" (the meaning of 1 cannot > be changed I think). But out w/o in doesn't sound very useful. > > -- > i.