Fuzzy Explicit Marking for Congestion Control in Differentiated ...

Download PDF
2 downloads 673 Views 323KB Size Report
Comment
within the differentiated services (Diff-Serv) framework to provide congestion control using a fuzzy logic control approach. Network congestion control remains a ...
Fuzzy Explicit Marking for Congestion Control in Differentiated Services Networks C. Chrysostomou, A. Pitsillides, G. Hadjipollas Department of Computer Science*, University of Cyprus, 75 Kallipoleos Street, P.O. Box 20537, 1678 Nicosia, Cyprus. e-mail: {cchrys, andreas.pitsillides, hpollas}@ucy.ac.cy

A. Sekercioglu

M. Polycarpou

Centre for Telecommunications and Information Engineering, Monash University, Melbourne, Australia. e-mail: [email protected]. edu.au

Department of Electrical and Computer Engineering, University of Cyprus, 75 Kallipoleos Street, P.O. Box 20537, 1678 Nicosia, Cyprus. e-mail: [email protected]

Abstract This paper presents a new active queue management scheme, Fuzzy Explicit Marking (FEM), implemented within the differentiated services (Diff-Serv) framework to provide congestion control using a fuzzy logic control approach. Network congestion control remains a critical and high priority issue. The rapid growth of the Internet and increased demand to use the Internet for timesensitive voice and video applications necessitate the design and utilization of effective congestion control algorithms, especially for new architectures, such as DiffServ. As a result, a number of researchers are now looking at alternative schemes to TCP congestion control. RED (Random Early Detection) and its variants are one of these alternatives to provide quality of service (QoS) in TCP/IP Diff-Serv networks. The proposed fuzzy logic approach for congestion control allows the use of linguistic knowledge to capture the dynamics of nonlinear probability marking functions and offer effective implementation, use multiple inputs to capture the (dynamic) state of the network more accurately, enable finer tuning for packet marking behaviors (either dropping a packet or setting its ECN –Explicit Congestion Notification- bit) for aggregated flows, and thus provide better QoS to different types of data streams, such as TCP/FTP traffic or TCP/Web-like traffic, whilst maintaining high utilization.

* Work partially supported by IST program SEACORN

1. Introduction The rapid growth of the Internet and increased demand to use the Internet for time-sensitive voice and video applications necessitate the design and utilization of new Internet architectures to include more effective congestion control algorithms in addition to the TCP based congestion control. As a result, the differentiated services (Diff-Serv) architecture was proposed [1] to deliver (aggregated) quality of service (QoS) in IP networks. Recently, active queue management (AQM) mechanisms (e.g. random early detection - RED) have been proposed [2, 3] within the framework of the Diff-Serv architecture to preferentially drop packets. Apart from RED, many variants of RED, such as n-RED, adaptive RED, RIO [3], BLUE [4] and Three Color marking schemes were proposed for Diff-Serv control. AQM mechanisms may use one of several methods for indicating congestion to the traffic sources. One method is to use a discard policy to the arriving packets. However, AQM allows the router to separate policies of dropping packets from the policies for indicating congestion. Therefore, AQM allows routers to use the Congestion Experienced (CE) codepoint in a packet header as an indication of congestion, instead of relying solely on packet drops [5]. Explicit Congestion Notification (ECN) [5] was proposed in order to provide TCP an alternative to packet drops as a mechanism for detecting incipient congestion in the network. The ECN scheme requires both end-to-end and network support. Recent studies [6, 7, 8, 9] have investigated the

impact of ECN implemented in TCP/IP networks. Many experiments have been carried out for RED, as the AQM mechanism at the network level, with and without ECN support. A RED gateway can mark a packet either by dropping it or by setting a bit in the packet’s header if the transport protocol is capable of reacting to ECN (for the rest of the paper, by marking a packet it is meant either dropping it or setting its ECN bit.). The use of ECN for notification of congestion to the end-nodes generally prevents unnecessary packet drops. In this paper, we use fuzzy logic techniques to develop a new AQM scheme, Fuzzy Explicit Marking (FEM), implemented within the Diff-Serv framework to provide congestion control. 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 good results 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 mark packets in Diff-Serv networks. The FIE output is the mark rate probability that is calculated based on two inputs: the instantaneous queue length and the rate of change of queue length. By marking we mean either dropping a packet or setting its ECN bit. If a packet is marked by setting its ECN bit, its mark is carried out to the destination and then conveyed back to the source via acknowledgement, knowing that the transport protocol is capable of reacting to ECN. The proposed fuzzy logic strategy is shown via simulations to be robust with respect to traffic modeling uncertainties and system nonlinearities, yet provide tight control (and as a result offer good service and achieve a high utilization). The paper is organized as follows. Section 2 reviews the Diff-Serv architecture and Section 3 discusses ECN, RED and its variants, and issues of concern. In Section 4 we briefly review some of the properties of Computational Intelligence and Fuzzy Logic Control and present our proposed Fuzzy Explicit Marking (FEM) implementation for Diff-Serv. Then Section 5 presents simulative examples and discusses the performance of FEM. Finally in Section 6 we present our conclusions.

2. Diff-Serv: New Internet Architecture Since Integrated Services (Int-Serv) failed to be adopted for widespread use, the IETF (Internet Engineering Task Force) proposed a more evolutionary approach that did not require significant changes to the Internet infrastructure and provided differentiation of

services (Diff-Serv) [1]. The Diff-Serv working group [13] has defined two broad aggregate behavior groups: the Expedited Forwarding (EF) Per-Hop Behaviour (PHB) and the Assured Forwarding (AF) PHB. 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 QoS. 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 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. 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” [14]. 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 guaranties (as is the case in ATM). Diff-Serv will try to provide some QoS using a DiffServ aware congestion control algorithm. Recently, AQM mechanisms (e.g. RED and its variants) have been proposed, e.g. [2, 3], within the framework of the DiffServ architecture to preferentially drop non conforming against conforming packets. Also, with the presence of ECN, AQM mechanisms can use alternative techniques for congestion indication, by marking a packet (setting its ECN bit). The use of ECN for the detection of incipient congestion in a Diff-Serv network can prevent unnecessary packet drops.

3. Diff-Serv Congestion Control: ECN, RED and its variants The most popular algorithms used for Diff-Serv implementation are based on RED [2]. RED simply sets some minimum and maximum marking thresholds in the router queues. In case the buffer queue size exceeds the minimum threshold, RED starts randomly dropping packets based on a probability depending on the average

Figure 1. Drop probability in RED and RIO (Figures not drawn to scale) [3] queue length (see Figure 1), or setting the ECN bit in packets’ header, as an indication of congestion. If the buffer queue size exceeds the maximum threshold then every packet is dropped (i.e., drop probability is set to 1). ECN provides an alternative to packet drops as a mechanism for detecting incipient congestion in the network. Many experiments have been carried out for RED with and without ECN support. The use of ECN for notification of congestion to the end-nodes generally prevents unnecessary packet drops. The RED implementation for Diff-Serv defines that we have different thresholds for each class. Best effort (BE) packets have the lowest minimum and maximum thresholds and therefore they are marked with greater probability than packets of AF or EF class. Also, there is the option that if an AF class packet does not comply with the rate specified then it would be reclassified as a BE class packet. EF

AF Class

Best Effort

Ye Check and traffic shaping

Priority Queue No

Discard

RIO Queue Max

Min

Figure 2. Diff-Serv scenario with RED queue for control In Figure 2 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. 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 BE class packets. Both AF and BE packets share a RIO [3] Queue. RIO stands for RED In/Out queue, where “In” and “Out”

means packets are in or out of the connection conformance agreement. EF packets use a separate high priority FIFO queue. For AF and BE class we have different minimum and maximum thresholds (see Figure 1). 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 mark probability. As illustrated in Figure 1, RIO is more aggressive in marking “Out” packets. It marks “Out” packets much earlier than it marks “In” packets; this is done by choosing the minimum threshold for “Out” packets smaller than the minimum threshold for “In” packets. It also marks “Out” packets with a higher probability, by setting the maximum mark 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 [15]. • Tuning of RED parameters has been an inexact science for sometime now, so much so that some researchers have advocated against using RED, in part because of this tuning difficulty [16]. The correct tuning of RED implies a “global” parameterization that is very difficult, if not impossible to achieve as it is shown in [4]. The results presented later show the potential of FEM to provide such desirable performance and queue management characteristics without any special parameterization or tuning. • Linearity of the dropping function has been questioned by a number of researchers (see for example [8]).

4. Fuzzy Logic: Implementation of FEM for Diff-Serv 4.1. Fuzzy Logic Fuzzy logic is a part of what is commonly known as Computational Intelligence (CI). CI [17, 18] is an area of fundamental and applied research involving numerical information processing (in contrast to the symbolic information processing techniques of Artificial Intelligence (AI)). Nowadays, CI research is very active and consequently its applications are appearing in some end user products. The definition of CI can be given indirectly by observing the exhibited properties of a system that employs CI components [17]: “A system is computationally intelligent when it: deals only with numerical (low-level) data, has a pattern recognition component, and does not use knowledge in the AI sense; and additionally, when it (begins to) exhibit: • computational adaptivity; • computational fault tolerance; • speed approaching human-like turnaround; • error rates that approximate human performance. The major building blocks of CI are artificial neural networks, fuzzy logic, and evolutionary computation.” While these techniques are not a panacea (and it’s important to view them as supplementing proven traditional techniques), we are beginning to see a lot of interest not only from the academic research community [19], but also from industry [20]. 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. FLCs have been applied successfully [11, 12] for controlling systems in which analytical models are not easily obtainable or the model itself, if available, is too complex and highly nonlinear. In recent years, a number of research papers using fuzzy logic investigating solutions to congestion control issues, especially to ATM networks, have been published. A survey is given in [19].

4.2 FEM Implementation for Diff-Serv Our design of a fuzzy control system for Diff-Serv networks is based on a fuzzy logic controlled RED queue. To implement it, we remove the fixed minimum, maximum queue thresholds from the RED queue for each class, and replace them with dynamic network state dependant thresholds calculated using an FIE [21]. As discussed earlier RED implementations with fixed thresholds cannot provide good results in the presence of

/* linguistic rules for assured (yellow) class */ if q is empty then pr_assured is zero; if q is moderate and if q is moderate and if q is moderate and if q is full and if q is full and if q is full and

dq is decreasing then pr_assured is zero; dq is zero then pr_assured is zero; dq is increasing then pr_assured is low;

dq is decreasing dq is zero dq is increasing

then pr_assured is low; then pr_assured is low; then pr_assured is medium;

Figure 3. Linguistic rules for the “assured” class traffic packets /* linguistic rules for best effort (red) class*/ if q is empty then pr_best_effort is zero; if q is moderate and if q is moderate and if q is moderate and medium; if q is full and if q is full and if q is full and

dq is decreasing then pr_best_effort is zero; dq is zero then pr_best_effort is low; dq is increasing then pr_best_effort is

dq is decreasing dq is zero dq is increasing

then pr_best_effort is medium; then pr_best_effort is high; then pr_best_effort is high;

Figure 4. Linguistic rules for the “best effort” class traffic packets dynamic network state changes, for example, the number of active sources. The FIE dynamically calculates the mark 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. We have implemented FEM with marking capabilities. By marking we mean either dropping a packet or setting its ECN bit. Therefore, FEM AQM mechanism is able to allow routers to use the CE codepoint in a packet header as an indication of congestion (FEM routers are given the option to set the ECN bit in the packet header), instead of relying solely on packet drops. The decision of marking a packet is based on the mark probability dynamically calculated by the FIE of each Diff-Serv class of service. The FIE uses separate linguistic rules for each class to calculate the mark probability based on the input from the queues (see Figure 3 and Figure 4). Usually multiinput FIEs can offer better ability to linguistically describe the system dynamics. We expect that we can tune the system better, and improve the behavior of the RED queue according to our class of service policy. The dynamic way of calculating the mark probability by the FIE 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 so inference apply. Based on these rules and inferences, the mark probability is calculated more dynamically than the classical RED approach. The rules for the “assured” class shown in Figure 3 are more aggressive about decreasing the probability of packet marking than increasing it sharply. There is only one rule that results in increasing mark probability, whereas two rules setting the mark probability to zero. If we contrast this with the linguistic

rules of the “best effort” class packets, shown in Figure 4, we see that more rules lead to an increase in mark probability, and so more packets are marked than the assured traffic class. These rules reflect the particular views and experiences of the designer, and are easy to relate to human reasoning processes and gathered experiences. 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. 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. Then, the rule base is fine tuned by observing the progress of simulation, such as packet marking occurrences and throughput curves. The tuning can be done with different objectives in mind. For example, any gain in throughput must be traded off by 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's 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 [22] 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 end-to-end delay experienced by the users. We have developed a compiler and an embeddable fuzzy logic inference engine (C-FLIE) for flexible definition of the rule base of the Fuzzy Congestion controller (FCC) and for conveniently interfacing to NS-2 simulation tool [23]. The source codes, shown in Figure 3 and Figure 4, are parsed to build the definitions of linguistic variables and “knowledge” of FCCs, for assured and best effort traffic. When a FCC first starts, it reads and parses this source file to initialize the inference engine. The development environment provides the FCC designer with a simple interface which allows the rule base to be tuned using observation of behavior of the simulated network, such as packet marking occurrences, throughput, and so on. 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 [4]. With FEM not only 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 using simulation the performance of FEM and compare with other published results. The implementation of the traffic sources is based on a recent version of NS-2 [23] simulator (Version 2.1b8a). Six simulation scenarios are presented. Scenarios 1-5 show the behavior of FEM under different network conditions using only TCP/FTP traffic and compare with RIO. Finally in Scenario 6 we introduce web traffic, reported to test the ability of RED [15] to evaluate a simple Diff-Serv implementation using RIO and FEM. The rule base files were used in all the simulation scenarios (Scenarios 1 – 6) without any change in order to show the capabilities of FEM in various scenarios using different parameters and network conditions.

