Date:   Sat, 21 Mar 2020 00:40:12 +0200 (EET)
From:   "Ilpo Järvinen" <ilpo.jarvinen@...helsinki.fi>
To:     Dave Taht <dave.taht@...il.com>
cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Yuchung Cheng <ycheng@...gle.com>,
        Neal Cardwell <ncardwell@...gle.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Olivier Tilmans <olivier.tilmans@...ia-bell-labs.com>
Subject: Re: [RFC PATCH 28/28] tcp: AccECN sysctl documentation

On Thu, 19 Mar 2020, Dave Taht wrote:

> On Wed, Mar 18, 2020 at 2:44 AM Ilpo Järvinen <ilpo.jarvinen@...sinki.fi> wrote:
> >
> > From: Ilpo Järvinen <ilpo.jarvinen@...helsinki.fi>
> >
> > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@...helsinki.fi>
> > ---
> >  Documentation/networking/ip-sysctl.txt | 12 +++++++++---
> >  1 file changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/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 connections and
> >                   also request ECN on outgoing connection attempts.
> > -               2 Enable ECN when requested by incoming connections
> > +               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 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 hands 
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 connections and
> > +                 also request AccECN on outgoing connection attempts.
> > +           0x102 Enable AccECN in optionless mode for incoming connections.
> > +           0x103 Enable AccECN in optionless mode for incoming and outgoing
> > +                 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 using 
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.

Powered by blists - more mailing lists