Fuzzy logic controlled RED: congestion control in TCP ... - Springer Link

Focus

Soft Computing 8 (2003) 79–92 Ó Springer-Verlag 2003 DOI 10.1007/s00500-002-0248-9

Fuzzy logic controlled RED: congestion control in TCP/IP differentiated services networks C. Chrysostomou, A. Pitsillides, L. Rossides, A. Sekercioglu

79 Abstract The use of the Internet for time-sensitive services, such as voice and video applications, requires a predictable quality of service. The TCP/IP differentiated services (DiffServ) architecture was introduced to achieve such performance. Network congestion control, however, still remains a critical and high priority issue. A number of researchers are looking at alternative schemes such as random early detection (RED) and its variants to handle congestion. In this paper we present the results of a fuzzy logic control approach to the implementation of RED – Fuzzy-RED. We believe that with fuzzy logic we are able to use linguistic knowledge to implement better understood nonlinear probability discard functions, achieve better differentiation for packet discarding behaviors for aggregated flows, and so provide better quality of service to different kinds of traffic whilst maintaining high utilization. Keywords Fuzzy logic control, Congestion control, TCP/IP, Diff-Serv, RED

1 Introduction It is generally accepted that the problem of network congestion control remains a critical issue of high priority, especially given the growing size, demand, and speed (bandwidth) of the increasingly integrated services network. One could argue that network congestion is a problem that is unlikely to disappear in the near future. As the growth of the Internet increases it becomes clear that the existing congestion control solutions deployed in the Internet transport control protocol (TCP) [22, 44] are becoming less effective. It is also generally accepted that these solutions cannot easily scale up even with various proposed ‘‘fixes’’ [24, 45, 21, 7], new approaches [16, 15] and architectures [6, 19]. The newly developed (also largely ad-hoc) strategies [41], [5] are also not proven to

Published online: 14 July 2003 C. Chrysostomou (&), A. Pitsillides, L. Rossides Department of Computer Science, University of Cyprus, 75 Kallipoleos Street, P.O. Box 20537, 1678 Nicosia, Cyprus e-mail: [email protected] A. Sekercioglu Centre for Telecommunications and Information Engineering, Monash University, Melbourne, Australia

be robust and effective. Empirical evidence demonstrates the poor performance and cyclic behavior of the TCP/IP Internet [28] (also confirmed analytically [26]). This is exacerbated as the demand on the network for better quality of service increases. Based on this experience it is clear that improvements to congestion control are needed. The existing TCP congestion avoidance mechanisms and its variants, while necessary and powerful, are not sufficient to provide good service in all circumstances [5]. Basically, there is a limit to how much control can be accomplished from the edges of the network. Some mechanisms are also needed in the routers as suggested by several researchers [16, 5, 41, 40]. The need for such gateway control has been known for some time [22]. The RED algorithm [16] was proposed as an active queue management (AQM) approach. RED proposes a strategy for when to start dropping packets and which packets to drop. The RED approach can be contrasted with the tail drop (TD) queue management approach, employed by common Internet routers, where the policy for discarding arriving packets is based on the overflow of the output port buffer. Contrary to TD, active queue management mechanisms [5] start dropping packets earlier in order to be able to notify traffic sources about the incipient stages of congestion. RED has been designed to replace TD and is currently implemented in commercially available routers, but it is not as yet widely deployed (see discussion, in Sect. 3). The congestion control problem in the Internet is further exacerbated as the Internet is increasingly transformed into a multiservice high-speed network; see for example the integrated services (Int-Serv) and Diff-Serv proposed architectures [6, 19, 3]. Currently, interest is mainly for Diff-Serv architectures, as scalability problems have been reported for Int-Serv. Recently, active queue management mechanisms (e.g. RED) have been proposed [3, 8] within the framework of the Internet Diff-Serv architecture to preferentially drop packets. Apart from RED, many variants of RED, such as n-RED, adaptive RED [11], RIO [8], BLUE [12, 13] and Three Color marking schemes were proposed for Diff-Serv control. In this paper, we aim to use the reported strength of fuzzy logic in controlling complex and highly nonlinear systems to address congestion control problems in DiffServ. We draw upon the vast experience, in both theoretical and practical terms, of computational intelligence control (fuzzy control) in the design of the control algorithm [36]. In particular, we aim to exploit some well known advantages of fuzzy logic control [36], such as:

an ability to quickly express the control structure of a system using a priori knowledge; less dependence on the availability of a precise mathematical model; easy handling of the inherent nonlinearities; and easy handling of multiple input signals.

