CAIDA Workshop (AIMS 2011) – Bauer and Beverly ECN results

The CAIDA workshop was last week with interesting talks; unfortunately, I did not attend.

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.

Questions include:

  • 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.

4 Responses to “CAIDA Workshop (AIMS 2011) – Bauer and Beverly ECN results”

  1. Alexandre Courant Bellefroid Says:

    This might be obvious to someone who’s worked inside those techs for as long as you, but, since every telco ever just puts Linuxes in all of their infrastructure, why not just submit a patch to the kernel that would schedule packet buffering once and for all? A simple algorithm to dynamically allocate a buffer size for each buffer, depending on the end-to-end latency, with the write() returning only when ready so that apps won’t send more data. Somewhat like slow-start on a by-link basis, possibly overruled by a system-wide watch dog. And maybe a hook for a user-space daemon for distributed self-monitoring, could be a good idea, that.

    I’m only a CS student and will happily defer to your vast experience, but I know I sometimes happen to have good ideas.

    • gettys Says:

      If only we had such a simple algorithm in hand…. See the posting I made with Kathie Nichol’s comments about RED.

    • gettys Says:

      If only we had such a simple algorithm in hand…. See the posting I made with Kathie Nichol’s comments about RED.

  2. alexbhr Says:

    Very nice post and link. As far as figuring out ECN support, tcptraceroute(1) has a flag that enables ECN-marked SYN sending. It could potentially be used to gather data as well.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: