Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The 2.4.x Kernel, ECN And Problem Websites

timothy posted more than 13 years ago | from the cable-modems-are-overrated dept.

The Internet 119

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 ;) )

cancel ×

119 comments

Re:ECN is *not* enabled by default! (1)

Anonymous Coward | more than 13 years ago | (#269520)

And if you do find it is on by some odd mischance, you do not even have to recompile your kernel. Just 'echo 0 > /proc/sys/net/ipv4/tcp_ecn' and voila, turned off in realtime. Anyone making a this sound like a bug really does owe the kernel devel team an appology.

Re:Two weeks ago (1)

Anonymous Coward | more than 13 years ago | (#269521)

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.

Re:Hilarious! RTFM, kind sir (1)

maelstrom (638) | more than 13 years ago | (#269522)

Since when does having a lower Slashdot ID make you a smarter poster?

ECN is *not* enabled by default! (5)

Frater 219 (1455) | more than 13 years ago | (#269523)

Contrary to the article's implications, ECN is not enabled by default in the 2.4.x kernels as Linus shipped them. In order to enable ECN, you must reconfigure and recompile the kernel. The configuration documentation for the ECN option explicitly states that turning it on will cause some routers and firewalls to drop your connections, and suggests that you leave it off unless you know you need ECN.

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.

ECN - the Next Great Battle (2)

jd (1658) | more than 13 years ago | (#269524)

ECN, if enabled in the kernel configuration, will be enabled by default on the computer. (This is the opposite to khttpd, which is DISabled after being compiled in, and must be explicitly ENabled to be used.)

IMHO, the kernel needs a standard on this. Should a network protocol be on or off, at boot time?

My next thought is that ECN is a Good Thing(tm) for these low-grade routers and firewalls. Either people upgrade (and thus remove security holes), or they lose sales, because nobody can reach them.

IMHO, someone needs to write an ECN module for Wintoes, to exploit this potential force for a quality Internet.

We =do= want a quality Internet... ...right??

Re:A bit like MS? (1)

Bander (2001) | more than 13 years ago | (#269525)

So my O/S gets to influence what sites my browser can and can't see? Ouch.

When is this ever not the case?

Bander


--

How do I determine which router drops my packets? (1)

artur (5677) | more than 13 years ago | (#269527)

Does anybody know how (or if) I can determine which router/firewall drops packets with ECN set? I would like to email people responsible for their setup to inform about this misconfiguration.
The bit currently used for ECN, used to be marked as reserved and told be ignored. Packet with this bit set should not be dropped.

Mandatory or Compelling changes? (2)

LinuxGeek (6139) | more than 13 years ago | (#269528)

Is something as useful as ECN presentable as a mandatory update for infrastructure providers ( i.e. Cisco) or mearly a nice addition to be added when other software changes/updates are applied to routers and major servers?

It seems that it could have major benefits in improving response times, but only if compliance was the rule rather than the exception. What other OSes currently support ECN? Anyone know? I haven't found much info yet.

Re:Please refer to the linux-kernel mailing list F (1)

MagicMike (7992) | more than 13 years ago | (#269530)

Its also important to note (for those that don't read the insanely useful Kernel Traffic [zork.net] that Rik had a good point, the LKML admin person eventually agreed with him, and they worked out an alternate solution.

Ahhh, open source. Its a bit messy, but works out nicely in the end more often than not...

So, I'd extrapolate and give them the benefit of the doubt on the ECN thing. They appear to be quite reasonable when presented with coherent arguments.

Hilarious! RTFM, kind sir (1)

MagicMike (7992) | more than 13 years ago | (#269531)

Seriously, man. You are making reasoned arguments, I'll grant you that, but you're basis is a bit dodgy.

Here's a link for ya. LKML FAQ on ECN [tux.org] . Nifty.

As an aside, I thought it was entirely funny watching that stairstep. Did you notice that you got totally outgunned on slashdot IDs? Every single person trying to reason with you had been around for longer than you, and you're id indicates you're no slouch.

Anyway, it appears from the FAQ, the RFCs, and the circumstantial evidence of major vendors providing bug-fix patches for this thing that its not a "deny by default" thing like blocking HTML tags, its a real-deal out-of-spec problem, and networking vendors need to get their act together.

I didn't enable that option though, so I don't particularly care either way...

RFC != Standard, and ECN summary (2)

Cato (8296) | more than 13 years ago | (#269533)

Somebody please mod this one up - clearly a lot of people think 'RFC = Standard', when the ECN RFC is clearly Experimental and explicitly not meant for production usage...

Currently there is *absolutely no practical benefit* in setting ECN bits in Internet packets today, because you need ECN capable routers throughout a network (or at least at bottleneck points) for ECN to be useful.

ECN is intended to work like this:

- ECN-capable host sends packets, setting the ECN-Capable bit in the IP Header's TOS byte to 1 so that routers know ECN is worth using

- packet experiences congestion in a router somewhere, i.e. router queue is filling up but not yet full

- router, rather than dropping the packet (which it could do, see WRED), chooses to forward the packet but mark it as 'congestion experienced' using a spare bit in the TOS byte of the IP header.

- host senses that congestion was experienced and does something about it - essentially the same as if the packet was dropped (e.g. TCP will halve its window size) but with the benefit of being able to process the packet rather than having to wait.

The end result should be quicker adaptation to congestion conditions, by avoiding some timeouts and retransmissions.

ECN is an interesting technique, but it will take a long time for it to be tested and debugged in realistic conditions, and for people to deploy it widely (perhaps in a modified version that is Standards Track within the IETF). Some routers, particularly routers in the core of the Internet, may never use ECN, since dropping packets is easier than modifying one bit.

Turning on ECN now will at least mean that some firewalls won't drop packets with ECN bits set, which is probably a good thing, but it's only going to help the ECN researchers in practical terms.

This is ridiculous!!! (1)

Rotten (8785) | more than 13 years ago | (#269534)

Problem???? Wheres the problem???? ECN is explicitly marked as experimental in the kernel info. Much more, it says that MANY ROUTERS ARE NOT PREPARED TO HANDLE IT. I cant beleive somebody wrote a piece about a experimental feature in linux kernel AND that slashdot links to it. Unbeliable. Fsacking amazing. Next year slashdot will link to a story about Apache 4.0.0.0.0a as Apache having trouble to serve pages because theres no 4.0.0.0.0a code writen yet.

Re:Please refer to the linux-kernel mailing list F (1)

grahamm (8844) | more than 13 years ago | (#269535)

And as of now (24 April), vger.kernel.org is still not using ECN. Unless something between it and here is removing the 'WE' flags, as I see incoming mail from vger arrive with only the SYN flag set.

Re:Carelessness (1)

grahamm (8844) | more than 13 years ago | (#269536)

Why should (hardware) vendors not release source drivers? The hardware vendor is in the business of selling hardware not (normally) drivers. The vendors produce drivers so that they can sell (more) hardware. So increasing the availability of drivers increases the potential hardware sales. Even if the hardware requires the driver to download firmware, this should not rule out a source level driver, as the downloadable firmware can be supplied either as a separate binary file which the driver reads, or as an initialised byte array in the source files.

Supporting operating systems (1)

blueHal (9304) | more than 13 years ago | (#269537)

Sally Floyd's ECN Page [aciri.org] lists ECN implementations. Thanks to some hard work, Linux features prominently in the list, having implementations that date back to 2.0 series kernels.

ECN does not require universal adaptation to be helpful: every packet that is marked instead of dropped helps. However, it does require that firewalls stay out of the way to be successful.

Re:Weird ... (2)

ch-chuck (9622) | more than 13 years ago | (#269538)

Maybe RFC 1812 - "4.2.2.6 Unrecognized Header Options: RFC 791 Section 3.1 A router MUST ignore IP options which it does not recognize." (caps emphasis theirs, not mine)

Re:Before any more strange comments show up... (2)

Phexro (9814) | more than 13 years ago | (#269539)

interesting. except for burstnet, the register (both running linux) and e3expo (nt) all the sites in that list run solaris.

and i'd bet that burstnet & the register use some sort of linux load-balancer, skewing the results.
---

Re:A fine line (1)

Dg93 (10261) | more than 13 years ago | (#269540)

No, the 'obvious' problem is present equipment -not- following spec. If routers don't know what the ECN bits are, they should leave them alone and pass them through (as those bit positions were marked as experimental/reserved for future use). The problem is in routers that are too intelligent for their own damn good, that busily reset flags that they shouldn't be touching. Things -were- designed for backward/forwards compatibility.

Router mfgrs saw fit to ignore that.

Re:No updating should be necessary (1)

ethereal (13958) | more than 13 years ago | (#269541)

The problem is not that ECN support is needed at the other end, the problem is that ECN uses bits which were otherwise reserved, and routers which don't know ECN are dropping packets based on the contents of reserved fields which they don't know anything about. If anything is broken, it's network hardware that's assigning new meanings to bits that it shouldn't assume anything about.

Re:ECN is *not* enabled by default! (2)

Raven667 (14867) | more than 13 years ago | (#269542)

I don't know which article you read, but I didn't see any statement that ECN was enabled by default. The author did not state where they got their 2.4.x kernel from but I assumed that they compiled it themselves. Especially since the first recommendation for disabling ECN was removing if from the kernel config file and recompiling. There is no need for a retraction, correction or apology. Please calm down 8^)

Re:Carelessness (2)

Raven667 (14867) | more than 13 years ago | (#269543)

Binary-only modules really aren't supported, you're not going to hear much crying on linux-kernel if they don't work. If you really-really-really cannot distribute modules precompiled for the major stock kernels (stock RH, Mandrake, Debian, SuSE, Caldera) or source then you can always do what 4-Front does, use a small shim that can be distributed as source. Recompile the shim on the target machine and voila! Linux will always be source compatable throughout a stable release, and that is what matters most.

Re:Please refer to the linux-kernel mailing list F (2)

Raven667 (14867) | more than 13 years ago | (#269544)

And if you would finish the story you would know that the vger admin turned off the DUL when he learned that it was causing problems. Case closed.

Re:Before any more strange comments show up... (2)

Skapare (16644) | more than 13 years ago | (#269545)

Way to go. You tell 'em!

Perhaps one way to describe the situation succinctly would be:
The problem is network devices that don't implement ECN and fail to act passively with regard to the formerly reserved bit now used for ECN.

Re:Odd. (1)

varslot (18991) | more than 13 years ago | (#269546)

Because it gives me a bigger kernel. I've now finally managed to exceed 1MB! Small kernels are for embedded systems;)

linux-kernel mailing list will soon require ECN! (2)

cpeterso (19082) | more than 13 years ago | (#269549)

According to this message on linux-kernel [lwn.net] , David S. Miller plans upgrade vger.kernel.org, the linux-kernel mailing list server, Real Soon Now. This will prevent users behind routers that don't understand ECN from using the linux-kernel mailing list!

Is this irresposible or just a good incentive for the entire internet to upgrade their routers?

Please refer to the linux-kernel mailing list FAQ (2)

cpeterso (19082) | more than 13 years ago | (#269550)

Please refer to the bold, red warning prefacing the linux-kernel mailing list FAQ [tux.org] :

Hot off the Presses:

On 22-FEB-2001, vger.kernel.org will enable ECN. You may need to switch ISP in order to receive linux-kernel email. See the section on ECN for more details.

On 25-JAN-2001, David Miller announced that vger.kernel.org will enable ECN in 4 weeks time. This means if your email account is with an ISP which has a buggy router, you will no longer be able to receive linux-kernel mail (as well as other mailing lists hosted on vger). You should check if your ISP is ECN tolerant, and get them to fix their routers or switch to another ISP.


Of course, these are the same people that use the MAPS DUL to block dial-up modem users [zork.net] from posting to the linux-kernel mailing list. Rik van Riel threw a temper tantrum, saying the DUL was class prejudice based on internet connection and that "DUL is an unethical list to use because it assumes guilty by default. Anyway, since linux-kernel has chosen to not receive email from me I won't bother answering VM bugreports or anything here." Alan Cox quickly replied, Thats ok. Andrea will I am sure be happy to take over as maintainer [of the VM subsystem]."

Re:Weird ... (2)

nyet (19118) | more than 13 years ago | (#269551)

Before opening your pie hole, read the RFCs. Only broken routers who DO NOT OBEY the RFCs fail to pass ECN.

I'm sorry, (2)

mindstrm (20013) | more than 13 years ago | (#269552)

but if any Linux admins working for me were upgrading production servers to each new kernel 'just because it was available', they'd get some lecturing. You upgrade production boxes when you NEED to. ie: A security patch...
It only takes moments to skim the kernel changelog for each new version.

Also, as I've said before, why on earth would you turn on something like ECN not knowing what it was? And the help file for ECN *DOES* say specifically that it will cause problems on the internet, because many routers don't support it yet.

This has nothing to do with instability. The kernel is very stable; this has to do with people using things without doing the research.

The reason a new 'version' isn't released once or twice a year only? OPEN SOURCE. Whenever there are a reasonable number of bug fixes, a new version comes out.

Not the point, however. (2)

mindstrm (20013) | more than 13 years ago | (#269553)

Whether ECN is experimental or not, *standards* dictate that the bits in use should be simply passed through by other routers. If a router doesn't understand certain option bits, it's supposed to IGNORE them. It is routers NOT following this *long-standing* standard that are causing the problem.

Re:Not the point, however. (2)

mindstrm (20013) | more than 13 years ago | (#269554)

These are not the same bits. The bits often used for TOS were specced for something else, but never really used.
THe bits ECN is using were originally flagged as 'other'.

And the main issue is packet filters that say 'these options aren't recognized, so it must be an attack! block it!'

Odd. (4)

mindstrm (20013) | more than 13 years ago | (#269555)

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?

Re:Before any more strange comments show up... (2)

Basje (26968) | more than 13 years ago | (#269557)

Unused bits in packets, be it IP or another protocol, could be used for a subliminal channel. So your statement that they should always left alone isn't always true. The paranoid among us should always clear them.

That said, most of the time you're probably right most of the time. Why fiddle with them when they're of no concern to you?

----------------------------------------------

Disabling ECN at runtime (1)

evin (31167) | more than 13 years ago | (#269558)

If you want the benefits of ECN but still need to connect to sites behind broken routers/firewalls, you can temporarily switch it off:

echo 0 > /proc/sys/net/ipv4/tcp_ecn

And then a 1 to turn it back on again. No need for a reboot.

Re:Please refer to the linux-kernel mailing list F (1)

ianezz (31449) | more than 13 years ago | (#269559)

Of course, these are the same people that use the MAPS DUL Please report the whole story, not just half. Maps DUL usage has been dropped shortly after.

Also, please note that using DUL generally does not block dial-up users: it forces them to use the ISP's server as a relay, as it should be. Unfortunately, it seems that there are troubles for some dial-up users to do so, and for the sake of them DUL has been dropped. But the vast majority is not affected at all.

Heck, if you want to use your local sendmail anyway (which makes sense with a dial-up account), setting it up your to smart relay your mail trough your ISP's servers is quite simple.

OTOH, ECN is really a benefit for every user on the net, and we should make pressure on ISPs and network admins to properly configure/update their routers, otherwise it will be just a really nice thing dropped for laziness.

Re:No updating should be necessary (3)

Spiv (32991) | more than 13 years ago | (#269561)

In fact, there's a very strong argument to be made that linux is being non-standards compliant

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.

Re:Please refer to the linux-kernel mailing list F (2)

mpe (36238) | more than 13 years ago | (#269562)

Also, please note that using DUL generally does not block dial-up users: it forces them to use the ISP's server as a relay, as it should be.

It is highly debatable if forcing the use of a third party relay is a good thing or not. My own opinion is that the intention should be to eliminate these. The more third party machines an email appears to have passed through the harder it is to find out where it really came from.

Re:A fine line (2)

mpe (36238) | more than 13 years ago | (#269563)

The problem is in routers that are too intelligent for their own damn good, that busily reset flags that they shouldn't be touching.

Or even software designers thinking they are doing something clever when in fact they are being completly daft. A common problem, certainly not confined to IP coding in routers.

Re:Weird ... (2)

cyberdonny (46462) | more than 13 years ago | (#269567)

> Why wasn't backwards compatibility built in to this?

Actually, backwards compatibility was built into this. The problem is buggy equipment, which misbehaves when presented with option bits which it doesn't understand. This behavior violates RFC 791 Section 3.1 "A router MUST ignore IP options which it does not recognize.". Which means, pass on the packet with these options unchanged, rather than silently dropping them.

No updating should be necessary (1)

alehmann (50545) | more than 13 years ago | (#269568)

It is a bug in the router if it doesn't pass through ECN packets. Some paranoid routers Hotmail was using thought ECN was some kind of security exploit and screwed up all communications _trying_ to use it, i.e. those attempting from ECN-enabled Linux 2.4 hosts. I'm not sure what the resolution has been but it's clear that blocking ECN is an abnormal activity that violates RFC's as well as common sense.

DONT DISABLE ECN ! (1)

chrysalis (50680) | more than 13 years ago | (#269569)

"this is a nice feature, it would make internet go faster, but some broken routers/firewalls are stupid enough to drop them, so disable it"

Sorry, but if we disable it, we slightly reduce chances of having proper ECN support everywhere. So we will stick with congestions, although defense techniques do exist and are implemented. Just because of some lame software/hardware/sysadmin.

Not using a nice feature because of broken third party software is not a thing to do. Enable the feature, and bother at non-conformant sites.

Should we stick to HTML 1.0 because some rare clients still have a very old browser lying around ? No. Having only a HTML 1.0 compliant browser is totally silly nowadays, clients have to upgrade. So why isn't it the same scenario with ECN ?

It's just like IPv6. IPv6 drafts exist for a long time. There are implementations for all major operating systems. Everything is widely documented. But almost no one did a single step to move toward IPv6. Why ? Because many pieces of software still don't support IPv6. And why don't they ? Because their developper think "almost no one moved to IPv6, anyway". And you got a marvellous vicious circle. And we stay with a shitty technology while there are alternatives.

Please do the step.

http://www.pureftpd.org

IPv6 compliant.

Re:Two weeks ago (2)

MartinG (52587) | more than 13 years ago | (#269570)

I agree actually, but some would say if you're the kind of person that turns kernel options on and off without reading all the text first and understanding all of it then you shouldn't be turning kernel options on and off - leave it to the distributions (who afaik all have ecn off by default)

Also, have you submitted a patch to fix the documentation?

Re:No problems here.. (1)

spinkham (56603) | more than 13 years ago | (#269571)

I agree with you that testing new things is good. Linux, like all unix variants, is an OS for power usert. The fact is that I still think this is not newsworthy, for the simple reason that this advisory says almost exactly the same thing as the warning on the kernel, and the kernel option is off by default. So, if you have turned on this option, you have almost definatly seen this warning already...

Re:No problems here.. (3)

spinkham (56603) | more than 13 years ago | (#269572)

ECN is disabled by default, there's big warnings in the kernel help... This is hardly newsworthy ;-)

Re:Weird ... (2)

PurpleBob (63566) | more than 13 years ago | (#269573)

A *standard* RFC says that if a router doesn't know what to do with one of the reserved bits, it should leave it alone. The router doesn't have to understand ECN to do this.
--

Re:Carelessness (3)

lizrd (69275) | more than 13 years ago | (#269574)

Hardware vendors aren't really in the business of selling hardware so much as they are in the business of integrating hardware with custom firmware and ASICs and selling the end product. The problem with handing out the driver source is that it likely gives more insight into exactly how their custom firmware and ASICs work. The actual process of soldering some chips onto the board is fairly easy and inexpensive, it's getting good firmware into the chips on the board and making the system work well together that's difficult. Anyone who buys a board can take it apart and look at each chip and look at the traces and be able to put together a pretty similar board without all that much work, so you have to protect the part that people can't just see and the best way to do that is to not release the source to the drivers.

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?

Re:No problems here.. (2)

wowbagger (69688) | more than 13 years ago | (#269575)

I disagree that it is not newsworthy. I was having this very problem, and this article helped me correct it.

True, it does say in the kernel configuration that this option might get you into trouble. So do several options. What the kernel help doesn't say is any good way to tell that ECN is giving you problems. No diagnostic measures to try in the event of problems.

Some of us like to try new things. We like to see what happens if we enable a feature, because we like to find bugs and squash them. Many people who are running Linux just want a stable system to work with, and that's good. However, those of us who remember what it was like before Linux went mainstream want to continue to push the envelope.

ECN protocol is probably broken... (1)

PTrumpet (70245) | more than 13 years ago | (#269576)

I think the real problem is that ECN makes some wild assumptions about which bits in the headers to use. The Ipv4 TOS byte is overloaded to blazes. Bad idea to use that as it should have been considered no man's land, and there appears to be no escape mechanism to negotiate behaviour between two hosts.

Had I done this, I would have added the extra bits elsewhere... perhaps TCP header extensions.

Hint to implementors. I would attempt to see if a clear path exists for those bits to work before applying it to a circuit.

As I said before I think that the protocol is broken because the discovery mechanism is unreliable as we have now seen.

Time to go back to the drawing board folks...

Re:ECN is *not* enabled by default! (1)

twilight30 (84644) | more than 13 years ago | (#269578)

Too right. Not that Mandrake is by any means perfect, but their 'hackkernel' release under 7.2 (2.4.0test10, I think) had ECN enabled. Took me a couple of days to figure out why I couldn't get to some sites. Now I have Mdk 8.0, with 2.4.3 by default, and ECN is not enabled. Get that author!!

Re:No updating should be necessary (1)

cperciva (102828) | more than 13 years ago | (#269579)

it's clear that blocking ECN is an abnormal activity that violates RFC's as well as common sense.

No, it isn't. ECN is an experimental protocol, and there is no requirement for everybody to implement every experimental protocol invented.

In fact, there's a very strong argument to be made that linux is being non-standards compliant, since the first rule of experimental protocols is "don't send packets to people who haven't asked for them".

*cough* EXPERIMENTAL *cough* (2)

cperciva (102828) | more than 13 years ago | (#269580)

Get the story right guys. This isn't a "linux is up to date while other people aren't" story -- this is a "linux is using a protocol marked as EXPERIMENTAL" story. EXPERIMENTAL protocols are protocols which are not only not internet standards, but are not even standard track.

If using an EXPERIMENTAL protocol breaks stuff, don't use it. You certainly shouldn't expect people to conform to your own non-standard behaviour.

Re:Weird ... (2)

cperciva (102828) | more than 13 years ago | (#269581)

Only broken routers who DO NOT OBEY the RFCs fail to pass ECN.

Right... only routers which do not obey an EXPERIMENTAL RFC run into problems. Guess what? You don't have to obey experimental RFCs. That's why they're *experimental*, not *standards*.

Re:ECN IS A STANDARD *NOT EXPERMENTAL* (2)

cperciva (102828) | more than 13 years ago | (#269582)

ECN is mature and at the Minn. IETF meeting it was voted to be added to the host requirement standard.

BZZZZZT. Nope, try again. There is now a [B]draft proposed standard[/B] for ECN. That's it. It isn't a standard yet, and won't be for quite some time yet.

Re:Weird ... (2)

cperciva (102828) | more than 13 years ago | (#269583)

Which RFC would that be? I can't seem to find it anywhere.

Re:Weird ... (2)

cperciva (102828) | more than 13 years ago | (#269584)

Maybe RFC 1812 - "4.2.2.6 Unrecognized Header Options:

Which doesn't apply here, since ECN is implemented via bits in the TOS octet, not in an optional IP header.

Re:Before any more strange comments show up... (2)

cperciva (102828) | more than 13 years ago | (#269585)

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!

In case people are too lazy to look up RFC 2026 themselves, here's the relevant section:
4.2 Non-Standards Track Maturity Levels


Not every specification is on the standards track. A specification
may not be intended to be an Internet Standard, or it may be intended
for eventual standardization but not yet ready to enter the standards
track. A specification may have been superseded by a more recent
Internet Standard, or have otherwise fallen into disuse or disfavor.

Specifications that are not on the standards track are labeled with
one of three "off-track" maturity levels: "Experimental",
"Informational", or "Historic". The documents bearing these labels
are not Internet Standards in any sense.

4.2.1 Experimental

The "Experimental" designation typically denotes a specification that
is part of some research or development effort. Such a specification
is published for the general information of the Internet technical
community and as an archival record of the work, subject only to
editorial considerations and to verification that there has been
adequate coordination with the standards process (see below). An
Experimental specification may be the output of an organized Internet
research effort (e.g., a Research Group of the IRTF), an IETF Working
Group, or it may be an individual contribution.

And from the top of RFC 2481:
A Proposal to add Explicit Congestion Notification (ECN) to IP


Status of this Memo

This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

It's called "deny by default" (2)

cperciva (102828) | more than 13 years ago | (#269586)

Putting aside for now the arguments about supporting experimental protocols and the use of one-used-and-now-reserved bits, there is a very simple issue here regarding firewall design.

Secure firewalls are designed to block traffic by default.

In other words, if the firewall doesn't understand the packets being sent through it, it will drop them. There's nothing wrong with this behaviour; in fact, if you try to build a "default-accept" firewall by blocking off packets which you know to be undesireable, you'll inevitably run into problems. However, anyone who has tried to get streaming media, or play warcraft, or use any other new protocols through an old firewall will be able to say that this policy can be a nuisance.

Which, of course, is one reason why there is an internet *standards track* giving people time to adapt to new protocols.

Re:Not the point, however. (2)

cperciva (102828) | more than 13 years ago | (#269587)

If a router doesn't understand certain option bits, it's supposed to IGNORE them.

I don't know about these specific routers (have we been told which they are?) but the problem might be that they do understand those bits -- in a different meaning. The TOS bits have been redefined a number of times, and the bits used by ECN have been used for other things in the past.

Re:Couldn't it be made per-host? (1)

Cyberdyne (104305) | more than 13 years ago | (#269588)

Trying every outgoing connection twice (once with, and once without) would work much better, but I don't know how many people would like that sort of behavior.

I suggested this at the time it was being discussed on lkml, but Dave Miller considered this to violate the RFCs. There are two ways in which these firewalls misbehave with ECN: either they send an RST packet ("connection refused"), in which case the kernel cannot retry the connection, or it just discards the packet (and the connection times out). In the latter case, the kernel retries anyway - but keeping ECN enabled.

I suggested retrying with ECN disabled on these retransmissions, but this was regarded as too much of a "hack". One problem is that these routers are broken - violating the RFCs - and Dave Miller is reluctant to work around this sort of problem. He wants as many hosts as possible to hit this problem, to force the owners of these routers to upgrade to RFC-compliant software instead. The trouble is, according to the IETF's survey, 8% of hosts are unreachable with ECN enabled - so enabling ECN is a big problem! (One site with ECN blocked when this topic came up on lkml is Hotmail - enable ECN, and you cut off a *LOT* of sites!)

Re:Carelessness (1)

-brazil- (111867) | more than 13 years ago | (#269589)

ndustry is dying trying to keep up with the kernel releases and from personal experience, a lot of the industry is getting sick of supporting Linux because there is a new friggin' kernel every friggin' month, which wreaks havoc when a kernel module needs to be released with a product...

Bull. The major kernel releases are more than a year apart, and the minor releases for user kernels are bugfixes, not "new kernels". If the bugfix breaks your module, you were doing something wrong.

The frequent minor releases are what makes the kernel *stable* because otherwise, not enough people could participate in debugging in the open environment.

Re:This just proves it. (1)

-brazil- (111867) | more than 13 years ago | (#269590)

Dried frog pills, most likely.

Re:Carelessness (1)

-brazil- (111867) | more than 13 years ago | (#269591)

I seem to remember an option somewhere in the module support section that lets your modules run on different kernel versions without recompiling.

Re:This just proves it. (1)

VultureMN (116540) | more than 13 years ago | (#269592)

Mr Gates, I told you to not drink when you're on your medication. I thought your performance during the trial would have convinced you that I was right.

Re:Two weeks ago (1)

bluelip (123578) | more than 13 years ago | (#269594)

It's right in my help file. It has been publized on the mailing lists. Do you normally enable options that you don't know the consequence of? This is a not a good idea on production servers.

Weird ... (1)

Dlugar (124619) | more than 13 years ago | (#269595)

Why wasn't backwards compatibility built in to this? Is there some major technical reason why it would be impossible? Seems to me that a "cutting edge" "experimental technology" ought to at least be backwards compatible with all the old stuff.

Sheesh!


Dlugar

Re:It's not the routers fault (1)

gengee (124713) | more than 13 years ago | (#269596)

Rest assured, it's not enabled by default. You have to explicitly choose it. The Kernel help tells you it will break major sites.

You can enable and disable it on the fly. And it's a great idea. I wouldn't knock it, lest you understand it.
signature smigmature

Two weeks ago (2)

gengee (124713) | more than 13 years ago | (#269597)

Where was this article two weeks ago, when we were upgrading all of our production servers to the 2.4.3 kernel, and couldn't figure out why we couldn't hit www.ibm.com or www.sabre.com.

After much troubleshooting, we found the problem. Perhaps the kernel help for ECN should have the warning about certain routers not supporting ECN nearer-to-the top of the help, instead of in the second paragraph:)

- James
signature smigmature

Yeah right. (1)

TheLink (130905) | more than 13 years ago | (#269598)

And RFC1149 is well on its way to becoming a standard?

Link.

A bit like MS? (1)

jedwards (135260) | more than 13 years ago | (#269600)

So my O/S gets to influence what sites my browser can and can't see? Ouch.

What is annoying..... (1)

nick255 (139962) | more than 13 years ago | (#269601)

....is the upgrades to using IPv6 stuff. Now when mozilla or Konqueror try to look up *.bbc.co.uk or *.doubleclick.net (ok the second one isn't as annoying) the fail to find them, probably due to IPv6 addresses rather than IPv4 ones being returned, but the rest of the net not being able to route me to them.

Re:Please refer to the linux-kernel mailing list F (1)

evil_one (142582) | more than 13 years ago | (#269602)

Although the answer to the linux-kernel ECN question went unanswered, linux-kernel DOES NOT use DUL.
---

Re:Huh? (1)

gunner800 (142959) | more than 13 years ago | (#269603)

I thought slashdot had patented that whole "making www pages unavailable" deal?

They did, but it would be hypocritical for them to enforce the patent. So OSDN will be doing it instead.


My mom is not a Karma whore!

Re:Carelessness (1)

_xeno_ (155264) | more than 13 years ago | (#269607)

Actually, if you're releaseing binary-only modules, it does reak havoc since your 2.2.17 module won't insmod on a 2.2.18 kernel - meaning you have to supply binary versions for every possible kernel combo to keep insmod happy.

At least - that's my understanding of how modules work. As far as I know, they contain specific symbols that link them to one kernel compile at a time - which is why the NVIDIA kernel module is a small C module to interface with the actual binary module. You compile the small C module which just links in at compile time the actual NVIDIA binary-only module. That solves the kernel versioning issues - although there may be ways to use out-dated modules in newer builds (like a 2.2.17 module in 2.2.18, but definately not 2.2.17 in 2.4.3). But if there is, I don't know what it is.

Of course, in the perfect Open Source world, you can recompile the modules every new kernel, but if people want vendor Linux driver support, some sacrafices must be made...

Re:No updating should be necessary (2)

vsync64 (155958) | more than 13 years ago | (#269608)

Whee, that's insightful. Not.

It might have helped if you had decided to read the comment you replied to. alehmann said nothing about implementing ECN. ahelmann did say something about blocking ECN. There is a world of difference. See, routers shouldn't just throw packets away if they have extra information in them. This is rude, and hinders adoption of new protocols, which don't hinder the router's operation in the least, and will often allow hosts on either side of the router to utilize these new protocols, even though the router in question cannot.

Go away and come back when you have learned about the Internet.

--

No problems here.. (2)

proxima (165692) | more than 13 years ago | (#269609)

I've been using the 2.4 kernel on my laptop since the week it was released, and I've had no problems (to my recollection, at least) visiting any sites. Granted, I use Datek instead of E-trade =). Looks like the sites that have older equipment have been quickly updating though, and I see no reason to disable this forward-thinking ECN.

Re:ECN is *not* enabled by default! (1)

sydb (176695) | more than 13 years ago | (#269610)

To clarify, if they give a recommendation for disabling ECN this implies it is already enabled.

Re:ECN is *not* enabled by default! (1)

swinge (176850) | more than 13 years ago | (#269611)

huh? the evidence you present supports Frater 219's interpretation quite nicely. you owe Frater 219 a retraction :)

Re:Couldn't it be made per-host? (1)

bk1e (176877) | more than 13 years ago | (#269612)

Think about it. If you only communicate with hosts using the criterion you mentioned for the "opt-in" version, you will never end up using ECN. The only time you will use ECN is when talking to hosts that always use ECN. Apply a bit of induction.

Trying every outgoing connection twice (once with, and once without) would work much better, but I don't know how many people would like that sort of behavior.

I wonder (1)

Sir_Real (179104) | more than 13 years ago | (#269613)

My linux box can't connect to my school's mail server, but my Windows Box that is being masq'd by my linux box can. Is this the same problem? Uninformed.

Couldn't it be made per-host? (3)

JCCyC (179760) | more than 13 years ago | (#269614)

Like... (correct me if I'm talking BS) if I receive an ECN packet from some IP, I store that IP in a table (maybe saved to disk every now and then) and only use ECN for hosts in that list. That would be the "opt-in" version.

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.

Re:No updating should be necessary (2)

Alien54 (180860) | more than 13 years ago | (#269615)

Some paranoid routers Hotmail was using thought ECN was some kind of security exploit and screwed up all communications _trying_ to use it, i.e. those attempting from ECN-enabled Linux 2.4 hosts.

Hey, since MS owns Hotmail, I am sure that someone there thinks that they are not under any obligation to help out by acceptin ECN.

;-)

"Bill, do you think we should use this ECN stuff?"
"I don't know, do we own it?"
"Nope"
"Does NOT accepting this Screw up Linux?"
"Yep"
"Can you read my Mind?"
"Yep!"

Of course, I would never accuse anyone of being negligent, or of being underhanded. Me? never!

Check out the Vinny the Vampire [eplugz.com] comic strip

Re:Please refer to the linux-kernel mailing list F (2)

Erasmus Darwin (183180) | more than 13 years ago | (#269616)

It is highly debatable if forcing the use of a third party relay is a good thing or not. My own opinion is that the intention should be to eliminate these.

However, it's worth pointing out that this isn't trying to force the user to use an arbitrary third-party relay. Instead, this is try to get dialup users to relay through their own ISPs mail server. If properly configured, the result is to increase accountability. Some ISPs add headers to identify the message source and, even if they don't, they've got server logs to allow them to track things in the event of spamming.

/. effect (1)

bn557 (183935) | more than 13 years ago | (#269617)

but the question on everyone's minds is how will this help prevent THE /. effect

(ignore grammer/spelling errors here. It's 1 AM and I'm drunk)

Re:Weird ... (1)

lkaos (187507) | more than 13 years ago | (#269618)

There is no backwards compatability. Router's should pass through ECN packets. This is just due to sub-standard equipment. Linux has always been the operating system on the cutting edge of networking (it was the first fullying compliant IPv4 OS).
On a side note, I have been using the 2.4 series since the initial release and have had no problems since I have not enabled ECN. If people are going to reconfigure their kernels they must take the time to understand what they are selecting and not just pick things because they sound cool.
Yet another case of M$ quality hardware causing problems...

Can't it gracefully degrade ? (1)

billcopc (196330) | more than 13 years ago | (#269619)

(IANA tcp/ip god)

If these ECN negotiation packets are rejected and discarded by certain older routers, then why can't the kernel detect this and fall back to non-ECN packets during subsequent transmissions with that particular host ? ECN is obviously not essential so why must the connection fail if this optional feature is not available ?

It's like being unable to start a car because you're not wearing sunglasses; sure the glasses would help reduce glare and let you see better, but they're still optional.

Re:Before any more strange comments show up... (3)

Cerlyn (202990) | more than 13 years ago | (#269620)

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 [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...

Before any more strange comments show up... (4)

Cerlyn (202990) | more than 13 years ago | (#269621)

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 [ietf.org] , 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)

  • www.zdnet.com
  • www.theregister.co.uk
  • www.returnbuy.com
  • www.uscourts.gov (the entire tree, more or less)
  • www.burstnet.net (at least I don't see their ads!)
  • www.time.com
  • www.latimes.com
  • www.e3expo.com

(These are only sites I visit rarely, thank goodness; I typically surf another 20+ websites daily without incident)

Re:A bit like MS? (1)

PSUdaemon (204822) | more than 13 years ago | (#269622)

So my O/S gets to influence what sites my browser can and can't see?

No. Actually some router out there decided that. Since you set bit's it's not even supposed to be concerned with. It should ignore the reserved bits, or at least throw an error. It should not silently drop packets...the OS in this case is merely doing the right thing. So it's the routers fault you can't see a web page.

It is also made very clear in the kernel config that you don't have to do this, and isn't set by default. So you'd have to go out of your way to make it happen.

Re:damn (1)

Zero Sum (209324) | more than 13 years ago | (#269623)

>Ya BSD is still trying to hack together working SMP, they won't have support for ECN for a long time.

I've been running SMP BSD for years now, I wish you would stop bitching about it. It is rock solid reliable, worked from day one and never stopped working despite (at least) monthly rebuilds. As for performance, I haven't found a promblem with it.

A fine line (1)

ageitgey (216346) | more than 13 years ago | (#269624)

The obvious problem with new protocols is backwards compatibility. If it doesn't exist, users are forced to upgrade or suffer the consequences. Usually the new feature is a Good Thing or the users wouldn't suffer through the upgrades, unless a monopoly has control of the market. But that is another discussion.

The point is, as cool as this new feature is, I think that it should have been disabled by default or users should see a very visible warning during the upgrade process (even if you are compiling it yourself, that act doesn't imply that you understand all the changes that have been made). Causing sections of the network to dissapear to your hosts after a production-machine upgrade is a good way to lose your job or at least turn management off to the idea of linux. If you have no idea why certain hosts are suddenly not reachable and you are the linux "expert" driving adoption in your company, your higher-ups won't have much confidence in being able to support linux systems economically.

Just my 2 cents.

Re:*cough* EXPERIMENTAL *cough* (1)

jo42 (227475) | more than 13 years ago | (#269625)

...not to mention that Linux itself is 'experimental'.

Herd Of Linux Hacks: Let's write this code. Let's release it. Doh! It's broke. Let's fix it. Repeat. :-p

Re:No updating should be necessary (2)

Alatar (227876) | more than 13 years ago | (#269626)

Dropping packets silently is more secure. Don't ask me why, I asked one time, and they just said, "dropping packets silently is more secure, now shut up and sit down, you non-NANOG-reading luser, whilst I upgrade my routers to the latest FreeBSD-STABLE ".

ENC 2.4 (1)

DankNinja (241851) | more than 13 years ago | (#269627)

I had this problem when I enabled it on our mailserver. Apparently it was related to certain types of firewalls, albeit older ones.

Re:It's not the routers fault (1)

MakinWaves (251435) | more than 13 years ago | (#269628)

Bad enough to be a troll...but then a stupid troll on top of that....yeeesh

Re:Two weeks ago (1)

Ehud (259882) | more than 13 years ago | (#269629)

Perhaps you should know not to enable ECN if you don't know what it is and what the consequences are.

("This looks l33t, I think I'll just enable it. I bet it'll make everything super-fast!")

What is ECN and how to TURN IT OFF (1)

blueherring (415746) | more than 13 years ago | (#269631)


ECN or Explicit Congestion Notification was added in Linux 2.4 kernel. Some companies are filtering packets that has bits in the packet header flipped in the reserved space thinking someone is trying to mangle packets to get around security. But these reserved bits are there for the new features like ECN, so it can be added.

http://www.tux.org/lkml/#s14-2

Why does the 2.4 kernel report Connection refused when connecting to sites which work fine with earlier kernels?

(DW) The 2.4 kernel is designed to make your Internet Experience more pleasurable. One of the ways in which it does so is by implementing Explicit Congestion Notification - a new method defined in RFC 2481 for improving TCP performance in the the presence of congestion by allowing routers to provide an early warning of traffic flow problems.
Unfortunately, there are bugs in some firewall products which cause them to reject incoming packets with ECN enabled. If your own firewall is broken in this respect, you should check with your vendor for a fix.
If the site to which you cannot connect is not under your control, then after you have contacted the administrator of the offending site to let them know about their problem, you can disable ECN in the 2.4 kernel either by disabling the CONFIG_INET_ECN option and recompiling the kernel, or by executing the following command as root:

# echo 0 > /proc/sys/net/ipv4/tcp_ecn

You might also take a look at http://www.aciri.org/floyd/ecn.html for more details on the ECN changes.

-- Ingram

Re:Mandatory or Compelling changes? (1)

Tech187 (416303) | more than 13 years ago | (#269632)

A mandatory upgrade [microsoft.com] ?

Hmmmm. I think I've heard of that someplace....

Re:linux-kernel mailing list will soon require ECN (1)

Tech187 (416303) | more than 13 years ago | (#269633)

You've gotta be trolling. Nobody could ever do something that stupid and get away with it for long....

Pretty soon there will be secret decoder rings or you won't be allowed to attend the LUG...

Re:This just proves it. (1)

HansvanV (442385) | more than 13 years ago | (#269634)



Time for your medicine.

Re:This just proves it. (1)

the_2nd_coming (444906) | more than 13 years ago | (#269635)

I wish slashcode could filter the winblows trolls out of hear.

Re:noone supports TCP ECN (1)

the_2nd_coming (444906) | more than 13 years ago | (#269636)

but a router should just ignor the extra bit by turning it off. the problem is not the protocol it is the router thinking the extra bit is a hacker trying to access the Network.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...