The reliance of the Internet on the TCP/IP protocol suite suggests that ... congestion control solutions deployed in the Internet Transport Control. Protocol (TCP) [i ...
Chapter 3.3.1 Fuzzy RED: Congestion Control for TCP/IP Diff-Serv L. Rossides1, A. Sekercioglu2, A. Pitsillides1, A. Vasilakos3, S. Kohler4, P. Tran-Gia4 1 University of Cyprus, Department of Computer Science,75 Kallipoleos Street, P.O. Box 20537, 1678 Nicosia,Cyprus, Phone: +357 2 892230, Fax: +357 2 892240. 2 Monash University, Centre for Telecommunications and Information Engineering, Melbourne, Australia, Phone: +61 3 9905 3503, Fax:+61 3 9905 3454. 3 ICS-FORTH, P.O Box 1385,Hearklion,Crete,Greece. 4 University of Wurzburg, Institute of Computer Science, Am Hubland, D-97074 Wurzburg, Germany, Phone: +49-931-888-6651, Fax: +49-931-888-4601.
Key words:
TCP/IP, congestion control, Diff-Serv, Fuzzy Logic
Abstract:
Network congestion control remains a critical and high priority issue. The rapid growth of the Internet, the massive amount of data traffic it carries and increased demand to use the Internet for time-sensitive voice and video applications necessitates the design and utilization of effective congestion control algorithms. The reliance of the Internet on the TCP/IP protocol suite suggests that we must focus our efforts in this area. Existing TCP/IP protocol suite has been designed for best effort (delay tolerant) services and cannot effectively support time sensitive applications. Designing effective congestion control strategies to support such applications is known to be difficult because of the nature of services supported, and the variety of dynamic parameters involved. As a result, a number of researchers are now looking at alternative schemes that have the ability to cope with these difficulties in order to devise effective, robust congestion control techniques as an alternative (or supplement) to the traditional control approaches. One popular example of this approach is RED (Random Early Detection) [xii]. In this chapter, we present initial results of a novel approach to RED implementation, a fuzzy logic controller based RED congestion algorithm. 1
2
Chapter 3.3.1
We believe that with the support of fuzzy logic, we will be able to achieve finer tuning for packet discarding behaviours for individual flows, and so provide better quality of service to different kinds of traffic.
1.
ISSUES ON TCP/IP CONGESTION CONTROL
As the growth of the Internet increases it becomes clear that the existing congestion control solutions deployed in the Internet Transport Control Protocol (TCP) [i,ii] are increasingly becoming ineffective. It is also generally accepted that these solutions cannot easily scale up even with various proposed “fixes” [iii,iv]. Also, it is worth pointing out that the User Datagram Protocol (UDP), the other transport service offered by IP Internet, offers no congestion control. However more and more users employ UDP for the delivery of real time video and voice services. The newly developed (also largely ad-hoc) strategies [v,vi] are also not proven to be robust and effective. Since these schemes are designed with significant non-linearities (e.g. two-phase—slow start and congestion avoidance—dynamic windows, binary feedback, additive-increase multiplicative-decrease flow control etc), and they are based mostly on intuition, the analysis of their closed loop behaviour is difficult if at all possible, even for single control loop networks. Even worse, the interaction of additional non-linear feedback loops can produce unexpected and erratic behaviour [vii]. Empirical evidence demonstrates the poor performance and cyclic behaviour of the TCP/IP Internet [viii] (also confirmed analytically [ix]). This is exacerbated as the link speed increases to satisfy demand (hence the bandwidth-delay product, and thus feedback delay, increases), and also as the demand on the network for better quality of service increases. Note that for wide area networks a multifractal behaviour has been observed [x], and it is suggested that this behaviour —cascade effect—may be related to existing network controls [xi]. Based on all these facts it is becoming clear that new approaches for congestion control must be investigated.
2.
THE INADEQUACY OF RED
The most popular algorithm used for Diff-Serv implementation is RED (Random Early Discard) [xii]. RED simply sets some min and max dropping thresholds for a number of predefined classes in the router queues. In case the buffer queue size exceeds the min threshold, RED starts dropping
3.3.1. Fuzzy RED: Congestion Control for TCP/IP Diff-Serv
3
randomly packets based on a probability depending on the queue length. If the buffer queue size exceeds the max threshold then every packet is dropped, (i.e. drop probability is set to 1) or ECN (Explicit Congestion Notification) marked. The RED implementation for Diff-Serv defines that we have different thresholds for each class. Best effort packets have the lowest min and max thresholds and therefore they are dropped with greater probability than packets of AF (Assured Forwarding) or EF (Expedited Forwarding) class. Also there is the option that if an AF class packet does not comply with the rate specified it will be reclassified as a best-effort class packet. Apart from RED, many other mechanisms such as n-RED, adaptive RED, BLUE [xiii] and Three colour marking schemes were proposed for Diff-Serv queue control. EF
AF Class
Best Effort
Ye Check and traffic shaping
Priority Queue
No
Discard
RIOQueue
Max
Min
Figure 1. Diff-Serv scenario with RED queue for control
In Figure 1 we can see a simple Diff-Serv scenario where RED is used for queue control. A leaky bucket traffic shaper is used to check if the packets comply with the SLA (Service Level Agreement). If EF packets do not comply with the SLA then they are dropped. For AF class packets, if they do not comply then they are remapped into Best Effort Class packets. Both AF and Best effort packets are sharing a RIO Queue. RIO stands for RED In/Out queue, where In and Out means packets are In or Out of connection conformance agreement. For AF and Best Effort class we have different min and max thresholds. EF packets are using a separate high priority FIFO queue.
4
Chapter 3.3.1
Unfortunately in cases with extremely bursty traffic sources, the active queue management techniques used by RED are often defeated since queue lengths grow and shrink rapidly well before RED can react. The inadequacy of RED can be understood more clearly by considering the operation of an ideal queue management algorithm (see Figure 2). If the sources send at a rate of L Mbps, then the queue management algorithm should try to maintain the correct amount of packets in the queue to keep a sending rate of sources at L. While RED can achieve performance very close to this ideal scenario, it needs a large amount of buffer and correct parameterisation to achieve it and as it is shown in [xiii] it is very difficult if not impossible to find such a “global” parameterisation. The results presented later on show that FLC RED can provide such performance and queue management characteristics without any special parameterisation or tuning.
A
L Mbs
B
Source Sink Sending rate L Mbps
Queue
Figure 2. Ideal Scenario
3.
FUZZY LOGIC CONTROLLED RED
A novel approach to the RED Diff-Serv implementation is FLC RED or Fuzzy RED, a fuzzy logic controlled RED queue. To implement it, we removed the fixed max, min queue thresholds from the RED queue for each class and replaced them with dynamic network state dependant thresholds calculated using a fuzzy logic controller (FLC). As was reported in [xiii] classical RED implementations with fixed thresholds can't provide good results when we have dynamic network state changes, e.g. in the number of active sources. The FLC calculates the drop probability behavior based on two network queue state inputs: the actual queue size and the queue rate of change. In implementation we add an FLC for each Diff-Serv class of
3.3.1. Fuzzy RED: Congestion Control for TCP/IP Diff-Serv
5
service. The FLC for each class uses separate rules and sets for calculating the drop probability based on the input from the queues. Since the two input FLCs can offer better ability to linguistically describe the system dynamics we expect that we can better tune the system and the behaviour of the RED queue according to our class of service policy. The dynamic way of calculating the drop probability by the FLC comes from the fact that according to the rate of change of the queues, the current buffer size and the class the packet belongs, a different set of fuzzy rules and inferences apply. Based on these rules and inferences, the drop probability is calculated. We expect the whole procedure to be independent of the number of active sources and thus avoid the problems of fixed thresholds mentioned by other RED schemes [xiii]. With fuzzy RED not only we expect to avoid such situations but also to generally provide better congestion control and better utilization of the network. Our initial results are very encouraging. We have done an initial testing of the performance of the fuzzy-RED queue management by using the ns simulation tool with the simple network topology shown in Figure 3 (also used by other researchers for RED performance and evaluation [xii]). From the simulation results shown in Figures 4 and 5 Fuzzy RED achieves more than 99% utilization while RED and droptail fail to achieve more than 90%. As one can see from Figures 4 and 5, FLC RED presents results very closed to the ideal (as presented in Figure 2).
*
Router 1
Router 0
*
40 Mb/s 20ms delay link * All access connetions are 100 Mb/s
Figure 3. Simple network topology used for the initial simulations
The throughput goes up to the 99.7% of the total link capacity (40 Mbps link) and the average queue size is around half the capacity of the buffer while maintaining a sufficient amount of packets in the queue for achieving this high throughput. While these are results from a very basic scenario (see
6
Chapter 3.3.1
Figure 3) they demonstrate the dynamic abilities and capabilities of an FLC RED queue compared to a simple RED queue or a classical droptail queue. The results presented in Section 4 shows that these characteristics and abilities are maintained in the simulated scenarios performed so far. 45 40
Throughput
35 30 25 20 15 10 5 0 0
20
40
FLC RED
60
80
100
Time
RED Droptail
Figure 4. Throughput vs Time
70
Buffer (packets)
60 50 40
FLC RED RED
30 20 10 0 0
20
40
60
80
100
Time(s)
Figure 5. Buffer Size vs Time
120
7
3.3.1. Fuzzy RED: Congestion Control for TCP/IP Diff-Serv
4.
SIMULATION RESULTS
In Figure 3 we show the simple network topology used, and Figures 4 and 5 present the results. The buffer size was set to 70 packets (max packet size 1000 bytes), the min threshold (minth) for RED was 23 packets and the max threshold was 69 packets. The link between the two routers was set to 40 Mbps and the simulation lasted for 100 seconds. The scripts used for simulation scenario 1 (and in all other simulation scenarios presented here) were based on the original scripts written in [xii]. In the Appendix the rulebase file used by the FLC for calculating the values for the Assured traffic class is shown. There is also another set of rules (not shown here) to control the best-effort traffic flows (which produce higher rate of packet discarding probabilities). In order to show the dynamic abilities of FLC RED we simulate a different scenario with six sources (each has different delay links varying from 1ms to 9 ms) named Scenario 2. 45 43 41
Throughput
39 37 35 33 FLC RED
31
RED
29
Droptail
27 25 0
50
100
150
200
250
300
Time
Figure 6. Throughput vs Time (Scenario 2)
All sources start at approximately the same time (with less than 1ms difference) but at simulation time t=100sec three of them stop and begin again after another 100 sec. The simulation stops at t=300sec. The buffer size for this scenario is set at 140 packets and the min threshold for RED is set to 40 packets. All sources are connected with 100 Mbps link with the Router 0. Router 0 and Router 1 are connected with a 45 Mbps link. Again the simulation scripts were based on [xii]. The results for the Throughput and Queue size are presented in Figures 6 and 7 respectively.
8
Chapter 3.3.1 120
Buffer
100 80 60 40 20 0 0
50
FLCRED
100
150
200
250
Time
RED Figure 7. Buffer size vs Time (Scenario 2)
From Figures 6 and 7 one can see that at time t=100sec when half of the sources stop FLC RED immediately loses some of its throughput capacity but it stays again above the numbers achieved by RED and droptail. The reason is that FLC RED can control the queue more successfully maintain an adequate level of packets in the queue so that the throughput remains at high levels.
5.
CONCLUSIONS
Current TCP/IP congestion control algorithms cannot efficiently support new and emerging services needed by the Internet community. Diff-Serv and RED propose a solution, however in cases with extreme bursty sources (such a case is Internet) it fails to control congestion effectively. Our proposal in implementing a fuzzy logic controlled RED queue is a novel, more effective, robust, scalable and more flexible approach and avoids the necessity of any special parameterisation or tuning. Based on our past experience with successful implementations of fuzzy logic control [xiv] and from these first results we are very optimistic that this proposal will offer significant improvements on controlling congestion in TCP/IP Diff-Serv networks.
300
3.3.1. Fuzzy RED: Congestion Control for TCP/IP Diff-Serv
APPENDIX A: DEFINITIONS OF FUZZY RULES AND SETS OF THE “ASSURED” CLASS TRAFFIC PACKETS /* rulebase of Fuzzy Controlled RED Queue for Assured traffic class */ /* Loukas Rossides, Stefan Koehler & Ahmet Sekercioglu */ /* $Id: assured.flr,v 1.4 2000/08/08 04:27:15 ahmet Exp $ */ /* set the defuzzification method */ defuzzify using centroid /* Value sets for each category */ /* normalized queue length */ lingvar q on [0,1] initially 0.0 with /* Assured */ lingvalue empty is trapezoid 0 0 0.4 0.5 lingvalue moderate is trapezoid 0.4 0.5 0.70 0.80 lingvalue full is trapezoid 0.70 0.80 1.0 1.0 end /* rate of change of queue length - common to all categories */ /* in units of normalized queue length */ lingvar dq on [-1,1] initially 0.0 with lingvalue decreasing is trapezoid -0.8 -0.8 -0.2 -0.1 lingvalue zero is trapezoid -0.2 -0.1 0.1 0.2 lingvalue increasing is trapezoid 0.1 0.2 0.8 0.8 end /* output variables: */ /* drop rate probability */ lingvar pr_assured on [0.0,1.0] initially 0.0 with lingvalue zero is trapezoid -5 -5.0 0.0 0.01 lingvalue low is trapezoid 0.0 0.10 0.10 0.20 lingvalue medium is trapezoid 0.15 0.20 0.20 0.30 lingvalue high is trapezoid 0.20 0.30 0.30 1.00 end /* linguistic rules for assured (yellow) class */ if q is empty then pr_assured is zero; if q is moderate and dq is decreasing then pr_assured is zero; if q is moderate and dq is zero then pr_assured is zero; if q is moderate and dq is increasing then pr_assured is zero; if q is full and dq is decreasing then pr_assured is low; if q is full and dq is zero then pr_assured is medium; if q is full and dq is increasing then pr_assured is high;
9
10
Chapter 3.3.1
REFERENCE: [i] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM88, 1988.
[ii] W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997. [iii] W. Stevens, TCP/IP Illustrated, Volume 1 The Protocols', Addison-Wesley, 1994. [iv] V. Jacobson, R. Braden, D. Borman, TCP Extensions for High Performance, RFC 1323, May 1992. [v] K.K. Ramakrishnan, and S. Floyd, A proposal to add explicit congestion notification (ECN) to IP, draft-kksjf-ecn-03.txt, October 1998. (RFC2481, January 1999). vi [ ] Braden et al, Recommendations on Queue Management and Congestion Avoidance in the Internet, RFC2309, April 1998. [vii] C.E. Rohrs and R. A. Berry and S. J.O'Halek, A Control Engineer's Look at ATM Congestion Avoidance, IEEE Global Telecommunications Conference GLOBECOM'95, Singapore, 1995. [viii] J. Martin, A. Nilsson, The evolution of congestion control in TCP/IP: from reactive windows to preventive flow control, CACC Technical Report TR-97/11, North Carolina State University, August 1997. [ix] T.V. Lakshman and U. Madhow, The Performance of TCP/IP for Networks with High Bandwidth Delay Products and Random Loss, IEEE/ACM Transactions on Networking, vol. 5, pp. 336-350, June 1997. [x] A.Feldmann, A.C. Gilbert, W. Willinger, “Data Networks as cascades: Investigating the multifractal nature of the Internet WAN traffic”, SIGCOMM 98, Vancouver, 1998. [xi] A. Feldmann, P. Huang, A.C. Gilbert, W. Willinger, Dynamics of IP traffic: A study of the role of variability and the impact of control, To appear at ACM/SIGCOMM 1999. [xii] S. Floyd and V. Jacobson, "Random Early Detection Gateways for Congestion Avoidance", ACM/IEEE Transaction on Networking, 1(4): pgs 397-413, August 1993 [xiii] Wu-chang Feng, "Improving Internet Congestion Control and Queue Management Algorithms", PhD Dissertation, University of Michigan, 1999 [xiv] A. Pitsillides, A. Sekercioglu, G. Ramamurthy, “Effective Control of Traffic Flow in ATM Networks using Fuzzy Explicit Rate Marking (FERM)”, IEEE JSAC, Vol. 15, Issue 2, Feb 1997, pp.209-225
