Download - 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
Project Report Distributed Traffic Management
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
Project Report Distributed Traffic Management
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
Project Report Distributed Traffic Management
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
Project Report Distributed Traffic Management
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
Department of CSE 4 GCE, Kannur
Project Report Distributed Traffic Management
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.
Department of CSE 5 GCE, Kannur
Project Report Distributed Traffic Management
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.
Department of CSE 6 GCE, Kannur
Project Report Distributed Traffic Management
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.
Department of CSE 7 GCE, Kannur
Project Report Distributed Traffic Management
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
Department of CSE 8 GCE, Kannur
Project Report Distributed Traffic Management
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-
Department of CSE 9 GCE, Kannur
Project Report Distributed Traffic Management
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)
Department of CSE 10 GCE, Kannur
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
Project Report Distributed Traffic Management
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.
Department of CSE 12 GCE, Kannur
Project Report Distributed Traffic Management
• 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.
Department of CSE 13 GCE, Kannur
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
Project Report Distributed Traffic Management
4.2 Software Specification
The minimum software requirements for the project are,
• Java (jdk 1.7.0 )
• Operating system (Windows or Linux)
Department of CSE 15 GCE, Kannur
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
Project Report Distributed Traffic Management
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,
Department of CSE 17 GCE, Kannur
Project Report Distributed Traffic Management
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
Department of CSE 18 GCE, Kannur
Project Report Distributed Traffic Management
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
Department of CSE 19 GCE, Kannur
Project Report Distributed Traffic Management
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
Department of CSE 20 GCE, Kannur
Project Report Distributed Traffic Management
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
Department of CSE 21 GCE, Kannur
Project Report Distributed Traffic Management
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.
Department of CSE 22 GCE, Kannur
Project Report Distributed Traffic Management
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
Department of CSE 23 GCE, Kannur
Project Report Distributed Traffic Management
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.
Department of CSE 24 GCE, Kannur
Project Report Distributed Traffic Management
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.
Department of CSE 25 GCE, Kannur
Project Report Distributed Traffic Management
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.
Department of CSE 26 GCE, Kannur
Project Report Distributed Traffic Management
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.
Department of CSE 27 GCE, Kannur
Project Report Distributed Traffic Management
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.
Department of CSE 28 GCE, Kannur
Project Report Distributed Traffic Management
Figure 5.10: Activity diagram
Department of CSE 29 GCE, Kannur
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
Project Report Distributed Traffic Management
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
Department of CSE 31 GCE, Kannur
Project Report Distributed Traffic Management
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
Department of CSE 32 GCE, Kannur
Project Report Distributed Traffic Management
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 cur- rent 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.
Department of CSE 33 GCE, Kannur
Project Report Distributed Traffic Management
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
Department of CSE 34 GCE, Kannur
Project Report Distributed Traffic Management
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
Department of CSE 35 GCE, Kannur
Project Report Distributed Traffic Management
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)
Department of CSE 36 GCE, Kannur
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
Project Report Distributed Traffic Management
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
Department of CSE 38 GCE, Kannur
Project Report Distributed Traffic Management
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-
Department of CSE 39 GCE, Kannur
Project Report Distributed Traffic Management
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
Department of CSE 40 GCE, Kannur
Project Report Distributed Traffic Management
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.
Department of CSE 41 GCE, Kannur
Project Report Distributed Traffic Management
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
Department of CSE 42 GCE, Kannur
Project Report Distributed Traffic Management
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.
Department of CSE 43 GCE, Kannur
Project Report Distributed Traffic Management
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:
Department of CSE 44 GCE, Kannur
Project Report Distributed Traffic Management
• Router Traffic
Figure 7.7: Router Traffic
• Bottleneck Queue
Figure 7.8: Bottleneck Queue
• Memory Used
Department of CSE 45 GCE, Kannur
Project Report Distributed Traffic Management
Figure 7.9: Memory Used
Department of CSE 46 GCE, Kannur
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