operating system, wireless link, and
Why is overbuffering a problem?
Oversized buffers fill and cause delay,
destroying many uses of the Internet:
˲ ˲ Stock traders and gamers do not
want their competition to have even a
1ms advantage over them.
˲ ˲ To play music, jitter (variation in
delay) and latency must be controlled
and kept below 100ms.
˲ ˲ For something to “feel” attached
to your hand (perfect rubber banding),
latencies need to be below the 30ms
range; for keyboard echoing to be imperceptible, 50ms.
˲ ˲ Speed-of-light latency dominates
voice over IP (VoIP) over long-haul
networks, making access latencies
critical for keeping end-to-end latency below 150ms (the longtime telephony metric).
˲ ˲ Excessive packet loss induced by
bufferbloat may cause DNS lookup
˲ ˲ Essential network protocols such
as ARP, DHCP, RA, and ND all presume timely response and can fail
˲ ˲ Web browsing becomes painful as
delays go from hundreds of milliseconds to multiple seconds.
Many service providers would like
to be able to provide low-latency ser-
vices in their networks to customers,
whether remote gaming, hosted desk-
top systems, or backup. Solving the
bufferbloat problem is necessary for
their successful deployment.
the tip of the iceberg
Operating systems and hardware have
an amazing number of buffer hiding
places. As software and hardware is
updated, more sources of bloat can be
uncovered. In particular, as older TCPs
are replaced with modern ones, users
not currently bloating their access buffers may suddenly experience much
longer delays, (for example, Windows
XP does not enable TCP window scaling, so it never has more than 64KB in
flight at once).
Current commonly used network
performance tests fail to test latency
simultaneously with bandwidth: a
link must become saturated for queuing delays to become obvious. It can
take 10 seconds to fill the buffers of a
broadband device, home router or operating system, and most consumer
broadband tests do not test for that
long—thus missing bufferbloat.
Excessive access delays tend to be
written off as network congestion.
Employing larger backbone pipes
and rationing bandwidth use cannot
improve performance for the users
congesting access uplinks or viewing
downloads through bloated buffers at
the provider edge.
There are glimmers of hope. DOCSIS
(Data over Cable Service Interface Specification) was modified in spring 2011
allowing cable operators to reduce
buffering in cable modems. This mitigation will not take effect until 2012
at best and will require cable-modem
firmware upgrades or (most likely) modem replacement, as well as motivated
and knowledgeable operators.
Proper solutions for Web browsers can improve access-link behavior.
These include HTTP/1.1 pipelining and
Google’s SPDY ( http://dev.chromium.
org/spdy), both of which can achieve better performance, reduce the total number of packets and bytes transferred,
and enable TCP to function better.
Some mitigations are simple and
direct for the knowledgeable. A home
router or your laptop, for example,
almost never operates in the high-bandwidth environment for which
the operating system has likely been
tuned. Adjusting buffering in the operating system and/or device drivers can
make a major improvement over the
defaults. Unfortunately, while these
adjustments may be accessible in your
laptop, they may not be accessible in
your home router or handheld devices.
Bandwidth shaping can be used to
prevent bottleneck buffers from filling,
but at a cost in bandwidth. Contrast
the smokeping result in Figure 6 with
that in Figure 2; almost two orders of
magnitude improvement is not bad.
Most importantly, static, unmanaged buffers are inappropriate for
modern network elements. Network
architects and designers must adjust.
figure 6. smokeping of file transfer from Jim’s house to Mit after mitigations.
Median Ping Rtt ( 18. 7 ms avg) 0 1/20 2/20 3/20 4/20 10/20 19/20
Packet Loss: 3.16% average 12.26% maximum 0.0% current
Probe: 20 iCMP echo Pings (1024 Bytes) every 300 seconds created on wed Dec 16 16:49: 15 2010