80

The application of fuzzy control techniques to the problem of congestion control in networks is suitable due to the difficulties in obtaining a precise mathematical model using conventional analytical methods. Moreover, traffic congestion on the Internet is a concept, which is well understood; therefore it is possible to obtain simple linguistic rules for congestion control. Our design of a fuzzy control system for Diff-Serv networks is based on a fuzzy logic controlled RED queue, which can provide effective control in the presence of dynamic network state changes. A fuzzy inference engine (FIE) is designed, which uses separate linguistic rules for each predefined class in the router queues to preferably drop packets in Diff-Serv networks. The FIE output is the drop rate probability that is calculated based on two inputs: the instantaneous queue length and the rate of change of queue length. Through simulations the proposed fuzzy logic strategy is shown to be robust with respect to traffic modeling uncertainties and system nonlinearities, yet provide tight control and so offers good service. There is increasing empirical knowledge gathered about RED and its variants, and several ‘rules of thumb’ have appeared in many papers. In this paper we only attempt to highlight the potential of the methodology, and choose a simple rule base and simulation examples. The fuzzy knowledge base is devised based on heuristic methods and experience. Other methods, such as use of the fuzzy proportional integral (PI) [31], will be investigated in future studies. The paper is organized as follows. Section 2 reviews the Diff-Serv architecture and Sect. 3 discusses RED and its variants, and issues of concern. In Sect. 4 we briefly review some of the properties of computational intelligence and fuzzy logic control and present our proposed Fuzzy-RED implementation for Diff-Serv. Then Sect. 5 presents simulative examples and discusses the performance of Fuzzy-RED. Finally in Sect. 6 we present our conclusions.

router can forward them. This can be done through a service level agreement (SLA) during the connection setup. In order to preserve this property on an end-to-end basis, EF requires traffic shaping and reshaping in the network. Although there is no specific method set for this, it will most probably be a leaky-bucket buffering algorithm. The AF-PHB group provides delivery of IP packets in four independently forwarded AF classes. Within each AF class two or three drop preference levels are used to differentiate flows. The idea behind AF is to preferentially drop best-effort packets and non-contract conforming packets when there is congestion. By limiting the amount of AF traffic in the network and by managing the best-effort traffic appropriately, routers can ensure low loss behavior to packets marked with the EF-PHB. To differentiate aggregated traffic classes, Diff-Serv uses the ToS (type of service) field bits in the IP header, which are now renamed as ‘‘DS (differentiated services) field’’ [34]. Figure 1 shows an example of the basic Diff-Serv architecture approach. Note that the priorities are set at the edges of the network, which reduces the complexity and makes the proposed architecture scalable. However, no measures are taken to assure that the priorities would actually mean something when the packet enters the Internet (leaves the edge router). Therefore the Diff-Serv provides only a rudimentary QoS, without any quantified guarantees. Diff-Serv tries to provide some QoS using a differentiated services aware congestion control algorithm. Recently, active queue management mechanisms (e.g. RED and its variants) have been proposed [3, 8], within the framework of the Internet differentiated services architecture. These are discussed in the next section.

3 Diff-Serv congestion control: RED and its variants The most popular algorithm used for Diff-Serv implementation are based on random early discard (RED) [16].

2 New Internet architectures: Diff-Serv Since Int-Serv failed to be adopted for widespread use, the Internet engineering task force (IETF) proposed a more evolutionary approach that did not require significant changes to the Internet infrastructure and provided differentiation of services (Diff-Serv) [3]. The Diff-Serv working group [19] has defined two broad aggregate behaviour groups: the expedited forwarding (EF) per-hop behaviour (PHB) [20] and the assured forwarding (AF) PHB [17]. The EF-PHB can be used to build a low loss, low latency, low jitter, assured bandwidth end-to-end service, thus indirectly providing some quality of service. In order to ensure that every packet marked with EF receives this service, EF requires from every router to allocate enough forwarding resources so that the rate of incoming EF packets is always less than or equal to the rate at which the Fig. 1. An example of the Diff-Serv architecture

81

Fig. 2. Drop probability in RED and RIO (Figures not drawn to scale) [8]

RED simply sets some minimum and maximum dropping thresholds in the router queues. If the buffer queue size exceeds the minimum threshold, RED starts randomly dropping packets based on a probability depending on the average queue length (see Fig. 2). If the buffer queue size exceeds the maximum threshold then every packet is dropped. The RED implementation for Diff-Serv defines different thresholds for each class. Best effort packets have the lowest minimum and maximum thresholds and are dropped with greater probability than packets of assured forwarding (AF) or expedited forwarding (EF) class. Also, there is the option that if an AF class packet does not comply with the rate specified it is reclassified as a best-effort class packet. In Fig. 3 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 service level agreement (SLA). If EF packets do not comply they are dropped. For AF class packets, if they do not comply they are remapped into Best Effort Class packets. Both AF and Best Effort packets share a RIO [8] Queue. RIO stands for RED In/Out queue, where ‘‘In’’ and ‘‘Out’’ mean packets are in or out of the connection conformance agreement. EF packets use a separate high priority FIFO queue. For AF and Best Effort class we have different minimum and maximum thresholds (see Fig. 2). RIO uses the same mechanism as in RED, but is configured with two different sets of parameters, one for ‘‘In’’ packets, and one for ‘‘Out’’ packets. The discrimination against ‘‘Out’’ packets is created by carefully choosing the parameters of minimum and maximum thresholds, and maximum drop probability. As illustrated in Fig. 2, RIO is more aggressive in dropping ‘‘Out’’ packets. It drops ‘‘Out’’ packets much earlier than it drops ‘‘In’’ packets; this is done by choosing the minimum threshold for ‘‘Out’’ packets smaller than the minimum threshold for ‘‘In’’ packets. It also drops ‘‘Out’’ packets with a higher probability, by setting the maximum drop probability for ‘‘Out’’ packets higher than the one for ‘‘In’’ packets. The properties of RED and its variants have been extensively studied in the past few years. It is becoming clear

that for successful implementation of RED based AQM (or its variants) for Diff-Serv, there are still a number of unresolved issues. These include: Problems with performance of RED under different scenarios of operation and loading conditions. For example, the influence of: the moving average of the Queue Occupancy on the responsiveness of control; the Loss Function on the congestion control feedback mechanism; and the Buffer Size to the reaction time of the congestion controller [25]. Note that most of the existing studies are obtained with simulations suggesting modifications to the algorithm. Numerous RED variants (e.g. [27, 35, 11, 13]) have been proposed, perhaps motivated by the difficulty in understanding the dynamics of RED completely. In [18] a comparative evaluation of RED with standard parameter settings, RED with optimal parameter settings [47], and Gentle RED found: no performance improvements with RED compared to Tail Drop that may justify deployment of RED in current backbone by ISPs; performance of RED with standard parameters setting exhibits higher

Fig. 3. Diff-Serv scenario with RED queue for control

82

only from the academic research community [46, 42], but also from industry [1]. Fuzzy logic controllers (FLCs) may be viewed as alternative, non-conventional way of designing feedback controllers where it is convenient and effective to build a control algorithm without relying on formal models of the system and control theoretic tools. The control algorithm is encapsulated as a set of commonsense rules. Fuzzy logic controllers have been applied successfully in control systems for which analytical models are not easily obtained or the model itself, if available, is too complex and highly non-linear. In recent years, a number of research papers using fuzzy logic investigate solutions to congestion control issues, especially to ATM networks were published. A survey is given in [42]. Our approach to the RED Diff-Serv implementation is Fuzzy-RED, a fuzzy logic controlled RED queue. To implement it, we remove the fixed maximum and, minimum queue thresholds from the RED queue for each class, and replace them with dynamic network state dependant thresholds calculated using a fuzzy inference engine (FIE) [39]. As discussed earlier, RED implementations with fixed thresholds cannot provide good results in the presence of dynamic network state changes, for example, a change to the number of active sources. The FIE dynamically calculates the drop probability behavior based on two network-queue state inputs: the instantaneous queue size and the queue rate of change. In implementation we add an FIE for each Diff-Serv class of service. The FIE uses separate linguistic rules for each class to 4 Fuzzy logic and implementation of fuzzy-RED for Diff-Serv calculate the drop probability based on the input from the queues (see Figs. 4 and 5). Usually multi-input FIEs make Computational intelligence (CI) [2, 37] can be defined it easier to describe the system dynamics linguistically. We indirectly by observing the exhibited properties of a expect that we can tune the system better, and improve the system that employs CI components [2]: ‘‘A system is computationally intelligent when it: deals behavior of the RED queue according to our class of service policy. The dynamic way of calculating the drop only with numerical (low-level) data, has a pattern recognition component, and does not use knowledge in the AI probability by the FIE comes from the fact that according sense (symbolically); and additionally, when it begins to to the rate of change of the queues, the current buffer size, and the packet’s class belongs, a different set of fuzzy exhibit: rules, apply. Based on these rules and inferences, the drop computational adaptivity; probability is calculated more dynamically than the classic computational fault tolerance; RED approach. This point can be illustrated by observing speed approaching human-like turnaround and the visualization of the decision surfaces of the FIEs used error rates that approximate human performance. in the Fuzzy-RED scheme (see Figs. 6 and 7). An inspection of these decision surfaces and the linguistic rules The major building blocks of CI are artificial neural shown in Figs. 4 and 5 provides hints on operation of networks, fuzzy logic, and evolutionary computation.’’ While these techniques are not a panacea (and its im- Fuzzy-RED. The rules for the ‘‘assured’’ class shown in portant to view them as supplementing proven traditional Fig. 4 are more aggressive about decreasing the probability techniques), we are beginning to see a lot of interest not of packet drop than increasing it sharply. There is only one dependency on the load situation than other mechanisms, indicating that fine tuning of the RED parameters is not sufficient to cope with undesired RED behavior; gentle RED capable of resolving some of the headaches on RED but not all. Tuning of RED parameters has been an inexact science for some time now, so much so that some researchers have advocated against using RED, in part because of this tuning difficulty [23, 29]. Recently, attempts have been made to evaluate the performance of RED analytically. In [30, 4] the dependence of RED performance with respect to bursty traffic is studied. An approach to investigate RED in the presence of feedback traffic is presented in [38] where a source consists of a 3-state Markov model. In [25] the sources behave as defined in the TCP Reno protocol. In [14] authors investigated issue of recommendations of RED parameters and gave guidelines for choosing them. In [32] a more formal, control theoretic stand-point is adopted to also investigate issue of recommending settings for the RED parameters. In [47] quantitative models on how to set RED parameters with TCP traffic are derived. The correct tuning of RED implies a ‘‘global’’ parameterisation that is very difficult, if not impossible to achieve as shown in [12]. The results presented later show the potential of Fuzzy-RED to provide such desirable performance and queue management characteristics without any special parameterisation or tuning.