5.1 Scenarios 1-5 In order to show the dynamic abilities of FEM we simulate various scenarios under the same network topology. In this network topology we have five sources (each has different delay links varying from 1ms to 8 ms) sending traffic to five other destinations through a link connecting two routers. The first source traffic is tagged as assured class traffic and the rest as best effort. The link bandwidth is set to 45 Mbps in all cases. The propagation delay between the two routers is varying from 5 to 20 ms. The TCP window also varies from 50 to 240 packets. The buffer size is set to 140 packets. For RIO the minimum threshold is set to 45 packets and the maximum threshold to 135 packets as “IN” packets are concerned. For “OUT” packets, the minimum threshold is set to 10 packets and the maximum threshold to 35 packets. The network topology used in this series of simulation scenarios is shown in Figure 5. The link propagation delay and the TCP window were changed in order to show how FEM 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 five simulations (simulation scenarios 1 – 5). For each scenario, we consider two cases, denoted by withand without-ECN cases, where both FEM and RIO mechanisms use marking (ECN-capable) and dropping (non-ECN capable) packets as a way of congestion control. For performance analysis purposes, we measure the throughput, i.e., the traffic rate traversing the bottleneck link, as well as the goodput, i.e., the traffic rate traversing the bottleneck link minus all retransmitted packets. Thus the link utilization can be found and compared. A measure of the total dropped packets is also taken. All results presented for these scenarios were extracted from the NS-2 simulation trace file, and summarized in Table 1 (Throughput and Link

In Scenario 3 the TCP window is further decrease to 50 packets, while keeping the link delay at 10 ms. In Scenario 4 the TCP window is set to 150, as in Scenario 2, but double the link delay to 20 ms. In Scenario 5 we keep the TCP window to 50 packets as in Scenario 3 but halve the link delay to 5 ms. In Scenario 1, (due to limited space, the reader can refer to the results summarized in Tables 1-3), FEM achieves much higher link utilization compared with RIO for both cases (with- and without-ECN). FEM mechanism for marking packets provides fewer drops than RIO does, and hence the higher goodput achieved. Also, the QoS is also maintained by providing fewer drops in the Assured class than in the Best Effort class. RIO shows a more aggressive behavior in marking Best Effort (“OUT”) packets compared with FEM. However, as indicated above, the rule base files used for the purposes of this paper were not changed in order to show the capabilities

dest1 / 1ms

src1 / 1ms

iMac

dest2 2ms src2 / 2ms

iMac

100 Mbps links

Router A

Router B dest3 4ms 45 Mbps

iMac

100 Mbps links

src3 / 4ms

dest4 5ms

src4 / 5ms

iMac

dest5 8ms

src5 / 8ms

iMac

Figure 5. Network Topology for Simulation Scenarios 2-5

Table 1. Throughput and Link Utilization for Scenarios 1-5 THROUGHPUT (Mbps) Without ECN With ECN RIO FEM RIO FEM 42.66 43.91 42.77 44.26 44.35 44.35 44.35 44.32 44.14 44.93 44.52 44.86 43.47 43.4 43.42 43.79 44.9 44.44 44.71 44.81

Scenarios 1 2 3 4 5

Utilization (%) Without ECN With ECN RIO FEM RIO FEM 94.8 97.58 95.04 98.35 98.55 98.55 98.55 98.48 98.08 99.84 98.93 99.69 96.6 96.44 96.49 97.31 99.78 98.76 99.35 99.58

Table 2. Total number of drops for Scenarios 1-5 DROPS (packets) Without ECN Scenarios 1 2 3 4 5

Best Effort 1016 1174 314 357 855

RIO Assured

Total

Best Effort

126 30 0 44 0

1142 1204 314 401 855

732 692 67 302 449

With ECN FEM Assured

Total

Best Effort

146 36 0 49 2

878 728 67 351 451

888 579 0 101 16

RIO Assured

Total

Best Effort

94 30 0 45 0

982 609 0 146 16

135 89 0 86 2

FEM Assured

Total

117 36 0 49 4

252 125 0 135 6

Table 3. Goodput and Link Utilization for Scenarios 1-5 Scenarios 1 2 3 4 5

GOODPUT (Mbps) Without ECN With ECN RIO FEM RIO FEM 42.58 43.84 42.7 44.24 44.26 44.29 44.3 44.31 44.11 44.93 44.52 44.86 43.44 43.37 43.41 43.78 44.84 44.4 44.7 44.81

Utilization), Table 2 (Drops) and Table 3 (Goodput and Link Utilization). In Scenario 1 the link delay between the routers is set to 10 ms and the TCP window to 240 packets. In Scenario 2 we keep the same link delay between the routers as in Scenario 1, but decrease the TCP window to 150 packets.

Utilization (%) Without ECN With ECN RIO FEM RIO FEM 94.62 97.42 94.89 98.31 98.35 98.42 98.44 98.47 98.02 99.84 98.93 99.69 96.53 96.37 96.47 97.29 99.64 98.67 99.33 99.58

of FEM in various scenarios using different parameters and network conditions. Making FEM more aggressive to Best Effort traffic class is a matter of further study and part of the fine-tuned procedure of the rule base files.

Scenario 2 uses the same network topology as the first Scenario but the TCP window is reduced to 150 packets. FEM and RIO exhibits almost the same behaviour when measuring the throughput. However, with the exception of the retransmitted packets, i.e., taking the goodput, FEM achieves a slightly higher utilization than RIO. In Scenario 3 we further decrease the TCP window size to 50 packets. The behavior of FEM shows that under these network conditions it continues to get a higher goodput compared to RIO, and hence it achieves a high utilization of the link for both cases. It can be said that the marking mechanism of FEM can give a better network performance by achieving higher utilization of the bottleneck link than RIO does. Scenario 4 uses the same network topology as Scenario 2 but the link delay between the routers is increased from 10 ms to 20 ms. In this scenario we test the behaviour of the algorithm under greater delays. Under the without-ECN case, RIO shows a higher throughput and goodput than FEM. However, under the with-ECN case FEM outperforms RIO by achieving a higher utilization of the bottleneck link. Finally, in Scenario 5, we use the network topology defined in Scenario 3, but the link delay is further decreased to 5 ms. Using the ECN capability, FEM gains in utilization of the bottleneck link compared with RIO.

