Analysis and Evolution of AQM Algortihms

Analysis & Evolution Of

AQM Algorithms

SUBMITTED BY:

SIDDHARTH NAWANI

Presentation Outlines General Idea of the Project.

General background about different AQM’s (RED & DropTail)

Modified RED AQM

Project Implementation Details

Future Work

Testing

Issues

Mathematical Elaboration

Abstract

The project focuses on how congestion control and queue management techniques have evolved over time and being modified to minimize the rate of packet loss. Extensive relevant research has been done on the existing AQM’s and from the midst of RED, our algorithm has evolved. The key idea is to modify the existing RED algorithm to achieve stabilization in Queue length, decrease in packet loss rate at routers and increased throughput in comparison to RED. The packet probability marking function of RED has been modified into four different functions and the results and effects on various parameters like Queue length, packet loss etc have been simulated and compared. The design rationale of RED has been studied and enhanced to achieve better stabilized queue and throughput.

Need…

Due to the enormous growth of the internet, demands for access from multiple users have increased and the request for new services for its application have also increased significantly. Due to this , there have been an increase in packet loss rates and drop in network efficiency. The problem has been well discussed over several years, still conventional Active Queue Management Algorithms cannot provide low complexity deployment.

Background - General

In today’s networks, transport layer protocols are the one responsible for congestion avoidance

When there is congestion in the router and its queue gets over flown , it drops packets from the tail until there is space to receive new packets in the buffer

The protocol is completely transparent to the hosts, they see it as “Black Box”. Their only indication of congestion is packet loss

The conventional algorithms

RED

Droptail

Drop Tail

The traditional technique for managing router is the method known as "tail drop“.

This method has served the Internet well for years, but it has two important drawbacks:

LOCK OUT

Drop-tail routers treat bursty traffic poorly

Traffic gets synchronized easily allows a few flows to monopolize the queue space

TCP-GLOBAL SYNCHRONIZATION

In computer networks It can happen to TCP/IP flows during periods of congestion because each sender will reduce their transmission rate at the same time when packet loss occurs.

Other Problems in real network scenarios

TCP global Synchronization

Congestive Collapse Network protocols which use aggressive retransmissions to

compensate for packet loss tend to keep systems in a state of network congestion even after the initial load has been reduced to a level which would not normally have induced network congestion. Thus, networks using these protocols can exhibit two stable states under the same level of load. The stable state with low throughput is known as congestive collapse

Fairness among different flows

Active Queue Management

In summary, an active queue management mechanism can provide the following advantages for responsive flows:

1. Reduce number of packets dropped in routers

By keeping the average queue size small, active queue management will provide greater capacity to absorb naturally- occurring bursts without dropping packets. Without active queue management, more packets will be dropped when a queue does overflow.

2. Provide lower-delay interactive service

By keeping the average queue size small, queue management will reduce the delays seen by flows. This is particularly important for interactive applications such as short Web transfers, Telnet traffic, or interactive audio-video sessions,whose subjective (and objective) performance is better when the end-to-end delay is low.

3. Avoid lock-out behavior

Active queue management can prevent lock-out behavior by ensuring that there will almost always be a buffer available for an incoming packet. For the same reason, active queue management can prevent a router bias against low bandwidth but highly bursty flows.

RED(Random Early Detection)

RED was designed with the objectives to

(1) minimize packet loss and queuing delay,

(2) avoid global synchronization of sources,

(3) maintain high link utilization, and

(4) remove biases against bursty sources.

RED gateways require the user to specify five parameters: the maximum buffer size or queue limit (QL), the minimum (minth) and maximum (maxth) thresholds of the "RED region", the maximum dropping probability (maxp), and the weight factorused to calculate the average queue size (wq).

RED – Cont.

Early packet dropping starts when the average queue size exceeds minth.

RED was specifically designed to use the average queue size (avg), instead of the current queue size, as a measure of incipientcongestion, because the latter proves to be rather intolerant of packet bursts.

avg is calculated as an exponentially weighted moving average using the following formula:

avg i = (1 - wq) × avgi-1 + wq × q

RED- Algorithm

Flow Graph

Packet Probability Marking function of RED

Simulations

The Topology Used:

Comparison on the basis of throughput

At Node 4:

Using RED: 0.241504MBytes/sec

Using DropTail: 0.207008MBytes/sec

At Node 5:

Using RED : Avg Throughput 0.20084Mbytes/sec

Using DropTail: Ang Throughput 0.184832Mbytes/sec

Throughput Graph for RED

PHASE -2

MODIFYING AN EXISTING ALGORITHM(RED)

The AlgorithmWhat’s About to change ?...

Pb = Pmax*(avg – th_min)/(th_max-th_min)

Pa = Pb / (1 – count*Pb)

RED calculates the probability of dropping a packet by 2 steps when average queue size falls in between th_min and th_max. The first step is to calculate a probability called Pb, which is based on the formula below,

It can be seen that the probability Pb is calculated based on a linear function.

In the second step, RED counts the number of packets have gone through the gateway (count) since last packet is dropped from the flow and apply the following formula,

SUBSYTEMSWhat’s New ?..

In this part, we modified the first step by applying 2 different functions to calculate Pb and compare the results. The curves for the 2 functions are roughly in left.

2

Mathematical Representation :

Original function:

Modified Functions: V1: Pb = Pmax*(m*log(v_ave) + n)

V2: Pb = Pmax*(m*exp(v_ave)+n)

Pb = Pmax*(v_a * v_ave + v_b) where v_a = 1.0 / (th_max – th_min), v_ave is the average queue size, and v_b = -th_min / (th_max – th_min).

SYSTEM INTEGRATIONChanges in the code

Add a variable func to the data structure edp.

Bind the variable in REDQueue constructor REDQueue::REDQueue

bind (“function_”,&edp_.func)’

Calculate p_new_probability function

Make changes in ns-default.tcl Queue/RED set function_ 0

Results

Simulation Topology

(scenario [15,45])

Modified RED

Drop Tail

COMPARATIVE ANALYSIS OF VARIOUS AQM VARIATIONS

Original RED

Concave Packet Probability Marking Function(v1)

Convex Packet Probability Marking Function(v4)

Piece-wise linear Packet Probability Marking Function(v2)

Piece-wise linear Packet Probability Marking Function(v3)

FINDINGS & CONCLUSION

Queue SizeFrom the plot, we can see that v1 keeps the average

queue size at a lower level than regular RED, while v4 keeps the average queue size at a higher level than regular RED. This is expected as v1 is always above the original linear function given the same average queue size value in the range of [th_min, th_max], in other words, v1 is more aggressive in terms of dropping packets when the average queue size is between th_min and th_max. On the contrast, v4 is less aggressive than regular RED.

Packet Loss From the simulation for loss packets, we can see that V4 ensures less

packet drop than regular RED and vice versa in case of V1, in which packet is dropped at a higher rate than V1 and regular RED algorithm. Same can be deduced for V2 and V3, with V2 being on the higher side.

Scenario[minp,maxp] Function/AQM Packet Sent Packet Lost % Packet Loss

[15,45] RED 18736 27 1.44

[15,45] Concave function (v1) 18717 23 1.22

[15,45] Piece wise Linear(v2) 18698 28 1.49


[15,45] Convex function (v4) 18194 44 2.41

[20,60] RED 18671 25 1.33





[25,75] RED 18645 29 1.55





[30,90] RED 18511 26 1.40





Table Showing Packet Loss For differect Scenarios & Functions

Throughput From the simulations, we can see that V4 function ensures higher

throughput than regular RED and V1 function.

Requirement specification

Functionality The purpose of this AQM is to stabilize the Average Queue length at

routers.

External Interface The AQM can be simulated in Network Simulator 2.34 and higher.

Unix environment will be used to simulate the Otcl and C++ classes.

The interaction of software will be through command line interface (like Unix and NS2)

Required Performance The complexity of the algorithm is O(N), where N is the total number of

routers participating in the exchange of Data at a particular time.

The robustness of the algorithm is tested and simulated with 50 Nodes including two main congestion control routers.

The simulated time with fixed delay of 100ms, proved to be under 1 sec.

Quality Attributes The design rationale of Modified RED AQM, is made closely with the actual

RED AQM, Hence all the standard measures of correctness, maintainability and security have been followed strictly.

Design Constraints imposed on the implementation The Testing has been done under a simulated scenario, keeping the delay

in consideration as close as possible to the real life scenario.

ISSUES

Installing Ns2.34 in Ubuntu 13.04 (resolved)

Appropriate parameters for running RED. Keeping the number of nodes high to observe the changes. Leading to overhead.

Appropriate parameters for running RED. Keeping the number of nodes high to observe changes in throughput.

It was observed that results in a particular scenario [20,60] beg to differ slightly from other scenarios.

COMPLEXITY & TESTING OF MODULE

Determining Complexity Most of the algorithms claim that they can provide fair sharing among different flows

