[PATCH] document ECN in 2.4 Configure.help

[PATCH] document ECN in 2.4 Configure.help

[Barry K. Nathan]

As the dates below show, I've actually been sitting on this patch for about
a week, but I just now got a chance to post it. I haven't had time to
fully, absolutely, completely grok what ECN is, so it's possible that this
help text is incorrect. If so, I'd like to hear about it.

This patch is against test10pre7 but applies cleanly to test10 final as
well.

-Barry K. Nathan <barryn@pobox.com>

diff -ruN linux-2.4.0test10pre7/Documentation/Configure.help linux-2.4.0test10pre7-bkn/Documentation/Configure.help
--- linux-2.4.0test10pre7/Documentation/Configure.help	Mon Oct 30 21:36:42 2000
+++ linux-2.4.0test10pre7-bkn/Documentation/Configure.help	Tue Oct 31 10:13:32 2000
@@ -2052,6 +2052,23 @@
   If you want to compile it as a module, say M here and read
   Documentation/modules.txt.  If unsure, say `N'.
 
+TCP Explicit Congestion Notification support
+CONFIG_INET_ECN
+  Explicit Congestion Notification (ECN) allows routers to notify
+  clients about network congestion, resulting in fewer dropped packets
+  and increased network performance. This option adds ECN support to the
+  Linux kernel, as well as a sysctl (/proc/sys/net/ipv4/tcp_ecn) which
+  allows ECN support to be disabled at runtime.
+
+  Note that, on the Internet, there are many broken firewalls which
+  refuse connections from ECN-enabled machines, and it may be a while
+  before these firewalls are fixed. Until then, to access a site behind
+  such a firewall (some of which are major sites, at the time of this
+  writing) you will have to disable this option, either by saying N now
+  or by using the sysctl.
+
+  If in doubt, say N.
+
 SYN flood protection
 CONFIG_SYN_COOKIES
   Normal TCP/IP networking is open to an attack known as "SYN
diff -ruN linux-2.4.0test10pre7/Documentation/networking/ip-sysctl.txt linux-2.4.0test10pre7-bkn/Documentation/networking/ip-sysctl.txt
--- linux-2.4.0test10pre7/Documentation/networking/ip-sysctl.txt	Fri Aug 18 10:26:25 2000
+++ linux-2.4.0test10pre7-bkn/Documentation/networking/ip-sysctl.txt	Tue Oct 31 10:13:32 2000
@@ -203,7 +203,7 @@
 tcp_dsack - BOOLEAN
 	Allows TCP to send "duplicate" SACKs.
 
-tcp_ecn - BOOLEN
+tcp_ecn - BOOLEAN
 	Enable Explicit Congestion Notification in TCP.
 
 tcp_reordering - INTEGER
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] document ECN in 2.4 Configure.help

[David S. Miller]

   From: "Barry K. Nathan" <barryn@cx518206-b.irvn1.occa.home.com>
   Date: 	Sun, 5 Nov 2000 22:15:20 -0800 (PST)

   This patch is against test10pre7 but applies cleanly to test10
   final as well.

This patch is fine, thanks a lot.

OH, btw, for all folks out there.  If there ever is an instance where
I (Alexey too) send email directly to your email address (not via
linux-kernel for example) your site will be effectively ECN tested.
We run ECN on all the time on our workstations.  (it's actually nice,
a lot of crap web sites I used to visit occaisionally are no longer
reachable :-) the only major loss is theregister.co.uk :-( )

So if it appears as if Alexey and myself are ignoring you, better
check whether your mail server can talk to off-site ECN speaking
hosts first.

Later,
David S. Miller
davem@redhat.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] document ECN in 2.4 Configure.help

[David S. Miller]

   Date: 	Mon, 6 Nov 2000 01:34:14 -0600 (CST)
   From: Oliver Xymoron <oxymoron@waste.org>

   I'm still not sure why it's been decided not to do fallback or how
   this whole situation is any different from path MTU discovery.

We don't use fallbacks for path MTU discovery (I assume you are
referring to black hole detection, we don't do it, never have never
will), you have to explicitly turn path-mtu discovery off.  It's been
on by default for 3 or 4 years now :-)

Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] document ECN in 2.4 Configure.help

[Oliver Xymoron]

On Sun, 5 Nov 2000, Barry K. Nathan wrote:

> +CONFIG_INET_ECN
> +  Explicit Congestion Notification (ECN) allows routers to notify
> +  clients about network congestion, resulting in fewer dropped packets
> +  and increased network performance. This option adds ECN support to the
> +  Linux kernel, as well as a sysctl (/proc/sys/net/ipv4/tcp_ecn) which
> +  allows ECN support to be disabled at runtime.

You might mention the RFC here, 2481 IIRC.

> +  Note that, on the Internet, there are many broken firewalls which
> +  refuse connections from ECN-enabled machines, and it may be a while
> +  before these firewalls are fixed. Until then, to access a site behind
> +  such a firewall (some of which are major sites, at the time of this
> +  writing) you will have to disable this option, either by saying N now
> +  or by using the sysctl.

I'm still not sure why it's been decided not to do fallback or how this
whole situation is any different from path MTU discovery.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] document ECN in 2.4 Configure.help

[Oliver Xymoron]

On Sun, 5 Nov 2000, David S. Miller wrote:

>    Date: 	Mon, 6 Nov 2000 01:34:14 -0600 (CST)
>    From: Oliver Xymoron <oxymoron@waste.org>
> 
>    I'm still not sure why it's been decided not to do fallback or how
>    this whole situation is any different from path MTU discovery.
> 
> We don't use fallbacks for path MTU discovery (I assume you are
> referring to black hole detection, we don't do it, never have never
> will), you have to explicitly turn path-mtu discovery off.  It's been
> on by default for 3 or 4 years now :-)

Hmmm, for some reason I thought we had it, but it's been a non-issue for a
long time. The ECN thing hasn't bitten me yet either, happily.

So the question then becomes what is the process whereby we decide that
Linux will follow standards that are known to silently break things in a
large part of the real world. We explicitly don't do this with a user's
hardware, and I think we have other work-arounds for network
interoperability. How big and how badly does something have to break
before it becomes something we work around?

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] document ECN in 2.4 Configure.help

[Andrew Morton]

Oliver Xymoron wrote:
> 
> I'm still not sure why it's been decided not to do fallback or how this
> whole situation is any different from path MTU discovery.

It has:

"Changes to make to the ECN RFC before it goes to proposed standard: 
     * If the TCP host receives no response to a SYN packet sent
       with the TCP ECN_ECHO and CWR flags set, to indicate
       ECN-capability, then the sender should send its second
       SYN packet without these flags set. This is because
       there are several deployed TCP implementations that
       don't respond to SYN packets with these ECN-related flags set"

	http://www.aciri.org/floyd/ecn.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] document ECN in 2.4 Configure.help

[Alan Cox]

>        with the TCP ECN_ECHO and CWR flags set, to indicate
>        ECN-capability, then the sender should send its second
>        SYN packet without these flags set. This is because

Now that is nice. The end user perceived effect is that folks with faulty 
firewalls have horrible slow web sites with a 3 or 4 second wait for each
page. The perfect incentive. If only someone could do the same to path mtu
discovery incompetents.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] document ECN in 2.4 Configure.help

[Andi Kleen]

On Mon, Nov 06, 2000 at 11:02:47AM +0000, Alan Cox wrote:
> >        with the TCP ECN_ECHO and CWR flags set, to indicate
> >        ECN-capability, then the sender should send its second
> >        SYN packet without these flags set. This is because
> 
> Now that is nice. The end user perceived effect is that folks with faulty 
> firewalls have horrible slow web sites with a 3 or 4 second wait for each
> page. The perfect incentive. If only someone could do the same to path mtu
> discovery incompetents.

And it penalizes good guys.
If the host cannot answer to the first SYN for some legitimate reason 
then it'll never be able to use ECN. 

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] document ECN in 2.4 Configure.help

[Dominik Kubla]

On Sun, Nov 05, 2000 at 11:03:00PM -0800, David S. Miller wrote:
...
> OH, btw, for all folks out there.  If there ever is an instance where
> I (Alexey too) send email directly to your email address (not via
> linux-kernel for example) your site will be effectively ECN tested.
> We run ECN on all the time on our workstations.  (it's actually nice,
> a lot of crap web sites I used to visit occaisionally are no longer
> reachable :-) the only major loss is theregister.co.uk :-( )
...

Well, that can be fixed quite easily: install a local junkbuster and
set it to proxy requests to theregister.co.uk via one of the public
junkbuster proxies. That has the nice side effect of killing unwanted
ads as well... ;-)

Cheers,
  Dominik
-- 
http://petition.eurolinux.org/index_html - No Software Patents In Europe!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] document ECN in 2.4 Configure.help

[jamal]

On Mon, 6 Nov 2000, Andi Kleen wrote:

> On Mon, Nov 06, 2000 at 11:02:47AM +0000, Alan Cox wrote:
> > >        with the TCP ECN_ECHO and CWR flags set, to indicate
> > >        ECN-capability, then the sender should send its second
> > >        SYN packet without these flags set. This is because
> > 
> > Now that is nice. The end user perceived effect is that folks with faulty 
> > firewalls have horrible slow web sites with a 3 or 4 second wait for each
> > page. The perfect incentive. If only someone could do the same to path mtu
> > discovery incompetents.
> 
> And it penalizes good guys.
> If the host cannot answer to the first SYN for some legitimate reason 
> then it'll never be able to use ECN. 
> 

The problem with ECN, unlike path MTU discovery, is not stupid
administrators who set the wrong things in the firewall; rather it is
stupid firewal/content-switch/intrusion-detector implementations.       
With Sally's and KK's clout and enough noise from users vendors will fix
this.
CISCO has already done it. Raptor is next. Nortel products do/will not  
have this problem. 

There is no reason to make the deployment more complex than it is and i am
not sure how wise it is to make the Mark Handley extension part of the
RFC. Not just because of complexity, but also because of holes such as the
one Andi points out.

cheers,
jamal

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] document ECN in 2.4 Configure.help

[Gregory Maxwell]

On Mon, Nov 06, 2000 at 11:02:47AM +0000, Alan Cox wrote:
[snip]
> Now that is nice. The end user perceived effect is that folks with faulty 
> firewalls have horrible slow web sites with a 3 or 4 second wait for each
> page. The perfect incentive. If only someone could do the same to path mtu
> discovery incompetents.

And each object too.. Wow, perhaps this will get them to implement persistent
connections in an attempt to work around the issue. :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] document ECN in 2.4 Configure.help

[James A. Sutherland]

On Mon, 06 Nov 2000, Andi Kleen wrote:
> On Mon, Nov 06, 2000 at 11:02:47AM +0000, Alan Cox wrote:
> > >        with the TCP ECN_ECHO and CWR flags set, to indicate
> > >        ECN-capability, then the sender should send its second
> > >        SYN packet without these flags set. This is because
> > 
> > Now that is nice. The end user perceived effect is that folks with faulty 
> > firewalls have horrible slow web sites with a 3 or 4 second wait for each
> > page. The perfect incentive. If only someone could do the same to path mtu
> > discovery incompetents.
> 
> And it penalizes good guys.
> If the host cannot answer to the first SYN for some legitimate reason 
> then it'll never be able to use ECN. 

It could be a good idea to retry as normal with ECN set; iff that fails
(so the user would normally see an error connecting) try again with
ECN clear. This way, ECN-capable hosts will only see non-ECN
connections under circumstances where the connection would
otherwise have failed completely.


James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] document ECN in 2.4 Configure.help

[Pavel Machek]

Hi!

> > > >        with the TCP ECN_ECHO and CWR flags set, to indicate
> > > >        ECN-capability, then the sender should send its second
> > > >        SYN packet without these flags set. This is because
> > > 
> > > Now that is nice. The end user perceived effect is that folks with faulty 
> > > firewalls have horrible slow web sites with a 3 or 4 second wait for each
> > > page. The perfect incentive. If only someone could do the same to path mtu
> > > discovery incompetents.
> > 
> > And it penalizes good guys.
> > If the host cannot answer to the first SYN for some legitimate reason 
> > then it'll never be able to use ECN. 
> 
> It could be a good idea to retry as normal with ECN set; iff that fails
> (so the user would normally see an error connecting) try again with
> ECN clear. This way, ECN-capable hosts will only see non-ECN
> connections under circumstances where the connection would
> otherwise have failed completely.

Hmm, so you want to wait 5 minutes for your TCP connection? TCP
retries for _long_ time.

I do not think that's such a good idea.
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] document ECN in 2.4 Configure.help

[Werner Almesberger]

David S. Miller wrote:
> Any workaround which ignores TCP resets is broken from the start and
> is not to be implemented.

Hmm, what actual consequences (besides being non-conformant to RFC793)
would you expect ? I can see mainly two of them:

 - non-ECN but otherwise healthy sites get an extra SYN packet for each
   RST they send to an ECN-capable host using this recovery scheme
   (strikes me as relatively harmless; note that any retry mechanism at
   a higher protocol layer would have the same characteristics)
 - if such a host receives a RST due to an ECN-unfriendly firewall, and
   this RST was duplicated in the network, the duplicated RST will
   probably reach the sender before the non-RST response reaches it, so
   the connection fails unnecessarily.

The second scenario suggests that perhaps TCP should pick a new ISN in
this case. But I'm not sure the scenario would happen all that often in
real life ...

I'm much more worried about the "fall back immediately after single
failure" problem.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] document ECN in 2.4 Configure.help

[David S. Miller]

   From: Bernd Eckenfels <ecki@lina.inka.de>
   Date: 	Tue, 07 Nov 2000 03:38:35 +0100

   Because this will add a Fallback (non ECN) packet to every denied
   target. I think this is bad policy at least. It might violate the
   RFCs, too. Keep in mind, we cannot recognice a rejection due to
   ECN.

It does in fact violate RFCs because the fallback has to handle the
case where ECN rejection comes in the form of a (perfectly valid)
TCP reset.

Any workaround which ignores TCP resets is broken from the start and
is not to be implemented.

Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] document ECN in 2.4 Configure.help

[Bernd Eckenfels]

In article <Pine.LNX.4.10.10011060113240.8248-100000@waste.org> you wrote:
> I'm still not sure why it's been decided not to do fallback or how this
> whole situation is any different from path MTU discovery.

Because this will add a Fallback (non ECN) packet to every denied target. I
think this is bad policy at least. It might violate the RFCs, too. Keep in
mind, we cannot recognice a rejection due to ECN.

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/