Hi,
On LKML (Linux Kernel Mailing List) there is talk <http://lkml.org/lkml/2008/11/4/151> about shipping the Linux kernel with ECN turned on by default (it was on by default a few years back but that change was reverted due to too many sites dropping ECN enabled SYNs).
Recent investigations <http://www.imperialviolet.org/binary/ecntest.pdf> shows that 0.5% of end hosts will drop SYN packets with ECN turned on. This is approximately the same rate I have seen for A/AAAA adoption in this tread <http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg01585.html>.
Do we in the operational ISP community have an opinion on ECN adoption that we want to voice? As far as I can discern from <http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ftwrdecn.html> for ECN to actually be useful, we (the ISPs) have to turn this option on in the routers as well. Is anyone doing this today? What vendors support it?
When I thought about it, the IP core (10G links etc) first came to mind, and there it's fairly easy to roll out (since I guess a lot of us do WRED already), but what about on slower links? Would it make sense to have our DSLAMs do this? What about DSL/cable modems (well, vendors should first realise that FIFO is not great to begin with :P) ?
<http://www.icir.org/tbit/> is a summary page I found on ECN that looks like a good resource for further reading. Is anyone looking into including ECN configuration into some BCP document?
When I thought about it, the IP core (10G links etc) first came to mind,
and there it's fairly easy to roll out (since I guess a lot of us do
WRED already), but what about on slower links? Would it make sense to
have our DSLAMs do this? What about DSL/cable modems (well, vendors
should first realise that FIFO is not great to begin with :P) ?
Implementing this in an MPLS core is not an easy task, you can really
only do this on the edge, when the MPLS labelled packet arrives at an
LSR, we don't know if it contains a TCP segment or not (fancy deep h/w
implementations excluded), all we know is that , if there is congestion,
we can discard it based on the EXP bits in the shim.
Dave.
David Freedman <david.freedman@uk.clara.net> writes:
Implementing this in an MPLS core is not an easy task, you can really
only do this on the edge, when the MPLS labelled packet arrives at an
LSR, we don't know if it contains a TCP segment or not (fancy deep h/w
implementations excluded), all we know is that , if there is congestion,
we can discard it based on the EXP bits in the shim.
Please see RFC 5129
Bjørn
Interesting , I hadn't followed this since draft-ietf-mpls-ecn-00,
, I eagerly await a vendor implementation 
Dave.
Bjørn Mork wrote:
I did some more checking and neither 12000 (IOS) nor CRS-1 seems to support WRED with ECN (at least the command doesn't show when I create a policy-map), so I'm going to ping my Cisco SE and hear about what's going on.
The only thing that's *required* for it to help is that the routers and
firewalls not actually *molest* the bits in the TCP SYN packet. If you pass
them and *do nothing else*, it at least has the potential of being useful at
some other router along the path. And let's face it - if *your* router is
congested enough for ECN to matter, there's a fairly good chance that the
router one hop up/downstream is *also* seeing some effects. Even if *you* don't
do anything else, your neighbor might - helping you out in the bargain.