Fig. 4. Linguistic rules for the assured class traffic packets

Fig. 5. Linguistic rules for the best effort class traffic packets

Fig. 6. Decision surface of the fuzzy inference engine of the assured class – the control surface is shaped by the rule base and the linguistic values of the linguistic variables

potential of the methodology, and choose a simple Rule Base and simulation examples. The fuzzy knowledge base is devised based on heuristic methods and experience. Usually, to define the linguistic rules of a fuzzy variable, Gaussian, triangular or trapezoidal shaped membership functions are used. Since triangular and trapezoidal shaped functions offer more computational simplicity, we have selected them for our rule base. The rule base is fine tuned by observing the progress of simulation, such as packet loss occurrences and throughput curves. The tuning can be done with different objectives in mind. For example, any gain in throughput must be traded off against a possible increase in the delay experienced at the terminal queues. However, since the tuning of the fuzzy rules is intuitive, and can be related in simple linguistic terms with user experience, it should be a straightforward matter to achieve an appropriate balance between a tolerable end-to-end delay, and the increase in throughput. Alternatively, an adaptive fuzzy logic control method [43] can be used which can tune the parameters of the fuzzy logic controller on line, using measurements from the system. The tuning objective can be based on a desired optimization criterion, for example, a trade-off between maximization of throughput with minimization of endto-end delay experienced by the users. We expect the whole procedure to be independent of the number of active sources and thus avoid the problems of fixed thresholds employed by other RED schemes [12]. With Fuzzy-RED, not only do we expect to avoid such situations but also to generally provide better congestion control and better utilization of the network, especially by introducing additional input variables and on-line (dynamic) adaptivity of the rule base (self-tuned).