without imposing too much deployment complexity. Most of the proposals focus on only one aspect of the problem (whether it is fairness, deployment complexity, or computational overhead), or fix the imperfections of previous algorithms, and their simulations setting are different from each other. These all make it difficult to evaluate, and to choose one to use under certain traffic load.

The complexity can be defined in terms of the following: DEPLOYMENT COMPLEXITY

The modified version of RED offers low deployment complexity as changes can be done in the original RED algorithm only and no new components need to be installed.

COMPUTATIONAL OVERHEAD

Each arriving packet at the respective Router triggers the algorithm(same as RED)

BIG-O-NOTATION

O(Nt); N-> is the number of arriving packet arriving at the routers for a particular flow.

The Algorithm is designed to work with the main routers

Performance evaluation By comparison

The comparison of the obtained queue length was done with the original RED AQM.

By comparison

ORIGINAL RED

MODIFIED CONCAVE AQM MODIFIED CONVEX AQM

Scenario :Queue/RED set thresh_ 15Queue/RED set maxthresh_ 45

RESULTS(Average Queue Length):

ORIGINAL RED: 130(approx)CONCAVE RED: 100 (approx)CONVEX RED 155(approx)

TYPE OF TEST WILL TEST BE PERFORMED

COMMENTS/EXPLANATION

SOFTWARE COMPONENT

Requirement Testing

Yes Involves testing of all the required components

Existing RED & Droptail AQM

Unit yes Unit of Algorithms including Average queue length, loss rates etc

RED

Integration Yes Integration of the changes done in the original RED

RED, Modified RED

Performance Yes Does not crash for high number of nodes

Modified RED

Stress Yes No. of load for which the algorithm works fine

Modified RED

Compliance NO Standards maintained by RED

Modified RED

Security NO Same standards as maintained by RED

Modified RED

Load Yes Tested for 50 + nodes

Modified RED

Role Name Specific Responsibilities

Developer & Tester

Siddharth Nawani

Working on developing and integration of modules. Testing of the whole Algorithm

The average queue length was tested for four different scenarios

Scenario 1: Queue/RED set thresh_ 15

Queue/RED set maxthresh_ 45







Risk Analysis & Mitigation Plan

Risk

Potential Impact on

Project SuccessL/M/H

Likelihood of

OccurrenceL/M/H

Mitigation Plan

1.Project Size H H Decomposition(Break into smaller phases

Phased implementation) 2. Project Scope H H Decomposition

Add another analysis phase Detailed specifications Early prototype/review of

functionality Add more time to the project

schedule.3. Project Decision-Making L(no

sponsor and one decision

maker)

L The Coder as well as the project implanter take care of this

4. Environmental State (Networking) H(it’s volatile and yest to be deployed)

H Additional testing, particularly stress testing

Training on new environment Find other projects using a similar

environment to compare notes Get a prototype deployed ASAP

on new environment

5. Team’s Experience M(Since no similar

Project has been done)

M Less effect since the project team comprises of one member only.

Cross referencing results with other verified results

6. Project Schedule L(Since the process is

still in developmen

t phase)

L Supplement resources (outside consultants, other groups)

FUTURE WORK

FUTURE WORK continues…

Later on we will propose an algorithm combining the advantage of BLUE, RED & CHOKe algorithm to minimize the loss rate.

THANK YOU FOR YOUR VALUABLE TIME… ;)


RED’s packet marking probability function Pb = Pmax*(v_a * v_ave + v_b) (1)

v_a = 1.0 / (th_max – th_min), v_ave is the average queue size, and v_b = -th_min / (th_max – th_min).


RED’s packet marking probability function Pb = Pmax*(v_a * v_ave + v_b) (1)

v_a = 1.0 / (th_max – th_min), v_ave is the average queue size, and v_b = -th_min / (th_max – th_min).

For the concave function: Pb = Pmax*(m*log(v_ave) + n) (2)

0 = Pmax*(m*log(th_min) + n) (3)

Pmax = Pmax*(m*log(th_max + n)) (4)

0 = Pmax*(v_a*th_min + v_b) (5)

m = 1/(log(th_max) – log(-v_b/v_a)) (6)

n = -m*log(-v_b/v_a) (9)

For the convex function Pb = Pmax*(m*exp(v_ave)+n)

(1)

m = 1/(exp(th_max) – exp(-v_b/v_a)) (2)

n = -m*exp(-v_b/v_a) (3)

Analysis and Evolution of AQM Algortihms

Engineering

Transcript of Analysis and Evolution of AQM Algortihms