CAIDA workshop – Sundaresan et. al.

The CAIDA workshop was last week with interesting talks; unfortunately, I did not attend.  The CAIDA workshop is  a venue for not-really-finished work; it’s home for things that are still being worked on, and maybe half baked.

There were two presentations of interest,  I know about:

  • Benchmarking Broadband Internet Performance by Srikanth Sundaresan, Walter de Donato, Nick Feamster, Renata Teixeira, Antonio Pescape
  • A survey of the current state of ECN support in servers, clients, and routers, presented by Steve Bauer of MIT.

Steve needs to finish tweaking his slides, so that will have to wait a bit.  But the Georgia Tech presentation is available. Page 18 is interesting.  Since some people don’t do well with log plots, Srikanth is kind enough to provide a version of that slide in linear form.

Upload times, in seconds (linear)

So as you could see in the ICSI data the times are horrifyingly bad.

7 Responses to “CAIDA workshop – Sundaresan et. al.”

  1. Flavio Says:

    Jim, I think you messed up the links to the presentations.

    I’m trying to digest all this stuff on bufferbloat so I can fix my home ADSL router. I’m getting >10s latencies on pings when I’m uploading a file, and that’s not good.

    • gettys Says:

      Fixed. Thanks!

    • gettys Says:

      Fixed. Thanks!

      Note you should first make sure the bloat is actually in your DSL router; if the bandwidth you are actually getting exceeds that you get out of any downstream links (e.g. your 802.11 wireless), the bloat will be in your OS/home router, rather than DSL.

      Now, for DSL, it is most likely in your DSL hop (since DSL bandwidth is typically lower than some other technologies), but you’d be frustrated to expend lots of effort in the wrong place (as I was some months ago, before I got my head around bufferbloat and its pervasiveness). Ping is your friend, for this diagnosis. You ping the first few upstream hops, and see where the “delta T” goes up…

      • Flavio Says:

        I’m pretty sure it’s the ADSL modem/router. Yesterday I did some testing with ping, traceroute and mtr (a wonderful tool, I see it was recommended to you already). The RTT between my router and the next hop, which I suppose is what’s called the DSLAM in the telecom’s exchange, jumped from 30-35ms to >11 seconds as soon as I started uploading a large file.

        My computer is running Linux 2.6.32, it’s directly attached to the router’s 100M Ethernet and I saw the same results with standard txqueuelen and ring buffer settings and with txqueuelen set to 1 and the transmit ring buffer set to 64 (the lowest my Nvidia nForce will go).

        Now the good part is that the router, a D-Link DSL-2640B, is a) running Linux, and b) is my own, not a telco locked down brick, so I could ssh into it and look at the network configuration. The txqueuelen was already set pretty low on the WAN interface (I think it was 3, and I gather it’s the default for PPP) so there must be some other queue in there, maybe in the ADSL stuff itself, either the hardware or the software.

        The not so good part is that this router not currently supported by DD-WRT, OpenWrt and the like, and will probably never be because there’s no open documentation for the ADSL chip if I understand correctly. However, I already went through the pain of rebuilding the GPLed firmware because I wanted to customize busybox (the morons built it without ‘ls’… how can you do that???) so I’m tempted to dive into it and see if there’s source code for at least some parts of the ADSL driver.

        • gettys Says:

          Best to join the bloat, bloat-devel and/or OpenWRT mailing lists to sort this out: there are likely better people than I to advise you. It does seem like it is the DSL modem/DSLAM hop from what you say.

          Note the ADSL device driver itself could be bloated; though I’m happy the transmit queue is something sane.

  2. Dave Täht Says:

    I use a highly modified and rapidly evolving version of wondershaper to rate limit on the outgoing interface. If you have tc and iptables on the router, you can fix this.

    • Flavio Says:

      iptables yes; tc I’m not sure, but the router can do QoS so there’s probably something. I thought about ratelimiting, either on the router itself or on my computer, but haven’t tried in practice yet. I’ll candidly admit that I know almost nothing about QoS, traffic shaping and related stuff, but this is probably a good chance to learn.

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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: