distributed traffic management framework

Main Project Report

on

Distributed Traffic Management Framework

(using Fuzzy Logic Control)

Submitted by

Saurabh U NambiarSurya Prabha C P

Smruthi KShijil K

Department of Computer Science and Engineering

GOVT. COLLEGE OF ENGINEERING,KANNUR

MARCH 2014

GOVERNMENT COLLEGE OF ENGINEERING

KANNUR

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

CERTIFICATE

This is to certify that this Main Project report entitled “DistributedTraffic Management Framework using Fuzzy Logic Control” is abonafide record of the Main Project done by Saurabh U Nambiar(B0ENCS1109), Surya Prabha C P (B0ENCS1130), Smruthi K(B0ENCS1129) and Shijil N (A7ENCS1137) in partial fulfillment ofthe requirement for the award of the Degree of Bachelor of Technologyin Computer Science & Engineering under Kannur University.

Dr. K. NajeebProject coordinator Professor & Head

Department of CSE

Acknowledgment

We express our sincere thanks to Dr. K. Najeeb (HOD, Department of

Computer Science and Engineering, GCE Kannur) for the support and

constant encouragement that has been provided. We extend our deep

sense of gratitude to him for providing us with valuable guidance and

encouragement throughout the project.

We are very thankful to our Principal, Dr. Shyam Prakash for pro-

viding us with the facilities to complete the project.

We thank all the teaching and non-teaching staff, our classmates

and friends for sharing their knowledge and valuable suggestions.

Abstract

In view of the fast-growing Internet traffic, this project is based on a dis-

tributed traffic management framework, in which routers are deployed

with intelligent data rate controllers to tackle the traffic mass. Unlike

other explicit traffic control protocols that have to estimate network pa-

rameters (e.g., link latency, bottleneck bandwidth, packet loss rate, or

the number of flows) in order to compute the allowed source sending

rate, our fuzzy-logic-based controller can measure the router queue size

directly; hence it avoids various potential performance problems aris-

ing from parameter estimations while reducing much consumption of

computation and memory resources in routers. As a network parame-

ter, the queue size can be accurately monitored and used to proactively

decide if action should be taken to regulate the source sending rate,

thus increasing the resilience of the network to traffic congestion. The

communication QoS (Quality of Service) is assured by the good perfor-

mances of our scheme such as max-min fairness, low queueing delay

and good robustness to network dynamics. Simulation results and com-

parisons have verified the effectiveness and showed that our new traffic

management scheme can achieve better performances than the existing

protocols that rely on the estimation of network parameters.

Contents

1 Introduction 11.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Breif Overview . . . . . . . . . . . . . . . . . . . . . 1

2 Background Information 32.1 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Congestion Control . . . . . . . . . . . . . . . 3

2.2 Other Explicit Congestion Control Protocols . . . . . . 4

2.2.1 XCP . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.2 RCP . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.3 Others . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Fuzzy Logic Control . . . . . . . . . . . . . . . . . . 7

2.3.1 Fuzzification . . . . . . . . . . . . . . . . . . 8

2.3.2 Inference . . . . . . . . . . . . . . . . . . . . 9

2.3.3 Defuzzification . . . . . . . . . . . . . . . . . 9

3 System Analysis 113.1 Existing Model . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 Disadvantages of Existing System . . . . . . . 11

3.2 Proposed System . . . . . . . . . . . . . . . . . . . . 12

i

Project Report Distributed Traffic Management

3.2.1 Advantages of Proposed System . . . . . . . . 12

4 Requirements Specification 144.1 Hardware Specification . . . . . . . . . . . . . . . . . 14

4.2 Software Specification . . . . . . . . . . . . . . . . . 15

5 System Design 165.1 Complete Network Model . . . . . . . . . . . . . . . 16

5.2 Simulation Model . . . . . . . . . . . . . . . . . . . . 18

5.3 Data Flow Diagram . . . . . . . . . . . . . . . . . . . 22

5.4 UML Diagrams . . . . . . . . . . . . . . . . . . . . . 24

5.4.1 UML . . . . . . . . . . . . . . . . . . . . . . 24

5.4.2 Goals . . . . . . . . . . . . . . . . . . . . . . 25

5.4.3 UML Case Diagram . . . . . . . . . . . . . . 25

5.4.4 Class Diagram . . . . . . . . . . . . . . . . . 26

5.4.5 Sequence Diagram . . . . . . . . . . . . . . . 27

5.4.6 Activity Diagram . . . . . . . . . . . . . . . . 28

6 Implementation Details 306.1 Modules . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.2 Module Description . . . . . . . . . . . . . . . . . . . 30

6.2.1 Sender . . . . . . . . . . . . . . . . . . . . . 30

6.2.2 Receiver . . . . . . . . . . . . . . . . . . . . 31

6.2.3 Router Queueing Scheme . . . . . . . . . . . 31

6.3 IntelRate Controller . . . . . . . . . . . . . . . . . . . 32

6.3.1 Rule base building . . . . . . . . . . . . . . . 33

6.3.2 Fuzzification . . . . . . . . . . . . . . . . . . 33

6.3.3 Inference using Fuzzy Smoother . . . . . . . . 34

Department of CSE ii GCE, Kannur


6.3.4 Defuzzification . . . . . . . . . . . . . . . . . 35

7 Performance and Results 377.1 Graphical Traffic Analysis . . . . . . . . . . . . . . . 37

7.1.1 Link Utilization . . . . . . . . . . . . . . . . . 38

7.1.2 Source Throughput . . . . . . . . . . . . . . . 39

7.1.3 IQSize . . . . . . . . . . . . . . . . . . . . . 40

7.2 Screen Shots . . . . . . . . . . . . . . . . . . . . . . . 41

7.2.1 Source Screen . . . . . . . . . . . . . . . . . . 41

7.2.2 Receiver Screen . . . . . . . . . . . . . . . . . 42

7.2.3 Router . . . . . . . . . . . . . . . . . . . . . . 43

7.2.4 Network Analysis Screen . . . . . . . . . . . . 44

8 Future Scope 47

9 Conclusion 48

References 49

Department of CSE iii GCE, Kannur

List of Figures

5.1 Network Model . . . . . . . . . . . . . . . . . . . . . 17

5.2 Simulated Network . . . . . . . . . . . . . . . . . . . 18

5.3 Source characteristics . . . . . . . . . . . . . . . . . 19

5.4 Http session . . . . . . . . . . . . . . . . . . . . . . . 20

5.5 Uncontrolled FTP Flow . . . . . . . . . . . . . . . . . 21

5.6 Data Flow Diagram . . . . . . . . . . . . . . . . . . . 23

5.7 UML Case diagram . . . . . . . . . . . . . . . . . . . 26

5.8 Class diagram . . . . . . . . . . . . . . . . . . . . . . 27

5.9 Sequence diagram . . . . . . . . . . . . . . . . . . . . 28

5.10 Activity diagram . . . . . . . . . . . . . . . . . . . . 29

6.1 IntelRate Controller . . . . . . . . . . . . . . . . . . . 32

6.2 Rule base of IntelRate Controller . . . . . . . . . . . . 33

6.3 Fuzzy smoother for e(t) . . . . . . . . . . . . . . . . . 35

6.4 Fuzzy Smoother for g(e(t)) . . . . . . . . . . . . . . . 35

6.5 Fuzzy Smoother, u(t) . . . . . . . . . . . . . . . . . . 36

7.1 Link Utilization . . . . . . . . . . . . . . . . . . . . . 38

7.2 Source Throughput . . . . . . . . . . . . . . . . . . . 39

7.3 IQSize . . . . . . . . . . . . . . . . . . . . . . . . . . 40

iv


7.4 Source Screen . . . . . . . . . . . . . . . . . . . . . . 42

7.5 Receiver Screen . . . . . . . . . . . . . . . . . . . . . 43

7.6 Router Screen . . . . . . . . . . . . . . . . . . . . . . 44

7.7 Router Traffic . . . . . . . . . . . . . . . . . . . . . . 45

7.8 Bottleneck Queue . . . . . . . . . . . . . . . . . . . . 45

7.9 Memory Used . . . . . . . . . . . . . . . . . . . . . . 46

Department of CSE v GCE, Kannur

Chapter 1

Introduction

1.1 Objective

The aim of this project is to develop a distributed traffic management

framework, in which routers are deployed with intelligent data rate

controllers to tackle the traffic mass and to enhance the performance

of high speed networks. The system aims at the application of fuzzy

logic controller using less performance parameters while providing bet-

ter performances than the existing protocols.

1.2 Breif Overview

Networking is the word basically relating to computers and their con-

nectivity. It is very often used in the world of computers and their

use in different connections. The term networking implies the link be-

tween two or more computers and their devices, with the vital purpose

of sharing the data stored in the computers, with each other. The net-

1


works between the computing devices are very common these days due

to the launch of various hardware and computer software which aid in

making the activity much more convenient to build and use.

NETWORK traffic management can prevent a network from severe

congestion and degradation in throughput- delay performance. Traffic

congestion control is one of the effective approaches to manage the net-

work traffic. Historically, TCP (Transmission Control Protocol) Reno,

is a widely deployed congestion control protocol that tackles the In-

ternet traffic. It has the important feature that the network is treated

as a black box and the source adjusts its window size based on packet

loss signal. However, as an implicit control protocol, TCP encounters

various performance problems (e.g., utilization, fairness and stability)

when the In- ternet BDP (Bandwidth-Delay Product) continues to in-

crease. These have been widely investigated with various proposed so-

lutions such as the AQM (Active Queue Management) schemes whose

control protocols are also implicit in nature.

Department of CSE 2 GCE, Kannur

Chapter 2

Background Information

2.1 TCP

The Transmission Control Protocol (TCP) is one of the core protocols

of the Internet protocol suite (IP), and is so common that the entire

suite is often called TCP/IP. TCP provides reliable, ordered and error-

checked delivery of a stream of octets between programs running on

computers connected to a local area network, intranet or the public In-

ternet. It resides at the transport layer.

2.1.1 Congestion Control

Transmission Control Protocol (TCP) uses a network congestion-avoidance

algorithm that includes various aspects of an additive increase/multiplicative

decrease (AIMD) scheme, with other schemes such as slow-start to

achieve congestion avoidance.

3


Slow Start

Slow-start is part of the congestion control strategy used by TCP, the

data transmission protocol used by many Internet applications. Slow-

start is used in conjunction with other algorithms to avoid sending more

data than the network is capable of transmitting, that is, to avoid caus-

ing network congestion.

Exponential Backoff

Exponential backoff is an algorithm that uses feedback to multiplica-

tively decrease the rate of some process, in order to gradually find an

acceptable rate.

Fast Recovery

In this state, TCP retransmits the missing packet that was signaled by

three duplicate ACKs, and waits for an acknowledgment of the entire

transmit window before returning to congestion avoidance. If there is

no acknowledgment, TCP Reno experiences a timeout and enters the

slow-start state.

2.2 Other Explicit Congestion Control Pro-

tocols

2.2.1 XCP

XCP is a congestion control protocol that can be applied to any trans-

port protocol. It performs especially well in very high delay-bandwidth



product networks. Typically in large bandwidth-delay product net-

works, efficiency of TCP goes down in the event of multiple of packet

losses and becomes unstable irrespective of queueing schemes used.

However in similar environments, XCP, using a control theory based

feedback model, achieves much more efficiency, stability and fairness

by sending feedback from the network to the sender for setting the data

flow into the network.

XCP’s scalability results from the fact that it requires no per-flow

state in the router to calculate the feedback. Most router-assisted con-

gestion control systems maintain per-flow information used to allocate

the resources. XCP keeps very little information in the router, and this

information is chosen to minimize both the amount of router state and

the per-packet operations needed to update that state.

For generality, XCP divides the resource allocation function be-

tween two controllers: a congestion controller that ensures that flows

use all available capacity, and a fairness controller that ensures that

flows are allocated the capacity fairly. Most congestion control systems

fail to make this division, much less to implement as two conceptually

distinct systems. This division allows a clear exposition and implemen-

tation of two basic resource allocation functions in XCP. XCP sources

send additional information about their current round-trip times and

router-assigned throughput in each packet. XCP routers insert feed-

back into the packets that is interpreted by the sources.



2.2.2 RCP

Rate Control Protocol (RCP) is a congestion control algorithm de-

signed for fast download times (i.e. aka user response times, or flow-

completion times). Whereas other modifications to TCP (e.g. STCP,

Fast TCP, XCP) are designed to work for specialized applications that

use long-lived flows (scientific applications and supercomputer cen-

ters), RCP is designed for the typical flows of typical users in the Inter-

net today. For example, a mid-size flow in the Internet today contains

1000 packets and TCP typically makes them last 10x longer than need-

be (XCP is even worse). RCP makes flows finish close to the min-

imum possible, leading to a perceptible improvement for web users,

distributed computing, and distributed file-systems. We believe RCP is

the only congestion control algorithm to do this.

The main properties of RCP are:

• Typical Internet flows will see 10 times faster download times

than TCP and 30 times faster than XCP. Winners are the greater

than 90 per cent of sessions that never leave slow-start today.

• Efficiently uses high bandwidth-delay product networks such as

the long haul optical links

• Provably stable network independent of link-capacities, round-

trip times and number of flows

• Flows are easy to police, to ensure they adhere to congestion

control (not generally possible with other schemes)

• Network operators can give preference (or weighted preference)

to some flows/aggregates.



2.2.3 Others

• JetMax and MaxNet signal network congestion by providing the

required fair rate or the maximum link price, and then the final

sending rate is decided by sources according to some demand

functions or utility functions.

• There are some latest protocols on wireless applications such as

QFCP (Quick Flow Control Protocol) and the three protocols

called Blind, ErrorS and MAC. They have improved on the esti-

mation error while having high link utilization and fair through-

put. However, they still have the fundamental problem of inac-

curate estimation resulting in performance degradation. In addi-

tion, their bandwidth probing speed may be too slow when the

bandwidth jumps a lot. Also, they cannot keep the queue size

stable due to oscillations, which in turn affects the stability of

their sending rates.

2.3 Fuzzy Logic Control

A fuzzy control system is a control system based on fuzzy logica math-

ematical system that analyzes analog input values in terms of logical

variables that take on continuous values between 0 and 1, in contrast

to classical or digital logic, which operates on discrete values of either

1 or 0 (true or false, respectively). The IntelRate Controller is imple-

mented using Fuzzy logic mechanism. FLC is a non linear mapping of

the inputs to the outputs.



Fuzzy logic is widely used in machine control. The term ”fuzzy” refers

to the fact that the logic involved can deal with concepts that cannot be

expressed as ”true” or ”false” but rather as ”partially true”. Although

