Study of Active Queue Management Algorithms ----Towards stabilize and high link utilization

Study of Active Queue Management Algorithms

----Towards stabilize and high link utilization

Computer Science and Engineering University of Nebraska−Lincoln

Lincoln, NE 66588-0115 {mli, hwang}@cse.unl.edu

Abstract

The focus of this work is to study the behaviors of varies queue managements, including RED (Random Early Detection), SRED (Stabilized-RED), and BLUE. The performance metrics of the comparison are queue size, the drop probability, and link utilization. The simulation is done using NS-2. The results of this work shows that different from the RED, SRED and BLUE, which use the available queue length as the indicator of the severity of congestion, they use packet loss and link idle events to manage the congestion. Thus SRED and BLUE achieve significant better performance in terms of packet loss rates and buffer size requirement in the Network. Finally we report a new queue management, SBQ (Stochastic Blue Queue management), which enforce fairness among a large number of flows.

Keywords: Congestion Control, SFQ, RED, SRED, BLUE, packet loss rates, buffer size, fairness

1. Introduction

As the Internet bandwidth increases, more users share the link. It is important to adopt some mechanisms to avoid packet loss since all resources which is consumed in transmit will be wasted if a packet is lost. As a result, TCP (Transmission Control Protocol) congestion control has been used to adaptively control the rates of individual connections sharing IP (Internet Protocol) network links over the last decade. Drop-tail queue has been used widely as the straightforward solution for queue management. However, current TCP still experiences high packet loss, even though it also uses other techniques suc h as congestion avoidance, slow start, fast retransmit and fast recovery mechanism. This leads many researches on the dynamic queue managements. The basic idea for dynamic queue management is to implicitly or explicitly notify sources to decrease the trans mission rates before the queue overflows in hope that this coordination between sources and network will eliminate any future sustained packet loss. A typical dynamic queue management is RED (Random Early Detection), which was recommended by the IETF for deployment in IP routers/networks and is supported by many routers. It is now widely believed that a RED-controlled queue performs better than a drop-tail queue. However, the inherent design of RED, which uses the available queue length as the indicator of the severity of congestion, makes it difficult to parameterize RED queues to give good performance under different network scenarios. Contrast to RED, SRED and BLUE use packet loss and link idle events to manage the congestion. The basic idea of SRED and BLUE is to maintain a single probability to mark packets when they are queued. The probability is changed

according the utilization ratio of the link. The simulation results show better performances on packet loss rate and buffer size management.

The rest of the report is organized as follows. Section 2 gives the descriptions of the different queue management algorithm, RED, SRED, and BLUE. Section 3 describes the simulation results of RED, SRED and BLUE queue algorithms using NS-2. Section 4 summarizes the dynamic queue algorithm and reports other approaches. Finally, section 5 concludes a future work.

2. Related Work

In this section, we focus on RED, SRED, BLUE and SFQ, and briefly explain them in each of the sub section. The main idea of this work is to compare these typical dynamic queuing algorithms instead of exhaustively reviewing the existing ones. This will be used in performance comparison.

2.1 RED Algorithm

RED (Early Detection Scheme) is proposed by Floyd and Jacobson for congestion avoidance in packet-switch networks. The idea is simple: the gateway notifies the incipient congestion to the sources by dropping the arriving packets.

The RED congestion control mechanism monitor the average queue size for each output queue with buffer size K. Whenever a packet arrive, RED checks the average used queue size, and decides to mark by compare the average queue size with the defined thresholds. If RED decides to mark the packet, it will discard this packet. The source will wait for timeout or duplicate ACK to confirm the packet loss and stop sending too much packets to the network.

In RED, it defines two thresholds, the minimum threshold MINth and the maximum threshold MAXth. Let the current average queue size is Q. If Q is less than MINth, the packet will not be marked. If Q is greater than MAXth, the packet will be marked. If Q is between MINth and MAXth, the packet will be marked by probability pm. The Q is vary linearly from MINth to MAXth.

The final probability to mark the packet increases slowly as the count increase since the last marked packet starting form 0. The maximum probability to drop a packet is defined by MAXp. Thus the packet-marking probability varies from 0 to MAXp:

) /(

)

( _{th th th}

p Q MIN MAX MIN

MAX

Pa ← − −

The final mark-probability is calculated as: pm ← pa/(1−Count× pa) The algorithm is as following:

For each packet PCK arrive

Calculate the average queue size Q

If Q≤MAX_th

if MINth≤Q≤MAXth

Calculate the probability pm With probability p_m mark the PCK

Else if Q≥ MAX_th

mark the PCK

There is a option for RED gate to measure the queue in bytes rather than in packets. With this option on the average queue size accurately reflects the average delay at the gateway. The above algorithm need to be modified to ensure that the probability that a packet is market is proportional to the packet size is bytes:

p_a← MAX_p (Q - MIN_th) / (MAX_th - MIN_th) p_a← p_a× PacketSize / MaximumPacketSize pm← pa / (1- Count× pa )

Form the above description of RED, it is easy to conclude that the effectiveness of RED relays on the proper set of the following parameters: MINth, MAXthand MAXp.

2.2 SRED Algorithm

SRED (Stabilized RED) derives from RED by adding some other features. Like RED, SRED discards packets with a load-dependent probability when the packets arrive at the queue, even thought the buffer is not full. In addition to this, SRED can stabilize its buffer occupation at a level of independent of the number of active connections over a wide range of load levels by estimating the number of active connections or flows statistically. This estimation is obtained without collecting or analyzing state information on individual flows.

Its goal is to identify flows that are taking more than their fair share of bandwidth, and to allocate a fair share of bandwidth to all flows without incurring in too many computations

Whenever a packet arrives at the queue, SRED do the comparison test and claims a hit only when two packets come from the same flow. A simple way to do the comparison is to compare it with a packet still in the queue. However, the task to search the whole queue is

O(n), where n is the size of the queue, is time consuming. SRED uses a “Zombie List” as the reference for comparison.

“Zombie list ” can be thought as a small list of M recently seen flows, with the following extra information for each flow in the list: a “Count” and a “time stamp”. It starts out empty. If the zombie list is not full, it will add the arriving packet identifier into the list. The Count of that zombie is set to zero, and its timestamp is set to the arrival time of the packet. If the zombie list is full, it will compare the arriving packet with the random selected zombie in the zombie list. If the two match, SRED declares a “hit” and increase the Count of that zombie by one. If the two not match, SRED declares a “not hit” and replace the chosen zombie by the arriving packet identifier, the Count of the zombie is set to 0, and the timestamp is set to the arrival time at the buffer with probability p.

SRED maintains an estimate P(t) for the hit frequency around the time of the arrival of the t-th packet at the buffer. Let

   = hit if 1 hit no if 0 Hit(t) P(t)=

(

)

SRED uses P(t)-1 to estimate of the effective number of active flow in the same shortly before the arrival of packet t. When there are exactly N flows with probabilities

( )

there are 1 1 1 2 _≤ ≤

∑

N π . To reduce comparison overhead, SRED allows to update P(t).

For 0≤P(t)<1/256, the packet drop probability Pzap is:

) )) ( 256 ( 1 , 1 min( ) ( ₂ t P q P P_{zap sred} × × = , where     ≤ ≤ × ≤ ≤ = otherwise 0 3/B q B/6 if 25 . 0 B/3 if ) ( _max max P B q P q P_sred

For 1/256≤P(t)≤1, Pzap =Psred(q).

In “Full SRED” we modify the drop probability as follows:

) ) ( ) ( 1 ( ) )) ( 256 ( 1 , 1 min( ) ( ₂ t P t HIt t P q P P_{zap sred} × + × × = 2.3 BLUE Algorithm

The key idea behind BLUE is to perform queue management based directly on packet loss

and link utilization rather than on the instantaneous or average queue lengths. Thus BLUE is fundamentally different with RED and SRED queue management algorithm. It maintains a single probability Pm, which it uses to mark (or drop) packets when they are queued. If the queue is continually dropping packets due to buffer overflow, BLUE will increments the marking probability, thus increase the rate at which it sends back

congestion notification. Conversely, BLUE will decrease its marking probability if the queue is empty or the link is idle.

The BLUE algorithm is as following:

Upon packet loss or ( Q_ten > L) event:

If ((now –last_update) > freeze_time) then

p_m=p_m+d₁

last_update=now

Upon link idle event:

If ((now – last_update) > freeze_time) then

p_m=p_m-d₂

last_update=now

To control how quickly the Pm changes over the time, BLUE uses the following

parameter: freeze_time, d1 and d2. Parameter freeze_time determines the minimum time interval between two successive updates of pm. parameter d1 and d2 determine the amount by which pm is incremented when the queue overflows or is decremented when the link is idle. By weighting heavily against packet loss, BLUE can quickly react to a substantial increase in traffic load.

We can conclude that BLUE is a very simple algorithm, and the performance of BLUE also counts on proper parameter setting.

3. Experiments and Evaluation

In this section, we first describe the network configuration and the NS-2 simulation model, then we describe the series of experiments performed, and the evaluation results are presented.

NS Simulator is a very big software packet and has various versions. We first use the 1.4b installed by Dr. Byrav Ramamthy on CSE952 account. We then installed the NS-2.19b-snapshot version to combine our own programs. We would like to thanks for the help of Dr. Byrav Ramamthy, the CSE account manager, Dr. Scott Chaffin, who increased our disk and file quota, and the NS resource owner ISI.

Figure 2 shows the NS-2 network model that represents a simple network bottleneck configuration with two routers and number of subnet nodes. Each subnet has a number of TCP and UDP sources. This configuration can represent the interconnection of LANs to WANs or dial-up access users through WANs as in the case of an ISP network. All simulations take 100 seconds.

The bottleneck-sharing link is 20Mbps with 20ms round trip time. The TCP source subnet use 100Mbps link with 2ms round trip time.

d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 100Mbps, 5ms s1 s2 s3 s4 s5 s6 s7 s9 s10 s8 Router1 Router2 Bottleneck Link

Drop-Tail, RED, SRED, BLUE, SFQ

10Mps, 100ms 100Mbps, 2ms

Figure2: Network topology for the queuing study.

3.1 Random Earlier Drop

In this scenario, the traffic source is TCP traffic with 10 sources and 10 sinks. The RED parameter values set according to the following table:

Table1: RED parameter values

Parameters Default Values

Queue size 100 packet

Minimum threshold (minth) 50 packets Maximum threshold (maxth) 100 packets Maximum value for Pb (maxp) 0.1

Queue weight (wq) 0.002

RED

Average Queue Size by bytes FALSE

The TCP source traffic window size is 511. We can get the queue size, the average queue size and the packet drop probability vary by the time by trace the simulation results. The bandwidth also can be calculated by multiply the average queue size with the packet size.

Maximum Threshold

Minimum Threshold

Figure 3. The queue size and average queue size of the RED queue.

Figure 5. Bandwidth of the RED queue simulation.

3.2 Stabilized RED

In this scenario, the traffic source is TCP traffic with 10 sources and 10 sinks. The SRED parameter values set according to the following table:

Table2: SRED parameter values

Parameters Default Values

Number of the zombie in the zombie list (M) 1000

The maximum drop probability (Pmax) 0.15

The efresh robability to update the zombie list (P) 0.25

SRED

Maximum value for Pb (maxp) 0.1

We can get the queue size, the average queue size and the packet drop probability vary by the time by trace the simulation results. The bandwidth also can be calculated by calculate the total received bytes in the SRED queue every 0.1 seconds. The bandwidth result of the bottleneck link is presented in Figure6. It is clear that the average bandwidth ranges around 0.31Mbps to 0.27Mbps.

The packet drop rate of the SRED queuing algorithm is presented in Figure7. The packet loss rate is about a quarter of the RED algorithm. The time for SRED to reach a stable packet drop rate is not high.

3.3 BLUE

In this scenario, the traffic source is TCP traffic with 10 sources and 10 sinks. The BLUE parameter values set according to the following table:

Table3: BLUE parameter values

Parameters Default Values

Initial Drop Probability 0.05

Freeze time period 0.01

Increase drop probability (d1) 0.00025 Decrease drop probability (d2) 0.000025

BLUE

Buffer Size (B) 450 packets

The bandwidth of the BLUE queuing algorithm is presented by figure8. It is very similar with SRED and higher than RED. The average bandwidth of BLUE ranges around 0.35Mbps to 0.28Mbps.

The packet drop rate of the BLUE queuing algorithm is presented by figure9. From the result, we found out BLUE has very low packet drop rate. However, it take BLUE a very long time to reach the low and stable packet drop rate.

Figure 9. Packet drop rate of BLUE

4. Performance Evaluation

In this section, we evaluate the performance of RED, SRED and BLUE. Comparison results are given based on the evaluation.The TCP sources are based on a TCP-Vegas implementation. The TCP connections are modeled as greedy FTP connections; they always have data to send as long as their congestion windows permit. The maximum segment size (MSS) for TCP is 536 bytes. All simulation is based on TCP traffic source. Based on the same network, we get the simulation results. However, the performances of each of the queuing algorithms depend on the configuration of parameters. It is difficult to fairly compare them. In order to be fair, we set most of the parameter values in each algorithm using the recommended values from the original papers

The simulation results are presented in figures. Among them figure 5 represent the usage bandwidth of RED, figure 6 represent the usage bandwidth of SRED, figure 8 represent the usage bandwidth of BLUE. It is obvious that the usage of bandwidth in BLUE and SRED queuing management are better than that of RED. The average usage bandwidth of RED is around 0.3Mbps to 0.1Mbps. While the average usage bandwidth of SRED ranges around 0.4Mbps to 0.2Mbps, and the average usage bandwidth of the BLUE ranges around 0.35Mbps to 0.28Mbps

Figure 4 represent the packet loss rate of the RED, figure 7 represent the packet loss rate of SRED and figure 9 presents the packet loss rate of BLUE queuing algorithm.

5. Conclusions and Future Work

From the simulation results, we can clearly see that the RED algorithm does not perform as well as the SRED and BLUE control algorithms in the heavily loaded network. In addition, RED is difficult to stabilize the queue size. The parameter configuration of RED is another challenge task under different network scenarios and over a wide range of load levels.

BLUE also has difficult to stabilize the queue size. It needs some starting time for BLUE to reach a fine-tuning. To solve this problem, other researcher proposed another enhanced BLUE algorithm, Stochastic BLUE queuing algorithm. SBLUE is also called fairblue queuing algorithm. If we have time, we can study and simulate it.

In this work, we do not cover the fairness issue for the queuing algorithm, which actually another important factor of queuing algorithm. Thus we future work can focus on discuss of the fairness issue also.

References

[1] V. Jacobson, “Congestion Avoidance and Control”, Proc. ACM SIGCOMM’88, Aug.1988, pp.314-329.

[2] W.Richard Stevens, “TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms”, RFC 2001, Jan 1997.

[3] S. Floyd and V. Jacobson. Random Early Detection for congestion avoidance.

IEEE/ACM Transactions On Networking, 1(4):397-413, August 1993.

[4] T. J. Ott, T.V.Lakshman, and L.H.Wong, “SRED: Stabilized RED”, Proc. IEEE INFOCOM’99, NY, March 21-25, 1999, pp.1346-1355.

[5] W.Feng, D. D.Kandlur, D.Saha, and D.G.Shin, “BLUE: A New Class of Active Queue Management Algorithms”, Technical Report CSE-TR-387-99, Dept. of EECS, University of Michigan, April 1999.

[6] Chengyu Zhu, Oliver W. W. Yang, James Aweya, Michel Ouellette, and Delfin Y. Montuno, "A Comparison of Active Queue management Algorithm Using OPNET Modeler", best paper award in OPNET 2001.

Appendix

1. Tcl script file for RED: red.tcl (combine the awk call procedure)

#Mengke Li RED

#Simulation the RED queue to get the average queue size of RED, #the packet mark probability, and the bandwidth.

set ns [new Simulator] #define the RED parameter Queue/RED set thresh_ 50 Queue/RED set maxthresh_ 100

Queue/RED set mean_pktsize_ 500 Queue/RED set q_weigth_ 0.002 Queue/RED set linterm_ 30 Queue/RED set drop_rand_ true #

# Create a simple 22 nodes topology: # # s1 d1 # \ / # 100Mb,2ms \ 10Mb,100ms / 100Mb,5ms # ... r1 --- r2 ... # 100Mb,2ms / \ 100Mb,5ms # / \ # s10 d10 #

#set the two RED queue router set node_(r1) [$ns node] set node_(r2) [$ns node]

#define the source and sink node number set nodenum 10

#define the simulation time set finish_time 100

#create node_(s1) to node_(s10) as the source node #create node_(d1) to node_(d10) as the sink node for {set i 0} {$i < $nodenum} {incr i} {

set node_(s$i) [$ns node] set node_(d$i) [$ns node] }

#create the links between the sources and sinks for {set i 0} {$i < $nodenum} {incr i} {

$ns duplex-link $node_(s$i) $node_(r1) 100Mb 2ms DropTail $ns duplex-link $node_(d$i) $node_(r2) 100Mb 5ms DropTail }

#create the RED queue link

$ns duplex-link $node_(r1) $node_(r2) 10Mbps 100ms RED #set the queue size

$ns queue-limit $node_(r1) $node_(r2) 100 $ns queue-limit $node_(r2) $node_(r1) 100

$ns duplex-link-op $node_(r1) $node_(r2) queuePos 0 $ns duplex-link-op $node_(r2) $node_(r1) queuePos 0 #create TCP traffics attached with one FTP agent for {set i 0} {$i < $nodenum } {incr i} {

set tcp($i) [$ns create -connection TCP $node_(s$i) TCPSink $node_(d$i) $i]

$tcp($i) set window_ 127

}

