Slashdot Mirror
The 2.4.x Kernel, ECN And Problem Websites
mitd writes: "Enterprise Linux Today is running an article about how some network devices i.e. routers, do not support ECN (Explicit Congestion Notification), causing WWW sites to be unavailable to 2.4.x kernel based hosts." The article does show you an easy workaround, though. (Read more below.)
"Nice quote: 'The answer is that Linux is once again on the cutting edge of networking technology ...' The article points out some major sites that have not updated their routers to handle ECN packets."
Anything that helps destroy congestion at least has my attention. (And in a parallel universe, legions of Windows users are howling that the Linux hegemonists have again chosen to implement new standards in order to drag them into the fold ;) )
If you find ECN enabled in your distributor's 2.4.x kernel package by default, please consider this a severe mistake on your distributor's part. Please do not consider it a bug in "the 2.4.x kernel". The author of the Enterprise Linux Today article owes Linus and the kernel developers a retraction and correction.
I find it strange. In moving to 2.4 kernels, the first thing I did was, of course, run through the configuration.
For each option that I didn't recognize, I hit the help button. The help button for ECN (which defaults to off) specifically states that ECN is not supported by some routers, and currently may cause problems with reaching websites on the Internet, so I left it off.
So my question is: Why would you turn on a new network option without knowing what it was?
Actually, ECN is designed to be backwards compatible - if a host doesn't understand ECN, it should respond with a packet with the ECN bit turned off, and the ECN-aware originating host will behave accordingly.
The problem is routers that drop these packets silently. They should either let them through, or if paranoid, reject them, sending a RST back to the original host, which can then retry without ECN. Dropping silently just makes the connection attempt "hang", until it times out.
Further, it is *not* enabled by default, can be toggled at runtime via /proc/sys/net/ipv4/tcp_ecn and comes with warnings in the appropriate build option. I'd say that's perfectly responsible way to introduce a new feature.
-Spiv.
ECN is disabled by default, there's big warnings in the kernel help... This is hardly newsworthy ;-)
Blessed are the pessimists, for they have made backups.
The thing that I don't understand is why the license agreement that comes with most drivers prohibits me from making copies of the drivers. Honestly, are you going to sell any fewer products if I give a copy of the driver to my friend?
I don't want free as in beer. I just want free beer.
An "opt-out" version could be made too, but I guess an external maintainer would be needed for such a list -- it wouldn't be desirable for every other connection to drop in the process of building what supposedly is a performance booster.
All right, this is a flame. Dareth I answer it...
ECN is *NOT* a standard, nor even standards track.
The fact ECN is written up as a request for comments document (RFC) means it *is* well on its way to becoming an Internet standard. Even the process itself of becoming an Internet standard is written up as an RFC. Look at the main web page at www.ietf.org and click on the link marked "The Internet Standards Process." Look at what is there! RFC 2026!
Many protocols in modern use never became an Internet "standard"; these include things like Mobile IP and 802.11 wireless Ethernet. Your idenfication protocol used by almost any IRC server is RFC's 1431 and 0931; they never became a standard. The number of Internet standards actually issued number less than 70. The IETF itself doesn't link to them much anymore since there is an normally an RFC representing the final form of each one.
[The] systems that you have 'problems' with are systems that support ECN, not systems that don't support ECN
Sorry! Thanks for playing. If the client says it supports ECN by flagging that fact with the bits once reserved for future use, it will not run into problems if the other side says it does not. The routers, firewalls, load balancers and/or servers on the other that do not know simply to leave those bits alone and continue normally can be faulted. The TCP protocol said those bits might be used later, but many programmers did not heed that warning. Instead, they drop packets using the once reserved bits, send TCP or ICMP reset messages, etc.
So in a way, it is the client's fault for supporing a newer extension of TCP/IP that the older one. The extension works fine -- as long as the other end still tries to establish a connection reguardless of ECN support!
The reason you have trouble with these sites is because you have a client which respects the ECN bit, and there are thousands/millions of other clients which don't, which has the effect of you never reaching the site, since you always back off in deference to those clients which don't.
Major sites must be busy to the point their links are congested, aren't they? I hope not. Read the article; the problem is routers, firewalls, and other devices seeing the bits marked "for furture use" being used, and considering packets invalid. Again, the fact that an ECN host tries contacting a host that does not support ECN is irrelevant; as long as the packets get through, the ECN-aware end will realize the other end does not, and revert to normal congestion behavior.
If no device on the other end spoke ECN, you wouldn't have this problem, as it wouldn't have any way to know to treat an ECN aware client differently than one that wasn't.
The ECN aware client is in charge, at least in the failure cases cited by the article. In most failure cases (at least those I have seen), it is the *client* requesting that the connection use ECN in the first place (although servers are welcome to as well). If after the initial handshake it discovers the remote host does not know ECN, it uses the old-style of TCP throttling behavior in response to bad packets. The ECN extension was designed to allow backwards compatibility with older clients; the people who designed it were not that foolish.
Get an education before you start posting pretending you know what you're talking about.
Is the fact I have a bachelors degree in Electrical and Computer Engineering (with honors), 99% of the work for a masters degree in the same, and the fact I was accepted to one of the top doctoral schools in the country enough education? I have spent many many years studying network protocol theory, and several years administering servers. I even wrote my own IRC client at ones point in time based off the RFC documents on it, and that protocol is hardly "experimental" anymore...
Let me just say that it is the systems that do *not* handle ECN that are at fault, not the systems that *do* support it. Read the RFC specification here here, or from your nearest RFC mirror (#2481). Note how bits marked as "presently unused" and "reserved for future use" are used for explicit congestion notification.
Any protocol implementation with a bit of sanity would know to leave reserved bits it did not how handle unchanged. Unfortunately, many systems do not do this. Some firewalls see reserved bits being used as a threat, and reset connections. Other systems have no clue how to react if a reserved bit is not the default value.
A partial list of sites I know have trouble with ECN enabled (thank goodness they are the minority of web sites out there) is below. But this is like the Y2K bug; it never really should have existed.
Sites with known ECN problems (that I've seen, anyway)
(These are only sites I visit rarely, thank goodness; I typically surf another 20+ websites daily without incident)