5 Simulation results In this section we evaluate the performance of Fuzzy-RED Fig. 7. Decision surface of the fuzzy inference engine of the best using simulation and compare results with other published effort class – the control surface is shaped by the rule base and the work. The implementation of the traffic sources is based on a recent version of ns-2 [33] simulator (Version linguistic values of the linguistic variables 2.1b8a). Five simulation scenarios are presented. Scenario 1 is a simple scenario used for initial evaluation and test of rule that results in increasing drop probability, whereas Fuzzy-RED. Scenarios 2–4 show the behavior of Fuzzytwo rules set the drop probability to zero. If we contrast RED under different network conditions using only TCP/ this with the linguistic rules of the ‘‘best effort’’ class FTP traffic. Finally in Scenario 5 we introduce web traffic. packets, shown in Fig. 5, we see that more rules lead to an increase in drop probability, and so more packet drops 5.1 than the assured traffic class. These rules reflect the Scenario 1 particular views and experiences of the designer, and are Initial testing of the performance of the Fuzzy-RED easy to relate to human reasoning processes and gathered queue management use of the simple network topology experiences. In this paper we only attempt to highlight the shown in Fig. 8 (also used by other researchers for RED

83

84

performance and evaluation [16]). The buffer size was set to 70 packets (maximum packet size 1000 bytes), the minimum threshold for RED was 23 packets and the maximum threshold was 69. The link between the two routers was set to 40 Mbps and the simulation lasted for 100 s. The scripts used for simulation Scenario 1 (and in all other simulation scenarios presented here) were based on the original scripts written in [16]. The rule base files used for scenario 1 were written without any previous study on how they can affect the performance of Fuzzy-RED. After an extensive series of simulations and analysis of their results a refined set of rule base files was created (Figs. 4 and 5). These files was used in the rest of the simulation scenarios (Scenarios 2–5) without any change in order to show the capabilities of Fuzzy-RED in various scenarios using different parameters. From the simulation results shown in Figs. 9 and 10 Fuzzy-RED achieves more than 99% utilization while RED and Tail Drop fail to achieve more than 90%. 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 number of packets in the queue to achieve this high throughput. While these are results from a very basic scenario (see Fig. 8) they demonstrate the dynamic abilities and capabilities of an FIE RED queue compared to a simple RED queue or a classical Tail Drop queue. The

results presented in the following simulation scenarios shows that these characteristics and abilities are maintained under all tested conditions without changing any parameters of Fuzzy-RED.

5.2 Scenarios 2–4 In order to show the dynamic abilities of Fuzzy-RED we simulate various scenarios under a new network topology. In this topology we have five sources (each has different delay links varying from 1 to 8 ms) sending traffic to five other sinks through a link connecting two routers. The link bandwidth is set to 45 Mbps in all cases. The propagation delay between the two routers varies from 10 to 20 ms. The TCP window also varies from 100 to 150 packets. The buffer size is set to 140 packets. For RED, the minimum threshold is set to 45 packets and the maximum threshold to 135 packets. The new network topology used in this series of simulation scenarios is shown in Fig. 11. The link propagation delay and the TCP window were changed in order to show how Fuzzy-RED behaves under different network conditions using the same parameters and rules. By increasing the TCP window we create conditions for more traffic and by limiting the delay we see the response time of the algorithm. We present results from three simulations (simulation scenarios 2–4). In Scenario 2 the link delay between the routers is set to 10 ms and the TCP window to 100 packets. In Scenario 3 we keep the same link delay between the routers as in Scenarios 2 at 10 ms but increase the TCP window to 150 packets. In Scenario 4 we keep the same TCP window as in Scenario 3 (at 150 packets) but double the routers link delay from 10 to 20 ms. From Fig. 12 we see that although we have increased the number of sources sending data, Fuzzy-RED manages to keep the queue size almost constant and significantly better than RED. What is more important is that Fuzzy-RED matches a near 100% throughput (99.57%), see Fig. 13, while packet drops are kept at very low levels Fig. 8. Scenario 1 – Simple network topology used for the initial (Fig. 14) compared to the number of packets-bytes simulations sent (Fig. 15).

Fig. 9. Scenario 1 – Throughput vs time

It was important to see how Fuzzy-RED will behave in These results show clearly that Fuzzy-RED manages to adequately control the queue size while keeping a higher cases of extreme traffic (created by simply increasing the than RED throughput (97.11% compared with 99.57% of TCP window to 150). The simulations run under these parameters were named Scenario 3. As expected, the Fuzzy-RED). drops were increased by 10% but the throughput was nearly 100%. As we see from Figs. 16 and 17 Fuzzy-RED clearly outperforms RED in both throughput and queue behavior. Note that the queue behavior of Fuzzy-RED is also starting to show cyclic behavior. Fine, or adaptive tuning may be used in this case. Fuzzy-RED delivers 99.62% throughput where RED achieves only 96.97%. It is also important to note that the rate packets are transmitted is also kept at an almost constant rate (see Fig. 18). From Fig. 19 we can see that the QoS is also maintained by providing fewer drops in the Assured class than in the Best-Effort class. Scenario 4 uses the same network topology as scenario 3 but the link delay between the routers is increased from 10 to 20 ms. In this scenario we test the behaviour of the algorithm under greater delays. Figure 20 shows that the queue is maintained at adequate levels and this is shown Fig. 10. Scenario 1 – Buffer size vs time better in Fig. 21 where the throughput is near 100% and

