P O Z N A N U N I V E R S I T Y O F T E C H N O L O G Y A C A D E M I C J O U R N A L S
No 54 Electrical Engineering 2007
__________________________________________
* AGH University of Science and Technology.
** This work is supported by under Polish Government Grant No. N517 012 32/2108
Agata KREMPA*
ANALYSIS OF RED ALGORITHM WITH RESPONSIVE AND NON-RESPONSIVE FLOWS**
In the article, the use of active queue management with responsive and non- responsive flows is proposed. The paper presents the simulation results of networks performance when Random Early Detection (RED) queue management algorithm is used and both responsive and non-responsive flows traverse through the network.
Keywords: TCP, UDP, tail drop, RED, queue management
1. INTRODUCTION
Internet traffic consists of data sent by different kinds of applications (web traffic, FTP traffic and real-time multimedia traffic such as voice and video traffic).
Different applications use different transmission protocols to send their data. FTP and web traffic are sent using TCP [7] protocol. Voice and video are sent using UDP [8] protocol. Sending different kinds of data simultaneously can result in one transmission having negative effect on the other one. It is highly accurate in case of mixing responsive flows such as TCP and non-responsive flows such as UDP. In that scenario UDP flows tend to suppress TCP flows. In this paper we present that use of active queue management can lessen the negative effect that UDP flows have on TCP flows.
The most common technique of queue management is a tail drop. In this method packets are accepted as long as there is space in the buffer. When it becomes full, incoming packets are dropped. This kind of approach results in dropping large number of packets in the time of congestion. This can result in lower throughput and TCP synchronization.
2007
Poznańskie Warsztaty Telekomunikacyjne Poznań 6 - 7 grudnia 2007 POZNAN UNIVERSITY OF TECHNOLOGY ACADEMIC JOURNALS
The advantages of using active queue management in case of responsive flows is widely known, but it can also be useful when sending TCP and UDP traffic simultaneously. Event when only UDP flows are present, it still has some advantages.
Section 2 of this paper presents concept of Random Early Detection (RED) – an active queue management algorithm. Section 3 describes simulation scenarios.
In section 4 simulation results are presented. Section 5 concludes this paper.
2. RED ALGORITHM
Random Early Detection (RED) [2,3,4] is an active queue management algorithm that complement congestion avoidance mechanism and helps to improve performance of congested nodes. The operating of RED algorithm consists of measuring the average queue size and dropping arriving packets probabilistically when queue size exceeds specified threshold. Minimum threshold is an average queue size below which no packets are dropped. Maximum threshold state the average queue size above which all of the incoming packets are dropped. For the average queue size that enclose between minimum and maximum threshold, probability of dropping packets varies linearly from 0 to P
max(typically 0,1 [5]).
Characteristic of probability of dropping packets is shown in Figure 1.
1
Pm ax
Min threshold Max threshold pb
Buffer size Figure 1. Probability of dropping packets.
This kind of approach results in dropping packets though the buffer is not full.
Dropping packets early, can be very useful as the dropped packets indicate the state
of congestion in congestion control mechanism. It can prevent buffer from
overflowing as senders reduce their transmission speed in response to the early
congestion notification.
Implementation of RED algorithm in congested nodes, in case of responsive flows can provide the following advantages:
1. capacity to absorb packet bursts 2. reduce the number of dropped packets 3. increase throughput
4. reduce delay
5. eliminate lock out phenomenon (result of TCP synchronization)
3. SIMULATION SCENARIOS
The goal of this paper is to show that active queue management algorithm not only improves the network performance, but also can help lessen the negative effect of mixing different kinds of traffic. In order to show the improvement, tests were run in two scenarios. The first one was a case when tail drop algorithm was used. The second one was the situation when active queue management was used.
Tests were run in ns-2 simulator [9] for simple bottleneck network, which topology is shown in Figure 2.
n0 n1
n4
n2
n6
n8 n9
n7 n5 n3
Figure 2. Network topology
Nodes n3, n5, n7 and n9 were sending data. Nodes n2, n4, n6 and n8 were receives. The bandwidth of serial link between routers n0 and n1 was set to 1,5 [Mbit/s]
In both scenarios node n8 was sending real-time multimedia traffic while
other nodes were sending FTP data. Real-time multimedia traffic was represented
by CBR flow. Queue length was set to 26 packets. Minimum threshold was set to 4
packets. Maximum threshold was set to 17 packets. For each of scenarios 10 tests
were run in order to get more reliable results. Factors considered as RED algorithm advantages, that were mention in section 2, were used to show the improvement.
4. SIMULATION RESULTS
The mean number of received packets in both scenarios is presented in Table 1.
Table 1. Mean number of received packets
Tail drop RED
Mean number of received
packets 2430 2443
Mean number of received
TCP packets 1310 1332
Mean number of received
UDP packets 1120 1110
In scenario with RED algorithm slightly more packets were sent through the network. What is more interesting the proportion between number of received TCP packets and number of received UDP packets was a little shifted. When RED algorithm was used less UDP packets and at the same time, more TCP packets were sent (1,7% more TCP packets sent) . This slightly lessen the unfairness in allocation of bandwidth among responsive and non-responsive flows.
Also the interesting part is how the number of received packets was divided between respective nodes. Number of received packets by respective nodes in all ten tests, that were run in both scenarios is shown in Figure 3 (tail drop) and Figure 4 (RED).
0 2 0 0 4 0 0 6 0 0 8 0 0 1 0 0 0 1 2 0 0
1 2 3 4 5 6 7 8 9 1 0
T e s t n u m b e r
Number of received packets
n 2 n 4 n 6 n 8
Figure 3. Number of received packets by respective nodes in scenario with tail drop algorithm
0 200 400 600 800 1000 1200
1 2 3 4 5 6 7 8 9 10
t est n u m b er
Number of received packets
n2 n4 n6 n8
Figure 4. Number of received packets by respective nodes in scenario with RED algorithm
In case of tail drop algorithm, lock out phenomenon was a great problem. Not only UDP flow suppressed TCP transmissions but also among TCP flows was a great unfairness in getting room in the queue. Presence of UDP traffic caused permanent state of congestion. Queue was maintained in almost full state causing that packet bursts could not be absorbed. As buffer overflowing occurred the problem of synchronization was present and led to lock out phenomenon. Changing the queue management algorithm to RED did not prevent buffer from overflowing as it do when only TCP flows are present. Still, tests results with RED algorithm show that use of active queue management caused a great improvement. Lock out problem could be reduced thanks to keeping the average queue length small.
Because of that, in the time of congestion buffer overflows were not as severe as in scenario with tail drop algorithm. That could lessen the problem of TCP synchronization.
Active queue management had also positive effect on delay. Mean end-to-end
delay in ten tests that were run in both scenarios is shown in Figure 5.
0 0,05 0,1 0,15 0,2 0,25
1 2 3 4 5 6 7 8 9 10
Test number
Mean delay [s]
tail drop RED
Figure 5. Mean packet delay in both scenarios
Greater end-to-end delay in scenario with tail drop algorithm is a result of heavy load that UDP traffic creates. Queue is maintained in almost full state and cause buffer delay to increase. The use of RED results in keeping the average queue length small and reduce the overall delay as buffer delay is smaller.
The only disadvantage of using RED queue management algorithm in case of mixed TCP and UDP traffic is greater number of dropped packets. With only TCP flows present, number of dropped packets is smaller when active queue management is used. Presence of UDP flow cause a state of heavy load in the network. As UDP flows do not respond to congestion indication, more packets have to be dropped to keep the average queue length small.
0 20 40 60 80 100 120 140
1 2 3 4 5 6 7 8 9 10
Test num ber
Number of dropped packets
tail drop RED
Figure 6. Number of dropped packets in both scenarios
5. CONCLUSIONS
In this paper the use of active queue management with mixed – responsive and non-responsive flows is proposed. The goal of this article was to test network performance when RED algorithm is used and different kinds of data is sent through the network. To test the efficiency of using active queue management in such scenario, test were performed in ns-2 simulator. The simulation results show that even when non-responsive flows are present, RED algorithm is useful. It helps increase throughput and reduce delay. The lock out phenomenon is also reduced.
The most interesting part is that active queue management helps slightly lessen the unfairness in allocation of bandwidth among responsive and non-responsive flows.
REFERENCES
[1] Allman M., Paxson V., Stevens W.: “TCP Congestion Control”. RFC 2581, April 1999
[2] Chodorek A.: „Kolejka RED a transmisja multimedialna”, Wysoko wydajne sieci komputerowe. Zastosowanie i bezpieczeństwo. Wydawnictwo Komunikacji i Łączności, Warszawa 2005
[3] Floyd S., Jacobson V., “Random Early Detection Gateways for Congestion Avoidance”. 1999
[4] Floyd S., Jacobson V.: “Recommendations on Queue Management and Congestion Avoidance in the Internet”. RFC 2309, April 1998
[5] Floyd S.: “RED: Disscussions of setting parameters” November 1997, http://www.icir.org/floyd/REDparameters.txt
[6] Jacobson V., Karels M., „Congestion Avoidance and Control”. November 1988 [7] Postel J.: “Transmission Control Protocol” RFC 793, September 1981
[8] Postel J.: „User Datagram Protocol”. RFC 768, August 1980
[9] VINT Project: “The ns Manual” (formerly ns Notes and Documentation). July 2006, http://www.isi.edu/nsnam/ns/