alternative approaches such as genetic algorithms and neural networks

can perform just as well as fuzzy logic in many cases, fuzzy logic has

the advantage that the solution to the problem can be cast in terms that

human operators can understand, so that their experience can be used

in the design of the controller. This makes it easier to mechanize tasks

that are already successfully performed by humans.

Fuzzy Logic Control is divided into three parts:

• Fuzzification

• Inference

• Defuzzification

2.3.1 Fuzzification

The input variables in a fuzzy control system are in general mapped

by sets of membership functions similar to this, known as ”fuzzy sets”.

The process of converting a crisp input value to a fuzzy value is called

”fuzzification”.

A control system may also have various types of switch, or ”ON-

OFF”, inputs along with its analog inputs, and such switch inputs of

course will always have a truth value equal to either 1 or 0, but the



scheme can deal with them as simplified fuzzy functions that happen to

be either one value or another.

2.3.2 Inference

Fuzzy inference is the process of formulating the mapping from a given

input to an output using fuzzy logic. The mapping then provides a

basis from which decisions can be made, or patterns discerned. The

process of fuzzy inference involves all of the pieces that are described

in Membership Functions, Logical Operations, and If-Then Rules.

2.3.3 Defuzzification

Defuzzification is the process of producing a quantifiable result in fuzzy

logic, given fuzzy sets and corresponding membership degrees. It is

typically needed in fuzzy control systems. These will have a number

of rules that transform a number of variables into a fuzzy result, that

is, the result is described in terms of membership in fuzzy sets. For

example, rules designed to decide how much pressure to apply might

result in ”Decrease Pressure (15 per cent), Maintain Pressure (34 per

cent), Increase Pressure (72 per cent)”. Defuzzification is interpreting

the membership degrees of the fuzzy sets into a specific decision or real

value.

A common and useful defuzzification technique is center of gravity.

First, the results of the rules must be added together in some way. The

most typical fuzzy set membership function has the graph of a triangle.

Now, if this triangle were to be cut in a straight horizontal line some-



where between the top and the bottom, and the top portion were to be

removed, the remaining portion forms a trapezoid. The first step of

defuzzification typically ”chops off” parts of the graphs to form trape-

zoids (or other shapes if the initial shapes were not triangles). For ex-

ample, if the output has ”Decrease Pressure (15 per cent)”, then this

triangle will be cut 15 per cent the way up from the bottom. In the

most common technique, all of these trapezoids are then superimposed

one upon another, forming a single geometric shape. Then, the centroid

of this shape, called the fuzzy centroid, is calculated. The x coordinate

of the centroid is the defuzzified value.

There are many different methods of defuzzification available, includ-

ing the following:

• AI (adaptive integration)

• BADD (basic defuzzification distributions)

• CDD (constraint decision defuzzification)

• LOM (last of maximum)

• MeOM (mean of maxima)

• MOM (middle of maximum)


Chapter 3

System Analysis

3.1 Existing Model

Historically, TCP (Transmission Control Protocol) is a widely deployed

congestion control protocol that tackles the Internet traffic. It has the

important feature that the network is treated as a black box and the

source adjusts its window size based on packet loss signal. However,

as an implicit control protocol, TCP encounters various performance

problems (e.g., utilization, fairness and stability) when the Internet

BDP (Bandwidth-Delay Product) continues to increase.

3.1.1 Disadvantages of Existing System

1. The fundamental problem of inaccurate estimation resulting in

performance degradation.

2. In addition, their bandwidth probing speed may be too slow when

the bandwidth jumps a lot.

11


3. Also, they cannot keep the queue size stable due to oscillations,

which in turn affects the stability of their sending rates.

3.2 Proposed System

The contributions of our work lie in:

1. Using fuzzy logic theory to design an explicit rate-based traf-

fic management scheme (called the IntelRate controller) for the

high-speed IP networks.

2. The application of such a fuzzy logic controller using less perfor-

mance parameters while providing better performances than the

existing explicit traffic control protocols.

3. The design of a Fuzzy Smoother mechanism that can generate

relatively smooth flow throughput.

4. The capability of our algorithm to provide max-min fairness even

under large network dynamics that usually render many existing

controllers unstable.

3.2.1 Advantages of Proposed System

• The queue size can be accurately monitored.

• Used to proactively decide if action should be taken to regulate

the source sending rate.



• QoS (Quality of Service) is assured by the good performances of

our scheme such as max-min fairness, low queueing delay and

good robustness to network dynamics.


Chapter 4

Requirements Specification

4.1 Hardware Specification

The minimum hardware requirements for the project are:

• Pentium IV 2.4 GHz Processor

• Minimum of 512 MB RAM

• Minimum of 40 GB HDD

• VGA Display with 640 x 480 screen in High/True color Display

mode

• 52X CD ROM Drive

• 15 Color Monitor

• Keyboard

• Mouse

14


4.2 Software Specification

The minimum software requirements for the project are,

• Java (jdk 1.7.0 )

• Operating system (Windows or Linux)


Chapter 5

