A survey of TCP-friendly router-based AQM schemes

Short Survey

A survey of TCP-friendly router-based AQM schemes

Gwyn Chatranona, Miguel A. Labradorb,*, Sujata Banerjeec

aDepartment of Information Science and Telecommunications, University of Pittsburgh, Pittsburgh, PA 15260, USAbDepartment of Computer Science and Engineering, University of South Florida, Tampa, FL 33620, USA

cHewlett-Packard Laboratories, Palo Alto, CA 94304, USA

Received 26 December 2003; revised 9 April 2004; accepted 5 May 2004

Available online 28 May 2004

Abstract

Although the majority of the traffic over the Internet is still TCP-based, applications such as voice over IP and video-conferencing are

changing this very rapidly. While TCP-based applications react to network congestion, UDP-based streaming applications usually do not

have any type of flow and congestion control mechanisms. UDP, the transport layer protocol used by audio and video streaming

applications, does not react to network congestion thus stealing bandwidth from the responsive TCP-based connections. Several solutions

have been suggested to combat this TCP-friendliness problem, mostly applied either in the end systems (end-to-end) at the transport layer

of the protocol stack or inside the network (routers) at the network layer. This article surveys the state-of-the-art in router-based

mechanisms to address the TCP-friendliness problem and presents a description of the most important algorithms, design issues,

advantages and disadvantages, and a performance evaluation. The article also describes ways to estimate the number of active flows

traversing a core router and points to further sources on this subject, which is widely used by many mechanisms, including several

described in this survey.

q 2004 Elsevier B.V. All rights reserved.

Keywords: Fairness; Active queue management; TCP-friendly; Congestion control

1. Introduction

The majority of the traffic in the Internet today is carried

by the Transmission Control Protocol (TCP). TCP is the

protocol of choice for the widely used World Wide Web

(HTTP), file transfer (FTP), TELNET, and email (SMTP)

applications, because it provides a reliable transmission

service. In practice, TCP has been widely deployed because

of its Congestion Avoidance algorithm, introduced by

Jacobson [1]. This mechanism helps a traffic source to

determine how much bandwidth is available in the network

and adjust its transmission rate accordingly. The basic idea

of this approach is to have the source gradually increase its

transmission rate until the available bandwidth is consumed,

and reduce its transmission rate when congestion is

detected. TCP uses a congestion window to regulate its

transmission rate and normally increases this window in a

linear manner but decreases it in a multiplicative manner to

quickly alleviate network congestion. This flow and

congestion control strategy, referred to as Additive

Increase/Multiplicative Decrease (AIMD), keeps the net-

work from being overloaded and has become a crucial factor

in the robustness and stability of the Internet.

Lately, different types of applications, especially multi-

media and audio/video streaming applications, are being

increasingly deployed over the Internet. Such applications

utilize the User Datagram Protocol (UDP) instead, which

does not employ end-to-end flow and congestion control.

Rather, the sending rate is set by the application and

normally no or little consideration of network congestion is

taken into account during the transmission. The lack of

end-to-end flow and congestion control from these

applications could result in two major problems already

identified in the Internet: unfairness and congestion

collapse [2].

The problem of congestion collapse occurs when senders

with no end-to-end flow and congestion control keep

transmitting packets even though they will be discarded

downstream, e.g. by a bottleneck link, before reaching their

final destinations [2]. This could become a major problem as

Computer Communications 27 (2004) 1424–1440

www.elsevier.com/locate/comcom

0140-3664/$ - see front matter q 2004 Elsevier B.V. All rights reserved.

doi:10.1016/j.comcom.2004.05.001

* Corresponding author. Tel.: þ1-813-974-3260; fax: þ1-813-974-5456.

E-mail addresses: [email protected] (M.A. Labrador), gwync@

mail.sis.pitt.edu (G. Chatranon), [email protected] (S. Banerjee).

http://www.elsevier.com/locate/comcom

a large amount of bandwidth can be wasted by these

undelivered packets. In a worst-case scenario, some

applications may even increase their transmission rates in

response to a higher packet drop rate, which would severely

worsen the situation. Currently, without the cooperation of

traffic sources and routers with an appropriate rate-

adaptation mechanism, there is yet no effective way to

regulate the unresponsive flows from causing this problem

in the current Internet [3]. Furthermore, per-flow scheduling

mechanisms, that were initially thought to be the solution to

the congestion collapse problem, have been shown to fail

under fairly common scenarios [2].

The problem of unfairness occurs when traffic sources

with no end-to-end flow and congestion control, e.g. UDP

sources, unfairly consume a larger amount of the bottleneck

bandwidth than competing well-behaved responsive

sources, such as TCP sources. During congestion, TCP

sources back off their transmission rates according to the

AIMD strategy, leaving a new portion of available

bandwidth for the non-congestion-controlled traffic. Under

persistent congestion, this situation continues and at some

point, unresponsive flows can actually consume the entire

channel capacity, if needed. Although some streaming

media applications deploy some level of responsive

mechanisms to handle network congestion, they are still

much more aggressive than TCP sources, and the unfairness

problem still occurs. The unfairness problem is being

addressed using router-based and end-system-based sol-

utions. These are solutions that are implemented either in

routers or in the end systems. In this article, we survey the

state-of-the-art in router-based approaches, providing a

comprehensive explanation, comparison and analysis of the

most important algorithms that can be used to address the

unfairness problem.

The rest of the article is organized as follows. Section 2

introduces basic concepts about TCP and presents an

important formula commonly used in both router-based

and end-system-based solutions. In Section 3, our motiv-

ation for focusing on router-based approaches is included

along with the description and evaluation of the most

important mechanisms. These mechanisms are compared in

Section 4. A brief explanation and evaluation of several

ways to estimate the number of actives flows utilized by

some of these mechanisms is also included at the end of

Section 4. Finally, a summary of this article is provided in

Section 5.

2. TCP flow and congestion control fundamentals

Transmission Control Protocol (TCP), the de-facto

standard transport layer protocol, is designed to provide a

reliable, in-order, connection-oriented communication

between a pair of hosts over diverse reliable and unreliable

internetworks. The TCP flow and congestion control

mechanisms are designed to determine the capacity

available in the network and vary its transmission rate

accordingly. The sender maintains a congestion window

(cwnd) state variable, which represents the amount of data

that can be transmitted at a given time according to the

congestion in the network. The maximum window size,

indicating the maximum number of bytes that can be sent at

any given time, is then set to be the minimum between the

congestion window and the advertised window, which

reflects the capacity of the receiver.

Initially, since there is no direct way for the TCP

source to have any knowledge about the congestion level

in the network, the sender slowly probes the network by

setting the congestion window to one segment and

exponentially increasing the window size until either a

timeout occurs, the advertised window is reached, or the

Slow Start threshold (setthresh) is reached. This phase is

referred to as the Slow Start phase, where the TCP

source doubles the congestion window size every round

trip time (RTT). Once the setthresh is reached, TCP

enters the Congestion Avoidance phase, where the sender

increases its congestion window by 1/(current congestion

window) for each received acknowledgment (ACK)

packet. If congestion occurs, which is detected by a

time out (ACK for a packet sent never received or

received too late), a source sets the Slow Start threshold

to half the value of the current congestion window, sets

the congestion window to 1, and begins the Slow Start

phase again. To date, there are several well-known

variants of TCP, such as Tahoe, Reno [4,5], Newreno

[6], Sack [7] and Vegas [8] versions, among the most

important ones. However, these variants still preserve the

following two fundamental components of their conges-

tion control mechanism [9]:

(1) The TCP source uses a packet drop as an indication

of congestion inside the network, and responds by

decreasing the congestion window at least by half.

This congestion window reduction is meant to

reduce the effective sending rate in order to relieve

the congestion.

(2) In the congestion avoidance phase, or linear phase,

the TCP sender increases the congestion window by

at most one packet per round trip time.

Some TCP variants may be more responsive in reacting

to congestion and less aggressive than others in obtaining a

bigger share of the available bandwidth. For example, the

TCP Tahoe version decreases the congestion window down

to one, instead of decreasing it to half the current value.

Some TCP implementations may send an ACK packet for

every two data packets, increasing the congestion window

by less than one packet per round trip time during the

congestion avoidance phase. Nonetheless, these two com-

ponents usually give us an upper bound on the sending rate

of TCP.

G. Chatranon et al. / Computer Communications 27 (2004) 1424–1440 1425

Several TCP models have been proposed to explain

TCP’s flow and congestion control mechanisms [9–13].

The simplest one is The Stationary Behavior of Ideal TCP

Congestion Avoidance [9] which has been used as a

fundamental concept in several mechanisms that aim to

solve the unfairness problem. In this model, a number of

simplified assumptions are made, such as

† Only a single packet is dropped when the congestion

window reaches W packets.

† Uniform (non-bursty) average packet drop rate of p:

† TCP segments of size B bytes.

† TCP runs over a path with sufficient bandwidth and a

fairly constant round trip time of RTT seconds.

† The sender always has data to transmit and the receiver

has infinite buffers.

† The details of TCP data recovery and retransmission are

neglected.

Under these assumptions the congestion window goes

through a periodic saw-tooth shape as shown in Fig. 1.

From the figure, once the congestion window reaches W

packets, it is cut back by the sender to half, or W=2: If the

receiver acknowledges every segment, the congestion

window increases by one packet per round trip, therefore

each cycle of the saw-tooth shape equals to W=2 round trips,

or RTTðW=2Þ s. The total data delivered are the area under

the saw tooth which is equal to ðW=2Þ2 þ 1=2ðW=2Þ2 ¼

ð3=8ÞW2 packets per cycle. An alternative way to calculate

this number is by observing that, in each cycle the

congestion window starts at W=2 and increases by at most

one per round trip time until it reaches W : Therefore, the

sender transmits at least W=2 þ ððW=2Þ þ 1Þ þ ððW=2Þ þ

2Þ þ · · · þ W < ð3=8ÞW2 packets per cycle. Hence, the

fraction p of the packets that are dropped is then bounded

by p # ð8=3W2Þ, which yields

W #

ffiffiffiffiffi8

3p

s: ð1Þ

As Eq. (1) provides an upper bound on the congestion

window W of a TCP connection when single packets are

dropped, the maximum throughput over a single cycle of

the steady-state model is then given as below

T ¼Data per cycle

Time per cycle¼

B3

8W2

RTTW

2

¼B=p

RTT

ffiffiffiffi2

3p

s ¼1:5

ffiffiffiffi2=3

pB

RTTffiffip

p :

ð2Þ

In Ref. [10], the authors use stochastic analysis for a more

precise model of TCP congestion control behavior in steady

state, which includes the effect of timeouts and retransmis-

sions as shown below.

T <minWmax

RTT;

1

RTT

ffiffiffiffiffiffi2Bp

3

rþT0min 1;3

ffiffiffiffiffiffi3Bp

8

r !pð1þ32p2Þ

0BBBB@

1CCCCA:

ð3Þ

In this case, T0 is a retransmission timeout, and Wmax is the

maximum congestion window when it is limited by the buffer

size at the receiver.

In the case of a TCP connection with delayed acknowl-

edgments, i.e. the receiver sends only one ACK for every two

received packets, the sender will increase its congestion

window more slowly. This is because the sender uses an ACK

as a trigger to increase its window, then for a delayed-ACK

the sender receives ACK packets at a slower rate, which

results in a slower congestion window increasing rate. In this

case, the fraction p of the sender’s packet drop rate is then

p ¼1XW

i¼0

ðW=2 þ i=2Þ

<1

ð3=4ÞW2: ð4Þ

With the same method to get the throughput equation from

Eq. (4), the upper bound on the arrival rate when the receiver

uses delayed-ACK is

T ¼1:5

ffiffiffiffi1=3

pB

RTTffiffip

p : ð5Þ

The importance of these models is that they provide a way to

calculate the theoretical throughput of a TCP connection

under these particular assumptions and compare it against the

actual measured throughput of a specific flow to draw

conclusions about its friendliness to TCP. These formulas

therefore, have been used in the design of TCP-friendly

protocols for streaming media applications [14,15], and

router-based mechanisms that provide fairness between TCP

and non-TCP traffic.

3. Router-based solutions

During the last several years, a number of mechanisms

have been proposed to solve the problem of unfairness.

Some of them are aimed at solving the problem from insideFig. 1. TCP congestion window behavior in steady state of a simplified

model.

G. Chatranon et al. / Computer Communications 27 (2004) 1424–14401426

the network, and some of them are focusing on developing a

responsive or a TCP-congestion-control-compatible proto-

col to be employed at traffic sources and destinations. These

mechanisms can be classified in different possible ways.

In this article, we classify the algorithms based on the

implementation placement as either router-based or end-

system-based.

A router-based algorithm is deployed inside the network,

i.e. in the routers, to regulate the flows causing the

unfairness problem. Some schemes may also introduce a

level of punishment on these flows to provide an incentive

for a protocol implementer to deploy end-to-end congestion

control mechanisms, which is a crucial factor to solve the

congestion collapse problem. End-system-based mechan-

isms are aimed at defining an end-to-end flow and

congestion control mechanism to be implemented at the

end systems. If the protocol is designed to be compatible

with TCP, it is called a TCP-friendly protocol. Although

both of these approaches are important, we consider that

router-based solutions are more appropriate, at least from

the unfairness problem point of view, since we do not leave

it up to the end user to decide to whether use flow and

congestion control or not. We do believe that to solve the

unfairness and congestion collapse problems simul-

taneously, both approaches might be necessary. However,

the focus of this article is the unfairness problem.

Many different protocols and algorithms have been

proposed so far. As part of end-system-based solutions

several TCP-friendly protocols have been proposed using

Eqs. (2) or (3) to adjust the sender’s transmission rate or

using other strategies to increase or decrease the congestion

window of TCP. Rate-based examples of TCP-friendly

transport layer protocols are TCP-Friendly Rate Control

Protocol (TFRC) [15], Rate Adaptation Protocol (RAP)

[16], Loss-Delay Based Adaptation Algorithm (LDA) [17],

and TCP Emulation At Receivers (TEAR) [18] among the

most important ones. The main goal of them is to transmit

data in a smoother manner so users from streaming

applications perceive a better quality than using TCP

while being TCP friendly. Window-based TCP-friendly

end-to-end protocols have also been devised, such as the

family of Binomial algorithms, like Inverse-Increase/

Additive-Decrease (IIAD) and SQRT [19], and the General

Additive Increase Multiplicative Decrease (GAIMD) [20]

algorithm that generalizes the same TCP protocol using

different values for the parameters a and b that define the

increase and decrease strategy.1 These end-to-end solutions

will not be further described in this article. For a detailed

description of these schemes the reader is directed to the

references cited and survey papers that already exist on the

topic, such as in Ref. [21].

Router-based solutions are the main focus of this survey.

In Sections 3.1 and 3.2 we will explain the main issues to

consider when designing such algorithms and describe the

most important proposed schemes. In particular, we will

include the TCP Model-based Identification Scheme [2],

Longest Queue Drop (LQD) [22], Fair Random Early

Detection (FRED) [23], Balanced RED (BRED) [24],

Stabilized RED (SRED) [25], CHOose and Keep for

responsive flows (CHOKe) [26], Stochastic Fair Blue

(SFB) [27], BLACKlisting unresponsive flows (BLACK)

[28], and Capture–REcapture (CARE) [29]. Then, in

Section 4, we include a thorough evaluation of the most

important ones.

3.1. Main design issues and goals

One of the most important objectives of a router-based

scheme is its ability to achieve fairness among competing

flows, particularly in the case where unresponsive high-

bandwidth best-effort flows share the bottleneck link. For

instance, this can be done by identifying those flows and

applying some sort of preferential dropping policy or similar

buffer management scheme, or a unique technique of its

own, as will be shown in Section 3.2. Some schemes also

restrict or punish identified unresponsive flows that

consume more bandwidth than their fair share, certainly at

the time of congestion, or even during light loads as a mean

of promoting the use of end-to-end congestion control

mechanisms. From this discussion, it can be inferred that

two important issues are the identification of unresponsive

flows and the calculation of the fairshare. A router has to

accurately identify which flows should be regulated so that

it does not accidentally punish well-behaved flows, and

once identified, the flows should be penalized fairly. These

and other important issues to consider in the design of a

router-based mechanism are explained next.

