Soft ware 2002 belfast 8 10 april 2002
This presentation is the property of its rightful owner.
Sponsored Links
1 / 28

Soft-Ware 2002 Belfast, 8-10 April 2002 PowerPoint PPT Presentation


  • 45 Views
  • Uploaded on
  • Presentation posted in: General

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.

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Soft ware 2002 belfast 8 10 april 2002

Soft-Ware 2002Belfast, 8-10 April 2002

Overview of Fuzzy-RED in

Diff-Serv Networks

Andreas Pitsilides, University of Cyprus


Overview

OVERVIEW

  • Introduction

  • Congestion Control problem

  • Diff-Serv architecture

  • RED and its variants

  • Fuzzy Logic

  • Fuzzy-RED

  • Simulation results

  • Conclusions


Introduction

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).


Diff serv architecture

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


Diff serv architecture cnt d

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


Diff serv architecture cnt d1

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


Diff serv architecture cnt d2

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


Congestion control problem cnt d

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.


Red rio and its variants

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.


Red and its variants cnt d

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


Red and its variants cnt d1

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.


Fuzzy logic

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.


Fuzzy logic cnt d

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.


Fuzzy red

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


Fuzzy red cnt d

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.


Fuzzy red cnt d1

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.


Fuzzy red the algorithm

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


Fuzzy red initial tests

Fuzzy RED-Initial Tests


Fuzzy red initial results

Fuzzy RED-Initial Results

throughput

Buffer length


Fuzzy red qos scenario

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


Fuzzy red qos results

Fuzzy RED- QoS Results

Queue behaviour

throughput


Fuzzy red qos results1

Fuzzy RED- QoS Results

Bytes sent

drops


Fuzzy red qos conclusion

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).


Fuzzy red diff serv

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.


Fuzzy red diff serv scenario

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.


Fuzzy red diff serv results

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.)


Fuzzy red diff serv conclusion

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.


Fuzzy red conclusions

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)


  • Login