System Design

5.1 Complete Network Model

We consider a backbone network interconnected by a number of geo-

graphically distributed routers, in which hosts are attached to the ac-

cess routers which cooperate with the core routers to enable end-to-end

communications. Congestion occurs when many flows traverse a router

and cause its IQSize (Instantaneous Queue Size) to exceed the buffer

capacity, thus making it a bottleneck in the Internet. Since any router

may become bottleneck along an end-to-end data path, we would like

each router to be able to manage its traffic.

16


Figure 5.1: Network Model

Inside each router, our distributed traffic controller acts as a data

rate regulator by measuring and monitoring the IQSize. As per its ap-

plication, every host (source) requests a sending rate it desires by de-

positing a value into a dedicated field Req rate inside the packet header.

This field can be updated by any router en route. Specifically, each

router along the data path will compute an allowed source transmission

rate according to the IQSize and then compare it with the rate already

recorded in Req rate field. If the former is smaller than the latter, the

Req rate field in the packet header will be updated; otherwise it remains

unchanged. After the packet arrives at the destination, the value of the

Req rate field reflects the allowed data rate from the most congested

router along the path if the value is not more than the desired rate of

the source. The receiver then sends this value back to the source via

an ACK (ACKnowledgment) packet, and the source would update its

current sending rate accordingly. If no router modifies Req rate field,



it means that all routers en route allow the source to send its data with

the requested desired rate.

5.2 Simulation Model

Figure 5.2: Simulated Network

The single bottleneck network is used to investigate the controller be-

havior of the most congested router. Router 1 is the only bottleneck in

the network, whereas Router 2 is configured to have sufficiently high

service rate and big buffer B so that congestion never happens there.

The numbers in the figure are the IDs of the subnets/groups attached

to each router. Their configuration is summarized in Table, in which

there are M = 11 subnet pairs, which form the source-destination data

flows in the network, and they run various Internet applications such as

the long-lived ftp, short-lived http, or the unresponsive UDP-like flows

(also called uncontrolled ftp flows). Since the link bandwidth we want

to simulate have a magnitude of Giga bits per second, we need to use 20



flows in each subnet to generate enough traffic to produce congestion.

All flows within each group have the same RTPD and behavior, but dif-

ferent from the flows of other groups. The RTPD includes the forward

path propagation delay and the feedback propagation delay, but does

not include the queueing delay, which may vary according to our set-

tings of TBO size in the experiments. The reverse traffic is generated

by the destinations when they piggyback the ACK information back to

the sources.

Figure 5.3: Source characteristics

The TBO and the buffer capacity B in Router 1 in each experiment

are set. We also adopt some typical values from the experiments of



existing works so that we can make our experiments more meaningful.

In particular, all the ftp packets have the same size of 1024 bytes while

the http packet size is uniformly distributed in the range of [800, 1300]

bytes.

In order to demonstrate and discuss the robustness of our IntelRate

controller, our experiments would focus on the testing of the 100 long-

lived ftp flows, unless otherwise stated. The 100 sporadic short-lived

http flows just act as the disturbance to the ftp traffic and their transfer

size follows the real web traffic scenario; it has a Pareto distribution

with a mean transfer size of 30 packets. The arrivals of http flows fol-

low a think-time uniformly distributed in [0.1s, 30s]. One of the http

session examples is shown in figure.

Figure 5.4: Http session

The uncontrolled ftp flow keeps using a window size of 100 packets

and operates at an almost constant rate as shown in figure. These http

and UDP-like flows generate an aggregate traffic v(t), which is termed



as uncontrolled traffic.

Figure 5.5: Uncontrolled FTP Flow

The controller is evaluated by the following performance measures.

1. Source throughput (or source sending rate) is defined to be the

average number of bits successfully sent out by a source per sec-

ond, i.e. bits/second. Here, a bit is considered to be successfully

sent out if it is part of a packet that has been successfully sent.

2. IQSize is the length of the bottleneck buffer queue (measured in

packets) seen by a departing packet.

3. Queueing delay is the waiting time of a packet in the router queue

before its service. Measurements are taken from the time the first

bit of a packet is received at the queue until the time the first bit

of the packet is transmitted.

4. Queueing jitter is the variation of queueing delay due to the queue

length dynamics, and is defined as the variance of the queuing



delay.

5. Link (or bottleneck) utilization is the ratio between the current

actual throughput in the bottleneck and the maximum data rate

of the bottleneck. It is expressed as a fraction less than one or as

a percentage.

6. Packet loss rate is the ratio between the number of packet dropped

and the number of total packets received per second by the bot-

tleneck.

7. Max-min fairness: A feasible allocation of rates is max- min fair

if and only if an increase of any rate within the domain of feasible

allocations must be at the cost of a decrease of some already

smaller or equal rates.

5.3 Data Flow Diagram

1. The DFD is also called as bubble chart. It is a simple graphical

formalism that can be used to represent a system in terms of input

data to the system, various processing carried out on this data,

and the output data is generated by this system.

