<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Jim Gettys</b> <span dir="ltr"><<a href="mailto:jg@freedesktop.org">jg@freedesktop.org</a>></span><br>Date: Sat, Sep 10, 2011 at 10:45 AM<br>
Subject: Fwd: caidathoughts on bufferbloat<br>To: Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>><br><br><br>
  

    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <br>
    Note the moosehaper.  Worth reading through in general.<br>
    <br>
    <br>
      <br>
    <pre>on caida chat room so far:


kenyon says, "hooray bufferbloat believers. I've been on the <a href="http://bufferbloat.net" target="_blank">bufferbloat.net</a>
    mailing list for a while. I do traffic shaping on my router to work around
    bufferbloat. Otherwise latency is horrible during large transfers."
You [to kenyon]: told him he really needs a blog entry showing how people can
    traffic shape their own home routers to prove to themselves it's real,
    i.e., that manipulating parameters to avoid buffer bloat makes a diff
Josh wants to be a believer
You [to Josh]:
    <a href="http://arstechnica.com/tech-policy/news/2011/01/understanding-bufferbloat-a" target="_blank">http://arstechnica.com/tech-policy/news/2011/01/understanding-bufferbloat-a</a>
    nd-the-network-buffer-arms-race.ars
kenyon [to you]: yes, but I guess it's hard or impossible unless you're
    running a "real" operating system on your router.
amogh says, "so the "solution" is to shape your upstream bandwidth to less
    than the upstream capacity (which is already much less than your
    downstream capacity)?"
You [to kenyon]: i thought most of these things use openwrt in the meantime
kenyon [to amogh]: yes, I think so.
You [to kenyon]: tho i guess cisco linksys are running a very old linux kernel
kenyon [to amogh]: also, same for the downstream, since the latency problem is
    the same for large downloads, at least for me.
kenyon says, "OpenWrt is the way to go if you have a compatible device."
kenyon uses mooseshaper |
    <a href="http://bazaar.launchpad.net/%7Emalcscott/mooseshaper/trunk/view/head:/moosesh" target="_blank">http://bazaar.launchpad.net/~malcscott/mooseshaper/trunk/view/head:/moosesh</a>
    aper
amogh [to kenyon]: do you see more packet loss when you do this shaping?
kenyon [to amogh]: it does cause packet loss, but I don't really "see" it.
    Can't see it with e.g. ping, since it is prioritized. Here is my current
    tc output, which does show that packets get dropped:
    <a href="http://paste.pocoo.org/show/473276/" target="_blank">http://paste.pocoo.org/show/473276/</a>
kenyon says, "I wouldn't say downloads take a lot longer. I set my downstream
    to 10000 kb/s, which is only a few Mb/s less than I could get with this
    connection."
amogh [to kenyon]: hmmm, I guess I need to learn more about how this shaping
    works and in particular how it affects loss rate
Josh says, "Looks like my Cisco/Linksys E3000 will not run OpenWrt but would
    run DD-WRT or Tomato"
Josh has extremely mixed household of web browsing, gaming, netflixing, and
    SSH sessions
dan has a household of one that mixes web browsing, gaming, netflixing, and
    ssh sessions.  ;)
kenyon says, "also, ECN=1
    <a href="http://en.wikipedia.org/wiki/Explicit_Congestion_Notification#Linux" target="_blank">http://en.wikipedia.org/wiki/Explicit_Congestion_Notification#Linux</a> :)"
amogh says, "ISPs (or router vendors) should ideally allow users to specify
    their typical traffic mix (long-running, short/interactive, mixed) and
    provide buffer size settings for each traffic mix. But this seems highly
    unlikely to happen, because as soon as you set short buffers but run a
    long upload/download, you'll have non-negligible packet loss rate, and
    ISPs don't want any of that.."
kenyon [to amogh]: that's why you need to prioritize traffic so that the
    packet loss happens on the long transfer, where you don't notice it - TCP
    just does its flow/congestion control stuff. If the long transfer is UDP,
    then I don't know, I guess the application will do its own buffering.
amogh [to kenyon]: you don't notice it probably because we're more tolerant of
    delays in long transfers. but TCP throughput is inversely proportional to
    sq-root of loss rate, so if your loss rate changes from 1% to 2% (say),
    your TCP throughput goes down by a factor of 1.4

so shortening the buffers makes interactive traffic snappy, but 
makes your file transfers take longer.  i think you need to 
quantify this tradeoff for a range of home traffic mixes....  
have you talked to renata about her homenet profiler tool?
<a href="http://cmon.lip6.fr/hnp/pages/home" target="_blank">http://cmon.lip6.fr/hnp/pages/home</a>

k

</pre>
  </div>

</div><br><br clear="all"><br>-- <br>Dave Täht<br>SKYPE: davetaht<br>US Tel: 1-239-829-5608<br><a href="http://the-edge.blogspot.com" target="_blank">http://the-edge.blogspot.com</a> <br>