Congestion control in differentiated services ... - Semantic Scholar

Control Engineering Practice 11 (2003) 1153–1170

Congestion control in differentiated services networks using Fuzzy-RED C. Chrysostomoua,*, A. Pitsillidesa, L. Rossidesa, M. Polycarpoub, A. Sekerciogluc b

a Department of Computer Science, University of Cyprus, 75 Kallipoleos Street, P.O. Box 20537, 1678 Nicosia, Cyprus Department of Electrical and Computer Engineering, University of Cyprus, 75 Kallipoleos Street, P.O. Box 20537, 1678 Nicosia, Cyprus c Centre for Telecommunications and Information Engineering, Monash University, Melbourne, Australia

Received 15 July 2002; accepted 2 March 2003

Abstract Network congestion control remains a critical and high priority issue. 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 effective congestion control algorithms, especially for new architectures, such as differentiated services (Diff-Serv). As a result, a number of researchers are now looking at alternative schemes to TCP congestion control. Random early detection (RED) and its variants are one of these alternatives to provide quality of service (QoS) in TCP/IP Diff-Serv networks. In this paper, we present the results of a fuzzy logic control approach to RED implementation, Fuzzy-RED, implemented within the Diff-Serv framework. The proposed fuzzy logic approach for congestion control allows the use of linguistic knowledge to capture the dynamics of non-linear probability discard functions and offer more effective implementation, use multiple inputs to capture the (dynamic) state of the network more accurately, enable finer tuning for packet discarding behaviors 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. r 2003 Elsevier Ltd. All rights reserved. Keywords: Fuzzy logic control; TCP/IP; Congestion control; Diff-Serv; RED

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 (Blake et al., 1998) to deliver (aggregated) quality of service (QoS) in IP networks. It should also be mentioned that, even for the present Internet architecture, network congestion control remains a critical and high priority issue, and is unlikely to disappear in the near future. Furthermore, if we consider the current utilization trends, congestion in the Internet may become unmanageable unless effective, robust, and efficient methods *Corresponding author. Tel.: +357-22-892700; fax: +357-22892701. E-mail address: [email protected] (C. Chrysostomou). 0967-0661/03/$ - see front matter r 2003 Elsevier Ltd. All rights reserved. doi:10.1016/S0967-0661(03)00052-2

for congestion control are developed. For example, the existing congestion control solutions for TCP transported traffic (Jacobson, 1988; Stevens, 1997) are increasingly becoming ineffective, and it is generally accepted that these solutions cannot easily scale up even with various proposed ‘‘fixes’’ (Karn & Partridge, 1987; Stevens, 1994; Jacobson, Braden, & Borman, 1992; Brakmo & Peterson, 1995), new approaches (Floyd & Jacobson, 1993; Floyd & Fall, 1999), and architectures (Braden, Clark, & Shenker, 1994; Black et al., 1998). The congestion control schemes employed by the TCP/IP protocol have been widely studied (see, e.g., Jacobson, 1988; Stevens, 1994, 1997; Karn & Partridge, 1987; Jacobson et al., 1992; Brakmo & Peterson, 1995; Zhang, 1989; Shenker, Zhang, & Clark, 1990; Lakshman & Madhow, 1997). The Internet protocol architecture is based on a connectionless, best-effort, end-to-end packet service using the IP protocol. TCP is an end-to-end transport protocol that provides reliable, in-order service over the IP packet service. Ever increasing demands on the Internet have led to a number

1154

C. Chrysostomou et al. / Control Engineering Practice 11 (2003) 1153–1170

