Sanaullah Manzoor, Ghulam Abbas and Masroor Hussain. Faculty of Computer Sciences and Engineering. GIK Institute of Engineering Sciences and ...
2015 IEEE International Conference on Computer and Information Technology; Ubiquitous Computing and Communications; Dependable, Autonomic and Secure Computing; Pervasive Intelligence and Computing
CHOKeD: Fair Active Queue Management Sanaullah Manzoor, Ghulam Abbas and Masroor Hussain Faculty of Computer Sciences and Engineering GIK Institute of Engineering Sciences and Technology, Topi 235640, Pakistan {sanaullah; abbasg; hussain}@giki.edu.pk
entire bandwidth. Although some streaming applications claim some level of responsiveness to control congestion, but these are still more aggressive than the well-behaved TCP flows and may still cause unfairness. In an extreme case, unfairness can also lead to congestion collapse [1].
Abstract— This paper proposes CHOKeD, a novel stateless Active Queue Management (AQM) scheme, to provide fairness among competing flows in the Internet. CHOKeD protects responsive flows by penalizing unresponsive flows, and by allocating bandwidth fairly. CHOKeD features such as fairness, high throughput and stateless design are promising for its deployment over the edge as well as the core routers. ns-2 simulations are carried out to evaluate the performance of CHOKeD. The results show that CHOKeD provides high fairness and better protection for responsive flows.
A. Related work To handle the problem of unfairness, many router based AQM solutions have been proposed. These AQM mechanisms are deployed in the network router to regulate the flows that cause unfairness. Conventional AQM protocols, such Random Early Detection (RED) [2] and BLUE [6], fail to protect responsive flows. Some AQM schemes, such as Cognitive Accountability Mechanism (CAM) [7], are able to protect responsive flows but they require per-flow state keeping, which increases the memory requirements significantly. Other AQM schemes, such as CHOKe [3], do not require per-flow states and punish unresponsive flows to protect responsive flows. CHOKe, on arrival of a packet, draws a packet from the buffer and compares it with the newly arrived packet. If both packets belong to the same flow, both are discarded. Otherwise, CHOKe restores the drawn packet while the arriving packet is dealt with by RED. Another stateless scheme is the SelfAdjustable CHOKe (SAC) [8], which divides the queue between minimum and maximum average queue thresholds into k sub-regions and draws j number of packets from jth region. SAC compares these packets with the newly arrived packet. ECHOKe [10] is a modification of CHOKe, which follows the same mechanism as that of the CHOKe for matchdrop comparisons. The only difference is that it is embedded in Random Exponential Marking (REM) [9], rather than in RED. CHOKeW [11] is another AQM scheme for priority based differential bandwidth allocation. CHOKeW follows the mechanism of the CHOKe with its own drawing factor rather than drawing one packet from the queue. PUNSI (Penalizing Unresponsive flows with Stateless Information) [12] treats UDP and TCP flows differently. PUNSI adopts a different match-drop mechanism if an arrived packet is a UDP. For TCP based arriving traffic, its working is the same as that of RED. WARD [13] draws two packets simultaneously from the queue and performs match-drop comparisons. If an arrived packet or any candidate packet from the queue has the flow ID similar to the arriving packet, WARD drops the matched packets. Moreover, WARD is embedded in Drop Tail, rather than in RED. Geometric CHOKe (gCHOKe) [14] generalizes the packet drawing mechanism of CHOKe, and works as follows. On the arrival of a packet, it draws one packet from the queue. If the arriving packet and the randomly drawn packet both have the same flow ID, it draws another packet from the queue and
Keywords— Active Queue Management; stateless; fairness; unresponsive flows.
I.
INTRODUCTION
Generally, the Internet traffic is carried by the Transmission Control Protocol (TCP). Numerous Internet applications, like the World Wide Web, TELNET, email and file transfer (FTP) are driven by TCP [1], [2], [3]. TCP provides congestion control mechanism and is, therefore, widely deployed over the Internet. The congestion control mechanism helps sources to determine the available network bandwidth and regulates their transmission rates accordingly [1], [4]. It allows sources to gradually increase their transmission rates up to the available bandwidth and, when congestion occurs, it starts decreasing their rates. This congestion control strategy of TCP keeps the network from being overloaded and secures the network from congestion collapse [1]. TCP flows are known as “responsive” flows as they lower their rates on account of network congestion. On the other hand, a number of new applications such as (audio/video streaming applications, and voice over IP) are largely deployed over the Internet [1]. These applications are mostly carried by the User Datagram Protocol (UDP). However, UDP lacks the crucial congestion control mechanism. UDP driven sources independently adjust their transmission rates and do not take account of the network congestion. Due to the increased deployment trend of UDP and its inability to control congestion, UDP-based applications result in two major problems in the Internet: (i) unfairness, and (ii) congestion collapse [1], [4], [5]. Unfairness occurs when UDP driven traffic, i.e., “unresponsive” flows steal a major portion of bottleneck link bandwidth from the well behaved responsive TCP flows. Because, after detecting congestion, TCP sources start decreasing their transmission rate while UDP sources keep sending at a fixed rate, UDP flows unfairly occupy a large portion of bandwidth left by the responsive TCP flows. This behavior continues and, under persistent congestion, unresponsive flows may eventually consume the 978-1-5090-0154-5/15 $31.00 © 2015 IEEE DOI 10.1109/CIT/IUCC/DASC/PICOM.2015.73
512
compares it with the arriving packet. Only two conditions can stop this match-drop comparisons; either a packet from different flow is selected, or a maximum “maxcomp” number of comparisons have been reached.
= ! . "
The drawing factor of CHOKe is based on the average queue size # , while the drawing factor of CHOKeD is based on current queue size . On the arrival of a packet at the queue, CHOKeD has to draw an appropriate number of drop candidate packets. Eq. (1) determines the appropriate value of the drawing factor because it includes the queue sensitivity thresholds $%& and $%#' , as well as the size of the buffer. For the flows that are coming more often to the queue, we must increase the drawing factor to punish these flows. As the queue has the tendency to be filled with the high bandwidth flows rather than with the flows that are arriving less often, the dropping probability for the high bandwidth flows will be higher too. If the current queue occupancy increases, CHOKeD increases its drawing factor to increase the punishment of the high bandwidth flows. In order to improve fairness and to cooperate with responsive flows, CHOKeD informs TCP sources by dropping an adequate number of packets to lower their transmission rates. The number of drawing packets for the match-drop comparisons is determined by Eq. (1) and Eq. (2). When a new packet pk arrives at congested buffer, the average queue size # is calculated, and CHOKeD performs the following actions, as depicted in Fig. 1. If # is less than the minimum threshold $%& , CHOKeD admits the newly arrived packet pk. If # is greater than the maximum threshold $%#' , CHOKeD does not allow pk to enter the queue. Otherwise, if the average queue size is greater than $%& but less than $%#' , CHOKeD slices the queue into two equal regions, namely the rear and the front regions. Firstly, using Eq. (1), it draws packets from the rear queue region and matches them with the flow ID of pk. If all or any of the packets from the queue has same flow ID as that of the pk, CHOKeD drops all matched packets as well as pk. If none of the candidate packets have the same ID as that of the arriving packet pk, CHOKeD returns all packets to the queue and draws packets from the front queue region using Eq. (2), before admitting the packet pk. Now CHOKeD compares the packets with the flow ID of packet pk. If any or all packets have the same flow ID as that of pk, the packet pk and all the matched packets are dropped from the queue. In the event of no matching at this moment, the drop candidate packets are restored in the queue, but pk may still be dropped with a probability that depends on the level of congestion given by RED.
As gCHOKe is simply an enhancement over CHOKe, it inherits all the shortcomings of CHOKe. There are two major shortcomings in CHOKe and gCHOKe algorithms. Firstly, although both claim fairness, their fairness significantly declines under large number of unresponsive flows. Secondly, both the schemes do not show concern about the location of drop candidate packets in the buffer, which are selected for match-drop comparisons. These two deficiencies motivate us to work for improvements in the CHOKe protocol. Moreover, besides these deficiencies of gCHOKe, another limitation is the parameter tuning for variable “maxcomp”. To address the shortcomings of CHOKe and gCHOKe, we propose a novel AQM scheme called CHOKeD that is inspired by CHOKe because of its stateless design. Experimentally, we have observed that’s packets from the unresponsive flows are accumulated more at the rear queue region rather than the front queue region. For this reason, there is a need to deal with both the queue regions distinctively. We introduce the queue region based drawing factor to increase the number of match-drop comparisons. CHOKeD is evaluated through numerous simulations and the results show that CHOKeD provides high fairness and more protection for responsive flows. The rest of the paper is organized as follows. Section II presents the proposed AQM protocol. Section III presents simulations results and Section IV concludes the paper. II.
THE PROPOSED AQM SCHEME
The main idea behind CHOKeD is that a high-bandwidth unresponsive flow is likely to have more packets in the buffer, hence, a higher probability for flow matching and consequently higher dropping. CHOKeD uses match-drop comparisons to protect the responsive flows without maintaining the per-flow state and is, therefore, capable of being deployed over network core routers. In order to punish the unresponsive flows and to restrict them from capturing the entire buffer space, CHOKeD increases the number of drop candidate packets for match-drop comparisons in proportion to the queue occupancy. A. Drawing factor On arrival of a packet, CHOKeD divides the queue into the front and rare regions to explicitly analyze the queue contents and selects a drawing factor (drop candidate packets) based on the queue region. CHOKeD draws a dynamic number of drop candidate packets from the rear queue region using Eq. (1). Thus, packets are drawn from the rear region and, in the case of a mismatch, packets are drawn from the front queue region using Eq. (2). The drawing factor is based on the current queue occupancy . As increases, CHOKeD also increases its drawing factor. CHOKeD does not introduce any extra variables and just uses the already available parameters from the system, such as current queue size and buffer size . =
( ) ()
,
(2)
B. Complexity The complexity of CHOKeD is *(+), + = 1,2,3, …, D, which depends upon number of drawn packets from the queue for the match-drop comparisons. This complexity is higher than that of CHOKe, which is *(1), but is much less than the complexity of the per-flow AQM schemes, such as CAM [7] that has *( log ) complexity. The complexity of CHOKeD is independent of the number of flows. The low complexity of CHOKeD is an attractive feature for its deployment over the network core routers.
(1)
513
$%& , # , $%#' , >? ,
start
4-
/-
/-
# = 1 @ A? # + A?
/0
/"
4"
/"
"
-
"
yes # < $%&
/5
/5
45
5
no yes
no
Fig. 2. Dumbbell topology for simulations
$%& < # < $%#' Draw packets from 9#:
UDP flows are considered at 12% of the overall network traffic [15] depicting the current practical ratio prevalent on the Internet. Delete ;+
;+ and packets from same flow?
no
;+ and packets from same flow?
Admit ;+
yes
Delete all matched packets
Draw packets from 96 C
no
A. TCP goodput Figure 3 shows the TCP goodput under RED, CHOKe, gCHOKe and the proposed CHOKeD. The number of flows in this scenario ranges from 25 to 100, containing TCP flows from 22 to 88, while UDP flows from 3 to 12. From Fig. 3, it is clear that under CHOKeD, the TCP goodput is higher with 0.063 Mb/s, while TCP goodput under other AQM protocols is: gCHOKe 0.038 Mb/s, CHOKe 0.033 Mb/s and RED 0.0025 Mb/s. Similarly, in the presence of UDP flows that increased from 6 to 12 when the numbers of flows are varied from 50 to 100, the TCP goodput under CHOKeD is still higher than the TCP goodput under gCHOKe, CHOKe and RED. Under RED, when the number of flows is 73 and 100, the TCP goodput is on a cutoff level. This reveals that RED fails to provide fair buffer space to the responsive traffic in the presence of unresponsive flows. Under CHOKeD, unresponsive flows are successfully restricted due to its enhanced match-drop mechanism. As a result, responsive flows receive a fair bandwidth allocation.
yes
end Fig. 1.
III.
B. Fairness Figure 4 shows the fairness plot under RED, CHOKe, gCHOKe and CHOKeD. Jain’s Fairness index is used to evaluate the AQM protocols [16], as in Eq. (3).
Flowchart of CHOKeD
SIMULATION RESULTS
TCP good-put (Mbps)
To validate the proposed CHOKeD algorithm, extensive simulations are carried out in ns2. The proposed algorithm is compared with other AQM protocols, namely, RED [2], CHOKe [3] and gCHOKe [14], under the dumbbell topology shown in Fig. 2., where /6 = 1 Mb/s and /7 = 10 Mb/s, 8 = 1,2, … N. Such a topology represents the real Internet traffic scenarios for evaluating fairness and has also been used in [3] and [14] for performance evaluations. The queue limit or buffer size is 100 packets and the average packet size is 1 KB. TCP flows are driven by FTP applications while UDP flows are driven by the constant bit rate (CBR) traffic with the speed 2 Mb/s, that is two times the bottleneck link capacity /0 . For all these AQM schemes, i.e., RED, CHOKe, gCHOKe and CHOKeD, minimum average queue size threshold, $%& = 40 packets; and maximum average queue size threshold, $%#' = 80 packets. .
0.07
RED
CHOKeD
gchoke
Choke
0.06 0.05 0.04 0.03 0.02 0.01 0 25
50
73
100
Number of Flows Fig. 3.
514
TCP goodput under RED, CHOKe, gCHOKe and CHOKeD
Jain Fairness Index
TABLE I. RED 1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 25
CHOKeD
gchoke
Simulation Results
Choke AQM Scheme
50
73
Fig. 4. Jain’s Fairness Index for RED, CHOKe, gCHOKe and CHOKeD
RED
CHOKeD
gchoke
Choke
Jain Fairness Index
0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 25
50
73
100
Number of Flows Fig. 5.
Jain’s Fairness Index with different RTTs
D=
I (EF GH ' )
I EF GH '
,
TCP Throughput
UDP Throughput
TCP Goodput
(Mb/s)
(Mb/s)
(Mb/s)
Fairness
RED
0.089986
0.542372
0.05794
0.38
CHOKe
0.521647
0.257291
0.390724
0.72
gCHOKe
0.543582
0.243744
0.407763
0.79
CHOKeD
0.574147
0.213571
0.436162
0.89
C. Buffer size compatibility To validate CHOKeD for the buffer size compatibility, simulations with different router buffer size are carried out. As there is a tradeoff between the buffer size and the link delay, researchers suggest routers with the small buffer size [1]. Routers with large buffer size yield high queuing delays [17]. In real networks, routers with different buffer sizes are available. Under the large buffers, unresponsive flows get more space as compared to the well-behaved responsive flows. Considering this important point, we simulate CHOKeD with the buffer of size 500 packets. For this simulation, 33 TCPs and 1 UDP flow is considered under the topology shown in Fig.2. Table I presents the simulation results with 500 packets queue limit, under RED, CHOKe, gCHOKe and CHOKeD. UDP throughputs are as follows: RED 0.54 Mb/s, CHOKe 0.26 Mb/s, gCHOKe 0.24 Mb/s and CHOKeD is the lowest with 0.21 Mb/s. TCP throughputs are: RED 0.089 Mb/s, CHOKe 0.52 Mb/s, gCHOKe 0.54 Mb/s and CHOKeD 0.57 Mb/s. Under CHOKeD, the TCP goodput is also higher than those of RED, CHOKe and gCHOKe, indicating the superior performance of CHOKeD. The fairness index values of RED, CHOKe and gCHOKe are 0.38, 0.72 and 0.79, respectively. The fairness index value of CHOKeD is 0.89, due to the lowest UDP throughput and higher TCP goodput, as compared with the other algorithms. Under CHOKeD, more bottleneck link bandwidth is available for responsive flows as more unresponsive packets are dropped due to the successful match-drop comparisons. It is clear from the results that CHOKeD affirms the buffer size compatibility.
100
Number of Flows
0.9
SIMULATION WITH 500 PACKETS BUFFER SIZE
(3)
where JK represents the throughput of flow K and denotes the number of flows. The closer the value of D is to 1, the better the fairness. The numbers of flows in this scenario are varied from 25 to 100, containing TCP flows from 22 to 88, while UDP flows from 3 to 12. Fig. 4 illustrates that the fairness of CHOKeD with 25 flows is 0.88, while the fairness under other AQM algorithms is: gCHOKe 0.80, CHOKe 0.68 and RED with 0.33. Similarly, in the presence of 100 flows having 12 unresponsive flows, the fairness of CHOKeD is still higher than that the fairness of other algorithms. In the presence of 100 flows, the fairness index values are: CHOKeD 0.42, gCHOKe 0.36, CHOKe 0.35 and RED 0.19. The high fairness value of CHOKeD confirms its ability to punish unresponsive flow more rigorously as compared to the other AQM scheme. The fairness indices of CHOKe and gCHOKe are closer, indicating that under many unresponsive streams gCHOKe tends to behave like the CHOKe algorithm. RED has the worst fairness level due to its ineffective protection to responsive flows in the presence of unresponsive flows. From Fig. 5, we conclude that in terms of fairness, CHOKeD outperforms gCHOKe, CHOKe and RED.
IV. CONCLUSION We have proposed a novel AQM scheme, called CHOKeD, to ensure the fairness among all flows of a congested router. To protect responsive flows, CHOKeD drops the unresponsive packets through match-drop comparisons. CHOKeD successfully protects responsive flows from misbehaving and unresponsive flows. The unique drawing factor of CHOKeD demonstrates successful matchdrop comparisons to control the unresponsive traffic. The performance of CHOKeD is validated through ns2 simulations and is compared with other AQM protocols. Simulation results reveal that CHOKeD provides high TCP goodput, low UDP throughput and high fairness.
515
REFERENCES [1]
[2]
[3]
[4]
[5] [6]
[7]
[8]
[9]
G. Abbas, Z. Halim, and Z. H. Abbas, “Fairness-Driven Queue Management: A Survey and Taxonomy,” IEEE Communications Surveys and Tutorials, DOI 10.1109/COMST.2015.2463121, July 2015. S. Floyd and V. Jacobson, “Random early detection gateways for congestion avoidance,” IEEE/ACM Transactions on Networking, vol. 1, no. 4, pp. 397–413, August 1993. R. Pan, B. Prabhakar, and K. Psounis, “CHOKe - a stateless active queue management scheme for approximating fair bandwidth allocation,” in Proc. Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies, INFOCOM ’00, vol. 2, 26–30 March 2000, Tel Aviv, Israel, pp. 942–951. G. Abbas, A. K. Nagar, and H. Tawfik, “On unified quality of service resource allocation scheme with fair and scalable traffic management for multiclass Internet services,” IET Communications, vol. 5, no. 16, pp. 2371–2385, Nov. 2011. S. Floyd, T. Henderson, and A. Gurtov, “The NewReno modification to TCP’s fast recovery algorithm”, IETF RFC 2582, April 1999. W. Feng, K. G. Shin, D. D. Kandlur, and D. Saha, “The BLUE active queue management algorithms,” IEEE/ACM Transactions on Networking, vol. 10, no. 4, pp. 513–528, August 2002. S. Latré, W. V. Meerssche, D. Deschrijver, D. Papadimitriou, T. Dhaene, and F. D. Turck, “A cognitive accountability mechanism for penalizing misbehaving ECN-based TCP stacks,” International Journal of Network Management, vol. 23, no. 1, pp. 16–40, January/February 2013. Y. Jiang, M. Hamdi, and J. Liu, “Self adjustable CHOKe: an active queue management algorithm for congestion control and fair bandwidth allocation,” in Proc. Eighth IEEE International Symposium on Computers and Communication, ISCC ’03, June 30–July 03 2003, Antalya, Turkey, pp. 1018–1025.
[10]
[11]
[12]
[13]
[14] [15]
[16] [17]
516
S. Athuraliya, S. H. Low, V. H. Li, and Q. Yin, “REM: Active queue management,” IEEE Network, vol. 15, no. 3, pp. 48–53, May 2001. H. Xu, T. Wu, X. Zhou, and Y. Zhu, “IP network control and AQM,”in Proc. 2004 International Conference on Machine Learning and Cybernetics, vol. 1, Shanghai, China, 2004, pp. 500–504. S. Wen, Y. Fang, and H. Sun, “Differentiated bandwidth allocation with TCP protection in core routers,” IEEE Transactions on Parallel and Distributed Systems, vol. 20, no. 1, pp. 34–47, January 2009. T. Yamaguchi and Y. Takahashi, “A queue management algorithm for fair bandwidth allocation,” Computer Communications, vol. 30, no. 9, pp. 2048–2059, June 2007. C.-Y. Ho, Y.-C. Chan, and Y.-C. Chen, “WARD: a transmission control protocol-friendly stateless active queue management scheme,” IET Communications, vol. 1, no. 6, pp. 1179–1186, December 2007. Eshete and Y. Jiang, “Generalizing the CHOKe flow protection,” Computer Networks, vol. 57, no. 1, pp. 147–161, January 2013. G. Abbas, A. K. Nagar, H. Tawfik, and J. Y. Goulermas, “Pricing and unresponsive flows purging for global rate enhancement,” Journal of Electrical and Computer Engineering, vol. 2010, Jun. 2010, Art. ID. 379652. R. Jain, The Art of Computer Systems Performance Analysis, JohnWiley & Sons, New York, NY, USA, 1991. R. Adams, “Active queue management: a survey,” IEEE Communications Surveys & Tutorials, vol. 15, no. 3, pp. 1425–1476, July 2013.