# Set tracing parameter to Tracing the RED queue set redq [[$ns link $node_(r1) $node_(r2)] queue] set tchan_ [open red_all.q w]

$redq trace curq_ $redq trace ave_ $redq trace prob1_ $redq attach $tchan_

#create the random number set rng [new RNG]

for {set i 0} {$i < $nodenum} {incr i} { set start_time [$rng uniform 0 1] $ns at $start_time "$ftp($i) start" }

$ns at $finish_time "finish"

# Define 'finish' procedure (include post-simulation processes) proc finish {} {

global tchan_

#Define the awk subprocedue to put the queuesize and average queuesize

#into file red_q.q and red_q.a set queueSize { { if ($1 == "Q" && NF>2) { print $2, $3 >> "red_q.q"; set end $2 }

else if ($1 == "a" && NF>2) print $2, $3 >> "red_q.a"; }

}

#Define the awk subprocedure to put the packet loss probability #into file red_d

set LostRate { { if ($1 == "p") print $2, $3 >> "red_d"; } }

#Define the awk subprocedure to put the bandwidth into file red_b set GetBandwidth { { if ($1 == "a" && NF>2 ) { print $2, $3*500*8.0/1000000 >> "red_b"; } } }

#Define datafile for xgraph for bandwidth show set bd [open red.bd w]