of incremental changes over the last 10 years designed to improve TCP/IP performance: 1. Improved round-trip time measurement algorithm (Karn’s algorithm) (Karn & Partridge, 1987). 2. slow-start and congestion avoidance (Jacobson, 1988; Stevens, 1997); 3. fast retransmit, fast recovery algorithms (Stevens, 1994); 4. improved operation over high speed, large delay networks (Jacobson et al., 1992); 5. improved congestion indication (Brakmo & Peterson, 1995). Even so, there is considerable evidence of observed TCP behavior that collectively contributes to TCP’s unpredictable performance. While the majority of TCP analysis has been simulation based, there have also been several empirical studies, which illustrate that TCP can exhibit unwanted behaviors, such as cyclic behavior, synchronization effects and ACK compression. A notable analytic evaluation of the performance of congestion algorithms for TCP/IP is given by Lakshman and Madhow (1997). Using simple dynamic models for the slow-start and congestion avoidance phases of TCP (Jacobson, 1988), they insightfully demonstrate the unwanted cyclic behavior of TCP/IP and the effect of a high-bandwidth delay product and random losses on its performance. Thus, the behavior of TCP/IP congestion control still remains a matter of continuous research interest in the TCP/IP world (highlighted by the frequent IETF RFCs—request for comments— proposing fixes or new solutions). It has become clear (Braden et al., 1998) that the existing TCP congestion avoidance mechanisms and its variants, while necessary and powerful, are not sufficient to provide good service in all circumstances. Basically, there is a limit to how much control can be accomplished from the edges of the network. Some additional mechanisms are needed in the routers to complement the endpoint congestion avoidance methods, as suggested by several researchers (Floyd & Jacobson, 1993; Braden et al., 1998; Ramakrishnan & Floyd, 1999; Ramakrishnan, Davie, & Floyd, 1999). Note that the need for gateway control was realised early; e.g. see Jacobson (1988), where for future work the gateway side is advocated as necessary. In Floyd and Jacobson (1993) it is again advocated that the most effective detection of congestion can occur in the gateway itself. Thus, the random early detection (RED) algorithm (Floyd & Jacobson, 1993) was proposed as an Active Queue Management (AQM) approach. RED proposes strategies 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 discard policy of arriving packets is based on the overflow of the output port buffer. Contrary to TD, AQM mechanisms (Braden et al., 1998) start dropping packets earlier in order to be able to notify traffic sources about the incipient stages of congestion. RED has been designed to substitute TD and is currently implemented in some commercially available routers, but not widely deployed (see discussion, in Section 3). The congestion control problem in the Internet is further exacerbated as the Internet is increasingly transformed into a multi-service high-speed network; see for example the Integrated Services (Int-Serv) and Diff-Serv proposed architectures (Braden et al., 1994; Black et al., 1998; Blake et al., 1998). Currently, interest is mainly for Diff-Serv architectures, as scalability problems have been reported for Int-Serv. Recently, AQM mechanisms (e.g. RED) have been proposed (Clark & Fang, 1998; Blake et al., 1998) within the framework of the Internet Diff-Serv architecture (Braden et al., 1998) to preferentially drop packets. Apart from RED, many variants of RED, such as n-RED, adaptive RED (Feng, Kandlur, Saha, & Shin, 1999b), RIO (Clark & Fang, 1998), BLUE (Feng, 1999; Feng, Kandlur, Saha, & Shin, 1999a) and Three-Color marking schemes were proposed for Diff-Serv control. In this paper, we present our fuzzy logic based approach for delivering an improved and more predictable congestion control implementation within the Diff-Serv architecture. Fuzzy logic control is a widely used Computational Intelligence (CI) technique for dealing with ‘‘soft’’ information processing (Brown & Harris, 1994; Passino & Yurkovich, 1998). It provides a system for designing feedback control algorithms in such cases where the system to be controlled is too complex to employ classical control methods. Fuzzy logic becomes especially useful on capturing human expert or operator’s qualitative control experience into the control algorithm. This algorithm is represented typically in the form of linguistic rules, which is gained through experience by human operators or other researchers who may be well familiar with the system to be controlled. Fuzzy control algorithms have been designed and implemented in a wide variety of applications (Yasunobu & Miyamoto, 1985; Morales, Polycarpou, Hemasilpin, & Bissler, 2001). We believe that 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 well understood concept and therefore it is possible to obtain simple linguistic rules for effective congestion control. Our design of a fuzzy control system for Diff-Serv networks is based on a fuzzy logic controlled RED queue (one for each differentiated class of service), which can provide effective congestion


control feedback to the traffic sources in the presence of dynamic network state changes. We designed a fuzzy inference engine (FIE) using separate linguistic rules for each predefined class of service in the router queues to discard packets with varying drop preferences. 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. The proposed fuzzy logic strategy is shown via simulations to be robust with respect to traffic modeling uncertainties and system non-linearities, yet provide tight control (and as a result offer good service). It is worth pointing out that there is increasing empirical knowledge gathered about RED and its variants, and several ‘rules of thumb’ have appeared in many papers. It will be beneficial to build the Fuzzy Control rule base using this knowledge. However, in this paper, we only attempt to highlight the potential of the methodology, and choose a simple set of linguistic rules and simulation examples. The paper is organized as follows. Section 2 reviews the Diff-Serv architecture, and Section 3 discusses RED and its variants, as well as issues of concern. In Section 4 we briefly review some of the properties of CI and fuzzy logic control and present our proposed Fuzzy-RED implementation for Diff-Serv. Then, Section 5 discusses the performance of Fuzzy-RED through a set of simulation exercises. Finally, in Section 6 we present our conclusions.

2. Diff-Serv: new Internet architecture 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) (Blake et al., 1998). To accomplish this, Diff-Serv uses the type of service (ToS) field bits in the IP header, which are now renamed as ‘‘DS (Differentiated Services) field’’ (Nichols et al., 1998). The functions associated with these bits have also been redefined. The main issue of the Diff-Serv approach is how to standardize a simple set of mechanisms for handling packets with different priorities denoted by the DS field in the IP header. Note that, in Diff-Serv approach, packet classification is performed only at the edges of the network, which reduces the operational complexity in the network core, and makes it more scalable. On the other hand, no specific measures are taken to assure that the priorities would actually relate to the desired QoS when a packet leaves the edge router. Therefore, the standard Diff-Serv architecture provides only rudimentary QoS, without any quantified guarantees (unlike the ATM case for example). Because of the

1155

availability of limited number of bits in the DS field, the Diff-Serv Working Group has defined a small set of building blocks, called per-hop behaviors (PHBs), which are used by the routers to deliver a variation of services. They are encoded in the DS field and they specify the forward behavior each packet expects to receive by the individual routers. The two PHBs being standardized are the Expedited Forwarding (EF) (Jacobson, Nichols, & Poduri, 1999), and the Assured Forwarding (AF) (Heinamen, Baker, Weiss, & Wroclawski, 1999). The EF PHB specifies a forwarding behavior with a low loss, low latency, low jitter, and assured bandwidth end-toend 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 an adequate level of 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 is 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 specifies a forwarding behavior in which packets see a very small amount of loss. The AF PHB group provides delivery of IP packets in four independently forwarded 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 packets non-conforming to contract when there is congestion. By limiting the amount of AF traffic in the network and by managing the best-effort traffic appropriately, routers can then ensure low loss behavior to packets marked with the EF PHB. In summary, Diff-Serv architecture will try to provide QoS by using Diff-Serv aware congestion control algorithms. Recently, AQM mechanisms (e.g. RED and its variants) have been proposed (Blake et al., 1998; Clark & Fang, 1998) within the framework of the Diff-Serv architecture (Braden et al., 1998) to preferentially drop non-conforming against conforming packets.

