problems of insufficient buffers, thus
erring on the side of larger buffers,
perhaps unaware that AQM is rarely
used or unavailable.
Wireless links and networks are increasingly part of the edge access and
are even more variable than broadband bandwidth: moving a device a
few centimeters can change rates by
one to two orders of magnitude; and
because wireless is a shared medium,
this also affects rates. Since bandwidth can vary by a factor of 100 at
short time scales, static buffering is
A number of approaches to speeding up Web access contribute to transient access-link bloat by dumping
large numbers of packets onto these
Revisiting the Bandwidth-Delay
The efficacy of BDP-sized buffers is in
question. As pointed out in a presentation at ACM SIGCOMM in 2004, BDP is
not appropriate for highly multiplexed
core links. 1 The rationale for maintaining a BDP buffer still applies at the
network edge where a single flow can
congest a link. The problem is in determining that BDP. Bandwidth variations
of two or more orders of magnitude
clearly play havoc with the bandwidth.
At the same time, the 100ms delay assumption has been weakened by the
advent of content delivery networks
(CDNs) and other services engineered
to bring common RTTs down to
10ms−30ms. Thus, even if an access
link is a constant bandwidth and its
buffer is sized to 100ms, it may still be
3− 10 times too large.
For more than a decade, TCP tuning
has been focused on improvements
needed for high-BDP environments
where large packet windows are required to achieve good throughput.
These new algorithms are not in themselves nefarious, focusing on efficiently filling the pipe, but the researchers
have unconsciously worked with a
model of high bandwidth and AQM-enabled buffers. When the large pipe
size comes from buffers rather than
bandwidth, the algorithms efficiently
fill those buffers, resulting in large delays. Controlling buffers makes it possible for one TCP to work well everywhere, a solution that is preferable to
and hardware have
an amazing number
of buffer hiding
places. as software
and hardware is
sources of bloat
can be uncovered.
attempting to create a version of TCP
specifically for access links.
Clearly there cannot be a “correct”
static amount of buffering in the global Internet: A self-adaptive AQM is the
only viable long-term solution in any device (including your computer or smart
phone) with a network buffer.
aQM for the Modern world
In early 1998, Kathleen Nichols discovered flaws in RED and started to
work with Jacobson to make improvements. At that time, the main concern
was finding an algorithm that could
be configured for any link by setting
a single-rate parameter, as well as developing a viable approach to tracking persistent queue while ignoring
short-term bursts. 7 Subsequent research tried to fix some of the flaws
but failed to create an AQM that could
keep persistent buffers short without overdropping. Network operators
faced only with algorithms requiring expert manual configuration that
might hurt them have understandably been unwilling to enable and
In the ensuing decade wireless has
been widely deployed, bringing wildly
varying bandwidth to many edge links,
cable Internet access has become common, and a device’s access bandwidth
can easily vary by two orders of magnitude. It is now obvious that any AQM
algorithm that does not take as an input the rate at which data leaves the
buffers cannot work in today’s highly
variable bandwidth environment.
Clearly without such an algorithm,
bufferbloat will be difficult to defeat.
Surprising to most, AQM is essential
for broadband service, home routers,
and even operating systems: It is not
just for big Internet routers.
When does overbuffering hurt?
Overbuffering hurts anytime you saturate a
link; for example:
˲ ˲ Copying a file over the Internet.
˲ ˲ Running old versions of BitTor-rent or other file-sharing application.
˲ ˲ Sending/receiving email messages
to Grandma with pictures attached.
˲ ˲ Uploading video to You Tube.
˲ ˲ Web browsing, which can hurt you
or others momentarily.
The saturated link can be anywhere,
in either or both directions in the path:
easiest and most common to see is the