Theodore Ts'o writes:
To continue quoting from RFC 3360, there were some good reasons stated
in that document for why reasonable implementors might not choose to
implement the workaround:
* The work-arounds would result in ECN-capable hosts not responding
properly to the first valid reset received in response to a SYN
packet.
* The work-arounds would limit ECN functionality in environments
without broken equipment, by disabling ECN where the first SYN or
SYN-ACK packet was dropped in the network.
* The work-arounds in many cases would involve a delay of six seconds
or more before connectivity is established with the remote server,
in the case of broken equipment that drops ECN-setup SYN packets.
By accommodating this broken equipment, the work-arounds have been
judged as implicitly accepting both this delay and the broken
equipment that would be causing this delay.
It sounds like ECN is pretty badly designed; I'm glad it wasn't my idea.
But since it is out there now, it still seems better to provide a
workaround that provides _some_ connectivity (even with a six-second
delay) than an implementation that provides none at all.
Better still, just turn ECN off.
It should also be noted that RFC 3168 did not require the workaround
as a MUST. If RFC 3168 had required the use of the workaround (which
presumably would have required the working group to come to a
consensus that the tradeoffs listed above were less important than
coddling trashy firewall implementations), then I'm sure the Linux
implementors would have respected such a MUST requirement in RFC 3168.
The problem is that RFC 3168 postdates all the RFCs that came before it,
and when something needs to be compatible with real-world systems that
are not all instantly and simultaneously upgraded, it needs to behave in
a way that works acceptably with systems that haven't guite reached RFC
3168.
This problem will only get worse, you know. More and more systems on
the Net, with more and more variable maintenance, mean ever greater
difficulty in making any non-backwards-compatible change at all to
anything. For better or for worse, the earliest design decisions of the
Internet will be haunting us for decades to come, and it will be
imperative to design anything new in a way that accommodates them.
Obviously this wasn't done for ECN, and I daresay it isn't being done
for lots of new specifications.
I guess this would be second on the list of most common mistakes made by
engineers, after the woeful misjudgement of necessary or available
capacity (in addressing schemes, for example).