A reminder: the CAIDA workshop is a venue for not-really-finished work; it is a home for things that are still being worked on, and talks are sometimes half baked.
With those caveats, Steve Bauer has been kind enough to give me a copy of his slides, slightly tweaked since that workshop, that goes over the state of ECN. They are much better than half-baked, but they are very much a work in progress. It has a quick overview of how ECN is implemented, and then goes into the current state of deployment and problems uncovered.
For those of you who are interested in bufferbloat, but don’t know the background around ECN, ECN provides an alternate way to hosts or routers to signal congestion to packet drops. Many wireless people (particularly cell operators) are particularly adverse to the idea of dropping packets to signal congestion, having often gone through heroic measures to move the bits; but unless we signal congestion somehow, our bloated buffers will fill. And ECN has not seen wide adoption in the Internet due to problems in some devices; the question is, can we start using it as we have hoped for a long time?
Again, this is preliminary data; Steve and Robert will have better data later this spring and summer.
I find a number of interesting points in the data, along with a few questions:
- Slide 10 shows the current behavior in various operating systems. Server side ECN deployment is now occurring at a good clip (remember; ECN won’t be used unless both ends agree), having gone from 1% to 12% in the last two years. Given when the key OS releases occurred, this is encouraging.
- The University results were strongly biased by a couple of the big research networks being mis-configured; those have been/are in the process of being fixed, and a number of the other problems (such as Steve’s home broadband carrier’s misconfiguration) are being fixed, often quite quickly (slide 38). This shows the importance of testing tools, which at the moment, we have few.
- There is a methodological result here: we can modify traceroute to build a tool to help diagnose ECN problems. Any volunteers?
- Another result: if routers ever turned on ECN marking, we could use method to find what routers were congested
- There is some brokenness that needs fixing.
- How do different paths differ? For example, much of the remaining broken kit out there is in the broadband part of the net; but this is seldom accessed from handsets. If we can’t use ECN everywhere immediately, there may be interesting intermediate positions.
- How to best account for the big content providers (e.g. video)? they tend to use multiple CDNs and those CDN’s are also moving targets; but turning ECN on on those content sources could have a very large impact quickly. But it’s therefore hard to keep track of how much traffic is ECN capable there. How can they make this monitoring more comprehensive and systematic?
If anyone is looking for a really helpful project to undertake, modifying mtr to both better report bufferbloat and make it useful as a ECN diagnostic tool would be wonderful. Shining the light on where problems are is essential to getting bufferbloat fixed.