Sizing router buffers.
All Internet routers contain buffers to hold packets during times of congestion. Today, the size of the buffers is determined by the dynamics of TCP's congestion control algorithm. In particular, the goal is to make sure that when a link is congested, it is busy 100% of the time; which is equivalent to making sure its buffer never goes empty. A widely used rule-of-thumb states that each link needs a buffer of size is the average round-trip time of a flow passing across the link, and C is the data rate of the link. For example, a 10Gb/s router linecard needs approximately 250ms x 2.5Gbits of buffers; and the amount of buffering grows linearly with the line-rate. Such large buffers are challenging for router manufacturers, who must use large, slow, off-chip DRAMs. And queueing delays can be long, have high variance, and may destabilize the congestion control algorithms. In this paper we argue that the rule-of-thumb now outdated and incorrect for backbone routers. This is because of the large number of flows (TCP connections) multiplexed together on a single backbone link. Using theory, simulation and experiments on a network of real routers, we show that a link with n flows requires no more than long-lived or short-lived TCP flows. The consequences on router design are enormous: A 2.5Gb/s link carrying 10,000 flows could reduce its buffers by 99% with negligible difference in throughput; and a 10Gb/s link carrying 50,000 flows requires only 10Mbits of buffering, which can easily be implemented using fast, on-chip SRAM.
INTRODUCTION
AND MOTIVATION
1.1 Background
Internet routers are packet switches, and therefore bu#er
packets during times of congestion. Arguably, router bu#ers
are the single biggest contributor to uncertainty in the Inter-
net. Bu#ers cause queueing delay and delay-variance; when
they overflow they cause packet loss, and when they underflow
they can degrade throughput. Given the significance
of their role, we might reasonably expect the dynamics and
sizing of router bu#ers to be well understood, based on a
well-grounded theory, and supported by extensive simulation
and experimentation. This is not so.
Router bu#ers are sized today based on a rule-of-thumb
commonly attributed to a 1994 paper by Villamizar and
Song [1].Using experimental measurements of at most eight
TCP flows on a 40 Mb/s link, they concluded that - because
of the dynamics of TCP's congestion control algorithms
- a router needs an amount of bu#ering equal to
the average round-trip time of a flow that passes through
the router, multiplied by the capacity of the router's net-work
interfaces. This is the well-known
We will show later that the rule-of-thumb does indeed make
sense for one (or a small number of) long-lived TCP flows.
Network operators follow the rule-of-thumb and require
that router manufacturers provide 250ms (or more) of bu#er-
ing [2]. The rule is found in architectural guidelines [3], too.
Requiring such large bu#ers complicates router design, and
is an impediment to building routers with larger capacity.
For example, a 10Gb/s router linecard needs approximately
250ms - 10Gb/s= 2.5Gbits of bu#ers, and the amount of
bu#ering grows linearly with the line-rate.
The goal of our work is to find out if the rule-of-thumb still
holds. While it is still true that most tra#c uses TCP, the
number of flows has increased significantly. Today, backbone
links commonly operate at 2.5Gb/s or 10Gb/s, and carry
over 10,000 flows [4].
One thing is for sure: It is not well understood how much
bu#ering is actually needed, or how bu#er size a#ects net-work
performance [5]. In this paper we argue that the rule-
of-thumb is outdated and incorrect. We believe that sig-
2.5 3 3.5 4 4.5
Window [pkts]

Figure

1: Window (top) and router queue (bottom) for a TCP flow through a bottleneck link.

Figure

