1 / 28

Soft-Ware 2002 Belfast, 8-10 April 2002

Soft-Ware 2002 Belfast, 8-10 April 2002. Overview of Fuzzy-RED in Diff-Serv Networks Andreas Pitsilides, University of Cyprus. OVERVIEW. Introduction Congestion Control problem Diff-Serv architecture RED and its variants Fuzzy Logic Fuzzy-RED Simulation results Conclusions.

kisha
Download Presentation

Soft-Ware 2002 Belfast, 8-10 April 2002

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Soft-Ware 2002Belfast, 8-10 April 2002 Overview of Fuzzy-RED in Diff-Serv Networks Andreas Pitsilides, University of Cyprus

  2. OVERVIEW • Introduction • Congestion Control problem • Diff-Serv architecture • RED and its variants • Fuzzy Logic • Fuzzy-RED • Simulation results • Conclusions

  3. Introduction • Network congestion control remains a critical and high priority issue. • Rapid growth of the Internet • Increased demand to use the Internet • time-sensitive voice and video applications • Necessitates the design and utilization of effective congestion control algorithms, especially for new architectures, such as Differentiated Services (Diff-Serv).

  4. Diff-Serv Architecture • Currently, interest is mainly for Diff-Serv architectures • Scalability problems for Int-Serv. • A more evolutionary approach thanInt-Serv • Int-Serv uses RSVP as a signaling protocol to establish the reservation path between the two nodes. • connection establish overheads • complexity and scalability problems in large networks • Diff-Serv does not require significant changes to the Internet Infrastructure. • provides differentiation of services

  5. Diff-Serv Architecture(cnt’d) • Uses existing ToS (Type of Service) bits in IP header for service (aggregated traffic classes) differentiation • Works in the edges of a network • Provides QoS using drop-preference algorithm • Diff-Serv working group: • Two broad aggregate behaviour groups (classes of services): • Expedited Forwarding (EF) Per-Hop Behaviour (PHB) • Assured Forwarding (AF) PHB

  6. Diff-Serv Architecture(cnt’d) • Expedited Forwarding – EF: • Low losses • Very low queuing delays • Allocation of resources through SLA (Service Level Agreement) at connection setup • Assured Forwarding – AF: • Low packet losses • Has 3-4 independent forward classes • Each such class has 2-3 different drop preferences • Preferentially drops best-effort packets and non-conforming packets when congestion occurs

  7. Diff-Serv Architecture(cnt’d) • Priorities are set at the edges of the network • reduces the complexity • more scalable • No measures are taken to assure that the priorities would actually mean something when the packet enters the Internet. • Diff-Serv provides only a rudimentary QoS • No quantified guaranties

  8. Congestion Control Problem (cnt’d) • Provide some QoS using some differentiated services aware congestion control algorithm. • RED (Random early Detection) algorithm was proposed as an Active Queue Management (AQM) approach to be employed by Internet routers. • AQM mechanisms start dropping packets earlier in order to be able to notify traffic sources about the incipient stages of congestion. • Contrary to the Tail Drop (TD) queue management approach, where the discarding arriving packets policy is based on the overflow of the output port buffer.

  9. RED (RIO) and its variants • Most popular algorithm used for Diff-Serv implementation: for each packet arrival • calculate the average queue size avg if minth avg maxth • calculate probability pa • with probability pa: mark the arriving packet else if maxth avg • mark the arriving packet min and max dropping thresholds for each predefined class in the router queues.

  10. EF AF Class Best Effort Yes Priority Queue Check and traffic shaping No Discard RIO Queue Max Min RED and its variants(cnt’d) • A simple Diff-Serv scenario • RED is used for queue control • RIO (RED In/Out) queue • packets are in or out of the connection conformance agreement

  11. RED and its variants(cnt’d) • Number of unresolved issues: • Problems with performance of RED under different scenaria of operation • Most of the existing studies are obtained with simulations suggesting modifications to the algorithm. • Tuning of RED parameters • The correct tuning of RED implies a “global” parameterization that is very difficult. • Linearity of the dropping function has been questioned by a number of researchers.

  12. FUZZY LOGIC • Part of Computational Intelligence. • Exploit the well known advantages of fuzzylogic control: • Ability to quickly express the control structure of a system using a priori knowledge • Less dependence on the availability of a precise mathematical model; • Easy handling of the inherent nonlinearities • Easy handling of multiple input signals.

  13. FUZZY LOGIC(cnt’d) • Fuzzy Logic Controllers (FLC) • Alternative, non-conventional way of designing feedback controllers • 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.

  14. Fuzzy-RED • A fuzzy logic controlled RED queue in Diff-Serv implementation • We replaced fixed thresholds with an FLC • Calculates pa based on two inputs, queue size and queue rate of change • The two inputs are described by fuzzy sets • The FLC determines the pa by applying a set of rules. • Each class of service has an FLC

  15. Fuzzy-RED (cnt’d) • Decision surface of the fuzzy inference engine of the “assured” class. • The control surface is shaped by the rule base and the linguistic values of the linguistic variables.

  16. Fuzzy-RED (cnt’d) • Decision surface of the fuzzy inference engine of the “best effort” class. • The control surface is shaped by the rule base and the linguistic values of the linguistic variables.

  17. Fuzzy RED - The algorithm Algorithm: for each packet arrival calculate queue size, queue rate of change calculate probability pa based on above metrics with probability pa mark the arriving packet pa is calculated by the FLC • Based on linguistic rules we calculate the dropping probability • Each class of service has its own definition of set and rules • Sample of rules: • If q is empty the pa is zero • If q is full and dq is zero the pa is medium • If q is full and dq is increasing then pa is high

  18. Fuzzy RED-Initial Tests

  19. Fuzzy RED-Initial Results throughput Buffer length

  20. Fuzzy RED – QoS Scenario • In order to show the dynamic abilities of Fuzzy-RED we use a new network topology. • propagation delay between the two routers is set to 10 ms. • The TCP window is set to 100 packets. Buffer size is set to 140 packets. • For RED the min threshold is set to 45 packets and the max threshold to 135 packets. Network Topology

  21. Fuzzy RED- QoS Results Queue behaviour throughput

  22. Fuzzy RED- QoS Results Bytes sent drops

  23. Fuzzy RED- QoS Conclusion • From the figures: • Although number of sources and sending data increased, Fuzzy RED manages to keep the queue size in a close to constant value and significantly better than RED. • Fuzzy RED matches a near 100% throughput (99.57%) while packet drops are kept at very low levels compared to the number of packets sent. • These results show clearly that Fuzzy RED manages to adequately control the queue size while keeping a higher that RED throughput (97.11% compared with 99.57% of Fuzzy RED).

  24. Fuzzy RED - Diff-Serv • To simulate a basic Diff-Serv environment we • introduce a combination of web-like traffic sources and TCP/FTP sources. • Half of the sources are TCP/FTP and the other half TCP/Web-like Traffic. • Traffic from the Web-like sources is tagged as assured class traffic and the FTP traffic as best effort. • We run the simulation three times for 5000 seconds each in order to enhance the validity of the results.

  25. Fuzzy RED - Diff-Serv Scenario We use TCP/SACK with a TCP window of 100 packets. Each packet has a size of 1514 bytes. For the Droptail queue we define a buffer size of 226 packets. We use AQM (Fuzzy RED or RIO) in the queues of the bottleneck link between router 1 and router 2. All other links have a simple droptail queue.

  26. Fuzzy RED - Diff-Serv Results Throughput prior to the bottleneck link of 10 Mbits/sec (excess throughput above 10 Mbits/sec will be lost) Goodput after the bottleneck link (goodput: traffic rate traversing a link minus all dropped packets and all retransmitted packets.)

  27. Fuzzy RED - Diff-Serv Conclusion • From graphs • RIO seems to stabilise its throughput around 10.25 Mbps (note that the link speed is limited to 10 Mbit/sec). This means that it can’t effectively control the rate at which the sources are sending traffic. • Around t=2500sec we see a small ascending step. At that point the traffic increases further from 10.1 Mbps to a 10.25 Mbps. This means that we have an increase of drops and therefore a decrease of goodput. • Fuzzy-REDdelivers a steady goodput around 9.9 Mbps while RIO has a decrease from 9.9 to 9.8 due to dropped packets that create retransmissions. • The difference is not as important as the fact that Fuzzy-RED seems to provide a more stable behaviour.

  28. Fuzzy RED - Conclusions Advantages: • Simplicity • Effectiveness • Scalability - each class has its own FLC rule file • Robustness Future Work: • Check also fairness in Diff-Serv environment • Deployment issues • Explore other Fuzzy Rule Base (e.g. Adaptive)

More Related