The IETF has provided a spec, and additional documents on deployment issues. They have provided all the guidance they are going to. It's now up to implementers to weigh the trade-offs. My own observations and opinions, for what they're worth: Turning on ECN doesn't hurt as much as it used to. Back in the early '00s, there were a lot of devices sold especially to financial institutions to "protect" their web sites. These devices dropped any packets with (previously) reserved header bits set, because some people used these as a covert information channel. I believe these devices are not as common as they once were, but there are still a few big sites that black hole these packets. (I know that southwest.com is still an offender.) I have not actually heard of any issues with consumer-grade stuff, but that may be because ECN has been disabled by default for so long. Almost no network operators turn on ECN marking in their routers. In fact, almost none care to do any sort of AQM. The practical benefits of ECN are still somewhat unclear for most people. For example, it can help with latency-sensitive applications, but mostly requires a big queue to work well, so doesn't help as much as you would hope. There are some interesting ideas on how to better use ECN information, but these are mostly still research. ECN black hole detection is pretty simple, and I don't see much reason not to do it. -John On Fri, Nov 7, 2008 at 6:45 AM, David Newall <davidn@xxxxxxxxxxxxxxx> wrote: > Isn't this a question for the IETF to answer? Are they saying turn on > ECN now? > -- > To unsubscribe from this list: send the line "unsubscribe linux-net" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