2: Single flow topology consisting of an access
link of latency l Acc and link capacity CAcc and a
bottleneck link of capacity C and latency l.
nificantly smaller bu#ers could be used in backbone routers
(e.g. by removing 99% of the bu#ers) without a loss in net-work
utilization, and we show theory, simulations and experiments
to support our argument. At the very least, we believe
that the possibility of using much smaller bu#ers warrants
further exploration and study, with more comprehensive
experiments needed on real backbone networks. This
paper isn't the last word, and our goal is to persuade one
or more network operators to try reduced router bu#ers in
their backbone network.
It is worth asking why we care to accurately size router
bu#ers; with declining memory prices, why not just over-
bu#er routers? We believe overbu#ering is a bad idea for
two reasons. First, it complicates the design of high-speed
routers, leading to higher power consumption, more board
space, and lower density. Second, overbu#ering increases
end-to-end delay in the presence of congestion. Large bu#ers
conflict with the low-latency needs of real time applications
(e.g. video games, and device control). In some cases large
delays can make congestion control algorithms unstable [6]
and applications unusable.
1.2 Where does the rule-of-thumb come from?
The rule-of-thumb comes from a desire to keep a congested
link as busy as possible, so as to maximize the throughput
of the network. We are used to thinking of sizing queues so
as to prevent them from overflowing and losing packets. But
TCP's ``sawtooth'' congestion control algorithm is designed
to fill any bu#er, and deliberately causes occasional loss to
provide feedback to the sender. No matter how big we make
the bu#ers at a bottleneck link, TCP will cause the bu#er
to overflow.
Router bu#ers are sized so that when TCP flows pass
through them, they don't underflow and lose throughput;
and this is where the rule-of-thumb comes from. The metric
we will use is throughput, and our goal is to determine the
size of the bu#er so as to maximize throughput of a bottle-neck
link. The basic idea is that when a router has packets
bu#ered, its outgoing link is always busy. If the outgoing
link is a bottleneck, then we want to keep it busy as much
of the time as possible, and so we just need to make sure
the bu#er never underflows and goes empty.
Fact: The rule-of-thumb is the amount of bu#ering
needed by a single TCP flow, so that the bu#er at the bottleneck
link never underflows, and so the router doesn't lose
throughput.
The rule-of-thumb comes from the dynamics of TCP's
congestion control algorithm. In particular, a single TCP
flow passing through a bottleneck link requires a bu#er size
equal to the bandwidth-delay product in order to prevent the
link from going idle and thereby losing throughput. Here,
we will give a quick intuitive explanation of where the rule-
of-thumb comes from; in particular, why this is just the right
amount of bu#ering if the router carried just one long-lived
TCP flow. In Section 2 we will give a more precise explana-
tion, which will set the stage for a theory for bu#er sizing
with one flow, or with multiple long- and short-lived flows.
Later, we will confirm that our theory is true using simulation
and experiments in Sections 5.1 and 5.2 respectively.
Consider the simple topology in Figure 2 in which a single
source sends an infinite amount of data with packets
of constant size. The flow passes through a single router,
and the sender's access link is much faster than the re-
ceiver's bottleneck link of capacity C, causing packets to be
queued at the router. The propagation time between sender
and receiver (and vice versa) is denoted by Tp . Assume
that the TCP flow has settled into the additive-increase and
multiplicative-decrease (AIMD) congestion avoidance mode.
The sender transmits a packet each time it receives an
ACK, and gradually increases the number of outstanding
packets (the window size), which causes the bu#er to gradually
fill up. Eventually a packet is dropped, and the sender
doesn't receive an ACK. It halves the window size and
pauses. 1 The sender now has too many packets outstanding
in the network: it sent an amount equal to the old win-
dow, but now the window size has halved. It must therefore
pause while it waits for ACKs to arrive before it can resume
transmitting.
The key to sizing the bu#er is to make sure that while
the sender pauses, the router bu#er doesn't go empty and
force the bottleneck link to go idle. By determining the rate
at which the bu#er drains, we can determine the size of the
reservoir needed to prevent it from going empty. It turns
out that this is equal to the distance (in bytes) between the
peak and trough of the "sawtooth" representing the TCP
We assume the reader is familiar with the dynamics of TCP.
A brief reminder of the salient features can be found in Appendix
A.
window size. We will show later that this corresponds to
the
It is worth asking if the TCP sawtooth is the only factor
that determines the bu#er size. For example, doesn't statistical
multiplexing, and the sudden arrival of short bursts
have an e#ect? In particular, we might expect the (very
bursty) TCP slow-start phase to increase queue occupancy
and frequently fill the bu#er. Figure 1 illustrates the effect
of bursts on the queue size for a typical single TCP
flow. Clearly the queue is absorbing very short term bursts
in the slow-start phase, while it is accommodating a slowly
changing window size in the congestion avoidance phase. We
will examine the e#ect of burstiness caused by short-flows in
Section 4. We'll find that the short-flows play a very small
e#ect, and that the bu#er size is, in fact, dictated by the
number of long flows.
1.3 How buffer size influences router design
Having seen where the rule-of-thumb comes from, let's see
why it matters; in particular, how it complicates the design
of routers. At the time of writing, a state of the art router
linecard runs at an aggregate rate of 40Gb/s (with one or
more physical interfaces), has about 250ms of bu#ering, and
so has 10Gbits (1.25Gbytes) of bu#er memory.
Bu#ers in backbone routers are built from commercial
memory devices such as dynamic RAM (DRAM) or static
RAM (SRAM). 2 The largest commercial SRAM chip today
is 36Mbits, which means a 40Gb/s linecard would require
over 300 chips, making the board too large, too expensive
and too hot. If instead we try to build the linecard using
DRAM, we would just need 10 devices. This is because
DRAM devices are available up to 1Gbit. But the problem
is that DRAM has a random access time of about 50ns,
which is hard to use when a minimum length (40byte) packet
can arrive and depart every 8ns. Worse still, DRAM access
times fall by only 7% per year, and so the problem is going
to get worse as line-rates increase in the future.
In practice router linecards use multiple DRAM chips
in parallel to obtain the aggregate data-rate (or memory-
they need. Packets are either scattered across
memories in an ad-hoc statistical manner, or use an SRAM
cache with a refresh algorithm [7]. Either way, such a large
packet bu#er has a number of disadvantages: it uses a very
wide DRAM bus (hundreds or thousands of signals), with
a huge number of fast data pins (network processors and
packet processor ASICs frequently have more than 2,000
pins making the chips large and expensive). Such wide buses
consume large amounts of board space, and the fast data
pins on modern DRAMs consume a lot of power.
In summary, it is extremely di#cult to build packet bu#ers
at 40Gb/s and beyond. Given how slowly memory speeds
improve, this problem is going to get worse over time.
Substantial benefits could be gained by placing the bu#er
memory directly on the chip that processes the packets (a
network processor or an ASIC). In this case, very wide and
fast access to a single memory is possible. Commercial
packet processor ASICs have been built with 256Mbits of
"embedded"DRAM. If memories of 2% the delay-bandwidth
product were acceptable (i.e. 98% smaller than they are to-
day), then a single-chip packet processor would need no external
memories. We will present evidence later that bu#ers
includes devices with specialized I/O, such as DDR-
SDRAM, RDRAM, RLDRAM and FCRAM.

Figure

3: Schematic evolution of a router bu#er for
a single TCP flow.50150250
Queue [Pkts]

Figure

4: A TCP flow through a single router with
bu#ers equal to the delay-bandwidth product. The
upper graph shows the time evolution of the congestion
window W (t). The lower graph shows the time
evolution of the queue length Q(t).
this small might make little or no di#erence to the utilization
of backbone links.
2. BUFFER SIZE FOR A SINGLE LONG-LIVED
In the next two sections we will determine how large the
router bu#ers need to be if all the TCP flows are long-lived.
We will start by examining a single long-lived flow, and then
consider what happens when many flows are multiplexed
together.
Starting with a single flow, consider again the topology in

Figure

2 with a single sender and one bottleneck link. The
schematic evolution of the router's queue (when the source
is in congestion avoidance) is shown in Figure 3. From time
t0 , the sender steadily increases its window-size and fills the
bu#er, until the bu#er has to drop the first packet. Just
under one round-trip time later, the sender times-out at
because it is waiting for an ACK for the dropped
packet. It immediately halves its window size from Wmax to
Wmax/2 packets 3 . Now, the window size limits the number
of unacknowledged (i.e. outstanding) packets in the net-
work. Before the loss, the sender is allowed to have Wmax
outstanding packets; but after the timeout, it is only allowed
to have Wmax/2 outstanding packets. Thus, the sender has
too many outstanding packets, and it must pause while it
waits for the ACKs for Wmax/2 packets. Our goal is to
make sure the router bu#er never goes empty in order to
keep the router fully utilized. Therefore, the bu#er must
not go empty while the sender is pausing.
If the bu#er never goes empty, the router must be sending
packets onto the bottleneck link at constant rate C. This in
3 While TCP measures window size in bytes, we will count
window size in packets for simplicity of presentation.
Queue [Pkts]

Figure

5: A TCP flow through an underbu#ered
router.50150250350
Window [Pkts]50150
Queue [Pkts]

Figure

flow through an overbu#ered
router.
turn means that ACKs arrive to the sender at rate C. The
sender therefore pauses for exactly (Wmax/2)/C seconds for
the Wmax/2 packets to be acknowledged. It then resumes
sending, and starts increasing its window size again.
The key to sizing the bu#er is to make sure that the bu#er
is large enough, so that while the sender pauses, the bu#er
doesn't go empty. When the sender first pauses at t 1 , the
bu#er is full, and so it drains over a period B/C until t 2
(shown in Figure 3). The bu#er will just avoid going empty
if the first packet from the sender shows up at the bu#er
just as it hits empty, i.e. (Wmax/2)/C # B/C, or
To determine Wmax , we consider the situation after the
sender has resumed transmission. The window size is now
Wmax/2, and the bu#er is empty. The sender has to send
packets at rate C or the link will be underutilized. It is well
known that the sending rate of TCP is
equation 7 in AppendixA). Since the bu#er is empty, we
have no queueing delay. Therefore, to send at rate C we
require that
RTT
or which for the bu#er leads to the
well-known rule-of-thumb
While not widely known, similar arguments have been made
previously [8, 9], and our result can be easily verified using
ns2 [10] simulation and a closed-form analytical model (Ap-
pendix B). Figure 4 illustrates the evolution of a single TCP
Reno flow, using the topology shown in Figure 2. The bu#er
size is exactly equal to the rule-of-thumb,
The window size follows the familiar sawtooth pattern, increasing
steadily until a loss occurs and then halving the window
size before starting to increase steadily again. Notice
that the bu#er occupancy almost hits zero once per packet
loss, but never stays empty. This is the behavior we want
for the bottleneck link to stay busy.