Fig. 11. Network topology for simulation scenarios 2–4

Fig. 12. Scenario 2 – Buffer size vs time (FuzzyRED dark line, RED grey)

85

86

Fig. 13. Scenario 2 – Throughput vs time (FuzzyRED dark line, RED grey)

Fig. 14. Scenario 2 – Packet Drops with FuzzyRED algorithm (Best effort packets dark line, Assured packets grey)

Fig. 15. Scenario 2 – Bytes transmitted with Fuzzy-RED algorithm (Best effort bytes dark line, Assured bytes grey)

87

Fig. 16. Scenario 3 – Throughput vs time (Fuzzy-RED dark line, RED grey)

Fig. 17. Scenario 3 – Buffer size vs time (Fuzzy-RED dark line, RED grey)

[18] and [9] and is summarized in Table 1. The implementation of the traffic sources is based on a recent version of the ns-2 simulator (version 2.1.8ba). All results presented for this scenario were extracted from the ns-2 simulation trace file. We run the simulation three times for 5000 s each in order to enhance the validity of the results. We use TCP/ SACK with a TCP window of 100 packets. Each packet 5.3 has a size of 1514 bytes. For the Tail Drop queue we Scenario 5 define a buffer size of 226 packets. We use AQM (FuzzyIn scenario 5 we use the network topology presented in Fig. 23, used in [18], and compare Fuzzy-RED with RIO. RED or RIO) in the queues of the bottleneck link between Half of the sources are TCP/FTP and the other half TCP/ router 1 and router 2. All other links have a simple Tail Web-like Traffic. Web-like traffic sources traffic are tagged Drop queue. The importance of this scenario is that it as assured class traffic and the FTP traffic as best effort. compares and evaluates not simply the performance of an algorithm but the performance in implementing a new IP The choice of distributions and parameters is based on clearly better than RED (98.57% for Fuzzy-RED and only 93.91% for RED). In Fig. 22 we see that a level of differentiation is maintained since assured traffic is transmitted at a near constant rate while best-effort packets show a transient behavior (explained also by the longer link delay).

88


Fig. 19. Scenario 3 – Packet Drops with Fuzzy-RED algorithm (Best effort packets dark line, Assured packets grey)

network architecture, Diff-Serv. This means that we want to check whether Fuzzy-RED can provide the necessary congestion control and differentiation and ensure acceptable QoS in a Diff-Serv network. We also attempt to compare Fuzzy-RED with RIO (a RED based implementation of Diff-Serv). From the results we see that although Fuzzy-RED and RIO show similar behaviour, Fuzzy-RED appears to provide better control of the flow rate across the network. From Fig. 24 we see the throughput behaviour. Throughput here means the rate at which traffic arrives at a link (in this case the link connecting router1 with router2) before entering any queue. So it is the total traffic arriving at router1 (both FTP and Web-like traffic). From the graph RIO seems to stabilise its throughput around 10.25 Mbps (note that the link

speed is limited to 10 Mbit/s). This means that it can’t effectively control the rate at which the sources are sending traffic. Around t ¼ 2500 s we see a small ascending step. At that point the traffic increases further from 10.1 Mbps to a 10.25 Mbps. This means that we have an increase of drops and therefore a decrease of ‘goodput’. We define goodput as the traffic rate traversing a link minus all dropped packets and all retransmitted packets. From Fig. 25 we see that Fuzzy-RED delivers a steady goodput around 9.9 Mbps while RIO has a decrease from 9.9 to 9.8 due to dropped packets that create retransmissions. The difference is not as important as the fact that Fuzzy-RED seems to provide a more stable behaviour. This result along with the previous encourages us to proceed with further testing in the future.

89

Fig. 20. Scenario 4 – Buffer size vs time (Fuzzy-RED dark line, RED grey)

Fig. 21. Scenario 4 – Throughput vs time (Fuzzy-RED dark line, RED grey)

6 Conclusions Current TCP/IP congestion control algorithms cannot efficiently support new and emerging services needed by the Internet community. Diff-Serv and RED/RIO propose a solution. However, in many reported cases, with extreme bursty sources (as in the Internet), it fails to effectively control congestion. Our proposal in implementing a fuzzy logic controlled Diff-Serv RED queue is a novel, more effective, robust, scalable, and more flexible approach. In this paper the design of the fuzzy knowledge base is kept simple. It avoids the need for any special parameterization or tuning, apart from the linguistic interpretation of system behavior. We have