src0 / 40ms

dest0 iMac

dest1

src1 / 20ms

iMac

500 Mbps links src2 / 20ms

Rtr0

100 Mbps / 10ms

Rtr1

Rtr2

10 Mbps / 30 ms

Rtr3

500 Mbps / 1ms delay links

100 Mbps / 10ms

dest2 iMac

src3 / 20ms

src4 / 40ms

iMac

dest3

iMac

dest4

Figure 6. Scenario 6 - Network Topology

5.2 Scenario 6 In Scenario 6 we use the network topology presented in Figure 6, similar to the one used in [15], and compare FEM with RIO. The first two of the sources are TCP/Web-like Traffic and the other three are TCP/FTP traffic sources. Web-like traffic is tagged as assured class traffic and the FTP traffic as best effort. The choice of distributions and parameters is based on [15] and is summarized in Table 4. The implementation of the traffic sources is based on a recent version of 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 seconds each in order to enhance the validity of the results. We use TCP/SACK with a TCP window of 100 packets. Each packet has a size of 1514 bytes. For the Tail Drop queue we define a buffer size of 226 packets. We use AQM (FEM or RIO) in the queues of the bottleneck link between router 1 and router 2. All other links have a simple Tail Drop queue. Figure 7 shows the throughput behaviour under the with-ECN case. Due to the small loss rate achieved by both FEM and RIO (less than 1%), the Table 4. Distributions and parameters for Web-like Traffic Distribution Mean Shape

Inter-page Time Pareto 50ms 2

Objects per page Pareto 4ms 1.2

InterObject Time Pareto 0.5ms 1.5

Object Size Pareto 12KB 1.2

Figure 7. Scenario 6 – Throughput – with-ECN goodput is almost identical with the throughput obtained. FEM appears to control better the flow rate across the network and provide a more stable behaviour. From the results it can be seen that FEM can provide the necessary congestion control and differentiation and ensure acceptable QoS in a Diff-Serv network. FEM provides better QoS to different types of traffic, whilst maintaining high utilization.

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 along with the support of ECN for detecting incipient congestion in the network. However in many reported cases with extreme bursty sources (such a case is the Internet) it fails to effectively control congestion. Our proposal is a novel, more effective, robust, scalable, and more flexible approach. The proposed fuzzy

logic approach for congestion control in a Diff-Serv framework is implemented with marking capabilities (either dropping a packet or setting its ECN bit). In this paper the design of the fuzzy knowledge base is kept simple. It avoids the necessity of any special parameterization or tuning, apart from linguistic interpretation of the system behavior. We have successfully used the reported strength of fuzzy logic (a CI technique) and have addressed limitations of existing RED, and RED variant, algorithms implemented in a Diff-Serv framework. This is clearly shown from the simulative evaluation. For example for the chosen simulative examples FEM is shown to behave well and deliver almost identical or better goodput results under various scenarios and conditions without any retuning or parameterization. FEM can 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 we define it or any special tuning. We believe that future work can include: further refinement of the rule base, self-tuning, or different fuzzy based control strategies for the design of the fuzzy rule base and its tuning. Furthermore, it is worth investigating the adaptation of FEM in different environments, e.g., mobile, and its application in a mobile IP-based radio access network (RAN), and its integration with proposed resource management frameworks in such environments, like the resource management in Diff-Serv (RMD) framework [24]. 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. Also, another issue worthy of investigation is how 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 we are very optimistic that the Fuzzy Control methodology will offer significant improvements on controlling congestion in TCP/IP DiffServ networks.

