top | item 8644642

Bufferbloat: Dark Buffers in the Internet (2011)

40 points| tel | 11 years ago |queue.acm.org | reply

9 comments

order
[+] teddyh|11 years ago|reply
Summary of what you can do for yourself:

1. In Linux, use the fq_codel queueing discipline for your interface which sits on your fast-to-slow network boundary:

    tc qdisc add dev $IFACE root fq_codel
2. On your Netgear WNDR3700v2 or WNDR3800 home router, install and run CeroWrt: http://www.bufferbloat.net/projects/cerowrt/wiki/Installatio...
[+] darklajid|11 years ago|reply
If you're more into this than I am:

What will 1) achieve here? Isn't the biggest problem ~elsewhere~ (i.e. my ISP sucks, and all the gazillion devices on the route might buffer far too much data)? Put differently: Can I make a difference, even if it's "just" for me? (I .. cannot, I guess - I'm stuck with a crappy cable modem/DECT base/wifi router combination from my ISP. But I'm interested in general)

Regarding 2): Is that recommended? Last time I checked most of CeroWrt was sent upstream, so is there a big difference between a reasonably current version of OpenWrt?

[+] tel|11 years ago|reply
I posted this as much as a note into the stability of the Internet as a commentary on scalable application architecture. I'd love to hear commentary from people who have implemented buffers internally as part of an architecture and whether they implemented smart feedback channels like RTT or faced difficulties like those mentioned here.
[+] nsamuell|11 years ago|reply
Bufferbloat is definitely a thing. Most home routers are terrible sources of bufferbloat by default (HTTP browsing crawls to a halt the second torrenting starts ramping up). Thankfully, most home routers have some amount of QoS which can help a _ton_.