Appendix

presents an analytical fluid model that provides
a closed-form equation of the sawtooth, and closely
matches the ns2 simulations.

Figures

5 and 6 show what happens if the link is under-
bu#ered or overbu#ered. In Figure 5, the router is under-
bu#ered, and the bu#er size is less than RTT - C. The
congestion window follows the same sawtooth pattern as in
the su#ciently bu#ered case. However, when the window
is halved and the sender pauses waiting for ACKs, there is
insu#cient reserve in the bu#er to keep the bottleneck link
busy. The bu#er goes empty, the bottleneck link goes idle,
and we lose throughput.
On the other hand, Figure 6 shows a flow which is over-
bu#ered. It behaves like a correctly bu#ered flow in that it
fully utilizes the link. However, when the window is halved,
the bu#er does not completely empty. The queueing delay
of the flows is increased by a constant, because the bu#er
always has packets queued.
In summary, if B # 2Tp the router bu#er
(just) never goes empty, and the bottleneck link will never
go idle.
3. WHEN MANY LONG TCP FLOWS
SHARE A LINK
In a backbone router many flows share the bottleneck link
simultaneously, and so the single long-lived flow is not a realistic
model. For example, a 2.5Gb/s (OC48c) link typically
carries over 10,000 flows at a time [4]. 4 So how should we
change our model to reflect the bu#ers required for a bottleneck
link with many flows? We will consider two situa-
tions. First, we will consider the case when all the flows are
synchronized with each other, and their sawtooths march
in lockstep perfectly in-phase. Then we will consider flows
that are not synchronized with each other, or are at least
not so synchronized as to be marching in lockstep. When
they are su#ciently desynchronized - and we will argue
that this is the case in practice - the amount of bu#ering
drops sharply.
3.1 Synchronized Long Flows
Consider the evolution of two TCP Reno flows through a
bottleneck router. The evolution of the window sizes, sending
rates and queue length is shown in Figure 7.
Although the two flows start at di#erent times, they
quickly synchronize to be perfectly in phase. This is a well-documented
and studied tendency of flows sharing a bottle-neck
to become synchronized over time [9, 11, 12, 13].
A set of precisely synchronized flows has the same bu#er
requirements as a single flow. Their aggregate behavior is
still a sawtooth; as before, the height of the sawtooth is
4 This shouldn't be surprising: A typical user today is connected
via a 56kb/s modem, and a fully utilized 2.5Gb/s can
simultaneously carry over 40,000 such flows. When it's not
fully utilized, the bu#ers are barely used, and the link isn't
a bottleneck. So we should size the bu#ers for when there
are a large number of flows.
Util [Pkts/s]
Rate [Pkts/s]500150025003500
Util [Pkts/s]
Queue [Pkts]

Figure

7: Two TCP flows sharing a bottleneck link.
The upper two graphs show the time evolution of
the RTT of the flows, the congestion window of the
senders, the link utilization and the sending rate
of the TCP senders. The bottom graph shows the
queue length of the router bu#er.
dictated by the maximum window size needed to fill the
round-trip path, which is independent of the number of
flows. Specifically, assume that there are n flows, each with
a congestion window W i (t) at time t, and end-to-end propagation
delay
n]. The window size is
the maximum allowable number of outstanding bytes, so
where Q(t) is the bu#er occupancy at time t, and T P is the
average propagation delay. As before, we can solve for the
bu#er size by considering two cases: just before and just
after packets are dropped. First, because they move in lock-
step, the flows all have their largest window size, Wmax at
the same time; this is when the bu#er is full, so:
Similarly, their window size is smallest just after they all
drop simultaneously [9]. If the bu#er is sized so that it just
goes empty as the senders start transmitting after the pause,
then
9500 10000 10500 11000 11500 12000 12500
Probability
Packets
link underutilized
packets dropped
PDF of Aggregate Window
Normal Distribution N(11000,400)

Figure

8: The probability distribution of the sum of
the congestion windows of all flows passing through
a router and its approximation with a normal distri-
bution. The two vertical marks mark the boundaries
of where the number of outstanding packets fit into
the bu#er. If sum of congestion windows is lower
and there are less packets outstanding, the link will
be underutilized. If it is higher the bu#er overflows
and packets are dropped.
Solving for B we find once again that
this result holds for any number of synchronized in-phase
flows.
3.2 Desynchronized Long Flows
Flows are not synchronized in a backbone router carrying
thousands of flows with varying RTTs. Small variations in
RTT or processing time are su#cient to prevent synchronization
[14]; and the absence of synchronization has been
demonstrated in real networks [4, 15]. Likewise, we found
in our simulations and experiments that while in-phase synchronization
is common for under 100 concurrent flows, it is
very rare above 500 concurrent flows. 5 Although we don't
precisely understand when and why synchronization of TCP
flows takes place, we have observed that for aggregates of
over 500 flows, the amount of in-phase synchronization de-
creases. Under such circumstances we can treat flows as
being not synchronized at all.
To understand the di#erence between adding synchronized
and desynchronized window size processes, recall that if we
add together many synchronized sawtooths, we get a single
large sawtooth, and the bu#er size requirement doesn't
change. If on the other hand the sawtooths are not syn-
chronized, the more flows we add, the less their sum will
look like a sawtooth; they will smooth each other out, and
the distance from the peak to the trough of the aggregate
window size will get smaller. Hence, given that we need as
much bu#er as the distance from the peak to the trough
of the aggregate window size, we can expect the bu#er size
5 Some out-of-phase synchronization (where flows are synchronized
but scale down their window at di#erent times
during a cycle) was visible in some ns2 simulations with up
to 1000 flows. However, the bu#er requirements are very
similar for out-of-phase synchronization as they are for no
synchronization at all.
time [seconds]
Buffer
Sum of TCP Windows [pkts]
Router Queue [pkts]

Figure