† Ability to identify and regulate unresponsive flows.

Identification of the unresponsive flows may or may

not be necessary to solve the unfairness problem.

Nonetheless, the ability to identify the traffic that is

harmful to the other traffic provides extra flexibility and

usually better results than otherwise. For example, one

may want to punish unresponsive traffic intensely to

provide an incentive to use a well-behaved end-to-end

congestion control, and not punishing well-behaved

flows at all. As another example, one may want to

place the flows in a lower priority queue, and put a rate

limitation or use any other restriction method, so that

they can co-exist well with good-behaved flows. Flow

identification is not for free though and care must be

taken to make the scheme simple and scalable.

† Fairness. Although achieving fairness is desirable for all

of the schemes of this kind, the meaning of fairness need

not be as strict and complex as that of a fair scheduling

mechanism. Since flows with no end-to-end congestion

control could gain more bandwidth and might even

completely shut down all responsive flows on the link,

1 For TCP, a ¼ 1 (additive increase) and b ¼ 0:5 (multiplicative

decrease).


putting some regulation or preferential dropping on this

type of flows may be enough to reduce the effect of this

problem. This could be done without using any complex

scheduling algorithm. In other words, we need to solve

the problem and be as fair as possible but we can also

relax the degree of fairness, allowing unresponsive flows

that need more bandwidth to obtain the resources they

need, or close to, as long as they are not harmful to

other flows.

† Need to estimate the number of active flows. Several

schemes need to have an accurate estimation of the

number of active flows traversing the router, without a

large amount of memory space required, in order to

calculate the fair share and achieve other goals. This is an

important area of active research very related to router-

based schemes. In Section 4.6 we provide a brief

overview of the most important mechanisms to estimate

the number of active flows along with an evaluation.

† Simplicity of operation. One approach to solve the

unfairness problem is to use per-flow scheduling

mechanisms that separately regulate the bandwidth of

each flow as stated in Ref. [30]. However, as demon-

strated through a series of simulations in Ref. [2],

although this mechanism may be able to alleviate the

problem of unfairness, the congestion collapse problem

can still occur regardless of the scheduling type. Per-flow

scheduling also introduces a high cost in terms of state

information and complexity in order to achieve fairness.

As opposed to a computationally complex scheme, a

simple, yet effective mechanism becomes one of the

most important goals in a router-based approach. This is

one of the main reasons why most schemes still use First-

Come First-Serve (FCFS) as the scheduling discipline.

† Scalability. Scalability is another important issue. Since

these schemes are part of the packet forwarding process

and core routers handle thousands or even millions of

flows, the mechanisms must scale well. For instance, the

complexity of the algorithm and the use of router

resources should not be proportional to the number of

flows. Simplicity and scalability are related and are both

very important issues to consider in order to implement

the algorithms in practice.

3.2. Description of the most important schemes

Router-based AQM schemes can be categorized into

schemes that need full per-flow state information and

schemes that do not need per-flow state information or

require only partial state information. At the same time, the

schemes that need no per-flow state information can be

further divided in two groups depending on whether they

need to estimate the number of active flows or not. A

diagram showing this classification is presented in Fig. 2. In

this work we focus our attention on the mechanisms that

don’t need full state information mainly for scalability

reasons. Even though the state-full schemes usually have

less computational complexity than fair scheduling mech-

anisms, they still have a high space complexity. As a result,

these mechanisms have rarely been implemented in practice

in a high speed or backbone router.

The rest of this section provides a description of each of

these AQM schemes and Table 1 summarizes a qualitative

comparison according to the main design issues discussed in

the previous section. Then, in Section 4, we include a

performance evaluation of the schemes that do not require

complete state information along with a short evaluation of

the most important methods utilized to estimate the number

of active flows.

3.2.1. TCP model-based identification scheme

The paper ‘Promoting the Use of End-to-End Congestion

Control in the Internet’ [2] is well-known for its extensive

demonstration of the danger of unfairness and congestion

collapse. A router-based solution is proposed to identify

unresponsive flows and punish them by limiting their rates or

putting them in a low priority class of queue. Unresponsive

flows are identified comparing the flow’s arrival rate with

the throughput ðTÞ obtained from the Eq. (6), which

Fig. 2. Classification of router-based solutions.


represents an approximation of the throughput that a TCP

connection would have received under the same circum-

stances as the flow under consideration.

T #1:5

ffiffiffiffi2=3

pB

RTTffiffip

p : ð6Þ

This equation is derived from a simple TCP model that

captures the behavior of the TCP congestion window in

steady state as shown in Fig. 1 [9]. The variable W in the

picture represents the size of the congestion window when a

packet is dropped with probability p: Note that in order to

determine the TCP throughput from this equation, the flow’s

round-trip time ðRTTÞ; packet size ðBÞ; as well as the

flow’s dropping probability ðpÞ should be known. If the

flow’s arrival rate, as estimated from RED’s packet drop

history, is greater than that obtained from the equation, it is

identified as an unresponsive flow and should be punished

by putting it into another class of queue. In this case, the

authors suggest Class Based Queue (CBQ) as a method to

partition the buffer space into a queue for responsive traffic

and a queue for unresponsive traffic. The flow’s rate

restriction is then removed once the flow’s arrival rate

decrease to less than 1:22B=ðRTTffiffip

pÞ for a new packet drop

probability p:

This mechanism is quite simple and can identify

unresponsive flows if the router knows the value of the

required parameters. However, there is no easy way for the

router to determine the flow’s round-trip time and hence, it

is unlikely that it will calculate the bandwidth from the

equation precisely. This may lead to mis-identification of

unresponsive flows in several circumstances. In addition, it

also needs an extra mechanism such as CBQ to take care of

identified unresponsive flows.

3.2.2. Longest queue drop (LQD)

In Ref. [22], a buffer management scheme to solve to

unfairness problem is proposed. The basic concept of LQD

is that the flow with the largest number of packets waiting in

the queue should be the first to be penalized. With this

scheme, the buffer space is partitioned so that each flow has

the same normalized buffer to achieve fair sharing of

bandwidth. If the size of the entire buffer is denoted as B;

each connection i has a nominal buffer allocation bi; which

can be thought of as connection i‘s guaranteed buffer size.

Initially, we can set bi to B=n for all i; where n is the number

of backlogged connections. When a connection i needs

more than bi buffers, two scenarios are possible. First, if the

global buffer occupancy is less than B; the connection i is

allocated space from the available buffer space, given that

the new global buffer occupancy does not exceed B: Second,

if the global buffer occupancy at that time is equal to B; and

connection i has a current occupancy qi that is less than bi;

then LQD makes room for the incoming packet by dropping

the front packet from a connection whose current occupancy

exceeds its allocation. The packets chosen are dropped from

the front because this triggers TCP’s fast retransmit/

recovery mechanisms faster, helping TCP in increasing its

throughput [31]. Three methods are proposed for choosing

the connection to drop the packet from:

(1) Longest queue drop (LQD). This option picks the

connection that obtains a higher share of the bandwidth

unused by other connections. This can be done by

choosing the connection j with the largest value of

ðqj 2 bjÞ over all connections. This method also helps

the router with some level of isolation and protection

since if there is only one misbehaving flow, only this

flow should experience a higher loss rate.

(2) Dynamic soft partitioning with random drop (RND).

This option selects a connection to be pushed-out at

random from amongst the connections for whom

qj . bj: The goal of this scheme is to reduce the amount

of bursty loss, as some TCP versions, e.g. TCP Reno, are

known to behave badly in presence of bursty losses.

Table 1

Queue management schemes comparison

Schemes Holds

per-flow

information

Estimates

number of

active flows

Explicitly

identifies

unresponsive flows

Penalizes

unresponsive

flows

Removes penalty

if the flow

becomes responsive

Early

congestion

notification

Factors of mis-identification

TCP model-based [2]

identification scheme

No No Yes Yes Yes N/A Unknown parameters

especially flow’s RTTs.

Very simplified TCP model

LQD [22] Yes Yes No Yes Yes No N/A

FRED [23] Yes No No Yes Yes Yes N/A

BRED [24] Yes No No Yes Yes Yes N/A

SRED [25] No Yes Yes No N/A Yes Its probabilistic mechanism

CHOKe [26] No No No Yes Yes Yes N/A