successfully used the reported strength of fuzzy logic and have addressed limitations of existing RED, and RED variant algorithms. This is clearly shown from the simulative evaluation. For example, in the scenarios described, Fuzzy-RED behaves well and delivers almost identical throughput results under various conditions without any retuning or parameterization. Fuzzy-RED can also perform equally well using homogeneous or heterogeneous traffic sources (in this case TCP/FTP traffic and TCP/Web-like traffic) without any change in the way it is defined or needing any special tuning. We believe that future work can include: further refinement of the rule base, self-tuning, or different fuzzy based control strategies, such as fuzzy proportional integral

90


Fig. 23. Scenario 5 – Network Topology (Half of the sources are TCP/FTP and the other half TCP/Web-like Traffic).

(PI) controllers [31] for the design of the fuzzy rule base and its tuning. Of course, many open issues still require investigation. These include: stability issues; fairness; robustness under various operating conditions, including a large number of geographically dispersed sources with traffic demands from classical TCP/IP traffic to Web-like traffic and real time traffic; complexity; and scalability. Another issue to investigate is how best to use existing empirical knowledge and ‘rules of thumb’, gathered by several researchers for the design of the fuzzy control rule base. From the results presented and past experience with successful implementations of fuzzy logic control [39], we

Table 1. Distributions and parameters for Web-like traffic

Distribution Mean Shape

Inter-page time

Objects per Interobject page time

Object size

Pareto 50 ms 2

Pareto 4 ms 1.2

Pareto 12 KB 1.2

Pareto 0.5 ms 1.5

are very optimistic that the fuzzy control methodology will offer significant improvements in congestion in TCP/IP Diff-Serv networks.