9: Plot of P W i (t) of all TCP flows, and of
the queue Q o#set by 10500 packets.
requirements to get smaller as we increase the number of
flows. This is indeed the case, and we will explain why, and
then demonstrate via simulation.
Consider a set of TCP flows with random (and indepen-
start times and propagation delays. We'll assume that
they are desynchronized enough that the window size processes
are independent of each other. We can model the
total window size as a bounded random process made up of
the sum of these independent sawtooths. We know from the
central limit theorem that the aggregate window size process
will converge to a gaussian process. Figure 8 shows that indeed
the aggregate window size does converge to a gaussian
process. The graph shows the probability distribution of the
sum of the congestion windows of all flows
di#erent propagation times and start times as explained in
Section 5.1.
From the window size process, we know that the queue
occupancy at time t is
In other words, all outstanding bytes are in the queue (Q(t)),
on the link (2Tp - C), or have been dropped. We represent
the number of dropped packets by #. If the bu#er is large
enough and TCP is operating correctly, then # is negligible
compared to 2TP - C. Therefore, the distribution of Q(t) is
shown in Figure 9, and is given by
Because W has a normal distribution, Q has the distribution
of a normal shifted by a constant (of course, the normal distribution
is restricted to the allowable range for Q). This is
very useful, because we can now pick a bu#er size and know
immediately the probability that the bu#er will underflow
and lose throughput.
Because it is gaussian, we can determine the queue occupancy
process if we know its mean and variance. The mean
is simply the sum of the mean of its constituents. To find
the variance, we'll assume for convenience that all sawtooths
have the same average value (having di#erent values would
still yield the same results). Each TCP sawtooth can be
modelled as oscillating with a uniform distribution around
its average congestion window size W i , with minimum 2
and maximum 4
Since the standard deviation of the
uniform distribution is 1
-th of its length, the standard
deviation of a single window size #W i
is thus
From Equation (5),
For a large number of flows, the standard deviation of the
sum of the windows, W , is given by
and so by Equation (5) the standard deviation of Q(t) is
Now that we know the distribution of the queue occu-
pancy, we can approximate the link utilization for a given
bu#er size. Whenever the queue size is below a threshold, b,
there is a risk (but not guaranteed) that the queue will go
empty, and we will lose link utilization. If we know the probability
that Q < b, then we have an upper bound on the lost
utilization. Because Q has a normal distribution, we can use
the error-function 6 to evaluate this probability. Therefore,
we get the following lower bound for the utilization.
1 A . (6)
Here are some numerical examples of utilization, using
10000.
Router Bu#er Size Utilization
Util # 99.99988 %
This means that we can achieve full utilization with bu#ers
that are the delay-bandwidth product divided by square-root
of the number of flows, or a small multiple thereof. As
the number of flows through a router increases, the amount
of required bu#er decreases.
This result has practical implications for building routers.
A core router currently has from 10,000 to over 100,000 flows
passing through it at any given time. While the vast majority
of flows are short (e.g. flows with fewer than 100
packets), the flow length distribution is heavy tailed and
the majority of packets at any given time belong to long
flows. As a result, such a router would achieve close to full
utilization with bu#er sizes that are only 1
1% of
the delay-bandwidth product. We will verify this result experimentally
in Section 5.2.
6 A more precise result could be obtained by using Cherno#
Bounds instead. We here present the Guassian approximation
for clarity of presentation.
4. SIZING THE ROUTER BUFFER FOR
Not all TCP flows are long-lived; in fact many flows last
only a few packets, never leave slow-start, and so never reach
their equilibrium sending rate [4]. Up until now we've only
considered long-lived TCP flows, and so now we'll consider
how short TCP flows a#ect the size of the router bu#er.
We're going to find that short flows (TCP and non-TCP)
have a much smaller e#ect than long-lived TCP flows, particularly
in a backbone router with a large number of flows.
We will define a short-lived flow to be a TCP flow that
never leaves slow-start (e.g. any flow with fewer than 90
packets, assuming a typical maximum window size of 65kB).
In Section 5.3 we will see that our results hold for short non-TCP
flows too (e.g. DNS queries, ICMP, etc.
Consider again the topology in Figure 2 with multiple
senders on separate access links. As has been widely reported
from measurement, we assume that new short flows
arrive according to a Poisson process [16, 17]. In slow-start,
each flow first sends out two packets, then four, eight, six-
teen, etc. This is the slow-start algorithm in which the
sender increases the window-size by one packet for each received
ACK. If the access links have lower bandwidth than
the bottleneck link, the bursts are spread out and a single
burst causes no queueing. We assume the worst case where
access links have infinite speed, bursts arrive intact at the
bottleneck router.
We will model bursts arriving from many di#erent short
flows at the bottleneck router. Some flows will be sending a
burst of two packets, while others might be sending a burst
of four, eight, or sixteen packets and so on. There will be a
distribution of burst-sizes; and if there is a very large number
of flows, we can consider each burst to be independent
of the other bursts, even of the other bursts in the same
flow. In this simplified model, the arrival process of bursts
themselves (as opposed to the arrival of flows) can be assumed
to be Poisson. One might argue that the arrivals are
not Poisson as a burst is followed by another burst one RTT
later. However under a low load and with many flows, the
bu#er will usually empty several times during one RTT and
is e#ectively "memoryless" at this time scale.
For instance, let's assume we have arrivals of flows of a
fixed length l. Because of the doubling of the burst lengths
in each iteration of slow-start, each flow will arrive in n
bursts of size
where R is the remainder,
1). Therefore,
the bursts arrive as a Poisson process, and their lengths
are i.i.d. random variables, equally distributed among
{2, 4, .2 n-1 , R}.
The router bu#er can now be modelled as a simple M/G/1
queue with a FIFO service discipline. In our case a "job" is
a burst of packets, and the job size is the number of packets
in a burst. The average number of jobs in an M/G/1 queue
is known to be (e.g. [18])
Here # is the load on the link (the ratio of the amount of
incoming tra#c to the link capacity C), and E[X] and E[X 2
are the first two moments of the burst size. This model will
overestimate the queue length because bursts are processed5152535450
Average
Queue
Length
Length of TCP Flow [pkts]
200 Mbit/s link
Model

Figure

10: The average queue length as a function
of the flow length for 0.8. The bandwidth has no
impact on the bu#er requirement. The upper bound
given by the M/G/1 model with infinite access link
speeds matches the simulation data closely.
packet-by-packet while in an M/G/1 queue the job is only
dequeued when the whole job has been processed. If the
queue is busy, it will overestimate the queue length by half
the average job size, and so
E[X]It is interesting to note that the average queue length is
independent of the number of flows and the bandwidth of
the link. It only depends on the load of the link and the
length of the flows.
We can validate our model by comparing it with simulations

Figure

shows a plot of the average queue length for
a fixed load and varying flow lengths, generated using ns2.
Graphs for three di#erent bottleneck link bandwidths (40, 80
and 200 Mb/s) are shown. The model predicts the relationship
very closely. Perhaps surprisingly, the average queue
length peaks when the probability of large bursts is highest,
not necessarily when the average burst size is highest. For
instance, flows of size 14 will generate a larger queue length
than flows of size 16. This is because a flow of 14 packets
generates bursts of X and the largest burst of
size 8 has a probability of 1
3 . A flow of 16 packets generates
bursts of sizes where the maximum burst
length of 8 has a probability of 1
4 . As the model predicts,
the bandwidth has no e#ect on queue length, and the measurements
for 40, 80 and 200 Mb/s are almost identical. The
gap between model and simulation is due to the fact that the
access links before the bottleneck link space out the packets
of each burst. Slower access links would produce an even
smaller average queue length.
To determine the bu#er size we need the probability distribution
of the queue length, not just its average. This is
more di#cult as no closed form result exists for a general
M/G/1 queue length distribution. Instead, we approximate
its tail using the e#ective bandwidth model [19], which tells
us that the queue length distribution is
# . E[X i
This equation is derived in Appendix C.
Our goal is to drop very few packets (if a short flow drops
a packet, the retransmission significantly increases the flow's
duration). In other words, we want to choose a bu#er size
B such that P (Q # B) is small.
A key observation is that - for short flows - the size of
the bu#er does not depend on the line-rate, the propagation
delay of the flows, or the number of flows; it only depends
on the load of the link, and length of the flows. Therefore, a
backbone router serving highly aggregated tra#c needs the
same amount of bu#ering to absorb short-lived flows as a
router serving only a few clients. Furthermore, because our
analysis doesn't depend on the dynamics of slow-start (only
on the burst-size distribution), it can be easily extended to
short unresponsive UDP flows.
In practice, bu#ers can be made even slower. For our
model and simulation we assumed access links that are faster
than the bottleneck link. There is evidence [4, 20] that
highly aggregated tra#c from slow access links in some cases
can lead to bursts being smoothed out completely. In this
case individual packet arrivals are close to Poisson, resulting
in even smaller bu#ers. The bu#er size can be easily
computed with an M/D/1 model by setting
In summary, short-lived flows require only small bu#ers.
When there is a mix of short- and long-lived flows, we will see
from simulations and experiments in the next section, that
the short-lived flows contribute very little to the bu#ering
requirements, and so the bu#er size will usually be determined
by the number of long-lived flows 7 .
5. SIMULATION AND EXPERIMENTAL
Up until now we've described only theoretical models of
long- and short-lived flows. We now present results to validate
our models. We use two validation methods: simulation
(using ns2), and a network of real Internet routers.
The simulations give us the most flexibility: they allow us to
explore a range of topologies, link speeds, numbers of flows
and tra#c mixes. On the other hand, the experimental net-work
allows us to compare our results against a network
of real Internet routers and TCP sources (rather than the
idealized ones in ns2). It is less flexible and has a limited
number of routers and topologies. Our results are limited to
the finite number of di#erent simulations and experiments
we can run, and we can't prove that the results extend to
any router in the Internet [21]. And so in Section 5.3 we
examine the scope and limitations of our results, and what
further validation steps are needed.
Our goal is to persuade a network operator to test our
results by reducing the size of their router bu#ers by approximately
99%, and checking that the utilization and drop
rates don't change noticeably. Until that time, we have to
rely on a more limited set of experiments.
5.1 NS2 Simulations
We ran over 15,000 ns2 simulations, each one simulating
several minutes of network tra#c through a router to verify
our model over a range of possible settings. We limit our
7 For a distribution of flows we define short flows and long
flows as flows that are in slow-start and congestion avoidance
mode respectively. This means that flows may transition
from short to long during their existence.5015025035050 100 150 200 250 300 350 400 450 500
Minimum
required
buffer
Number of long-lived flows
98.0% Utilization
99.5% Utilization
99.9% Utilization

