Bufferbloat is a widespread problem present throughout the Internet, "end-to-end." Debloating is a "work in progress" industry wide and will take years. Ultimately, all buffering/queuing in operating systems needs to be carefully managed and be automatically adaptive to the data transfer rates. All network routers (and operating systems!) should be running with AQM (e.g. algorithms such as RED) including home routers: unfortunately, existing algorithms such as RED are unlikely to work correctly in today's home network environment.
CeroWrt is the test platform for improved AQM algorithms. To achieve ultimate latencies under load across the high bandwidth variation of 802.11 and broadband, new AQM algorithms need testing in addition to more complex changes in internal buffering; these will take time and therefore debloating will be a work in progress for an extended period.
In the upstream direction, the bottleneck link may be adjacent to your home devices (e.g. your laptop on wireless), and in your operating system, outside of our control; you may see problems therefore copying from your home device upstream to the Internet and/or your home file server. Unfortunately, TCP acks can be stalled behind packets queued in a particular direction, so bufferbloat in one direction can result in bad performance (poor latency) in the other direction. If you run Linux, you can help with debloating by working with those working on the debloat-testing work going on on bufferbloat.net. On other operating systems, you should contact your operating system vendor and complain. Be gentle (but insistent), however: before 2011, bufferbloat was not understood to be a general problem, and it will take time to overcome.
Note that bufferbloat only occurs in the device just before the bottleneck in a path. A common strategy when fixes for bufferbloat are not available for the devices either side of a bottleneck, therefore, is to try to arrange to move the bottleneck from a device which is badly bloated to one which is not: e.g. you might arrange to ensure that your wireless bandwidth is always bigger than your broadband bandwidth (and using bandwidth shaping and QoS to avoid the consequences of bufferbloat in that hop as best you can).
Current operating systems has been tuned over the last decade for maximum bandwidth over very long, high bandwidth LFN ("Large Fat Network") paths without consideration of bufferbloat (gigabit speed + over 100ms or longer paths).
The quest for "land speed" record bragging rights has destroyed latency, the speed we really need. The bandwidth-delay product (BDP) of these LFN paths is very high indeed, and buffers have been adjusted upwards accordingly. When these same operating systems are used in home routers (e.g. Linux and Apple's system), LFN tuning becomes a serious headache as the circumstances differ tremendously.
Home routers never operate in LFN's, rather, they operate in two network environments, sometimes simultaneously:
We can therefore cut the buffering in the router greatly, since there are never high bandwidth, high delay paths through these devices. If we've done this correctly, you'll never see lower bandwidth, but will see much better latency. Please let us know if you see any performance problems.
Debloating techniques currently in place include but are not limited to:
QoS classification is interesting to improve low latency applications (e.g. VoIP & gaming) and to help with the reverse path consequences of bufferbloat (e.g. delay of acks, DNS and other key protocols which are killing performance and even inducing failures). QoS is a useful but insufficient tool: bufferbloat cannot be completely solved without AQM, a common misunderstanding.