9. Feldmann A, Gilbert AC, Huang P, Willinger W (2000) Dynamics of IP Traffic: A study of the role of variability and the impact of control. Proceedings of ACM, SIGCOMM 2000 10. Feldmann A, Gilbert AC, Willinger W (1998) Data Networks as cascades: Investigating the multifractal nature of the Internet WAN traffic. SIGCOMM 98, Vancouver 11. Feng W, Kandlur D, Saha D, Shin K (1999) A self-configuring RED gateway. IEEE INFOCOM’99, New York 12. Feng W (1999) Improving Internet Congestion Control and Queue Management Algorithms. PhD Dissertation, University of Michigan 13. Feng W, Kandlur D, Saha D, Shin K (1999) Blue: A New Class of Active Queue Management Algorithms. Technical Report UM CSE-TR-387–99 14. Firoiu V, Borden M (2000) A study of active queue management for congestion control. IEEE Infocom 2000, Tel Aviv 15. Floyd S, Fall K (1999) Promoting the use of end-to-end congestion control in the Internet, IEEE/ACM Transact Networking 7(4): 458–472 16. Floyd S, Jacobson V (1993) Random early detection gateways for congestion avoidance, IEEE/ACM Trans. on Networking 1(4): 397–413 Fig. 24. Scenario 5 – Throughput vs time (Link bandwidth is 17. Heinamen J, Baker F, Weiss W, Wroclawski J (1999) Assured limited to 10 Mbit/s. Any excess above 10 Mbit/s will be lost and Forwarding PHB Group. RFC 2597 will require to be retransmitted) 18. Iannaccon G, Brandauer C, Ziegler T, Diot C, Fdida S, May M (2001) Tail Drop and Active Queue Management Performance for bulk-data and Web-like Internet Traffic. 6th IEEE Symposium on Computers and Communications, Hammamet 19. IETF Differentiated Services Working Group (http:// www.ietf.org/html.charters/diffserv-charter.html) 20. Jacobson V, Nichols K, Poduri K (1999) An Expedited Forwarding PHB. RFC 2598 21. Jacobson V, Braden R, Borman D (1992) TCP Extensions for High Performance, RFC 1323 22. Jacobson V (1988) Congestion Avoidance and Control. ACM SIGCOMM88 23. Jeffay MCK, Ott D, Smith F (2000) Tuning Red for web traffic. ACM/SIGCOMM 24. Karn P, Partridge C (1987) Improving round-trip time estimates in reliable transport protocol. ACM SIGCOMM87 25. Kohler S, Menth M, Vicari N (2000) Analytic Performance Evaluation of the RED Algorithm for QoS in TCP/IP. Research Report Series, Networks University of Wurzburg, Institute of Computer Science, Report No. 259 Fig. 25. Scenario 5 – Goodput vs time (This is the useful 26. Lakshman TV, Madhow U (1997) The Performance of TCP/IP throughput, i.e., retransmissions have been removed) for Networks with High Bandwidth Delay Products and Random Loss. IEEE/ACM Transactions on Networking, 5: 336–350 27. Lin D, Morris R (1997) Dynamics of random early detection. References ACM SIGCOMM Computer Commun Rev 27: 127–136 1. Azvine B (1997) ERUDIT Technical committee D on Traffic 28. Martin J, Nilsson A (1997) The evolution of congestion and Telecommunications: application of soft computing control in TCP/IP: from reactive windows to preventive flow techniques to the telecommunication domain, Aachen control. CACC Technical Report TR-97/11, North Carolina 2. Bezdek JC (1994) In: Zurada JM et al (Eds) What is ComState University putational Intelligence: Imitating Life. IEEE Press, pp 1–12 29. May M, Bonald T, Bolot JC (2000) Analytic Evaluation of RED 3. Blake S et al (1998) An architecture for Differentiated Performance. IEEE Infocom 2000, Tel Aviv Services. RFC 2475 30. May M, Bolot JC, Jean-Marie A, Diot C (1999) Simple 4. Bonald T, May M, Bolot JC (2000) Analytic evaluation of RED performance models of differentiated services schemes for the performance. IEEE INFOCOM’2000, Tel Aviv internet. IEEE INFOCOM’99, New York, USA 5. Braden et al (1998) Recommendations on Queue Manage31. Misir D, Malki A, Chen G (1996) Design and analysis of a ment and Congestion Avoidance in the Internet. RFC2309 fuzzy proportional-integral-derivative controller, Fuzzy Sets 6. Braden R, Clark D, Shenker S (1994) Integrated services in and Systems 79: 297–314 the internet architecture: an overview. RFC 1633 32. Misra V, Gong WB, Towsley D (2000) Fluid-based Analysis of 7. Brakmo L, Peterson L (1995) TCP Vegas: End to end a Network of AQM Routers Supporting TCP Flows with an congestion avoidance on a global internet, IEEE J Selected Application to RED. ACM/SIGCOMM2000 Areas Commun. 13(8): 1465–1480 33. Network Simulator, ns-2, Homepage, http://www.isi.edu/ 8. Clark D, Fang W (1998) Explicit allocation of best effort nsnam/ns/ packet delivery service. IEEE/ACM Transact Networking 6(4): 34. Nichols K et al (1998) Definition of the differentiated Services 362–373 Field in the Ipv4 and Ipv6 Headers. RFC 2474

91

92

35. Ott TJ, Lakshman TV, Wong LH (1999) SRED: Stabilized RED. IEEE INFOCOM’99, New York, USA 36. Pedrycz W, Vasilakos AV (eds) (2000), Computational Intelligence in Telecommunications Networks. CRC Press, ISBN: 0-8493-1075-X 37. Pedrycz W (ed) (1998) Computational Intelligence: An Introduction. CRC Press 38. Peeters S, Blondia C (1999) A discrete time analysis of random early detection with responsive best-effort traffic. Technical Report 257TD(99)29, COST-257, MC meeting, Cyprus 39. Pitsillides A, Sekercioglu A, Ramamurthy G (1997) Effective Control of Traffic Flow in ATM Networks using Fuzzy Explicit Rate Marking (FERM), IEEE JSAC 15(2): 209–225 40. Ramakrishnan KK, Davie B, Floyd S (1999) A Proposal to Incorporate ECN in MPLS. Internet-draft, http:// www.aciri.org/floyd/papers/draft-mpls-ecn-00.txt

41. Ramakrishnan KK, Floyd S (1999) A proposal to add explicit congestion notification (ECN) to IP. RFC2481 42. Sekercioglu A, Pitsillides A, Vasilakos A (2001) Computational intelligence in management of ATM networks. Soft Computing J 5(4): 257–263 43. Sekercioglou A, Pitsillides A, Egan GK (1994) Study of an adaptive fuzzy controller based on the adaptation of relative rule weights. In: Proceedings of ANZIIS’94, Brisbane, Queensland, Australia, pp 204–208 44. Stevens W (1997) TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. RFC 2001 45. Stevens W (1994), TCP/IP Illustrated, Volume 1 The Protocols. Addison-Wesley 46. Special issue on Computational Intelligence (1997) IEEE J Selected Areas in Communications (JSAC) 15(2): 209–225 47. Ziegler T, Fdida S, Brandauer C (2000) Stability Criteria of RED with TCP Traffic (http://www.newmedia.at/tziegler/ papers.html)