Figure

11: Minimum required bu#er to achieve 98,
99.5 and 99.9 percent utilization for an OC3 (155
Mb/s) line with about 80ms average RTT measured
with ns2 for long-lived TCP flows.
simulations to cases where flows experience only one congested
link. Network operators usually run backbone links
at loads of 10%-30% and as a result packet drops are rare
in the Internet backbone. If a single point of congestion is
rare, then it is unlikely that a flow will encounter two or
more congestion points.
We assume that the router maintains a single FIFO queue,
and drops packets from the tail only when the queue is full
(i.e. the router does not use RED). Drop-tail is the most
widely deployed scheme today. We expect the results to
extend to RED, because our results rely on the desynchronization
of TCP flows - something that is more likely with
RED than with drop-tail. We used TCP Reno with a maximum
advertised window size of at least 10000 bytes, and a
1500 or 1000 byte MTU. The average propagation delay of
a TCP flow varied from 25ms to 300ms.
5.1.1 Simulation Results for Long-lived TCP Flows

Figure

11 simulates an OC3 (155Mb/s) line carrying long-lived
flows. The graph shows the minimum required
bu#er for a given utilization of the line, and compares it with
the bu#er size predicted by the model. For example, our
model predicts that for 98% utilization a bu#er of RTT-C
should be su#cient. When the number of long-lived flows
is small the flows are partially synchronized, and the result
doesn't hold. However - and as can be seen in the graph
- when the number of flows exceeds 250, the model holds
well. We found that in order to attain 99.9% utilization, we
needed bu#ers twice as big; just as the model predicts.
We found similar results to hold over a wide range of
settings whenever there are a large number of flows, there
is little or no synchronization, and the average congestion
window is above two. If the average congestion window
is smaller than two, flows encounter frequent timeouts and
more bu#ering is required [22].
In our simulations and experiments we looked at three
other commonly used performance metrics, to see their
e#ect on bu#er size:
Minimum
Required
Buffer
Length of TCP Flow [pkts]
200 Mbit/s link
M/G/1 Model p=0.01

Figure

12: The minimum required bu#er that increases
the Average Flow Completion Time (AFCT)
by not more than 12.5% vs infinite bu#ers for short
flow tra#c.
. Packet loss If we reduce bu#er size, we can expect
packet loss to increase. The loss rate of a TCP flow
is a function of the flow's window size and can be approximated
to
(see [22]). From Equation 1, we
know the sum of the window sizes is RTT -C +B. If
B is made very small, then the window size halves, increasing
loss by a factor of four. This is not necessarily
a problem. TCP uses loss as a useful signal to indicate
and TCP's loss rate is very low (one
packet per multiple round-trip times). More impor-
tantly, as we show below, flows complete sooner with
smaller bu#ers than with large bu#ers. One might argue
that other applications that do not use TCP are
adversely a#ected by loss (e.g. online gaming or media
streaming), however these applications are typically
even more sensitive to queueing delay.
. Goodput While 100% utilization is achievable, goodput
is always below 100% because of retransmissions.
With increased loss, goodput is reduced, but by a very
small amount, as long as we have bu#ers equal or
greater than RTT-C
. Fairness Small bu#ers reduce fairness among flows.
First, a smaller bu#er means all flows have a smaller
round-trip time, and their sending rate is higher. With
large bu#ers, all round-trip times increase and so the
relative di#erence of rates will decrease. While over-
bu#ering would increase fairness, it also increases flow
completion times for all flows. A second e#ect is that
timeouts are more likely with small bu#ers. We did
not investigate how timeouts a#ect fairness in detail,
however in our ns2 simulations it seemed to be only
minimally a#ected by bu#er size.
5.1.2 Short Flows
We will use the commonly used metric for short flows:
the flow completion time, defined as the time from when
the first packet is sent until the last packet reaches the des-
tination. In particular, we will measure the average flow
completion time (AFCT). We are interested in the tradeo#
between bu#er size and AFCT. In general, for a link with a50015000 50 100 150 200 250 300 350 400 450 500
Minimum
required
buffer
Number of long-lived flows
Minimum buffer for 95% utilization