7. References [1] S. Blake et al. “An architecture for Differentiated Services”, December 1998, RFC 2475, December 1998. [2] S. Floyd, V. Jacobson, “Random Early Detection gateways for congestion avoidance”, IEEE/ACM Trans. on Networking, Aug. 1993. [3] D. Clark, W. Fang “Explicit Allocation of Best Effort Packet Delivery Service”, IEEE/ACM Transactions on Networking, Vol. 6, No. 4, pp. 362-373, August 1998. [4] W. Feng, D. Kandlur, D. Saha, and K. Shin, “Blue: A New Class of Active Queue Management Algorithms,” tech. rep., UM CSE-TR-387-99, 1999.

[5] K. Ramakrishnan, and S. Floyd, “The Addition of Explicit Congestion Notification (ECN) to IP”, RFC 3168, 2001. [6] S. Floyd, “ TCP and Explicit Congestion Notification”, ACM Computer Communication Review, 24(5), 8-23, 1994. [7] K. Pentikousis and H. Badr, "On the Resource Efficiency of Explicit Congestion Notification", in Proceedings of Networking 2002, Pisa, Italy, May 2002. [8] S. Athuraliya, V. H. Li, S. H. Low, Q. Yin, “REM: Active Queue Management”, IEEE Network, 15(3), 48-53. [9] P. Bagal, s. Kalyaanaraman, b. Packer, “Comparative Study of RED, ECN, and TCP Rate Control”, Technical Report, Department of ECSE, Rensselaer Polytechnic Institute, Troy NY 12180-3590, USA, March 1999. [10] K. Passino, S. Yurkovich, “Fuzzy Control”, Addison Wesley, 1998. [11] S. Yasunobu, S. Miyamoto, “Automatic Train Operation by Predictive Fuzzy Control”, in Industrial Applicatons of Fuzzy Control, M. Sugeno, Ed., pp. 1-18, Elsevier Science Publishers, 1985. [12] E. Morales, M. Polycarpou, N. Hemasilpin, J. Bissler, “Hierarchical Adaptive and Supervisory Control of Continuous Venovenous Hemofiltration”, IEEE Transactions on Control Systems Technology, Vol. 9, No. 3, pp. 445-457, May 2001. [13] IETF Differentiated Services Working Group (http://www.ietf.org/html.charters/diffserv-charter.html) [14] Nichols K et al. (1998) Definition of the differentiated Services Field in the Ipv4 and Ipv6 Headers. RFC 2474. [15] 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, 2001. [16] May M, Bonald T, Bolot JC (2000), “Analytic Evaluation of RED Performance”, Tel Aviv, IEEE Infocom 2000. [17] J. C. Bezdek, “What is Computational Intelligence: Imitating Life”, edited by J.M. Zurada, et al, IEEE Press, pp. 1-12, 1994. [18] W.Pedrycz, “Computational Intelligence: An Introduction”, CRC Press, 1998. [19] A. Sekercioglu, A. Pitsillides, A. Vasilakos, “Computational intelligence in management of ATM networks”, Soft Computing Journal, 5 (2001) 4, 257-263.. [20] B. Azvine, & A. Vasilakos, “Application of soft computing techniques to the telecommunication domain”, ERUDIT Roadmap, (G. Tselentis, Ed.), (2000), pp. 89-110, http://www.erudit.de/erudit/papers/Roadmap.pdf. [21] C. Chrysostomou, A. Pitsillides, L. Rossides, M. Polycarpou, A. Sekercioglu, “Congestion Control in Differentiated Services Networks using Fuzzy-RED”, Special Issue on "Control Methods for Telecommunication Networks" in IFAC Control Engineering Practice (CEP) Journal, to appear 2003. [22] 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. [23] Network Simulator, NS-2, Homepage, http://www.isi.edu/nsnam/ns/ [24] Westberg et.al., "Resource Management in Diffserv (RMD):A functionality and performance behavior", Proc. of the 7th International Workshop on Protocols For High-Speed Networks (PfHSN'2002).