SFB [27] No No Yes Yes Yes Yes Size of bins and

number of flows

BLACK [28] No Yes Yes Yes Yes Yes Estimation of number

of flows

CARE [29] No Yes Yes Yes Yes No Large amount of

memory for CR model


(3) Approximated longest queue drop (ALQD). One draw-

back of LQD method is that it requires a searching

operation through the backlogged queues in order to

determine which connection has the longest queue.

ALQD improves this issue by having a register holding

the length and identity of the longest queue.

It has been shown through simulations that LQD works

quite well for flow isolation even with TCP flows with

different round trip delays. The drawback of this scheme is

that a router needs to keep state information for every

backlogged flow, otherwise a searching procedure through

the entire buffer space is needed every time a push-out

decision is to be made. Although the ALQD method was

designed to reduce this cost, it may lead to bursty losses since

it tends to drop only the packets from the flow with the

longest queue. In addition, LQD drops packets only when the

global buffer is full. This results in a lack of early congestion

notification which is a prominent feature of active queue

management schemes such as RED and its derivations.

3.2.3. Fair random early detection (FRED)

Fair Random Early Detection (FRED)[23] is a modified

version of RED meant to solve the unfairness problem.

Basically, FRED works in the same way as the very well-

known RED scheme [32] but with the following additions.

Two global parameters, minq and maxq; are added for the

minimum and maximum number of packets that each flow

allowed to queue at the router. For each active flow, two

pieces of information need to be maintained—the number of

packets buffered (qlen) and the number of times the flow has

failed to respond to congestion notification (strike). Lastly,

FRED introduces an average per-flow queue size, avgcq, as

a global variable is.

FRED uses minq to protect low-speed flows guaranteeing

them a minimum buffer space. Arriving packets are always

buffered if the connection has fewer number of packets

(qlen) than minq; and the average buffer size is less than

maxth: In order to manage unresponsive flows, FRED

enforces per-flow queueing limits. This could be done by

keeping a flow buffer occupancy at maximal maxq; and

counting the number of times each flow tries to go beyond

maxq in the per-flow strike variable. The number of buffered

packets from flows with high values of strike are not

allowed to be more than the average per-flow queue size

avgcq; thus preventing unresponsive flows from consist-

ently dominating the buffer space.

Overall, FRED can achieve fairness in several situations,

with minimal modifications to RED. However, the main

drawback of FRED is the amount of per-flow state

information that needs to be maintained, limiting its

scalability.

3.2.4. Balanced-RED (BRED)

The fundamental idea of Balanced-RED or BRED [24] is

to provide fairness having a RED-like mechanism that acts

upon each active flow passing through the router. BRED

maintains qleni as the number of packets of each active flow

i inside the global buffer of size B; and Nactive as the

number of total active flows. Three thresholds are set on the

size of each qleni in order to perform their own dropping

policy as follows:

(1) t1; minimum number of packets that a flow is allowed

to have in the buffer before its packets start being

dropped with a probability p1:

(2) t2; number of packets that a flow is allowed to have in

the buffer before its packets start being dropped with a

probability p2; where p2 . p1:

(3) Wm; the maximum number of packets that the flow

is allowed to have in the buffer.

Then for each arriving packet, if the flow state from this

connection is not present, it is initialized with qleni ¼ 0; and

the number of active flows, Nactive, is incremented by one.

If the information of this flow is already in memory, then

preferential dropping is applied to the arriving packet

according to the number of packets from this flow already in

the queue, or qleni; as shown above. Then, for any departing

packet from flow i; its qleni is decremented by one packet. If

qleni reaches zero, the number of active flows is decreased

by one.

BRED has shown to have the ability to isolate

unresponsive flows quite well. However, unresponsive

flows still can get much higher bandwidth than responsive

flows. This effect is significant when the buffer size is not

enough to make the effective buffer size for each flow less

than its bandwidth-delay product. There are many par-

ameters that may have an effect on the performance of

BRED in a similar way as RED. Yet, the article did not

explore whether those parameters would have significant

impact on different types of scenarios. Lastly, BRED also

requires per-flow state information to make decisions about

which packet to be dropped.

3.2.5. Stabilized RED (SRED)

Stabilized RED or SRED [25] is aimed at stabilizing the

occupancy of a FCFS buffer, independent of the number of

active flows. Therefore, the dropping probability depends on

both the buffer occupancy and the estimate of the number of

active flows.

The TCP bandwidth equation (Eq. (6)) shows that

cwnd , p2ð1=2Þ: ð7Þ

where cwnd is the flow’s congestion window, and p is the

packet drop probability. With N flows, the sum of the N

congestion windows will be in the order of N £ p2ð1=2Þ

(MSSs, assuming all flows have the same MSS—Maximum

Segment Size). The authors argue that the target buffer

occupation, Q0; must be of the same magnitude as

N £ p2ð1=2Þ; and they assume Q0 ¼ N £ p2ð1=2Þ MSSs.

Therefore, p must be of the order of N2: This becomes


a part of the dropping policy of SRED as follows

pzap ¼ psredðqÞ £ min 1;1

ð256 £ ðPðtÞÞ2

�; ð8Þ

with

psredðqÞ ¼

pmax if ð1=3ÞB # q , B;

ð1=4Þ £ pmax if ð1=6ÞB # q , ð1=3ÞB;

0 if 0 # q , ð1=6ÞB:

8>><>>:

where 1=PðtÞ is an estimate of the effective number of active

flows in the time shortly before the arrival of packet t; B is

the buffer size, and q is the instantaneous buffer occupancy.

From the dropping policy, as long as the number of active

flows N does not exceed 256 (arbitrary picked number), the

dropping probability also depends on the number of active

flows to maintain the target buffer occupancy. That is

pzap ¼psred

2562£

1

ðPðtÞÞ2,

psred

65; 536£ ðnumber of flowsÞ2:

Once N exceeds 256, the dropping probability is equal to

psred in order to prevent TCP sources to spend much time in

time-out due to an excessive dropping probability.

In order to estimate the number of active flows, SRED

maintain a data structure, called the Zombie List, of the M

recently seen flows, as opposed to maintaining per-flow

state. Each flow in the Zombie list contains a variable

Count; that represents how often the packets of this flow

arrive. If the Zombie list is empty, as a packet arrives its

flow identifier is added to the list, with the Count variable

set to zero. If the Zombie list is full, whenever a packet

arrives, it is compared with a randomly chosen item in the

Zombie list:

† If they match, the Count of that flow in the list is

increased by one. This event is called a Hit.

† If they do not match, the flow identifier that is randomly

picked from the list is replaced with that of the arriving

packet with the Count reset to zero, with probability p:

This event is called a No Hit.

When packet t arrives, let

HitðtÞ ¼0 if no hit;

1 if hit;

