| Message ID | 1584524612-24470-29-git-send-email-ilpo.jarvinen@helsinki.fi |
|---|---|
| State | RFC |
| Delegated to: | David Miller |
| Headers | show |
| Series | : Accurate ECN for TCP | expand |
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... > + 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 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 and I don't know what optionless means in this context. > Default: 2 > > tcp_ecn_fallback - BOOLEAN > If the kernel detects that ECN connection misbehaves, enable fall > back to non-ECN. Currently, this knob implements the fallback > - from RFC3168, section 6.1.1.1., but we reserve that in future, > - additional detection mechanisms could be implemented under this > + from RFC3168, section 6.1.1.1., as well as the ECT codepoint mangling > + detection during the Accurate ECN handshake, but we reserve that in > + future, additional detection mechanisms could be implemented under this > knob. The value is not used, if tcp_ecn or per route (or congestion > control) ECN settings are disabled. > Default: 1 (fallback enabled) > -- > 2.20.1 >
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. 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.
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. > > 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). What can a server configure to process only RFC3168 ECN if it prefers to? > > 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.
On Fri, 20 Mar 2020, Yuchung Cheng wrote: > 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. > > > > 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). > What can a server configure to process only RFC3168 ECN if it prefers to? That's why I suggested the flag-based approach? > > 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). 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.
On Mon, Mar 23, 2020 at 6:34 AM Ilpo Järvinen <ilpo.jarvinen@cs.helsinki.fi> wrote: > > On Fri, 20 Mar 2020, Yuchung Cheng wrote: > > > 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. > > > > > > 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). > > What can a server configure to process only RFC3168 ECN if it prefers to? > > 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 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). > > 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.
On Mon, 23 Mar 2020, Yuchung Cheng wrote: > On Mon, Mar 23, 2020 at 6:34 AM Ilpo Järvinen > <ilpo.jarvinen@cs.helsinki.fi> wrote: > > > > On Fri, 20 Mar 2020, Yuchung Cheng wrote: > > > > > 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. > > > > > > > > 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). > > > What can a server configure to process only RFC3168 ECN if it prefers to? > > > > 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 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). > > > > 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. So you mean you'd want to have control that is finer-grained than what the sysctls offer?
On Tue, Mar 24, 2020 at 5:50 AM Ilpo Järvinen <ilpo.jarvinen@cs.helsinki.fi> wrote: > > On Mon, 23 Mar 2020, Yuchung Cheng wrote: > > > On Mon, Mar 23, 2020 at 6:34 AM Ilpo Järvinen > > <ilpo.jarvinen@cs.helsinki.fi> wrote: > > > > > > On Fri, 20 Mar 2020, Yuchung Cheng wrote: > > > > > > > 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. > > > > > > > > > > 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). > > > > What can a server configure to process only RFC3168 ECN if it prefers to? > > > > > > 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 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). > > > > > > 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. > > So you mean you'd want to have control that is finer-grained than what the > sysctls offer? I recommend having separate sysctl values for AccECN so that servers configured to use existing values do not behave differently (on ECN) after kernel upgrade, similar to what Dave Taht suggested. > > > -- > i.
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. + 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. Default: 2 tcp_ecn_fallback - BOOLEAN If the kernel detects that ECN connection misbehaves, enable fall back to non-ECN. Currently, this knob implements the fallback - from RFC3168, section 6.1.1.1., but we reserve that in future, - additional detection mechanisms could be implemented under this + from RFC3168, section 6.1.1.1., as well as the ECT codepoint mangling + detection during the Accurate ECN handshake, but we reserve that in + future, additional detection mechanisms could be implemented under this knob. The value is not used, if tcp_ecn or per route (or congestion control) ECN settings are disabled. Default: 1 (fallback enabled)