puts $bd "TitleText: Bandwidth of RED" exec rm -f red_b

exec touch red_b

exec awk $GetBandwidth red_all.q

puts $bd \"Bandwidth" exec cat red_b >@ $bd close $bd

exec xgraph -bb -tk -x "Time" -y "Bandwidth (Mbps)" red.bd -geometry 800x400 &

#Define data file for xgraph for queue size show set f [open red.queue w]

puts $f "TitleText: Queue Size o f RED" if { [info exists tchan_] } {

close $tchan_ }

exec rm -f red_q.q red_q.a red_d exec touch red_q.a red_q.q red_d

exec awk $queueSize red_all.q

puts $f \"Current_Queue_Size" exec cat red_q.q >@ $f

puts $f \n\"Average_Queue_Size" exec cat red_q.a >@ $f

close $f

exec xgraph -bb -tk -x "Time" -y "Queue Size" red.queue -geometry 800x400 &

#Define the data file for xgraph packet drop probability show set f1 [open red_d.q w]

puts $f1 "TitleText: Packet Drop Probability of RED" puts $f1 \"Packet_Drop_Probability"

exec awk $LostRate red_all.q exec cat red_d >@ $f1 close $f1

exec xgraph bb tk x "Time" y "Packet Drop Probabiltiy" red_d.q -geometry 800x400 &

