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 <[email protected]>
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
From: "Barry K. Nathan" <[email protected]>
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
[email protected]
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.."
Date: Mon, 6 Nov 2000 01:34:14 -0600 (CST)
From: Oliver Xymoron <[email protected]>
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
[email protected]
On Sun, 5 Nov 2000, David S. Miller wrote:
> Date: Mon, 6 Nov 2000 01:34:14 -0600 (CST)
> From: Oliver Xymoron <[email protected]>
>
> 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.."
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
> 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
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
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!
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
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. :)
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.
In article <[email protected]> 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
From: Bernd Eckenfels <[email protected]>
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
[email protected]
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 [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
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 [email protected] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/