(

and PðtÞ; an estimate for the hit frequency around the time of

arrival of the t-th packet at the buffer, according to

PðtÞ ¼ ð1 2 aÞPðt 2 1Þ þ aHitðtÞ; ð9Þ

with 0 , a , 1: Finally, the number of active flows N is

estimated by 1=PðtÞ as proposed by the authors.

One of the drawbacks of SRED is that it assumes that all

N flows have the same traffic intensity. In addition, although

it can use this hit mechanism to identify unresponsive flows,

it does not provide an effective penalizing scheme.

3.2.6. CHOKe

A design goal of CHOKe [26] is to keep the mechanism

as simple as possible while controlling unresponsive flows.

A small modification is proposed over a plain FCFS queue

with RED active queue management to achieve this goal.

The algorithm of CHOKe is as shown in Fig. 3 with CHOKe

functions being the shaded items while RED functions being

the rest.

When a packet arrives, if the average queue size is

greater than minth; CHOKe draws a packet randomly from

the buffer (drop candidate) and compares it with the

arriving packet. If they are from the same flow, then they are

both dropped, otherwise the arriving packet is accepted in

the queue with a drop probability that is computed by RED.

The basic idea behind CHOKe is that a FIFO queue is more

likely to have packets that belong to unresponsive flows

more than those of responsive ones, and they are more likely

to be chosen for comparison. Therefore, packets from

unresponsive flows are likely to be dropped more often.

Fig. 3. The CHOKe algorithm [26].


Since this scheme might work well only if there is only

one unresponsive flow, the authors also proposed a

modification to deal with multiple unresponsive flows.

One way to do this is to partition the buffer between minth

and maxth into k regions, and the number of drop candidates

ðmÞ is set to 2·i ði ¼ 1;…; kÞ according to the region that the

average buffer occupancy falls in.

CHOKe is very simple to implement, maintains mini-

mum state information, and controls unresponsive flows,

especially for CHOKe with multiple drop candidates.

However, CHOKe can control unresponsive flows only if

there are more packets from those flows in the buffer at the

time of congestion. This is due to the fact that CHOKe does

not keep track of those unresponsive flows. In addition,

some responsive flows might be punished unnecessarily as a

result of its probabilistic algorithm.

3.2.7. Stochastic fair blue (SFB)

The main novelty of the Stochastic Fair Blue (SFB)[27]

scheme is that it attempts to manage unresponsive flows

without using queue occupancy statistics (Fig. 4). SFB

maintains a data structure as a set of L hash tables of

different hash functions, with N items in each table. Each

item, which is referred to as a bin, keeps the number of times

flows are hashed into that item, and a marking or dropping

probability pm: Each arriving packet will be hashed, using

some form of string such as the flow ID, into one of the N

bins in each of L hash tables, and the number of packets

stored in that bin is increased by one. If the number of

packets in a particular bin is higher than a certain number,

the dropping probability pm for the bin is increased by some

amount. On the other hand, pm is decreased when the

number of packets in a bin drops to zero. Here, for each

flow, we have L values of pm from L tables it is hashed to.

The final marking or dropping probability is, however,

determined as the minimum value of these pm:

With this algorithm, an unresponsive flow that consumes

high bandwidth would ramp up pm to 1 in all of the bins of

L tables. In this way, this flow is then identified as a high-

bandwidth unresponsive flow and should be penalized by

limiting its rate. And because multiple hash tables are used,

it is unlikely that two different flows would be hashed into

the same items on every table. In other words, a perfect

hashing for every active flow passing through the router is

not required. Consequently, the possibility of penalizing a

responsive flow that hashed into the same item as any

unresponsive flow is reduced. Even with multiple hash

tables, however, SFB can still mis-identify a responsive

flow if there are more unresponsive flows at the router. In

addition, the identified unresponsive flow that later become

responsive, as well as those responsive flows that are mis-

identified, would be continually penalized without reclassi-

fying. To correct these problems, the authors propose SFB

with moving hash, where the hash function is changed and

reset every certain time, e.g. two seconds in the paper. The

authors also suggest double sets of tables that work at

different times, so that one set of tables can warm up a

mechanism before another set is reset. This would prevent

the unresponsive flows from getting higher share of

bandwidth at the time after the resetting.

Nonetheless, the size of the tables should be well pre-

determined because the higher the number of unresponsive

flows, the higher the probability of mis-identification. Also,

the higher the number of responsive flows, even short-lived

ones, the higher the number of responsive flows being

hashed into the same bins as unresponsive flows and

penalized. Another drawback is that since the mechanism is

independent of the queue occupancy, some unresponsive

flows could still be punished even though there is plenty of

buffer space available.

3.2.8. BLACKlisting unresponsive flows (BLACK)

The fundamental idea of the BLACK scheme is to detect

and control high bandwidth unresponsive flows as well as

achieve fairness among different types of flows [28]. A

buffer occupancy fraction is used as an indicator of

bandwidth share at a network link, based on the idea that,

under a FCFS queue, if the router allocates the buffer evenly

among all active flows, fair bandwidth allocation can be

achieved at a high degree [22].

To reduce the number of per-flow state information,

BLACK uses a sampling technique to approximate the

buffer occupancy fraction of only large flows. This is based

on the fact that most of the bytes of Internet traffic are

actually coming from only a small number of connections,

while the remaining huge number of connections are low

bandwidth flows [33,34]. When congestion occurs, the

packets from these flows should be held responsible and

thus dropped first.

For each packet arrival, if the queue size exceeds a

threshold, BLACK randomly samples one packet from the

queue. If this flow has never been recorded in a limited-size

cache memory, this flow ID is stored2 and a Hit for that flow

is declared. Next time, if a sampled packet is from that

particular flow again, its Hit value is increased by one. After

m samplings, the buffer occupancy fraction Hit Fraction of

Fig. 4. Example of SFB data structure [27].

2 A flow ID could be a combination of source and destination address,

source port and destination port, or only a FlowID field for an IPv6 packet.


the recorded flows is estimated by dividing Hit by m; which

is called a Hit Fraction: A flow with a larger Hit Fraction

than the fair buffer occupancy fraction, or 1/(number of

active flows), is considered a candidate of being a high

bandwidth flow and should be dropped according to the

dropping probability below.

p̂i ¼�Hi 2 1=Nact

1=Nact; ð10Þ

where

�Hi ¼Hiti þ ðHimÞ

m0 þ m; ð11Þ

and m0 is the current number of sampling packets in this

period, and m0 # m: BLACK estimates the number of active

flows Nact; in a similar way to the one utilized by SRED.

Based on the same assumption that all flows have the same

traffic intensity, BLACK computes Pmatch (PðtÞ in SRED)

and estimates it by counting the number of match events

over m packet arrivals. Hence, the estimated number of

active flows during the m arriving packets interval is Nact ¼

E½1=Pmatch� ¼ m=ðnumber of match eventsÞ: BLACK also

works on top of RED [32] to keep the average queue size

low, and thus the queueing delay, and to provide an early

congestion notification back to the responsive traffic

sources.

BLACK has been shown to provide a good fairness

performance not only in those scenarios with high

bandwidth unresponsive flows but also in environments

where TCP flows with different round trip times are

competing for the bottleneck bandwidth. One of the

drawbacks of BLACK is its simplified estimation of the

number of flows, which is not accurate in all cases such as

when the traffic intensity of flows are very different and

when the buffer size is not large enough compared to the

bandwidth delay-product. In order to fix these problems,

the authors suggest the Bitmap Approach to estimate the

number of active flows as discussed in Section 4.6.

3.2.9. CApture–REcapture (CARE)

CARE [29] is based on a Capture–Recapture (CR)

model that has been widely used to estimate a number of

animals in the population by ecologists and biologists, and

to estimate the number of defects in software inspection

processes. This model is applied here to estimate the arrival

rate of traffic flows and the number of active flows using the

M0 CR model and the Mh CR model, respectively.

The basic idea of the M0 model is that the proportion of

packets from flow i (m2) among t captured packets is the

same as the proportion of the total number of packets from

flow i (n2) in a buffer of size B: If CARE captures t incoming

packets, the incoming rate of flow i can be estimated from

the proportion Bðm2=tÞ: On the other hand, the Mh model is

more suitable to an scenario where the capture probabilities

are different among flows, thus it is chosen for estimating

the number of active flows ðNÞ: For this task, CARE uses

the Jackknife estimator as the method to estimate N:

Because the derivation of the Jackknife estimator is rather

difficult, the estimation of the number of active flows is

briefly summarized as follows:

(1) Capture an incoming packet with probability pcap and

store the packet in the capture list, which can store t

packets.

(2) After capturing t packets, construct the capture

frequency to see how many unique flows have been

seen once ðf1Þ; twice ðf2Þ; and up to t times ðftÞ:

(3) Based on these capture frequencies, use the Jackknife

estimator to estimate the number of active flows ðNJKÞ

using the following equation

NJK ¼ aðt;KÞ1f1 þ aðt;KÞ2f2 þ · · · þ aðt;KÞtft; ð12Þ

where aðt;KÞi are the coefficients in terms of the

number of capture occasions ðtÞ and the order of

estimation ðKÞ: An optimum value of K has to

determined because as K increases, the bias of NJK

will decrease while the variance of NJK will increase.

To determine the optimal K; the coefficients for K ¼

1–5 have to be derived. Then, combined with

frequency data, NJ1; NJ2;…;NJ5 are calculated. Next,

an interpolated estimator between m 2 1 and m; where

m is the first order of estimation that the significance

level Pm . 0:05 is computed. If m ¼ 1; then NJ1 can be

taken as the estimator, otherwise the interpolation

between NJðm21Þ and NJm is used to estimate the

number of active flows.

(4) Once the estimated number of active flows is obtained,

CARE can drop packets from the flows that consume

more than a fairshare with a dropping probability of

1:0 2 ðt=ðNJK·m2ÞÞ:

CARE has several drawbacks. First, in order to increase

the accuracy of the estimation, the model has to make a

large amount of captures (parameter t), compared to a

number of flows. This has a direct impact on the scalability

and simplicity of operation of the scheme. A large t means

running the capture process t times, building a capture

frequency table of up to t values, and calculating the

coefficients to finally apply Eq. (12) and find the estimated

number of flows. This might imply more CPU processing

power making CARE not suitable for high-speed routers.

Second, there is no mechanism described in Ref. [29] that

reduces the size of the capture list, which can then grow up

to the number of flows (not a scalable solution). Finally, no

evaluation is done to assess the performance of CARE under

the assumption that the number of flows is considerably

bigger than the size of the capture list. In other words,

CARE works well when the memory space available is large

enough although it does not require full per-flow state

information, otherwise, the estimation of the number of

active flows could be inaccurate (see Section 4.6 for further

discussion about estimation of the number of active flows).


A qualitative comparison of the surveyed schemes is

shown in Table 1 where the mechanisms are compared

according to the main design issues discussed in Section 3.1.

4. Performance evaluation

In this section, we evaluate the performance of the most

important AQM schemes under consideration. As explained

before, the mechanisms that require full per-flow state

information are not included here because of their practical

limitations due to scalability problems, especially in high-

speed routers that handle several thousands of flows.

However, of the schemes on the right side of Fig. 2 only

CHOKe, SFB, BLACK and CARE, are evaluated. SRED

and the TCP equation-based mechanism are not evaluated

because, although both of them could identify misbehaving

flows, SRED does not provide a mechanism to control them

and the TCP equation-based mechanism requires an extra

mechanism such as a separate CBQ queue to handle those

identified flows. As a base for comparison, we also included

RED since it is the most widely AQM scheme utilized in

practice. In addition, at the end of this section, we include an

evaluation of the most important techniques utilized to

estimate the number of active flows passing through a

router, which is a crucial mechanism to achieve fairness in

several of the AQM mechanisms above.

4.1. Simulation setup

We use the NS-2 [35] simulation tool and the dumbbell

topology shown in Fig. 5 to assess the performance of RED,

SFB, CHOKe, BLACK and CARE under four different

scenarios. In the first scenario, we compare the effectiveness

of the AQM schemes in achieving fairness when TCP

sources compete with one unresponsive flow. In the second

scenario, we repeat the first scenario but include multiple

unresponsive flows. In the third set of simulations, we

consider only TCP sources but with different round-trip

times. The fourth scenario compares the effect of the AQM

mechanisms on TCP-friendly protocols. Common simu-

lation settings are as follows. Constant-bit-rate UDP flows

compete against a number of TCP flows over a 5-Mbps

R1–R2 link and end nodes are connected to the routers at

100 Mbps. Both UDP and TCP flows transmit data with

a packet size of 1 Kbyte. The maximum buffer space at the

router R1 is set to 300 packets. Each experiment lasts for

150 s of simulation time, and it is repeated 20 times. SFB is

configured with two levels of hash functions of 23 bins, with

the NS code provided by Ref. [36]. The minth and maxth

threshold settings for BLACK, CHOKe, and RED are 100

and 200 packets, respectively, according to the configur-

ation in Ref. [26]. CHOKe is implemented with its self-

adjusting mechanism to handle multiple unresponsive flows,

where the region between minth and maxth are divided into

k ¼ 8 subregions and the number of drop candidates is set to

f ðiÞ ¼ 2·i (i ¼ 1;…; k). For the case of CARE, the number

of capture occasions ðtÞ is 200, where 50 out of 200 can be

used for the estimation of the number of flows, and the

probability pcap is 0.04 according to Ref. [29].

4.2. Single unresponsive flow

In the first experiment, only one UDP source transmits

packets at the rate of the bottleneck link (5 Mbps) from node

N5 to S5. 100 TCP connections are randomly selected to be

originated from one of the source nodes N0–N4 to one of

the sink nodes S0–S4. The propagation delays on all the

links are 10 ms. The BLACK queue is equipped at the router

R1 with a cache size of 26 with a value of m and moving

average weight ðaÞ of 3000 and 0.3, respectively. For SFB,

according to Ref. [27], the only suggested mechanism to

handle misbehaving flows is to limit the rate not to exceed a

certain defined level. Thus, we set two rate limit thresholds

for SFB as twice the fair rate and at the fair rate, for

reference.

Table 2 summarizes the results of the individual

throughput of each of the 100 TCP connections and the

UDP traffic. Under RED, the unresponsive UDP flow still

grabs a large amount of bandwidth leaving the remaining

TCP connections with an inferior performance in terms of

throughput. CHOKe provides better fairness but it is still far

from the fair share because there are not enough packet

matchings to control the unresponsive flow effectively.

BLACK and CARE provide a much lower throughput for

the UDP flow, although not as equal to the TCP throughput,

Table 2

Single unresponsive flow scenario

Average UDP

throughput

(Kbps)

Average TCP

throughput

(Kbps)

Jain’s fairness

index among

TCP flows

RED 3 397.25 15.957 0.9079

CHOKe 1 124.03 38.260 0.9868

SFB, rate limit <twice the fair rate

98.73 48.627 0.9184

SFB, rate limit <fair rate

49.24 46.254 0.9189

BLACK 74.04 49.033 0.9871

CARE 191.59 46.831 0.9775Fig. 5. Simulation topology.


showing superior performance than the other schemes.

For SFB, the UDP flow receives a fair throughput only with

a good adjustment of the rate limiting. Note that, in practice,

the inability to set up the fair rate limit automatically is a big

disadvantage of SFB. And for CARE, although it usually

performs well, the estimation of the number of active flows

is not as good in this scenario with a high bandwidth UDP

source.

4.3. Multiple unresponsive flows

To demonstrate how each scheme handles multiple

unresponsive flows, we performed an experiment using the

same topology but now including five 5-Mbps unresponsive

UDP sources sending traffic through the bottleneck R1–R2

link. The results are tabulated in Table 3. Both CHOKe and

RED show the inability to protect responsive TCP flows

causing a low average TCP throughput. However, BLACK

handles all the unresponsive flows quite well while

providing reasonably large throughput to the TCP connec-

tions, even with a small cache size. Besides, the fairness

among TCP connections with BLACK is shown to be better

than the other schemes, even under the impact of multiple

UDP traffic flows. CARE on the other hand, is not able to

cope with the unresponsive flows as they still obtain a huge

portion of the bandwidth.

Table 3

Multiple unresponsive flows scenario

Average UDP

throughput

(Kbps)

Average TCP

throughput

(Kbps)

Jain’s fairness

index among

TCP flows

RED 654.46 16.424 0.9516

CHOKe 516.71 22.857 0.9022

SFB, rate limit <twice the fair rate

96.58 42.875 0.9063

SFB, rate limit <fair rate

47.21 45.216 0.9069

BLACK 67.02 44.402 0.9799

CARE 974.39 9.4444 0.9458

Fig. 6. Per-flow TCP throughput for 200 TCP connections with different RTTs over a 45-Mbps link; plotted with 95% confidence interval.


4.4. TCP Sources with different round trip times

We also include results showing how these schemes

behave with TCP sources that do not share a bottleneck link

fairly because they have different round-trip times ðRTTsÞ:

Using the topology in Fig. 5, but with the propagation delay

of the access links as 1, 2, 5, 10 and 20 ms, the bottleneck

link R1–R2 set at 45-Mbps and 20 ms propagation delay,

we performed an experiment with two hundred TCP sources

randomly selected to originate from nodes N0–N4 and

terminate at randomly selected sink nodes S0–S4. To

conduct a fair comparison with SFB that maintains two

levels of hash functions of 23 bins, the BLACK scheme is

configured with a cache size of 46, and CARE is set up with

200 capture size. The results, shown in Fig. 6 with 95%

confidence intervals, indicate the better fairness achieved by

BLACK over RED, SFB, CHOKe, and CARE. In Table 4,

we include the standard deviation and Jain’s fairness index

[37] achieved by the four schemes. It can be seen that the

BLACK scheme presents better fairness results than the

other schemes. Note that although CARE provides a closer

fairness to BLACK, CARE needs a larger memory space to

store information. For reference, Jain’s fairness index is

calculated by

f ¼

Xn

i¼1xi

� �2

nXn

i¼1x2

i

; ð13Þ

where 0 # f # 1; given flow throughputs x:

4.5. Effect of AQM mechanisms on TCP-friendly protocols

In this section, we include an evaluation commonly

overlooked: the effect of AQM mechanisms on TCP-

friendly protocols. The AQM mechanisms included in this

article have been designed to address the TCP-friendliness

problem and provide fairness to all flows sharing the same

bottleneck link. On the other hand, several end-to-end

transport layer protocols have been designed to satisfy the

requirements of streaming applications while being friendly

to TCP. However, these two approaches have been studied

and proposed separately and no research has been done on

assessing the effect of AQM mechanisms on TCP-friendly

protocols when they work together. In other words, if we use

proved TCP-friendly transport layer protocols, will fairness

still be achieved if the system also includes these

router-based AQM mechanisms? Also, assuming that

the transport layer protocols are not completely fair,

do the AQM mechanisms actually help improving fairness

or on the contrary they produce more unfairness?

There are many TCP-friendly protocols proposed in the

literature and this evaluation can easily fill an entire research

paper. Therefore, our intention is to make the reader aware

of this issue and show some results that actually answer the

questions above for particular cases. In particular, in this set

of experiments we show the effect of RED, CHOKe, SFB,

BLACK, CARE and Drop Tail when TCP Reno sources

compete against a TFRC sources. Fig. 7 shows the

simulation results where we plot the normalized throughput

of individual sources as well as the average normalized

throughput achieved by all the sources of the same type.

This case is very simple to analyze. It is well known that

TFRC is friendly to TCP over long term when TCP SACK is

used. However, TFRC is considerably less responsive than

TCP Reno to network congestion and as a result, TFRC

obtains more bandwidth than Reno. This can be seen in the

Drop Tail case that we included as the basis for comparison.

However, when we change Drop Tail and use RED, SFB,

CHOKe, BLACK, and CARE, we observe that connections

are sometimes more unfair and sometime more fair to each

other, saying that AQM mechanisms can make things better

or worse. For instance, RED and BLACK improve fairness,

CHOKe and CARE produce more unfairness, and SFB does

not have an appreciable effect. In this case, CHOKe and

CARE degrade the performance because they drop both

incoming and sampled packets, and we know that TCP Reno

does not handle very well multiple packet drops within the

same congestion window. Note that, on the other hand,

CHOKEe and CARE provide much better fairness in other

cases with other TCP versions, even when TCP is

competing with aggressive TCP-friendly protocol (not

shown here). This is an active area of research where

more analysis is still needed.

4.6. Estimation of the number of active flows

A mechanism that estimates the number of active flows

without maintaining full per-flow state information is

crucial to a number of router-based mechanisms such as

SRED, BLACK and CARE. This mechanism has a direct

impact on the overall fairness provided by the AQM scheme

because the calculation of the fairshare usually depends on a

good estimation on the number of active flows. In this

section, we provide a brief description and evaluation of the

existing estimation methods.

The estimation techniques can be classified into three

categories: (1) Probabilistic approach (SRED and BLACK);

(2) CR model approach (CARE); and (3) Bitmap approach.

The probabilistic approach, as discussed with SRED and

BLACK in Section 3.2, although very simple and performs

well in various scenarios, still presents two problems.

First, the model assumes the same traffic intensity for

the incoming flows, and inaccuracies can occur when the

traffic intensity is very different. Second, problems might

Table 4

TCP connections with different round-trip time scenario

Flow throughput

(Kbps)

RED CHOKe SFB BLACK CARE

Standard deviation 43.725 38.268 41.996 22.054 30.194

Jain’s fairness index 0.9769 0.9721 0.9665 0.9905 0.9815


Fig. 7. Reno competing with TFRC, with Drop Tail, RED, CHOKe (first row), BLACK, SFB and CARE (second row).

Fig. 8. Estimated number of active flows for the experiment with 150, 450, and 300 TCP flows over 0–200, 200–400, and 400–600 seconds respectively, given

that t ¼ 100 and b ¼ 100:


occur when the buffer size is not large enough compared to

the bandwidth-delay product, where correlations between

the sampled and incoming packets might exist. The CR

model approach, such as the Jackknife estimator that is used

by CARE, is more accurate but usually much more

complex, as shown in Section 3.2.9. Finally, for the Bitmap

approach, the technique relies on a probabilistic algorithm

in conjunction with hashing at the bit level. The simplest

form of the Bitmap scheme is known as Direct Bitmap

[38,39] based on a technique as follows. Initially, all of the

bits in the bitmap of size b are reset to zero. For each

incoming packet, the flow ID is hashed to a bit of the bitmap

and that particular bit is set to one. At the end of the

measurement interval, the estimation of the number of

active flows is calculated using a formula that takes into

account collisions from hashing. For a bitmap of size b bits,

the probability that a given flow hashes to a particular bit is

p ¼ 1=b: For n number of active flows, the probability that

no flow hashes to a particular bit is then pz ¼ ð1 2 pÞN <ð1=eÞN=b: Therefore, the expected number of bits not set

during the interval is given by E½z� ¼ bpz < bð1=eÞN=b; and

the estimated number of active flows is n̂ ¼ b lnðb=zÞ for z

zero bits. An evaluation of these estimation techniques is

shown below.

The same dumbbell topology was used for these

experiments. n TCP flows compete for the bandwidth of

the 10 Mbps bottleneck link with 5 ms propagation delay,

all the access links are 2 ms, and the queueing discipline is

tail dropping. One important aspect in the performance of

these methods is the amount of memory space they need to

provide an accurate estimation. In that regard, we found that

all the schemes perform well when the number of actual

flows is not much larger than the required memory space—

that is when the capture size t of CR model or the bitmap

size b is less than the number of active flows n: The

estimation begins to be unstable when t and b are larger than

n; and the results are unpredictable when t p n and b p n;

which is shown in Fig. 8, for reference.

The performance provided by these mechanisms

becomes significantly different when unresponsive traffic

is mixed along with TCP traffic. BLACK’s estimation

technique underestimates the number of flows considerably

even when the UDP traffic consumes only 33% of the

bottleneck bandwidth. The Jackknife estimator performs

well with a small portion of UDP traffic but begins to be

inaccurate with large UDP traffic, such as in the case shown

in Fig. 9 where a UDP flow consumes 66% of the link

bandwidth. Direct Bitmap shows a superior performance

Fig. 9. Estimated number of active flows for the experiment with 30, 90, and 60 TCP flows over 600 seconds, with UDP traffic consuming 66% of bottleneck

link bandwidth starting at 300 s.


even in the presence of large UDP traffic because the bit that

a flow hashes to is irrelevant to the number of packets

injected to the network by this flow.

In terms of computational complexity, the Jackknife

estimator clearly requires a much larger amount of

computations. As previously described in Section 3.2.9, a

large capture size is needed for an accurate estimation.

However, a large capture size results in a much higher

complexity since it has to build the capture frequency table

and calculate the coefficients with complex equations. This

leaves the Direct Bitmap approach as the better choice for

high-speed routers. However, further research is needed to

determine the effect of memory limitations (reduced buffer

space), algorithm complexity, scalability regarding the

number of flows (thousands, millions of flows), different

traffic intensities, short and long lasting flows together, TCP

sources with different RTTs, and other important factors.

5. Conclusions

This article surveys the state-of-the-art in router-based

AQM mechanisms used to address the TCP-friendliness

problem. The most important issues to design one of these

algorithms are first described. Then, the most important

algorithms are described and compared against these issues.

A qualitative comparison is included to compare all the

existing schemes. Then, a quantitative performance evalu-

ation is included to show the advantages and disadvantages

of only those schemes that don’t require full per-flow state

information since they are more likely to be implemented in

practice. We found that RED is not able to handle

unresponsive flows while CHOKe, although better than

RED, still is not capable of dealing with these flows. SFB is

perhaps the best performing scheme in terms of throughput

control but it has the major drawback that to achieve that

performance it requires a pre-determined knowledge of the

fair share to adjust the rate limit, which is not practical.

CARE is a very complex scheme and in addition it performs

worse than SFB and BLACK. Overall, BLACK is the best

performing scheme offering simplicity and good

performance.

The problem of estimating the number of active flows in

core routers is also described and investigated in this article.

Current solutions are described and a performance evalu-

ation is included. We found that the algorithms used to

estimate the number of flows in BLACK and CARE do not

provide a good estimation under certain scenarios such as

when irresponsible flows consume a large portion of the

bottleneck link. We show that the Direct Bitmap estimator

responds quite nicely to sudden changes in the number of

flows and also when unresponsive flows are present. This is

still an active area of research and needs further investi-

gation since several mechanisms besides the ones described

in this article rely on this type of estimation.

References

[1] V. Jacobson, Congestion Avoidance and Control, in: Proceedings of

ACM SIGCOMM, 1988, pp. 314–329.

[2] S. Floyd, K. Fall, Promoting the use of end-to-end congestion control

in the Internet, IEEE/ACM Transactions Networking 7 (4) (1999)

458–472.

[3] D.P. Hong, C. Albuquerque, C. Oliveira, T. Suda, Evaluating the

Impact of Emerging Streaming Media Applications on TCP/IP

performance, IEEE Communications 39 (4) (2001) 76–82.

[4] V. Jacobson, Berkeley TCP Evolution from 4.3-tahoe to 4.3-reno, in:

Proceedings of the 18th Internet Engineering Task Force, 1990, p.

365.

[5] W. Stevens, TCP Slow Start, Congestion Avoidance, Fast Retransmit,

and Fast Recovery Algorithms, IETF RFC 2001, 2001.

[6] S. Floyd, T. Henderson, The NewReno Modification to TCP’s Fast

Recovery Algorithm, RFC 2582.

[7] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, TCP Selective

Acknowledgement Options, RFC 2018.

[8] L. Brakmo, S. O’Malley, L. Peterson, TCP Vegas: New Techniques

for Congestion Detection and Avoidance, in: Proceedings of ACM

SIGCOMM, 1994, pp. 24–35.

[9] M. Mathis, J. Semke, J. Mahdavi, and T. Ott, The Macroscopic

Behavior of the Congestion Avoidance Algorithm, Computer

Communications Review 27 (3), July (1997).

[10] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, Modeling TCP

Throughput: A Simple Model and its Empirical Validation, in:

Proceedings of ACM SIGCOMM’98, Vancouver, BC, 1998, pp. 303–

314.

[11] E. Altman, K. Avrachenkov, C. Barakat, Model of TCP/IP with

Stationary Random Losses, in: Proceedings of SIGCOMM, 2000, pp.

231–242.

[12] I. Yeom, A.L.N. Reddy, Modeling TCP Behavior in a Differentiated

Services Network, IEEE/ACM Transactions on Networking 9 (1)

(2001) 31–46.

[13] B. Sikdar, S. Kalyanaraman, K. Vastola, Analytic Models for the

Latency and Steady-state Throughput of TCP Tahoe, Reno and

SACK, in: Proceedings IEEE GLOBECOM, 2001.

[14] J. Mahdavi, S. Flyod, TCP-friendly Unicast Rate-based Flow Control,

Note Sent to End-to-End Mailing List.

[15] S. Floyd, M. Handley, J. Padhye, J. Widmer, Equation-based

Congestion Control for Unicast Applications, in: Proceedings of

ACM SIGCOMM, Stockholm, Sweden, 2000, pp. 43–56.

[16] R. Rejaie, M. Handley, D. Estrin, RAP: End-to-End Rate-Based

Congestion Control Mechanism for Realtime Streams in the Internet,

in: Proceedings of IEEE INFOCOM, 1999, pp. 1337–1345.

[17] D. Sisalem, A. Wolisz, LDA þ TCP-Friendly Adaptation: A

Measurement and Comparison Study, in: The 10th International

Workshop on Network and Operating Systems Support for Digital

Audio and Video (NOSSDAV’2000), Chapel Hill, NC, USA, 2000.

[18] I. Rhee, V. Ozdemir, Y. Yi, TEAR: TCP Emulation at Receivers—

Flow Control for Multimedia Streaming, Tech. rep., NCSU Technical

Report, 1999.

[19] D. Bansal, H. Balakrishnan, Binomial Congestion Control Algor-

ithms, in: Proceedings of IEEE INFOCOM, 2001, pp. 631–640.

[20] Y. Yang, S. Lam, General AIMD Congestion Control, Tech. Rep. TR-

200009, Department of Computer Science, University of Texas at

Austin, 2000.

[21] J. Widmer, R. Denda, M. Mauve, A Survey on TCP-Friendly

Congestion Control, IEEE Network 15 (3) (2001) pp. 28–37.

[22] B. Suter, T. Lakshman, D. Stiliadis, A. Choudhury, Design

Considerations for Supporting TCP with Per-Flow Queuing, in:

Proceedings of IEEE INFOCOM, 1998, pp. 299–306.

[23] D. Lin, R. Morris, Dynamics of Random Early Detection, in:

Proceedings of SIGCOMM, 1997, pp. 127–137.


[24] F. Anjum, L. Tassiulas, Fair Bandwidth Sharing Among Adaptive and

Non-Adaptive Flows in the Internet, in: Proceedings of IEEE

INFOCOM, 1999, pp. 1412–1420.

[25] T. Ott, T. Lakshman, L. Wong (Eds.), SRED: Stabilized RED, IEEE

INFOCOM, 1999.

[26] R. Pan, B. Prabhakar, K. Psounis, CHOKe—A Stateless Active

Queue Management Scheme For Approximating Fair Band-

width Allocation, in: Proceedings of IEEE INFOCOM, 2000,

pp. 942–951.

[27] W. Feng, D. Kandlur, D. Saha, K. Shin, Stochastic Fair Blue: A Queue

Management Algorithm for Enforcing Fairness, in: Proceedings of

IEEE INFOCOM, 2001, pp. 1520–1529.

[28] G. Chatranon, M.A. Labrador, S. Banerjee, BLACK: Detection and

Preferential Dropping of High Bandwidth Unresponsvie Flows, in:

Proceedings of IEEE ICC, 2003, pp. 664–668.

[29] M. Chan, M. Hamdi, An Active Queue Management Scheme Based

on a Capture–Recaptured Model, IEEE J. Select. Areas Commun. 21

(4), May 2003.

[30] S. Keshav, An Engineering Approach to Computer Networking: ATM

Networks, the Internet, and the Telephone Network, Addison-Wesley,

Massachusetts, 1997.

[31] T.V. Lakshman, A. Neidhardt, T. Ott, The Drop from Front Strategy

in TCP and in TCP over ATM, in: Proceedings of IEEE Infocom,

1996, pp. 1242–1250.

[32] S. Floyd, V. Jacobson, Random Early Detection Gatewas for Conges-

tion Avoidance, IEEE/ACM Trans. Networking 1 (4) (1993) 397–413.

[33] L. Guo, I. Matta, The War Between Mice and Elephants, Tech. Rep.

2001-005, Computer Science Department, Boston University, May

2001.

[34] I. Kim, Analyzing Network Traces To Identify Long-Term High Rate

Flows, Master’s Thesis, Texas A and M University, May 2001.

[35] NS Network Simulator. URL http://www.isi.edu/nsnam/ns

[36] The Network Simulator: Contributed Code. URL http://www.isi.edu/

nsnam/ns/ns-contributed.html

[37] R. Jain, A. Durresi, G. Babic, Throughput Fairness Index: An

Explanation, ATM Forum/99-0045.

[38] C. Estan, G. Varghese, M. Fisk, Bitmap Algorithms for Counting

Active Flows on High Speed Links, Tech. Rep. CS2003-0738, UCSD,

Mar. 2003.

[39] C. Estan, G. Varghese, M. Fisk, Counting the Number of Active Flows

on a High Speed Link, ACM SIGCOMM Computer Communication

Review 32.


http://www.isi.edu/nsnam/ns

http://www.isi.edu/nsnam/ns/ns-contributed.html

http://www.isi.edu/nsnam/ns/ns-contributed.html

Documents

A survey of TCP-friendly router-based AQM schemes