[Ecn-sane] Fwd: [RFC PATCH 28/28] tcp: AccECN sysctl documentation

[Dave Taht <dave.taht@gmail.com>]

On Fri, Mar 20, 2020 at 3:40 PM Ilpo Järvinen
<ilpo.jarvinen@cs.helsinki.fi> wrote:
>
> On Thu, 19 Mar 2020, Dave Taht wrote:
>
> > On Wed, Mar 18, 2020 at 2:44 AM Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> wrote:
> > >
> > > From: Ilpo Järvinen <ilpo.jarvinen@cs.helsinki.fi>
> > >
> > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@cs.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.

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 arbitrarily



>
> 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.



--
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729