Show 125 – Bufferbloat – What Can You Do Today to Suffer Less

Buffer Bloat is the overuse of buffering in network equipment. Well meaning but misguided and, most likely, stupid equipment vendors have tried to avoid packet loss by increasing the the buffers in the network. But they have missed a fundamental property of TCP and UDP protocols, if they live in a buffer for too long, the receiver will time out and request retransmission. As a result, data is transmitted twice or three times.

To make matters worse, the overbuffering causes TCP fast start algorithm failure. That is, TCP must acknowledge receipt of frames and if those ACK packet are stuck in a buffer, the next tranche of data cannot be sent. Therefore, bandwidth is unused to since TCP cannot burst into the available capacity.

In this podcast, we talk to Jim Gettys, who first published his take on the problem and comprehensively proved it. Since then, things have started to happen.

Here in our boardroom that is fully equipped with keen minds, practical and bitter experiences, and overblown sense of what the future should look like, we attempt to tackle the issues that matter to the networking engineers.

Bandwidth Delay Product

ICSI Netalyzer –

Greg Ferro
Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count. He is a host on the Packet Pushers Podcast, blogger at and on Twitter @etherealmind and Google Plus.
Greg Ferro
Greg Ferro
Greg Ferro
Greg Ferro

Latest posts by Greg Ferro (see all)

  • bitman

    Steve Gibson (security now) already had a Podcast about Buffer Bloat months ago.

    • Lindsay Hill

      Good for him – turns out that we don’t all listen to the same set of podcasts.

    • Toby Jason Davey

      I’m sure he’s calling the lawyers in to fight this injustice!

  • John G

    I’ve had to tell customers this for years, but very simply they keep asking for more buffers. Therefore the right amount of buffer, according to some, is infinite!

  • Derick Winkworth

    Looking forward to this one. Bufferbloat is a problem, but there are extremists about advocating “single packet” buffers or no buffers at all. This falls into the category of “sometimes network engineers avoid hard to do things like properly configuring QoS” and “Would be nice if OS guys worked with the network guys to put the right default TCP settings on systems…”

  • Craig Gill

    These guys have a good website on buffer bloat,

    They have a very good solution for the linux platform, using byte queue limits and codel in the linux 3.6 kernel

  • Douglas Hanks

    Some applications like MapReduce work well with buffer

  • Liam

    still on 1500k/256k DSL, and this is a serious problem – if someone starts downloading then RTT goes over 6 seconds, and if they start uploading, then its over 8 seconds – if they do both at once, then ~12-15 seconds!
    All in all it makes for a very poor user experience.

  • Liam

    It was only after using a decent network at my university that I found out that ‘networks shouldn’t do that’.

  • Liam

    That video-streaming is terrible for those with lower bandwidth links. Those bursts fill the buffer, and take a while to ramp up.
    It is also really bad for high bandwidth connections – it generates a huge burst of incoming traffic which can even overwhelm 100Mbit switched ethernet serviced by a 1Gbps backbone. Even on that system we would observe latency spikes due to ‘streaming’ video and even web traffic!