Figure

13: Bu#er requirements for tra#c mix with
di#erent flow lengths, measured from a ns2 simulation

load # 1, the AFCT is minimized when we have infinite
bu#ers, because there will be no packet drops and therefore
no retransmissions.
We take as a benchmark the AFCT with infinite bu#ers,
then find the increase in AFCT as a function of bu#er size.
For example, Figure 12 shows the minimum required bu#er
so that the AFCT is increased by no more than 12.5%. Experimental
data is from ns2 experiments for 40, 80 and 200
Mb/s and a load of 0.8. Our model, with P (Q >
is plotted in the graph. The bound predicted by the M/G/1
model closely matches the simulation results.
The key result here is that the amount of bu#ering needed
does not depend on the number of flows, the bandwidth or
the round-trip time. It only depends on the load of the link
and the length of the bursts. For the same tra#c mix of only
short flows, a future generation 1 Tb/s core router needs the
same amount of bu#ering as a local 10 Mb/s router today.
5.1.3 Mixes of Short- and Long-Lived Flows
In practice, routers transport a mix of short and long
flows; the exact distribution of flow lengths varies from net-work
to network, and over time. This makes it impossible
to measure every possible scenario, and so we give a general
idea of how the flow mix influences the bu#er size. The
good news is that long flows dominate, and a bu#er size of
su#ce when we have a large number of
flows. Better still, we'll see that the AFCT for the short
flows is lower than if we used the usual rule-of-thumb.
In our experiments the short flows always slow-down the
long flows because of their more aggressive multiplicative
increase, causing the long flows to reduce their window-size.

Figures

13 and 14 show a mix of flows over a 400 Mb/s link.
The total bandwidth of all arriving short flows is about 80
Mb/s or 20% of the total capacity. The number of long flows
was varied from 1 to 500. During the time of the experiment,
these long flows attempted to take up all the bandwidth left
available by short flows. In practice, they never consumed
more than 80% of the bandwidth as the rest would be taken
by the more aggressive short flows.
As we expected, with a small number of flows, the flows
are partially synchronized. With more than 200 long-lived
flows, the synchronization has largely disappeared. The
Average
completion
time
for
apkt
flow
Number of long-lived flows
AFCT of a 14 packet flow (RTT*BW Buffers)
AFCT of a 14 packet flow (RTT*BW/sqrt(n) Buffers)

Figure

14: Average flow completion times with a
bu#er size of (RTT -C)/ # n, compared with a bu#er
size RTT - C.
graph shows that the long flows dominate the flow size.
If we want 95% utilization, then we need a bu#er close to
This means we can ignore the short flows
when sizing the bu#er. Of course, this doesn't tell us how the
short-lived flows are faring - they might be shutout by the
long flows, and have increased AFCT. But Figure 14 shows
that this is not the case. In this ns2 simulation, the average
flow completion time is much shorter with RTT - C/ # n
bu#ers than with RTT - C sized bu#ers. This is because
the queueing delay is lower. So by reducing the bu#er size,
we can still achieve the 100% utilization and decrease the
completion times for shorter flows.
5.1.4 Pareto Distributed Flow Lengths
Real network tra#c contains a broad range of flow lengths.
The flow length distribution is known to be heavy tailed
[4] and in our experiments we used Pareto distributions to
model it. As before, we define short flows to be those still
in slow start.
For Pareto distributed flows on a congested router (i.e.
# 1), the model holds and we can achieve close to 100%
throughput with bu#ers of a small multiple of (RTT -
C)/ # n. 9 For example in an ns2 simulation of a 155 Mb/s
line, -
RTT # 100ms) we measured 100-200 simultaneous
flows and achieved a utilization of 99% with a bu#er of only
packets.
It has been pointed out [23] that in a network with low la-
tency, fast access links and no limit on the TCP window size,
there would be very few concurrent flows. In such a network,
a single very heavy flow could hog all the bandwidth for a
short period of time and then terminate. But this is unlikely
in practice, unless an operator allows a single user to
saturate their network. And so long as backbone networks
are orders of magnitude faster than access networks, few
users will be able to saturate the backbone anyway. Even
if they could, TCP is not capable of utilizing a link quickly
8 Here n is the number of active long flows at any given time,
not the total number of flows.
9 The number of long flows n for sizing the bu#er was found
by measuring the number of flows in congestion avoidance
mode at each instant and visually selecting a robust minimum

due to its additive increase behavior above a certain window
size. Tra#c transported by high-speed routers on commercial
networks today [4, 24] has 10's of 1000's of concurrent
flows and we believe this is unlikely to change in the future.
An uncongested router (i.e. # 1) can be modeled using
the short-flow model presented in section 4 which often leads
to even lower bu#er requirements. Such small bu#ers may
penalize very long flows as they will be forced into congestion
avoidance early even though bandwidth is still available. If
we want to allow a single flow to take up to 1/n of the
bandwidth, we always need bu#ers of (RTT -C)/ # n, even
at a low link utilization.
We found that our general result holds for di#erent flow
length distributions if at least 10% of the tra#c is from long
flows. Otherwise, short flow e#ects sometimes dominate.
Measurements on commercial networks [4] suggest that over
90% of the tra#c is from long flows. It seems safe to assume
that long flows drive bu#er requirements in backbone
routers.
5.2 Measurements on a Physical Router
While simulation captures most characteristics or router-
TCP interaction, we verified our model by running experiments
on a real backbone router with tra#c generated by
real TCP sources.
The router was a Cisco GSR 12410 [25] with a 4 x OC3
POS"Engine 0" line card that switches IP packets using POS
(PPP over Sonet) at 155Mb/s. The router has both input
and output queues, although no input queueing took place
in our experiments, as the total throughput of the router
was far below the maximum capacity of the switching fabric.
TCP tra#c was generated using the Harpoon tra#c generator
[26] on Linux and BSD machines, and aggregated using
a second Cisco GSR 12410 router with Gigabit Ethernet line
cards. Utilization measurements were done using SNMP on
the receiving end, and compared to Netflow records [27].
Router Bu#er Link Utilization (%)
Flows RTT-BW
Pkts RAM Model Sim. Exp.
200

Figure

15: Comparison of our model, ns2 simulation
and experimental results for bu#er requirements of
a Cisco GSR 12410 OC3 linecard.
5.2.1 Long Flows

Figure

15 shows the results of measurements from the
GSR 12410 router. The router memory was adjusted by
limiting the length of the interface queue on the outgoing
interface. The bu#er size is given as a multiple of RTT-C
the number of packets and the size of the RAM device that
would be needed. We subtracted the size of the internal
FIFO on the line-card (see Section 5.2.2). Model is the lower-bound
on the utilization predicted by the model. Sim. and
Exp. are the utilization as measured by a simulation with
ns2 and on the physical router respectively. For 100 and 200
flows there is, as we expect, some synchronization. Above
that the model predicts the utilization correctly within the
measurement accuracy of about -0.1%. ns2 sometimes predicts
a lower utilization than we found in practice. We attribute
this to more synchronization between flows in the
simulations than in the real network.
The key result here is that model, simulation and experiment
all agree that a router bu#er should have a size equal
to approximately RTT-C
as opposed to RTT - C (which
in this case would be 1291 packets).0.011
Queue length [pkts]
FIFO
link underutilized
Exp. Cisco GSR if-queue
Exp. Cisco GSR buffers
Model M/G/1 PS
Model M/G/1 FIFO

Figure

Experimental, Simulation and Model
prediction of a router's queue occupancy for a Cisco
GSR 12410 router.
5.2.2 Short Flows
In Section 4 we used an M/G/1 model to predict the bu#er
size we would need for short-lived, bursty TCP flows. To
verify our model, we generated lots of short-lived flows and
measured the probability distribution of the queue length of
the GSR 12410 router. Figure 16 shows the results and the
comparison with the model, which match remarkably well. 10
5.3 Scope of our Results and Future Work
The results we present in this paper assume only a single
point of congestion on a flow's path. We don't believe our
results would change much if a percentage of the flows experienced
congestion on multiple links, however we have not
investigated this. A single point of congestion means there
10 The results match very closely if we assume the router
under-reports the queue length by 43 packets. We learned
from the manufacturer that the line-card has an undocumented
128kByte transmit FIFO. In our setup, 64 kBytes
are used to queue packets in an internal FIFO which, with
an MTU of 1500 bytes, accounts exactly for the 43 packet
di#erence.
is no reverse path congestion, which would likely have an
e#ect on TCP-bu#er interactions [28]. With these assump-
tions, our simplified network topology is fairly general. In
an arbitrary network, flows may pass through other routers
before and after the bottleneck link. However, as we assume
only a single point of congestion, no packet loss and little
tra#c shaping will occur on previous links in the network.
We focus on TCP as it is the main tra#c type on the
internet today. Constant rate UDP sources (e.g. online
games) or single packet sources with Poisson arrivals (e.g.
DNS) can be modelled using our short flow model and the
results for mixes of flows still hold. But to understand tra#c
composed mostly of non-TCP packets would require further
study.
Our model assumes there is no upper bound on the congestion
window. In reality, TCP implementations have maximum
window sizes as low as 6 packets [29]. Window sizes
above 64kByte require use of a scaling option [30] which
is rarely used. Our results still hold as flows with limited
window sizes require even smaller router bu#ers [1].
We did run some simulations using Random Early Detection
[12] and this had an e#ect on flow synchronization
for a small number of flows. Aggregates of a large number
(> 500) of flows with varying RTTs are not synchronized
and RED tends to have little or no e#ect on bu#er require-
ments. However early drop can slightly increase the required
bu#er since it uses bu#ers less e#ciently.
There was no visible impact of varying the latency other
than its direct e#ect of varying the bandwidth-delay product

Congestion can also be caused by denial of service (DOS)
[31] attacks that attempt to flood hosts or routers with large
amounts of network tra#c. Understanding how to make
routers robust against DOS attacks is beyond the scope of
this paper, however we did not find any direct benefit of
larger bu#ers for resistance to DOS attacks.
6. RELATED WORK
Villamizar and Song report the RTT - BW rule in [1],
in which the authors measure link utilization of a 40 Mb/s
network with 1, 4 and 8 long-lived TCP flows for di#erent
bu#er sizes. They find that for FIFO dropping discipline and
very large maximum advertised TCP congestion windows it
is necessary to have bu#ers of RTT-C to guarantee full link
utilization. We reproduced their results using ns2 and can
confirm them for the same setup. With such a small number
of flows, and large congestion windows, the flows are almost
fully synchronized and have the same bu#er requirement as
a single flow.
Morris [32] investigates bu#er requirements for up to 1500
long-lived flows over a link of 10 Mb/s with 25ms latency.
He concludes that the minimum amount of bu#ering needed
is a small multiple of the number of flows, and points out
that for a bandwidth-delay product of 217 packets, each flow
has only a fraction of a packet in transit at any time. Many
flows are in timeout, which adversely e#ects utilization and
fairness. We repeated the experiment in ns2 and obtained
similar results. However for a typical router used by a carrier
or ISP, this has limited implications. Users with fast
access links will need several packets outstanding to achieve
adequate performance. Users with very slow access links
(e.g. 32kb/s modem users or 9.6kb/s GSM mobile access)
need additional bu#ers in the network so they have su#cient
packets outstanding. However this additional bu#er should
be at the ends of the access link, e.g. the modem bank at the
local ISP, or GSM gateway of a cellular carrier. We believe
that overbu#ering the core router that serves di#erent users
would be the wrong approach, as overbu#ering increases latency
for everyone and is also di#cult to implement at high
line-rates. Instead the access devices that serve slow, last-mile
access links of under 1Mb/s should continue to include
a few packets worth of bu#ering for each link.
With line speeds increasing and the MTU size staying
constant, we would also assume this issue to become less
relevant in the future.
Avrachenkov et al [33] present a fixed point model for
utilization (for long flows) and flow completion times (for
short flows). They model short flows using an M/M/1/K
model that only accounts for flows but not for bursts. In
their long flow model they use an analytical model of TCP
that is a#ected by the bu#er through the RTT. As the model
requires fixed point iteration to calculate values for specific
settings and only one simulation result is given, we can not
directly compare their results with ours.
Garetto and Towsley [34] describe a model for queue
lengths in routers with a load below one that is similar to
our model in section 4. The key di#erence is that the authors
model bursts as batch arrivals in an M [k] /M/1 model
(as opposed to our model that models bursts by varying
the job length in a M/G/1 model). It accommodates both
slow-start and congestion avoidance mode, however it lacks
a closed form solution. In the end the authors obtain queue
distributions that are very similar to ours.
7. CONCLUSION
We believe that the bu#ers in backbone routers are much
larger than they need to be - possibly by two orders of
magnitude. If our results are right, they have consequences
for the design of backbone routers. While we have evidence
that bu#ers can be made smaller, we haven't tested the hypothesis
in a real operational network. It is a little di#cult
to persuade the operator of a functioning, profitable network
to take the risk and remove 99% of their bu#ers. But that
has to be the next step, and we see the results presented in
this paper as a first step towards persuading an operator to
try it.
If an operator verifies our results, or at least demonstrates
that much smaller bu#ers work fine, it still remains to persuade
the manufacturers of routers to build routers with
fewer bu#ers. In the short-term, this is di#cult too. In
a competitive market-place, it is not obvious that a router
vendor would feel comfortable building a router with 1% of
the bu#ers of its competitors. For historical reasons, the net-work
operator is likely to buy the router with larger bu#ers,
even if they are unnecessary.
Eventually, if routers continue to be built using the current
rule-of-thumb, it will become very di#cult to build linecards
from commercial memory chips. And so in the end, necessity
may force bu#ers to be smaller. At least, if our results are
true, we know the routers will continue to work just fine,
and the network utilization is unlikely to be a#ected.
8.

ACKNOWLEDGMENTS

The authors would like to thank Joel Sommers and Professor
Paul Barford from the University of Wisconsin-Madison
for setting up and running the measurements on a physical
router in their WAIL testbed; and Sally Floyd and Frank
Kelly for useful disucssions. Matthew Holliman's feedback
on long flows led to the central limit theorem argument.
9.



--R

High performance tcp in ansnet.
http://www.
RFC 3439: Some internet architectural guidelines and philosophy
Provisioning Internet Backbone Networks to Support Latency Sensitive Applications.

Dynamics of tcp/red and a scalable control.
Analysis of a memory architecture for fast packet bu

Some observations on the dynamics of a congestion control algorithm.
The network simulator - ns-2

Random early detection gateways for congestion avoidance.
Oscillating behaviour of network tra
Understanding the performance of many tcp flows.
Aggregate tra
area tra
Data networks as cascades: Investigating the multifractal nature of internet WAN tra

Notes on E
Internet tra

Scalable tcp congestion control.

Personal communication with stanford networking on characteristics of residential tra
Cisco 12000 series routers.


Observations on the dynamics of a congestion control algorithm: The e

RFC 1213: Management information base for network management of TCP/IP-based internets:MIB-II
A framework for classifying denial of service attacks.
Tcp behavior with many flows.

Modeling, simulation and measurements of queueing delay under long-tail internet tra#c
Illustrated
--TR
Observations on the dynamics of a congestion control algorithm
Random early detection gateways for congestion avoidance
High performance TCP in ANSNET
area traffic
Data networks as cascades
Some observations on the dynamics of a congestion control algorithm
Statistical bandwidth sharing
Difficulties in simulating the internet
Aggregate traffic performance with active queue management and drop from tail
Understanding the performance of many TCP flows
Modeling, simulation and measurements of queuing delay under long-tail internet traffic
behavior with many flows
Provisioning internet backbone networks to support latency sensitive applications

--CTR
Gaurav Raina , Oliver Heckmann, TCP: Local stability and Hopf bifurcation, Performance Evaluation, v.64 n.3, p.266-275, March, 2007
Amogh Dhamdhere , Constantine Dovrolis, Open issues in router buffer sizing, ACM SIGCOMM Computer Communication Review, v.36 n.1, January 2006
Performance analysis of timer-based burst assembly with slotted scheduling for optical burst switching networks, Performance Evaluation, v.63 n.9, p.1016-1031, October 2006
Robert N. Shorten , Douglas J. Leith, On queue provisioning, network efficiency and the transmission control protocol, IEEE/ACM Transactions on Networking (TON), v.15 n.4, p.866-877, August 2007
Mahmoud Elhaddad , Rami Melhem , Taieb Znati, Analysis of a transmission scheduling algorithm for supporting bandwidth guarantees in bufferless networks, ACM SIGMETRICS Performance Evaluation Review, v.34 n.3, p.48-63, December 2006
Yee-Ting Li , Douglas Leith , Robert N. Shorten, Experimental evaluation of TCP protocols for high-speed networks, IEEE/ACM Transactions on Networking (TON), v.15 n.5, p.1109-1122, October 2007
Damon Wischik , Nick McKeown, Part I: buffer sizes for core routers, ACM SIGCOMM Computer Communication Review, v.35 n.3, July 2005
G. Vu-Brugier , R. S. Stanojevic , D. J. Leith , R. N. Shorten, A critique of recently proposed buffer-sizing strategies, ACM SIGCOMM Computer Communication Review, v.37 n.1, January 2007
Sangtae Ha , Long Le , Injong Rhee , Lisong Xu, Impact of background traffic on performance of high-speed TCP variant protocols, Computer Networks: The International Journal of Computer and Telecommunications Networking, v.51 n.7, p.1748-1762, May, 2007
Do Young Eun , Xinbing Wang, Performance analysis of TCP/AQM with generalized AIMD under intermediate buffer sizes, Computer Networks: The International Journal of Computer and Telecommunications Networking, v.51 n.12, p.3655-3671, August, 2007
George Varghese , J. Andrew Fingerhut , Flavio Bonomi, Detecting evasion attacks at high speeds without reassembly, ACM SIGCOMM Computer Communication Review, v.36 n.4, October 2006
Yashar Ganjali , Nick McKeown, Update on buffer sizing in internet routers, ACM SIGCOMM Computer Communication Review, v.36 n.5, October 2006
Mihaela Enachescu , Yashar Ganjali , Ashish Goel , Nick McKeown , Tim Roughgarden, Part III: routers with very small buffers, ACM SIGCOMM Computer Communication Review, v.35 n.3, July 2005
Joel Sommers , Paul Barford , Nick Duffield , Amos Ron, Improving accuracy in end-to-end packet loss measurement, ACM SIGCOMM Computer Communication Review, v.35 n.4, October 2005
Aleksandar Kuzmanovic, The power of explicit congestion notification, ACM SIGCOMM Computer Communication Review, v.35 n.4, October 2005
Zhenyun Zhuang , Tae-Young Chang , Raghupathy Sivakumar , Aravind Velayutham, A 3: application-aware acceleration for wireless data networks, Proceedings of the 12th annual international conference on Mobile computing and networking, September 23-29, 2006, Los Angeles, CA, USA
Elvis Vieira , Michael Bauer, Proactively controlling round-trip time variation and packet drops using SmoothTCP-q, Proceedings of the 3rd international conference on Quality of service in heterogeneous wired/wireless networks, August 07-09, 2006, Waterloo, Ontario, Canada
Allen B. Downey, TCP self-clocking and bandwidth sharing, Computer Networks: The International Journal of Computer and Telecommunications Networking, v.51 n.13, p.3844-3863, September, 2007
Joel Sommers , Paul Barford , Nick Duffield , Amos Ron, A geometric approach to improving active packet loss measurement, IEEE/ACM Transactions on Networking (TON), v.16 n.2, p.307-320, April 2008
A. Kortebi , L. Muscariello , S. Oueslati , J. Roberts, Evaluating the number of active flows in a scheduler realizing fair statistical bandwidth sharing, ACM SIGMETRICS Performance Evaluation Review, v.33 n.1, June 2005
Sumitha Bhandarkar , Saurabh Jain , A. L. Narasimha Reddy, LTCP: improving the performance of TCP in highspeed networks, ACM SIGCOMM Computer Communication Review, v.36 n.1, January 2006
buffer size;internet router;TCP;bandwidth delay product