Stig Venaas writes: > Well, the real issue is who has a broken TCP implementation, or > firewall or other device that mishandles those packets. The real issue is whether an ECN bit is reserved, or not reserved. If it is reserved, dropping connections that set it is appropriate behavior; if it is not reserved, then properly processing the bit is appropriate behavior. However, the notion that software that considers the bit reserved should just ignore it and keep on going is very dangerous. RFC 3360 takes this attitude, and it's a risky one, no matter how useful it might be to Linux hobbyists. It's not appropriate to simply ignore reserved bits on input, because, if any of them are set, your correspondent is obviously using functionality that you don't have, and you know the functionality is not backwards compatible because reserved bits are being set. Truly backwards-compatible features will use reserved bits in ways that leaves them unchanged (i.e., zero) in compatible modes. So what is the "correct" behavior? Well, ECN is not backwards-compatible. So a system that supports ECN should first attempt to establish a connection that uses it, with the appropriate bits set. If the remote host understands this, the connection will continue normally. If the remote host does not understand ECN, then the proper remote behavior is to DROP THE CONNECTION, at which point the local host must REESTABLISH the connection, this time WITHOUT ECN, and with the reserved bits all set to zero. The principle of "liberal in what you accept, conservative in what you expect" does indeed apply, but here people are applying it to the wrong host. It is prudent to drop connections that set reserved bits, because you have no idea why those bits are set, or what the other end may expect in consequence. It is not prudent to set reserved bits and then expect every other host to tolerate that; the entire world will not upgrade at once and you must be able to deal with older implementations. So the correct behavior is for the ECN-aware host to first attempt a connection with ECN, then attempt again without it if the remote system demonstrates that it is unable to support ECN (by resetting the connection when it sees "reserved" bits mysteriously in use). That's how compatibility is supposed to work, but apparently someone got it wrong, and now the wrong parties are being blamed for the mistake.