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? -- Mikael Abrahamsson email: swmike@swm.pp.se
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:
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
On Fri, 7 Nov 2008, David Freedman wrote:
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.
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. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Fri, 07 Nov 2008 08:27:58 +0100, Mikael Abrahamsson said:
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?
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.
On Fri, 7 Nov 2008, Valdis.Kletnieks@vt.edu wrote:
On Fri, 07 Nov 2008 08:27:58 +0100, Mikael Abrahamsson said:
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?
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.
See: http://www.icir.org/floyd/ecn.html http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ftwrdecn.html -Hank
participants (5)
-
Bjørn Mork -
David Freedman -
Hank Nussbacher -
Mikael Abrahamsson -
Valdis.Kletnieks＠vt.edu