From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (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 8B1883B29D for ; Fri, 20 Mar 2020 22:46:24 -0400 (EDT) Received: by mail-io1-xd42.google.com with SMTP id v3so8288642iot.11 for ; Fri, 20 Mar 2020 19:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=CTUjyGq6D+YnIb7q9RfDZDoAHM4K2+7vplAZpC5yE2k=; b=soo0iMgyThSsL6K8w70igwWo7jOo1+4/uzelAxHSxmhi5AxcLyjnZcvGUpa5kQ/ZaG 1Ak9W85A1weQE1zDobKouK0RgVjrK5zya6Nezs6cyntFHRgc5cO61LQ2S1jMKJUC2Ft9 guK9w6H2WEvaCvk5045snVIvDKyjvKZUVBiCBIc0wkueccEJoprk/7CtqfY5qdpNPaug ZGPD559BrVh+JufdIq5HHk3jd94Fi0NWcNLvBNEEj45h5bHrxIR2ysUEQK9Y9+f9g5ar C7XwDLpzxECvfcoApAk2HzioTMFjEB4Fp+Jp5J1QLS6RIl/KLMQG9CfmFNy6n++Mzqvq AjpQ== 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:content-transfer-encoding; bh=CTUjyGq6D+YnIb7q9RfDZDoAHM4K2+7vplAZpC5yE2k=; b=F4uZthtnFwpDsZGmewbWXPFTdU6DgYWdfpNobmC8NL5UZRHu0Y0t0PmZINTFcwrL5T 1E9xiOaoMnPffWTiQ5ztAk/Gk6xM6wbTrn+V2YkIWVVpi9MYiHas67qlwEf1XtX5/dPC WKd18GdLiySW+AFmaCkQx5gmQDQSeyxwojCErpRHo0x/vLwdw7mwpgJFpxSu95wP+8cH 8Vhl7gknu477HVZimMM41xJOfPQUyW6CuEWrwM8MZSuLA9qa5fPL2ZWT7iFsryTHvs/g r88k21RNCRFY2j3c+2ZLfH0S9deNmqaEmtuQo0wbOO7Zw8GioWl7K8cNw5hAdADJwfTG mmug== X-Gm-Message-State: ANhLgQ3ngurRgiYp/TXMwZz2OEqU80fR4w4Fe4JREA5XPE3+TJyWeXuy XZLsxbpi34q7fCFroVUFJhAv3Q82CO3A/WuzL3kg8FeM X-Google-Smtp-Source: ADFU+vsXMxIDIo8skodEV5ohJRI1BHWaWJpGIeK2COZtDq5uxT/cS9kyN0gX8jc2TzUd3DmpjFRoWOVHTtEtd2oeXmk= X-Received: by 2002:a05:6602:d0:: with SMTP id z16mr10457026ioe.161.1584758783768; Fri, 20 Mar 2020 19:46:23 -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: Dave Taht Date: Fri, 20 Mar 2020 19:46:11 -0700 Message-ID: To: ECN-Sane Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Ecn-sane] Fwd: [RFC PATCH 28/28] tcp: AccECN sysctl documentation 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: Sat, 21 Mar 2020 02:46:24 -0000 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/Documentation/n= etworking/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 connections a= nd > > > also request ECN on outgoing connection attempts. > > > - 2 Enable ECN when requested by incoming connections > > > + 2 Enable ECN or AccECN when requested by incoming con= nections > > > 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. If you would like me to make a more specific objection, from what I read elsewhere in this patchset, an accecn enabled transaction can also arbitrar= ily > > The kernel default on ECN is/has been "do nothing" like forever. Yet, > passively allowing ECN on servers is a low risk operation because nothing > will change before client actively asks for it. However, it was obvious > that the servers didn't do that. The servers could have set tcp_ecn to 1 > (before 2 was there) which is low risk for _servers_ (unlike for clients) > 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 make > conscious decision by setting the sysctl (which servers didn't want to > do). That is, 2 gives decision on what to do into the hands of the client > side which was the true intent of 2 (in case you don't know, I made that > change). > > Allowing the client side to make the decision alone has proven successful > approach. We now have significant passive RFC3168 ECN server deployment. > It is wide-spread enough that Apple found it useful enough for their > client side, experimented with it and worked to fix the issues where they > discovered something in the network was incompatible with ECN. I don't > believe it would have happened without leaving the decision into the hand= s > of the clients. > > Similarly, passively allowing the client to decide to use AccECN is > low risk thing. ...As with RFC 3168 ECN, "do nothing" applies also for > Accurate ECN here unless the client asks for it. > > > > + 3 Enable AccECN when requested by incoming connection= s and > > > + also request AccECN on outgoing connection attempts= . > > > + 0x102 Enable AccECN in optionless mode for incoming conne= ctions. > > > + 0x103 Enable AccECN in optionless mode for incoming and o= utgoing > > > + connections. > > > > In terms of the logic bits here, it might make more sense > > > > 0: disable ecn > > 1: enable std ecn on in or out > > 2: enable std ecn when requested on in (the default) > > 3: essentially unused > > 4: enable accecn when requested on in > > 5: enable std ecn and accecn on in or out > > 6: enable accecn and ecn on in but not out > > If "full control" is the way to go, I think it should be made using flags > 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). > > I think it's a bit complicated though but if this is what most people > want, I can of course change it to flags. > > > Do we have any data on how often the tcp ns bit is a source of > > firewalling problems yet? > > > > 0x102 strikes me as a bit more magical than required > > To me it compares to some fast open cookie things that are similarly usin= g > higher order bits in flag like manner. > > > and I don't know > > what optionless means in this context. > > Do you mean that "optionless" is not a good word to use here? (I'm not > a native speaker but I can imagine it might sound like "futureless"?) > I meant that AccECN operates then w/o sending any AccECN option (rx side > still processes the options if the peer chooses to send them despite not > getting any back). > > Thanks. > > -- > i. -- Make Music, Not War Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729