exit 0 }

$ns run

2. Implementation of SRED: mainly get reference from http://home.lanl.gov/sunil 3. Tcl script file for SRED: sred.tcl, similar with red.tcl

4. Implementation of BLUE: mainly get reference from http://home.lanl.gov/sunil 5. Tcl script file for BLUE. blue.tcl, similar with red.tcl

#Mengke Li

#Get format data from row data file BEGIN {

system ("rm -f sred_q") system ("rm -f sred_q.all") system ("rm -f sred_qq") if (ARGC!=2)

print "No input file" else

{

input=ARGV[1]; print input

system ("awk '{print $1, $2, $6}' "input" > sred_q.all") last=0

total=0

while ( (getline data < "sred_q.all") >0 ) { split(data, anarray, " ") indicator=anarray[1] time=anarray[2] packet=anarray[3] if (indicator=="r") {

total = total + packet if (time-last > 0.1) {

total=total*8/1000000

print time, total > "sred_q" total=0 last = time } } } close ("sred_q") } }

7. AWK script to compute the packet loss rate from row data of SRED: getdd, similar with “get”

8. AWK script to compute the bandwidth from the row data of BLUE: get, similar with SRED’s “get”

9. AWK script to compute the packet loss rate from row data of BLUE: getdd, similar with SRED’s “get”

Note: Because NS BLUE and SRED algorithm has some problem binding LossMonitor agent with the node, thus we use the awk script to get the formatted data.