2. The data flow diagram (DFD) is one of the most important mod-

eling tools. It is used to model the system components. These

components are the system process, the data used by the process,

an external entity that interacts with the system and the informa-

tion flows in the system.



3. DFD shows how the information moves through the system and

how it is modified by a series of transformations. It is a graphical

technique that depicts information flow and the transformations

that are applied as data moves from input to output.

4. DFD is also known as bubble chart. A DFD may be used to

represent a system at any level of abstraction. DFD may be parti-

tioned into levels that represent increasing information flow and

functional detail.

Figure 5.6: Data Flow Diagram



5.4 UML Diagrams

5.4.1 UML

UML stands for Unified Modeling Language. UML is a standardized

general-purpose modeling language in the field of object-oriented soft-

ware engineering. The standard is managed, and was created by, the

Object Management Group.

The goal is for UML to become a common language for creating mod-

els of object oriented computer software. In its current form UML is

comprised of two major components: a Meta-model and a notation. In

the future, some form of method or process may also be added to; or

associated with, UML.

The Unified Modeling Language is a standard language for specifying,

Visualization, Constructing and documenting the artifacts of software

system, as well as for business modeling and other non-software sys-

tems.

The UML represents a collection of best engineering practices that have

proven successful in the modeling of large and complex systems. The

UML is a very important part of developing objects oriented software

and the software development process. The UML uses mostly graphi-

cal notations to express the design of software projects.



5.4.2 Goals

The Primary goals in the design of the UML are as follows:

1. Provide users a ready-to-use, expressive visual modeling Lan-

guage so that they can develop and exchange meaningful models.

2. Provide extendibility and specialization mechanisms to extend

the core concepts.

3. Be independent of particular programming languages and devel-

opment process.

4. Provide a formal basis for understanding the modeling language.

5. Encourage the growth of OO tools market.

6. Support higher level development concepts such as collabora-

tions, frameworks, patterns and components.

7. Integrate best practices.

5.4.3 UML Case Diagram

A use case diagram in the Unified Modeling Language (UML) is a type

of behavioral diagram defined by and created from a Use-case analy-

sis. Its purpose is to present a graphical overview of the functionality

provided by a system in terms of actors, their goals (represented as

use cases), and any dependencies between those use cases. The main

purpose of a use case diagram is to show what system functions are

performed for which actor. Roles of the actors in the system can be

depicted.



Figure 5.7: UML Case diagram

5.4.4 Class Diagram

In software engineering, a class diagram in the Unified Modeling Lan-

guage (UML) is a type of static structure diagram that describes the

structure of a system by showing the system’s classes, their attributes,

operations (or methods), and the relationships among the classes. It

explains which class contains information.



Figure 5.8: Class diagram

5.4.5 Sequence Diagram

A sequence diagram in Unified Modeling Language (UML) is a kind of

interaction diagram that shows how processes operate with one another

and in what order. It is a construct of a Message Sequence Chart. Se-

quence diagrams are sometimes called event diagrams, event scenarios,

and timing diagrams.



Figure 5.9: Sequence diagram

5.4.6 Activity Diagram

Activity diagrams are graphical representations of workflows of step-

wise activities and actions with support for choice, iteration and con-

currency. In the Unified Modeling Language, activity diagrams can be

used to describe the business and operational step-by-step workflows

of components in a system. An activity diagram shows the overall flow

of control.



Figure 5.10: Activity diagram


Chapter 6

Implementation Details

6.1 Modules

1. Sender

2. Receiver

3. Router Queuing Scheme

6.2 Module Description

6.2.1 Sender

• Server module is the main module for this project.

• Inside each router, our distributed traffic controller acts as a data

rate regulator by measuring and monitoring the IQ Size.

• As per its application, every host (source) requests a sending rate

30


it desires by depositing a value into a dedicated field Req rate

inside the packet header.

• In addition there is also Message Log, where all the alerts and

messages are stored for the references. This Message Log can

also be saved as Log file for future references for any network

environment.

6.2.2 Receiver

• The receiver then sends this value back to the source via an ACK

(Acknowledgment) packet, and the source would update its cur-

rent sending rate accordingly.

• If no router modifies Req rate field, it means that all routers en

route allow the source to send its data with the requested desired

rate.

6.2.3 Router Queueing Scheme

• In this module, each router along the data path will compute an

allowed source transmission rate according to the IQ Size and

then compare it with the rate already recorded in Req rate field.

• If the former is smaller System model of an AQM router, than

the latter, the Req rate field in the packet header will be updated;

otherwise it remains unchanged.

• After the packet arrives at the destination, the value of the Req rate

field reflects the allowed data rate from the most congested router



along the path if the value is not more than the desired rate of the

source.

6.3 IntelRate Controller

Figure 6.1: IntelRate Controller

IntelRate Controller is implemented on the router. Each router within

a network is controlled by the IntelRate Controller. It is a TISO (Two-

Input Single-Output) controller. The TBO (Target Buffer Occupancy)

q0 > 0 is the queue size level we aim to achieve upon congestion.