3. RED and its variants for Diff-Serv congestion control The most popular algorithm used for Diff-Serv implementation is random early discard (RED) (Floyd & Jacobson, 1993). RED simply sets some minimum and maximum dropping thresholds for a number of predefined traffic classes 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 queue length (see Fig. 1). If the buffer queue size exceeds the maximum


1156 P(drop)

P(drop In)

P(drop out)

1

1

Pmax_out Pmax minth

Pmax_in

maxth avg min_in

max_in Avg_in

min_in

max_out Avg_total

Fig. 1. Drop probability in RED and RIO (figures not drawn to scale) (Clark & Fang, 1998).

EF

AF Class

Best Effort

Ye Priority Queue Check and traffic shaping

No

Discard

RIO Queue

Max Min Fig. 2. Diff-Serv scenario with RED queue for control.

threshold then every packet is dropped (i.e., drop probability is set to 1). The RED implementation for Diff-Serv defines that we have different thresholds for each class. Best-effort packets have the lowest minimum and maximum thresholds and therefore they are dropped 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 best-effort class packet. In Fig. 2 we see a simple Diff-Serv scenario where RED is used for AQM based congestion control. A leaky-bucket traffic shaper is used to check if the packets comply with the SLA. EF packets are discarded if they do not comply with the SLA. For the case of AF class packets, they are remapped into Best-Effort Class packets if they do not comply. Both AF and Best-Effort packets share an RIO (Clark & Fang, 1998) 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. We have different minimum and maximum thresholds (see Fig. 1) for AF and Best-Effort classes. 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. 1, RIO is more aggressive in dropping ‘‘Out’’ packets than ‘‘In’’ packets. It drops ‘‘Out’’ packets much earlier than it drops ‘‘In’’ packets; this is achieved 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. Apart from RED, many other mechanisms such as n-RED, adaptive RED, BLUE (Feng, 1999; Feng et al., 1999a) and Three-Color marking schemes were proposed for Diff-Serv AQM based congestion control. 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, a number of issues need to be resolved. These include: *

Problems with performance of RED under different operational scenarios: For example, the influence of: (a) the moving average of the Queue Occupancy on the responsiveness of control; (b) the Loss Function on the congestion control feedback mechanism; and (c) the buffer size to the reaction time of the congestion controller are documented, see e.g. Kohler, Menth, and Vicari (2000). Note that most of the existing studies are obtained with simulations suggesting modifications to the algorithm. Numerous RED variants (e.g., Lin & Morris, 1997; Ott, Lakshman, & Wong, 1999; Feng at al., 1999a, b) have been proposed, perhaps motivated by the difficulty in understanding the dynamics of RED completely. Comparative evaluations of RED and Gentle RED schemes with standard and optimal parameter settings in Iannaccon et al. (2001) and Ziegler, Fdida, and Brandauer (2001) showed no significant performance improvements against Tail Drop queue management scheme. This means that widespread deployment of RED in backbone routers by ISPs


*

*

may not be justifiable, since performance of RED with standard parameter settings exhibits higher dependency on the traffic load dynamics as compared to other mechanisms, indicating that even efforts spent on fine tuning of the RED parameters are not sufficient to eliminate the undesired RED behavior. It should also be noted that gentle RED is only capable of partially resolving the above-mentioned problems (Iannaccon et al., 2001; Ziegler et al., 2001). Tuning of RED parameters has been an inexact science, so that some researchers have advocated against using RED, in part because of this tuning difficulty (Jeffay, Ott, & Smith, 2000; May, Bonald, & Bolot, 2000). Recently, some effort was undertaken to evaluate the performance of RED analytically. In May, Bolot, Jean-Marie, and Diot (1999) and Bonald, May, and Bolot (2000) 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 Peeters and Blondia (1999) where a source consists of a 3state Markov model, and in Kohler et al. (2000) the sources behave as defined in the TCP Reno protocol. Firoiu and Borden (2000) investigated issue of recommendations of RED parameters, and provided some heuristic guidelines for choosing them. In Misra, Gong, and Towsley (2000) a more formal, control theoretic stand-point is adopted to also investigate issue of recommending settings for the RED parameters. In Ziegler et al. (2001) quantitative models on how to set RED parameters with TCP traffic are derived. The correct tuning of RED implies a ‘‘global’’ parameterization that is very difficult, if not impossible to achieve as it is shown in Feng (1999). The results of our work presented in the later sections of this paper show the potential of FuzzyRED 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 Floyd and Fall (1999), Kohler et al. (2000), Iannaccon et al. (2001), Misra et al. (2000), and Aweya, Ouellette, Montuno, and Chapman (2001). Nonlinear function examples include: * Gentle RED (GRED) (Floyd & Fall, 1999) modifies RED’s dropping function in the case where the average queue exceeds the maximum threshold. Drop probability increases linearly between the maximum threshold and buffer size with a slope of (1–maxp)/maxth. * REM (Athuraliya, Li, Low, & Yin, 2001) implements an exponential form of the marking probability. * In Kohler et al. (2000) further studies are advocated to investigate the influence of non-

*

1157

linear loss functions for an RED queue and in Iannaccon et al. (2001) different queue management algorithms. * In Misra et al. (2000), and Aweya et al. (2001) the probability function is dynamically chosen according to a linear feedback control strategy. Other input signals (apart from average queue length): For example, REM (Athuraliya et al., 2001) uses input rate and queue size, adaptive BLUE (Feng et al., 1999a) uses buffer overflow and link idle events, SRED (Ott et al., 1999) and Self-Configuring RED (Feng et al., 1999b) use number of active connections, Feng et al. (1999b) adapts RED parameters based on traffic load and mix, and Ziegler et al. (2001) uses bottleneck bandwidth, number of flows, and round-trip time to derive analytical functions for optimal settings.

4. Fuzzy logic control—implementation of Fuzzy-RED for Diff-Serv 4.1. Fuzzy logic Fuzzy logic is a part of what is commonly known as CI (Bezdek, 1994; Pedrycz, 1998). CI 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 (Bezdek, 1994): ‘‘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 its 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 (Pitsillides, Sekercioglu, & Ramamurthy, 1997; Pitsillides & Sekercioglu, 2000; Sekercioglu, Pitsillides, & Vasilakos, 2001), but also from industry (Azvine & Vasilakos, 2000).

1158


Fuzzy logic controllers (FLCs) may be viewed as an 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 for controlling systems in which analytical models are not easily obtainable or the model itself, if available, is too complex and highly non-linear. 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 Sekercioglu et al. (2001). Fig. 5. Decision surface of the FIE of the ‘‘assured’’ class. (The control surface is shaped by the rule base and the linguistic values of the linguistic variables.)

4.2. Fuzzy-RED implementation for Diff-Serv Our approach to the RED Diff-Serv implementation is Fuzzy-RED, a fuzzy logic controlled RED queue. To implement Fuzzy-RED queue management algorithm, we remove the fixed maximum, minimum queue thresholds from the RED queue for each class, and replace them with dynamic network state dependant thresholds calculated using an FIE (Pitsillides et al., 1997). As discussed earlier RED implementations with fixed thresholds cannot provide satisfactory results on resource utilization in the presence of dynamic network state changes, for example, 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 rate of the change in the queue size. In implementation we have a separate FIE for each Diff-Serv class of service. The FIE uses separate linguistic rules for each class to calculate the drop probability based on the input from the queues (see Figs. 3 and 4). Usually, multi-input FIEs

can offer better ability to linguistically describe the system dynamics. We expect that we can tune the system to yield results closer to optimum, and improve the behavior of the RED queue according to our class of service policy. The dynamic way of calculating the drop 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 drop probability is calculated more dynamically than the classical RED approach. This point can be illustrated by observing the visualization of the decision surfaces of the FIEs used in the Fuzzy-RED scheme (see Figs. 5 and 6). An inspection of these decision surfaces and the linguistic rules shown in Fig. 3 and Fig. 4 provides hints on operation of the Fuzzy-RED. The rules for the ‘‘assured’’ class shown in Fig. 3 are more aggressive

/* 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 medium; then pr_assured is high;

Fig. 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 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 zero; dq is increasing then pr_best_effort is low;

dq is decreasing dq is zero dq is increasing

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

Fig. 4. Linguistic rules for the ‘‘best-effort’’ class traffic packets.


1159

Fig. 6. Decision surface of the FIE of the ‘‘best-effort’’ class. (The control surface is shaped by the rule base and the linguistic values of the linguistic variables.)

about decreasing the probability of packet drop than increasing it sharply. There is only one rule that results in increasing drop probability, whereas two rules setting the drop probability to zero. If we contrast this with the linguistic rules of the ‘‘best-effort’’ class packets, shown in Fig. 4, we see that more rules lead to an increase in drop probability, and so more packet drops 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. The selection of rule base is based on our experience and beliefs on how the system should behave (in other words, human expert’s heuristic knowledge). Design of a rule base is two-fold: First, the linguistic rules (‘‘surface structure’’) are set; afterwards, membership functions of the linguistic values (‘‘deep structure’’) are determined (see Figs. 7 and 8). The trade-off involving the design of the rule base is to have a set of minimum number of linguistic rules representing the control surface with sufficient accuracy to achieve an acceptable performance. Recently, in the fuzzy control literature, some formal techniques for obtaining a rule base by using Artificial Neural Networks or Genetic Algorithms have appeared. Nevertheless, we have used the conventional trial and error approach under the guidance of some design rules of thumb (see Driankov, Hellendoorn, & Reinfrank, 1993 for a discussion of these). 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 loss occurrences and throughput curves. The tuning can be done with

Fig. 7. Assured class traffic: Membership functions of the linguistic values representing the input variables ‘‘normalized queue length’’ and ‘‘rate of change of queue’’ and the output variable ‘‘drop rate probability’’.

1160


src1/1ms dest0

Router 0 100 Mbps links

40 Mbps / 10 ms delay link

src2/1ms

Throughput

Fig. 9. Scenario 1—simple network topology used for the initial simulations.

45 40 35 30 25 20 15 10 5 0

0

20

40

Fuzzy RED

60 Time RED

80

100

Droptail

Fig. 10. Scenario 1—throughput vs. time.

70

Buffer (packets)

60 50 40 30 20 10 0 0

20

40

60

Time(s) Fuzzy RED

80

100

120

RED

Fig. 11. Scenario 1—buffer size vs. time.

Fig. 8. Best-effort class traffic: Membership functions of the linguistic values representing the input variables ‘‘normalized queue length’’ and ‘‘rate of change of queue’’ and the output variable ‘‘drop rate probability’’.

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 (Sekercioglou, Pitsillides, & Egan, 1994) can be used which can tune the parameters of the FLC on-line, using measurements from the system.


1161

dest1 / 1ms src1 / 1ms dest2 2ms src2 / 2ms 100 Mbps links

Router A

Router B dest3 4ms 45 Mbps

100 Mbps links

src3 / 4ms

dest4 5ms

src4 / 5ms

dest5 8ms

src5 / 8ms

Fig. 12. Network topology for simulation Scenarios 2–5. 120.00 100.00 Queue (packets)

The tuning objective can be based on a desired optimization criterion, for example, a trade-off between maximization of throughput and minimization of endto-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 the ns-2 simulation tool (Network Simulator). The source codes, shown in Figs. 3 and 4, are parsed to build the definitions of linguistic variables and ‘‘knowledge’’ of FCCs, for assured and best-effort traffic. When an 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 loss occurrences and throughput. 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 (Feng, 1999). 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, especially by introducing additional input variables and on-line (dynamic) adaptivity of the rule base (self-tuned).

80.00 60.00 40.00 20.00 0.00 0.00

20.00

40.00 60.00 Time (sec) RED

80.00

100.00

Fuzzy RED

Fig. 13. Scenario 2—buffer size vs. time (Fuzzy-RED dark line, RED gray).

published results. The implementation of the traffic sources is based on a recent version of ns-2—version 2.1b8a—(Network Simulator). Six simulation scenarios are presented. Scenario 1 was a simple scenario used to make an initial evaluation and test of Fuzzy-RED. Scenarios 2–5 show the behavior of Fuzzy-RED under different network conditions using only TCP/ FTP traffic and compare with RED. Finally, in Scenario 6 we introduce web traffic, reported to test the ability of RED in Iannaccon et al. (2001), to evaluate a simple Diff-Serv implementation using RIO and FuzzyRED. 5.1. Scenario 1

5. Simulation results In this section, we evaluate using simulation the performance of Fuzzy-RED and compare with other

We have done an initial testing of the performance of the Fuzzy-RED queue management using the ns-2 simulation tool with the simple network topology shown in Fig. 9 (also used by other researchers for RED


1162

previous study on how they can affect the performance of Fuzzy-RED, and so they can be seen as a ‘‘logical’’ set of rules for evaluating Fuzzy-RED. After an extensive series of simulations and analysis of their results a new set of rule base files was created (Figs. 3 and 4) (fine tuning). This set of files was used in the rest of the simulation scenarios (Scenarios 2–6) 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. 10 and 11 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 amount of packets in the queue for achieving this high throughput. While these are results from a very basic scenario (see Fig. 9) 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 conditions without changing any parameters of Fuzzy-RED.

Throughput (Mbps)

performance and evaluation Floyd & Jacobson, 1993). 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 packets. 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 Floyd and Jacobson (1993). The rule base files used for Scenario 1 were written without any

45 42.5 40 37.5 35 32.5 30 27.5 25 22.5 20 17.5 15 12.5 10 7.5 5 2.5 0

5.2. Scenarios 2–5 0

10

20

30

40

50

60

70

80

90

100

Time (sec)

In order to show the dynamic abilities of Fuzzy-RED we simulate various scenarios under a new network topology. In this network topology we have five sources (each has different delay links varying from 1 to 8 ms)

Fuzzy RED

RED

Fig. 14. Scenario 2—throughput vs. time (Fuzzy-RED dark line, RED gray).

400000.00

350000.00

300000.00

Bytes sent

250000.00

200000.00

150000.00

100000.00

50000.00

0.00 0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

80.00

90.00

100.00

Time (sec) Assured

Best Effort

Fig. 15. Scenario 2—bytes transmitted with Fuzzy-RED algorithm (best-effort bytes dark line, Assured bytes gray).


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 in different scenarios. The TCP window also varies from 50 to 150 packets. The buffer size is set to 140 packets. For RED the minimum threshold is set 45 packets and the maximum threshold to 135 packets. The new network topology used in this series of simulation scenarios is shown in Fig. 12. The link propagation delay and the TCP window were changed in order to show how Fuzzy-RED behaves under different network conditions (heavy traffic, low traffic) using the same parameters and rules. By increasing the TCP window we create conditions for 160.00

140.00

Drops (Packets)

120.00

100.00

80.00

60.00

40.00

20.00

0.00 0.00

20.00

40.00

60.00

80.00

100.00

Time (sec) Assured Class

Best Effort Class

Fig. 16. Scenario 2—packet drops with Fuzzy-RED algorithm (besteffort packets dark line, assured bytes gray).

1163

more traffic and by limiting the delay we can observe the response time of the algorithm. We present result from four simulations (simulation Scenarios 2–5). 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 but decrease the TCP window to 50 packets. In Scenario 4 we keep the same link delay between the routers as in Scenarios 2 and 3 at 10 ms but increase the TCP window to 150 packets. In Scenario 5 we keep the same TCP window as in Scenario 4 (at 150 packets) but double the routers link delay from 10 to 20 ms. From Fig. 13 we see that although we have increased the number of sources sending data, the 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. 14, while packet drops are kept at very low levels (Fig. 16) compared to the number of packets-bytes sent (Fig. 15). These results show clearly that Fuzzy-RED manages to adequately control the queue size while keeping a higher than RED throughput (97.11% compared with 99.57% of Fuzzy-RED). In Scenario 3 we reduce the TCP window from 100 packets to 50 packets in order to see how the algorithm will behave in lower traffic conditions. It is important to see the throughput and packet drops behavior. From Fig. 17 we see that the queue size remains at acceptable levels without having at any time large oscillations or a zero packet occupancy in the buffer, which is not the case with RED. The throughput is shown in Fig. 18. Although at the beginning is lower than that of RED at the end it

70.00

60.00

Queue (packets)

50.00

40.00

30.00

20.00

10.00

0.00 0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

80.00

90.00

Time (sec) RED

Fuzzy RED


100.00


1164

catches up at exactly 99.66%. This is important since it shows that the good characteristics shown with previous scenarios continue with this setup as well. Note also that the parameters of Fuzzy-RED remain unchanged. In Fig. 19 we see that the packets-bytes of both classes are transmitted at almost a constant rate and that drops as expected are fewer than in the case with bigger TCP window (see Fig. 20). Since Fuzzy-RED behaved relative well with reduced TCP window it was important to see how it will behave in cases of extreme traffic (created by simply increasing the TCP window to 150). The simulation run under these parameters was named Scenario 4. As it was expected the drops were increased by 10% but the throughput nearly matched 100%. As we see from Figs. 23 and 21 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 kept also at an almost constant rate (see Fig. 22). From Fig. 24 we can see that the QoS is also maintained by providing less drops in the Assured class than in the Best-Effort class. Scenario 5 uses the same network topology as Scenario 4 but the link delay between the routers is increased from 10 to 20 ms. In this scenario we test the behavior of the algorithm under greater delays. Fig. 25 shows that the queue is maintained at adequate levels, and this is shown better in Fig. 26 where the throughput is near 100% and clearly better than RED (98.57% for Fuzzy-RED and only 93.91% for RED). In Fig. 27 we 250.00

45.00 44.50 200.00

43.50 Drops (packets)

Throughput (Mpb)

44.00

43.00 42.50 42.00

150.00

100.00

41.50 41.00

50.00

40.50 40.00 0.00

0.00 0.00

10.00 20.00 30.00 40.00 50.00 60.00 70.00 80.00 90.00 100.00 Time (sec)

10.00

20.00

30.00

50.00

60.00

70.00

80.00

Assured


Fig. 20. Scenario 3—packet drops with Fuzzy-RED algorithm (besteffort packets dark line, assured packets gray).

350000.00

Sent (bytes)

300000.00

250000.00

200000.00

150000.00

100000.00

50000.00

10.00

20.00

30.00

100.00

Best Effort

400000.00

0.00 0.00

90.00

Time (sec)

Fuzzy RED

RED

40.00

40.00

50.00

Time (sec) Assured

60.00

70.00

80.00

90.00

100.00

Best Effort

Fig. 19. Scenario 3—bytes transmitted with Fuzzy-RED algorithm (best-effort bytes dark line, assured bytes gray).


1165

140

120

Queue (packets)

100

80

60

40

20

0 0

10

20

30

40

50

60

70

80

90

100

Time (sec) Fuzzy RED

RED


350000.00

300000.00

Sent (bytes)

250000.00

200000.00

150000.00

100000.00

50000.00

0.00 0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

80.00

90.00

100.00

Time (sec) Assured

Best Effort

Fig. 22. Scenario 4—bytes transmitted with Fuzzy-RED algorithm (best-effort bytes dark line, assured bytes gray).

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). 5.3. Scenario 6 In Scenario 6 we use the network topology presented in Fig. 28, used in Iannaccon et al. (2001), and compare Fuzzy-RED with RIO. Half of the sources are TCP/ FTP and the other half TCP/Web-like Traffic. Web-like traffic sources traffic is tagged as assured class traffic

and the FTP traffic as best effort. The choice of distributions and parameters is based on Iannaccon et al. (2001) and Feldmann, Gilbert, Huang, and Willinger (2000), and is summarized in Table 1. The implementation of the traffic sources is based on a recent version of ns-2 simulator (version 2.1.8b). 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 has a size of 1514 bytes. For the Tail Drop queue we


1166

define a buffer size of 226 packets. We use AQM (FuzzyRED or RIO) in the queues of the bottleneck link between router 1 and router 2. All other links have a simple Tail Drop queue. The importance of this scenario is that it compares and evaluates not simply the performance of an algorithm but the performance in implementing a new IP 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 DiffServ network. We also attempt to compare Fuzzy-RED with RIO (an RED based implementation of Diff-Serv). From the results we see that although Fuzzy-RED and RIO show similar behavior, Fuzzy-RED appears to control better the flow rate across the network. From Fig. 29 we see the throughput behavior. With throughput here we mean the rate at which traffic is coming to a link (in this case the link connecting router 1 with router 2) before entering any queue. So it is the total traffic arriving at router 1 (both FTP and Web-like traffic). From the graph RIO seems to stabilize its throughput around 10.25 Mbps (note that the link speed is limited to 10 Mbit/s). This means that it cannot effectively control the rate at which the sources are sending traffic (according to the ideal scenario shown in Fig. 8). Around t ¼ 2500 s we see a small ascending step. At that point the traffic increases further from 10.1 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. 30 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

45.00 40.00

Throughput (Mbps)

35.00 30.00 25.00 20.00 15.00 10.00 5.00 0.00 0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

80.00

90.00

100.00


RED

Fig. 23. Scenario 4—throughput vs. time (Fuzzy-RED dark line, RED gray). 250.00

Drops (packets)

200.00

150.00

100.00

50.00

0. 00 0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

80.00

90.00

100.00

Time (sec) Assured

Best Effort

Fig. 24. Scenario 4—packet drops (best-effort packets dark line, assured packets gray).

120.00

100.00

Queue (packets)

80.00

60.00

40.00

20.00

0.00 0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

80.00

90.00 100.00

Time (sec) RED

Fuzzy RED



queue is a novel, more effective, robust, scalable, and more flexible approach and 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 Fuzzy-RED is shown to behave well and deliver almost identical throughput results under various scenarios and conditions without any retuning or parameterization. Specifically Fuzzy-RED delivers in Scenarios 2, 3 and 4 more than 99.5% and for Scenario 5 98.5%. On the other hand, RED fails to deliver more than 98% in all cases except Scenario 3 and even then Fuzzy-RED achieves the same throughput. In Scenario 6 we see that Fuzzy-RED, using the same rules and values in the fuzzy sets (i.e., no finer tuning), has achieved equal or better performance than RIO, in which we use the optimal parameterization discussed in papers of Iannaccon et al. (2001) and Feldmann et al. (2000). From this scenario we see that Fuzzy-RED 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 with further refinement of the rule base, or self-tuning, Fuzzy-RED algorithm can achieve even better results. Of course, many open issues still require investigation. These include: Formal stability proof; investigation of alternative fuzzy rule structures, e.g. based on control theoretic concepts, Fairness; Robustness under various operating conditions, including a large number of

45.00 40.00

Throughput (Mbps)

35.00 30.00 25.00 20.00 15.00 10.00 5.00 0.00 0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

80.00

90.00

100.00

Time (sec) RED

1167

Fuzzy RED


create retransmissions. The difference is not as important as the fact that Fuzzy-RED seems to provide a more stable behavior. This result along with the previous encourages us to proceed with further testing in the future.

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 (such a case is the Internet) it fails to effectively control congestion. Our proposal in implementing a fuzzy logic controlled Diff-Serv RED

250000.00

Sent (Bytes)

200000.00

150000.00

100000.00

50000.00

0.00 0.00

10.00

20.00

30.00

40.00

50.00 60.00 Time (sec)

Sent Assured

70.00

80.00

90.00

100.00

Sent Best Effort

Fig. 27. Scenario 5—bytes transmitted (best-effort bytes dark line, Assured bytes gray).


1168

src0 / 20ms

dest0

dest1

src1 / 40ms

Rtr1

Rtr0

Rtr2

Rtr3 500 Mbps / 1ms delay links

500 Mbps links 100 Mbps /

10 Mbps

100 Mbps /

10ms

/ 30 ms

10ms dest2

src2 / 20ms

dest3 src3 / 40ms

Fig. 28. Scenario 6—network topology. Table 1 Distributions and parameters for Web-like traffic Inter-page time

Objects per page

Inter-object time

Object size

Pareto 50 ms 2

Pareto 4 ms 1.2

Pareto 0.5 ms 1.5

Pareto 12 KB 1.2

Goodput (Mbps)

Distribution Mean Shape

10.0

9.5

9.0

10.5

8.5

Throughput (Mbps)

10.0

0

1000

2000

3000

4000

5000

Time (sec)

9.5

Fuzzy RED 9.0

RED

Fig. 30. Scenario 6—goodput vs. time. (This is the useful throughput, i.e., retransmissions have been removed).

8.5 8.0 7.5 7.0 0

1000

2000

3000

4000

5000


RED

Fig. 29. Scenario 6—throughput vs. time. (Link bandwidth is limited to 10 Mbit/s. Any excess above 10 Mbit/s will be lost and will require to be retransmitted).

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 is to use existing empirical knowledge and ‘rules of thumb’ gathered by several researchers and build the Fuzzy Control rule base using this knowledge. From the results presented and past experience with successful implementations of fuzzy logic control (Pitsillides et al., 1997), we are very optimistic that the Fuzzy Control methodology will offer significant improvements on controlling congestion in TCP/IP Diff-Serv networks.

References Athuraliya, S., Li, V. H., Low, S. H., & Yin, Q. (2001). REM: Active queue management. IEEE Network, 15(3), 48–53.

C. Chrysostomou et al. / Control Engineering Practice 11 (2003) 1153–1170 Aweya, J., Ouellette, M., Montuno, D. Y., & Chapman, A. (2001). A control theoretic approach to active queue management. Computer Networks, 36, 203–235. Azvine, B., & Vasilakos, A. (2000). Application of soft computing techniques to the telecommunication domain. ERUDIT Roadmap, (G. Tselentis, Ed.) pp. 89–110, http://www.erudit.de/erudit/papers/ Roadmap.pdf. Bezdek, J. C. (1994). What is computational intelligence: Imitating life (pp. 1–12). New York: IEEE Press. Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z., & Weiss, W. (1998). An architecture for differentiated services. RFC 2475 (also see IETF Differentiated Services Working Group http://www. ietf.org/html.charters/diffserv-charter.html). Blake, S., et al. (1998). An architecture for Differentiated Services. Request for Comments RFC 2475, Internet Engineering Task Force. Bonald, T., May, M., & Bolot, J. C. (2000). Analytic evaluation of RED performance. Proceedings of the IEEE INFOCOM 2000, Tel Aviv, Israel. Braden, B., et al. (1998). Recommendations on queue management and congestion avoidance in the Internet. Request for Comments RFC 2309, Internet Engineering Task Force. Braden, R., Clark, D., & Shenker, S. (1994). Integrated services in the Internet architecture: An overview. Request for Comments RFC 1633, Internet Engineering Task Force. Brakmo, L., & Peterson, L. (1995). TCP Vegas: End to end congestion avoidance on a global Internet. IEEE Journal of Selected Areas in Communications, 13(8), 1465–1480. Brown, M., & Harris, C. (1994). Newrofuzzy adaptive modelling and control. Englewood cliff, NJ: Prentice-Hall. Clark, D., & Fang, W. (1998). Explicit allocation of best effort packet delivery service. IEEE/ACM Transactions on Networking, 6(4), 362–373. Driankov, D., Hellendoorn, H., & Reinfrank, M. (1993). An introduction to fuzzy control. Berlin: Springer. Feldmann, A., Gilbert, A. C., Huang, P., & Willinger, W. (2000). Dynamics of IP traffic: A study of the role of variability and the impact of control. ACM, SIGCOMM 2000, Boston, MA. Feng, W. (1999). Improving Internet congestion control and queue management algorithms. Ph.D. Dissertation, University of Michigan, USA. Feng, W., Kandlur, D., Saha, D., & Shin, K. (1999a). Blue: A new class of active queue management algorithms. Technical Report, UM CSE-TR-387-99, University of Michigan, USA. Feng, W., Kandlur, D., Saha, D., & Shin, K. (1999b). A selfconfiguring RED gateway. Proceedings of the IEEE INFOCOM 1999, New York, USA. Firoiu, V., & Borden, M. (2000). A study of active queue management for congestion control. Proceedings of the IEEE infocom 2000, Tel Aviv, Israel. Floyd, S., & Fall, K. (1999). Promoting the use of end-to-end congestion control in the Internet. IEEE/ACM Transactions on Networking, 7(4), 458–472. Floyd, S., & Jacobson, V. (1993). Random early detection gateways for congestion avoidance. IEEE/ACM Transactions on Networking, 1(4), 397–413. Heinamen, J., Baker, F., Weiss, W., & Wroclawski, J. (1999). Assured forwarding PHB Group. Request for Comments RFC 2597, Internet Engineering Task Force. 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. Proceedings of the sixth IEEE symposium on computers and communications 2001, Hammamet, Tunisia. Jacobson, V. (1988). Congestion avoidance and control. ACM SIGCOMM 1988, Stanford, CA.

1169

Jacobson, V., Braden, R., & Borman, D. (1992). TCP extensions for high performance. Request for Comments RFC 1323, Internet Engineering Task Force. Jacobson, V., Nichols, K., & Poduri, K. (1999). An Expedited Forwarding PHB. Request for Comments RFC 2598, Internet Engineering Task Force. Jeffay, M. C. K., Ott, D., & Smith, F. (2000). Tuning red for web traffic. ACM SIGCOMM, 2000, Stockholm, Sweden. Karn, P., & Partridge, C. (1987). Improving round-trip time estimates in reliable transport protocol. ACM SIGCOMM 1987, Stowe, VT. Kohler, S., Menth, M., & Vicari, N. (2000). Analytic performance evaluation of the RED algorithm for QoS in TCP/IP. Research Report Series, Report No. 259. Institute of Computer Science, University of Wurzburg. Lakshman, T. V., & Madhow, U. (1997). The performance of TCP/IP for networks with high bandwidth delay products and random loss. IEEE/ACM Transactions on Networking, 5(3), 336–350. Lin, D., & Morris, R. (1997). Dynamics of random early detection. ACM SIGCOMM Computer Communications Review, 27, 127–136. May, M., Bonald, T., & Bolot, J. C. (2000). Analytic evaluation of RED performance. Proceedings of the IEEE Infocom 2000, Tel Aviv, Israel. May, M., Bolot, J. C., Jean-Marie, A., & Diot, C. (1999). Simple performance models of differentiated services schemes for the Internet. Proceedings of the IEEE INFOCOM 1999, New York, USA. Misra, V., Gong, W. B., & Towsley, D. (2000). Fluid-based analysis of a network of AQM routers supporting TCP flows with an application to RED. ACM SIGCOMM 2000, Stockholm, Sweden. Morales, E., Polycarpou, M., Hemasilpin, N., & Bissler, J. (2001). Hierarchical adaptive and supervisory control of continuous venovenous hemofiltration. IEEE Transactions on Control Systems Technology, 9(3), 445–457. Network Simulator, ns-2, Homepage, http://www.isi.edu/nsnam/ns/. Nichols, K., et al. (1998). Definition of the differentiated Services Field in the Ipv4 and Ipv6 Headers. Request for Comments RFC 2474, Internet Engineering Task Force. Ott, T. J., Lakshman, T. V., & Wong, L. H. (1999). SRED: Stabilized RED. Proceedings of the IEEE INFOCOM 1999, New York, USA. Passino, K., & Yurkovich, S. (1998). Fuzzy control. Reading, MA: Addison-Wesley. Pedrycz, W. (1998). Computational intelligence: An introduction. Boca Raton, FL: CRC Press. 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 1999, Cyprus. Pitsillides, A., & Sekercioglu, A. (2000). Congestion control. In W. Pedrycz, & A. V. Vasilakos (Eds.), Computational intelligence in telecommunications networks (pp. 109–158). Boca Raton, FL: CRC Press, ISBN: 0-8493-1075-X. Pitsillides, A., Sekercioglu, A., & Ramamurthy, G. (1997). Effective control of traffic flow in ATM networks using fuzzy explicit rate marking (FERM). IEEE Journal on Selected Areas in Communications (JSAC), 15(2), 209–225. Ramakrishnan, K. K., 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. Ramakrishnan, K. K., & Floyd, S. (1999). A proposal to add explicit congestion notification (ECN) to IP. Request for Comments RFC 2481, Internet Engineering Task Force. Sekercioglou, A., Pitsillides, A., & Egan, G. K. (1994). Study of an adaptive fuzzy controller based on the adaptation of relative rule weights. Proceedings of the ANZIIS 1994 (pp. 204–208), Brisbane, Queensland, Australia.

1170


Sekercioglu, A., Pitsillides, A., & Vasilakos, A. (2001). Computational intelligence in management of ATM networks. Soft Computing Journal, 5(4), 257–263. Shenker, S., Zhang, L., & Clark, D. D. (1990). Some observation on the dynamics of a congestion control algorithm. Computer Communication Review, 30–39. Stevens, W. (1994). TCP/IP illustrated, Volume 1 the protocols. Reading, MA: Addison-Wesley. Stevens, W. (1997). TCP slow start, congestion avoidance, fast retransmit, and fast recovery algorithms. Request for Comments RFC 2001, Internet Engineering Task Force.

Yasunobu, S., & Miyamoto, S. (1985). Automatic train operation by predictive fuzzy control. In M. Sugeno (Ed.), Industrial applications of fuzzy control (pp. 1–18). Amsterdam: Elsevier. Zhang, L. (1989). A new architecture for packet switching network protocols. Ph.D. Dissertation, M.I.T. Lab. Computer Science. Ziegler, T., Fdida, S., & Brandauer, C. (2001). Stability criteria of RED with TCP traffic. Proceedings of the IFIP ATM&IP working conference, Budapest, Hungary.