[PATCH net-next] doc: make the description of how tcp_ecn works more explicit and clear

[PATCH net-next] doc: make the description of how tcp_ecn works more explicit and clear

[Rick Jones]

From: Rick Jones <rick.jones2@hp.com>

Make the description of how tcp_ecn works a bit more explicit and clear.


Signed-off-by: Rick Jones <rick.jones2@hp.com>

---

diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 98ac0d7..2992160 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -199,15 +199,16 @@ tcp_early_retrans - INTEGER
 	Default: 2
 
 tcp_ecn - INTEGER
-	Enable Explicit Congestion Notification (ECN) in TCP. ECN is only
-	used when both ends of the TCP flow support it. It is useful to
-	avoid losses due to congestion (when the bottleneck router supports
-	ECN).
+	Control use of Explicit Congestion Notification (ECN) by TCP.
+	ECN is used only when both ends of the TCP connection indicate
+	support for it.  This feature is useful in avoiding losses due
+	to congestion by allowing supporting routers to signal
+	congestion before having to drop packets.
 	Possible values are:
-		0 disable ECN
-		1 ECN enabled
-		2 Only server-side ECN enabled. If the other end does
-		  not support ECN, behavior is like with ECN disabled.
+		0 Disable ECN.  Neither initiate nor accept ECN.
+		1 Always request ECN on outgoing connection attempts.
+		2 Enable ECN when requested by incomming connections
+		  but do not request ECN on outgoing connections.
 	Default: 2
 
 tcp_fack - BOOLEAN

Re: [PATCH net-next] doc: make the description of how tcp_ecn works more explicit and clear

[David Miller]

From: raj@tardy.usa.hp.com (Rick Jones)
Date: Wed, 28 Nov 2012 11:53:10 -0800 (PST)

> From: Rick Jones <rick.jones2@hp.com>
> 
> Make the description of how tcp_ecn works a bit more explicit and clear.
> 
> Signed-off-by: Rick Jones <rick.jones2@hp.com>

Applied, thanks Rick.

I think we should change the default to one, to be honest.  I thought
that's what we were doing by now...

'2' made sense 10 years ago, but it doesn't really today.

Re: [PATCH net-next] doc: make the description of how tcp_ecn works more explicit and clear

[Eric Dumazet]

On Thu, 2012-11-29 at 13:16 -0500, David Miller wrote:
> From: raj@tardy.usa.hp.com (Rick Jones)
> Date: Wed, 28 Nov 2012 11:53:10 -0800 (PST)
> 
> > From: Rick Jones <rick.jones2@hp.com>
> > 
> > Make the description of how tcp_ecn works a bit more explicit and clear.
> > 
> > Signed-off-by: Rick Jones <rick.jones2@hp.com>
> 
> Applied, thanks Rick.
> 
> I think we should change the default to one, to be honest.  I thought
> that's what we were doing by now...
> 
> '2' made sense 10 years ago, but it doesn't really today.

With 1 setting, I for example was enable to connect to a HP device,
when I was still working for SFR.

(It was an HTTP/HTTPS based administrative software, to manage HP c7000
enclosures)

I would suggest making a large scale experiment before doing this 2->1
move.

Re: [PATCH net-next] doc: make the description of how tcp_ecn works more explicit and clear

[Rick Jones]

On 11/29/2012 10:42 AM, Eric Dumazet wrote:
> On Thu, 2012-11-29 at 13:16 -0500, David Miller wrote:
>> From: raj@tardy.usa.hp.com (Rick Jones)
>> Date: Wed, 28 Nov 2012 11:53:10 -0800 (PST)
>>
>>> From: Rick Jones <rick.jones2@hp.com>
>>>
>>> Make the description of how tcp_ecn works a bit more explicit and clear.
>>>
>>> Signed-off-by: Rick Jones <rick.jones2@hp.com>
>>
>> Applied, thanks Rick.

Am I correct in assuming that the documentation is supposed to word-wrap 
somewhere around 72 columns?  If so, as I have time for floor sweeping I 
can try to go through more of it.

>> I think we should change the default to one, to be honest.  I thought
>> that's what we were doing by now...

You weren't the only one - what triggered my looking at that description 
in the first place was an assertion in the tcpm mailing list that Linux 
defaulted to ecn enabled.

>> '2' made sense 10 years ago, but it doesn't really today.
>
> With 1 setting, I for example was enable to connect to a HP device,
> when I was still working for SFR.
>
> (It was an HTTP/HTTPS based administrative software, to manage HP c7000
> enclosures)

If you have some of the particulars, feel free to send them to me 
offline.  Being one of the cobbler's children I cannot make promises but 
I can try to see if whatever it was has evolved since then.

> I would suggest making a large scale experiment before doing this 2->1
> move.

Perhaps one or more of the "development oriented" (term?) distros can 
ship with a sysctl.conf file that sets it to one?  Or some companies 
with rather large Internet presence.

At the time of the tcpm message I went ahead and set it to one on 
netperf.org but that is far from a large scale experiment.  It has been 
a couple weeks and I've captured almost 250000 SYN segments (netperf.org 
isn't all that busy).  My recollection is that at least one search 
engine provider's bots were negotiating ECN and one noteable one was 
not.  I'd think a search engine provider's crawlers would be a large 
scale experiment.

rick jones