• TISO(Two Input Single Output)

• Queue Deviation(error), e(t) = q0 - q(t)

• To remove steady state error, g(e(t)) =∫e(t).dt

• FLC is non linear mapping of inputs to outputs.

• Four parts:

1. Rule base building

2. Fuzzification



3. Inference

4. Defuzzification

6.3.1 Rule base building

Rule base is set of linguistic values used to map inputs to outputs using

”If...Then” format.

Figure 6.2: Rule base of IntelRate Controller

6.3.2 Fuzzification

IntelRate controller employs the isosceles triangular and trapezoid-like

functions as its MFs (Membership Func- tions).

To determine how much a rule is certain to a current situation, our

controller applies the Zadeh AND logic to perform the inference mech-

anism, e.g. for crisp inputs p 1 and p 2 , the final certainty (also referred

to as the firing level) of a rule is computed with

µP1m(p1)

⋂µP2

m(p2) = min(µP1m(p1), µP2

m(p2)) : p[i]εPi

where min is the minimum operation in the Zadeh AND logic.



This type of design is not suitable when FLC is applied to our Inter-

net traffic controller. The reason is twofold.

• When e(t) and g(e(t)) have the same number of MFs, the output

u(t) has a tendency to change fast when the queue size has drastic

variations. This would not give us a smooth source sending rate.

• Since it is possible to have light traffic sometimes, g(e(t)) will

increase indefinitely if not bounded. Therefore, a limit has to be

imposed on g(e(t)). In light of the above issues, we require the

e(t) and g(e(t)) in our controller to have different number of MFs,

and add an upper limit mq0to the highest LV of g(e(t)).

6.3.3 Inference using Fuzzy Smoother

• Fuzzy smoother:

1. realize a smaller TBO.

2. reduce queueing delay upon heavy traffic.

• Upper and lower limits are set for both inputs.

1. −mq0 ≤ g(e(t)) ≤ mq0

2. q0 −B ≤ e(t) ≤ q0



Figure 6.3: Fuzzy smoother for e(t)

Figure 6.4: Fuzzy Smoother for g(e(t))

6.3.4 Defuzzification

For the defuzzification algorithm, the IntelRate controller applies the

COG (Center of Gravity) method to obtain the crisp output with the

equation,

• Membership degree of fuzzy set is transformed to real valued

result.

• IntelRate controller uses COG(Centre of Gravity) method.

u(t) = (Summation(cjSj)/Summation(Sj)), j = 1, 2..k



where

k = No. of rules

cj is bottom centroid of triangular MF

Sj is the area of triangle

Figure 6.5: Fuzzy Smoother, u(t)


Chapter 7

Performance and Results

7.1 Graphical Traffic Analysis

Network analysis demonstrates that the IntelRate controller is supe-

rior to other explicit congestion controllers. For examples, the Intel-

Rate controller has better robustness and link utilization than the XCP

upon bandwidth variations; it has a lower requirement on computa-

tional and memory resources than API-RCP while having equivalent

and even better performances. Below figures shows a comparison be-

tween QFCP, BLIND and IntelRate controller.

37


7.1.1 Link Utilization

Figure 7.1: Link Utilization

The figure shows the bottleneck utilization which is the ratio between

the actual bottleneck throughput and 11Mbps in this case. Since the

controllers do not know the bottleneck bandwidth at the beginning, in

order to fully utilize the available bandwidth, they need to probe (or

say, to estimate) it. As seen, QFCP spends about 20s approaching the

100per cent utilization (i.e., fully utilizing 11Mbps). There are oscilla-

tions in both its probing stage (when t < 20s) and steady state (when

t < 20s). The fact that there are still oscillations in its steady state

between 80 per cent and 100 per cent shows that the QFCP has a band-

width under-estimation problem even though the over- estimation issue

is addressed by using the router output as the link bandwidth. Blind

spends a similar amount of time on the probing but shows smoother

steady-state utilization (overlapping with the IntelRate) than QFCP. In

contrast, the IntelRate controller only spends about 3s reaching 100 per



cent link bandwidth utilization. Furthermore, it shows the same stable

performance as Blind in the steady state. The reason that QFCP and

Blind take a longer probing time is due to the probing process they use

to explore the available bandwidth. In comparison, the IntelRate con-

troller aims at building the queue up to the TBO of 60 packets as soon

as possible. Once the queue size is built up, the bandwidth is fully uti-

lized. The ability of the IntelRate controller to stably control the queue

size to TBO of 60 packets indicates that the incoming traffic and the

link bandwidth of 11Mbps have struck a balance. This is why the In-

telRate controller shows much shorter time reaching the 100 per cent

utilization.

7.1.2 Source Throughput

Figure 7.2: Source Throughput

The throughput of one of the sources in the three controllers is shown

in THE FIGURE. In the first 20s, both the QFCP and the Blind grad-



ually increase their sending rates in order to probe the available band-

width. In their steady state (i.e., t<20s), QFCP has more oscillations

than Blind due to two reasons:

• QFCP calculates the sending rate based on the estimated link

bandwidth. If the bandwidth is under-estimated from time to

time, the sending rate of the source will be decreased accord-

ingly.

• QFCP has unstable queue size to be illustrated next. The second

reason can also explain the slight sinusoidal oscillations in the

sending rate of Blind as perceived in Figure. As with previous

figure, the sending rate of the IntelRate controller shows much

faster convergence speed and smoother steady state than QFCP

and Blind.

7.1.3 IQSize

Figure 7.3: IQSize



The figure depicts the instantaneous queue size of the three controllers.

Similar to the transients in previous two figures, both QFCP and Blind

take about 20s to build up their queues due to their slow bandwidth

probing process. In the steady state, their queue sizes are unstable and

oscillating wildly all the time. This in turn results in an oscillating

RTT which affects the smoothness of their source sending rates. Un-

like QFCP and Blind, the IntelRate controller has a closed-loop system

dedicated to controlling the queue size. Therefore, the IntelRate con-

troller presents a much more stable queue size after it quickly reaches

the TBO of 60 packets.

7.2 Screen Shots

7.2.1 Source Screen

There can be multiple sources trying to send data to multiple receivers.

Here, the source would select one file to be sent to receiver. The source

is prompted to select the file and provide the receiver’s address.



Figure 7.4: Source Screen

7.2.2 Receiver Screen

The receiver receives the file sent by the source via one or more routers.

The receiver selects the



Figure 7.5: Receiver Screen

7.2.3 Router

The router tracks the source and receiver nodes connected to it, that

is, nodes that are sending data through it. The router screen shows

information about all the packets that it processes.



Figure 7.6: Router Screen

7.2.4 Network Analysis Screen

The network Analysis is done by the router module. The network anal-

ysis is done by creating graphs or charts by using java’s open source

tool JFreeChart. Time Series Chart Interactivity implements a new (to

JFreeChart) feature for interactive time series charts — to display a

separate control that shows a small version of ALL the time series data,

with a sliding ”view” rectangle that allows you to select the subset of

the time series data to display in the main chart. Dashboard mechanism

that supports a subset of JFreeChart chart types (dials, pies, thermome-

ters, bars, and lines/time series) that can be delivered easily via both

Java Web Start and an applet. Following are some graphs created by

analying the parameters during the transmission:



• Router Traffic

Figure 7.7: Router Traffic

• Bottleneck Queue

Figure 7.8: Bottleneck Queue

• Memory Used



Figure 7.9: Memory Used


Chapter 8

Future Scope

• Enhancements are possible for a faster design , that is, faster

queue size calculation using sophisticated techniques.

• In low speed networks, this framework can be enhanced for effi-

cient utilization of bandwidth.

• Better congestion protocols can be implemented using this frame-

work so that it is compatible with TCP(widely used current and

future transport layer protocol).

47

Chapter 9

Conclusion

A novel traffic management scheme, called the IntelRate controller, has

been proposed to manage the Internet congestion in order to assure the

quality of service for different service applications. The controller is

designed by paying attention to the disadvantages as well as the ad-

vantages of the existing congestion control protocols. As a distributed

operation in networks, the IntelRate controller uses the instantaneous

queue size alone to effectively throttle the source sending rate with

max-min fairness. Unlike the existing explicit traffic control proto-

cols that potentially suffer from performance problems or high router

resource consumption due to the estimation of the network parameters,

the IntelRate controller can overcome those fundamental deficiencies.

To verify the effectiveness and superiority of the IntelRate controller,

extensive experiments have been conducted in OPNET modeler. In ad-

dition to the feature of the FLC being able to intelligently tackle the

nonlinearity of the traffic control systems, the success of the IntelRate

controller is attributed to the careful design of fuzzy logic elements.

48

References

[1] Jungang Liu, Student Member, IEEE, and Oliver W. W. Yang, Se-

nior Member, IEEE, Using Fuzzy Logic Control to Provide Intelli-

gent Traffic Management Service for High-Speed Networks, IEEE

TRANSACTIONS ON NETWORK AND SERVICE MANAGE-

MENT, VOL. 10, NO. 2, JUNE 2013.

[2] 11th International Conference on Telecommunications - ConTEL

2011 ISBN: 978-953-184-152-8, June 15-17, 2011, Graz, Austria–

Fuzzy CAC based Traffic Management

[3] International Journal of Advances in Engineering & Technology,

Nov 2011–DESIGN AND SIMULATION OF AN INTELLIGENT

TRAFFIC CONTROL SYSTEM

[4] J. Liu and O. Yang, Stability analysis and evaluation of the Intel-

Rate controller for high-speed heterogeneous networks, in Proc.

2011 IEEE ICC

[5] Fuzzy – http://en.wikipedia.org/wiki/Fuzzy logic as accessed on

February 17, 2014.

49

distributed traffic management framework

Engineering

traffic congestion

traffic management3

traffic mass

fuzzy logic control72

fastgrowing internet

network dynamics

system analysis

network parameters