Congestion Control using Network Based Protocol (NBP)

ACKNOWLEDGEMENT

I have taken efforts in this project (Congestion Control using NBP). However it would not have
been possible without the kind support and help of many individuals and organizations. I would
like to extend my sincere thanks to all of them.
I am highly indebted to Chandigarh University and its faculty members for their guidance and
constant supervision as well as for providing necessary information regarding the project & also
for their support in completing the project.
I would like to express my gratitude towards my parents & member of Chandigarh University for
their kind co-operation and encouragement which help me in completion of this project.
I would like to express my special gratitude and thanks to industry persons for giving me such
attention and time.
My thanks and appreciations also go to my colleague in developing the project and people who
have willingly helped me out with their abilities.

Somesh Srivastava

ii
 Congestion Control using Network Based Protocol (NBP)

ABSTRACT

The Internet’s excellent scalability and robustness result in part from the end-to-end nature
of Internet congestion control. End-to-end congestion control algorithms alone, however, are
unable to prevent the congestion collapse and unfairness created by applications that are
unresponsive to network congestion.

To address these maladies, we propose and investigate a novel congestion-avoidance

mechanism called Congestion Free Router (CFR). CFR entails the exchange of feedback between
routers at the borders of a network in order to detect and restrict unresponsive traffic flows before
they enter the network, thereby preventing congestion within the network.

The Internet’s excellent scalability and robustness result in part from the end-to-end nature
of Internet congestion control. End-to-end congestion control algorithms alone, however, are
unable to prevent the congestion collapse and unfairness created by applications that are
unresponsive to network congestion. To address these maladies, we propose and investigate a
novel congestion-avoidance mechanism called Congestion Free Router (CFR).

CFR entails the exchange of feedback between routers at the borders of a network in order
to detect and restrict unresponsive traffic flows before they enter the network, thereby preventing
congestion within the network.

The fundamental philosophy behind the Internet is expressed by the scalability argument:
no protocol, mechanism, or service should be introduced into the Internet if it does not scale well.
A key corollary to the scalability argument is the end-to-end argument: to maintain scalability,
algorithmic complexity should be pushed to the edges of the network whenever possible .

iii
 Congestion Control using Network Based Protocol (NBP)

List of Figures

Figure No. Title Page No.

1. Data Flow Diagram 7

2. Leaky Bucket Algorithm 8

3. Rate Control Algorithm 9-10

4. Time Sliding Window Algorithm 11

5 Input port of an InRouter 17

6 Output port of an OutRouter 18

7 Forward and Backward Feeback 20

8 Rate Control Algorithm 21-22

9-14 ScreenShots of UI 25-27

iv
 Congestion Control using Network Based Protocol (NBP)

Table of Content.

Sr. No. Topic Page No.

1 Introduction 1-2

2 SRS 3-6

3 Architecture Diagram 7-11

4 Project Methodology 12-27

5 Screenshot 28-30

6 Conclusion and Future Scope 31

7 Biblography 32

v
 Congestion Control using Network Based Protocol (NBP)

CHAPTER 1: INTRODUCTION

 Existing system

As a result of its strict adherence to end-to-end congestion control, the current

Internet suffers from two maladies:

Congestion collapse from undelivered packets, and unfair allocations of

bandwidth between competing traffic flows.

1. The first malady — congestion collapse from undelivered packets —

arises when packets that are dropped before reaching their ultimate
continually consume bandwidth destinations.

2. The second malady—unfair bandwidth allocation to competing network

flows—arises in the Internet for a variety of reasons, one of which is the
existence of applications that do not respond properly to congestion.
Adaptive applications (e.g., TCP-based applications) that respond to
congestion by rapidly reducing their transmission rates are likely to
receive unfairly small bandwidth allocations when competing with
unresponsive applications. The Internet protocols themselves can also
introduce unfairness. The TCP algorithm, for instance, inherently causes
each TCP flow to receive a bandwidth that is inversely proportional to its
round-trip time [6]. Hence, TCP connections with short round-trip times
may receive unfairly large allocations of network bandwidth when
compared to connections with longer round-trip times.

The impact of emerging streaming media traffic on traditional data traffic is of

growing concern in the Internet community. Streaming media traffic is unresponsive
to the congestion in a network, and it can aggravate congestion collapse and unfair
bandwidth allocation.

1
 Congestion Control using Network Based Protocol (NBP)

 Proposed system

To address the maladies of congestion collapse we introduce and

investigate a novel Internet traffic control protocol called Congestion Free Router
(CFR). The basic principle of CFR is to compare, at the borders of a network, the
rates at which packets from each application flow are entering and leaving the
network. If a flow’s packets are entering the network faster than they are leaving it,
then the network is likely buffering or, worse yet, discarding the flow’s packets. In
other words, the network is receiving more packets than it is capable of handling.
CFR prevents this scenario by “patrolling” the network’s borders, ensuring that each
flow’s packets do not enter the network at a rate greater than they are able to leave
the network. This patrolling prevents congestion collapse from undelivered packets,
because unresponsive flow’s otherwise undeliverable packets never enter the
network in the first place.

Although CFR is capable of preventing congestion collapse and improving

the fairness of bandwidth allocations, these improvements do not come for free. CFR
solves these problems at the expense of some additional network complexity, since
routers at the border of the network are expected to monitor and control the rates of
individual flows in CFR. CFR also introduces added communication overhead, since
in order for an edge outer to know the rate at which its packets are leaving the
network, it must exchange feedback with other edge routers.

Unlike some existing approaches trying to solve congestion collapse,

however, CFR’s added complexity is isolated to edge routers; routers within the core
of the network do not participate in the prevention of congestion collapse. Moreover,
end systems operate in total ignorance of the fact that CFR is implemented in the
network, so no changes to transport protocols are necessary at end systems.

2
 Congestion Control using Network Based Protocol (NBP)

CHAPTER 2: SRS

1. INTRODUCTION
1.1 Purpose
The Internet’s excellent scalability and robustness result in part from the
end-to-end nature of Internet congestion control. End-to-end congestion
control algorithms alone, however, are unable to prevent the congestion -and
unfairness created by applications that are unresponsive to network
congestion.

To address these maladies, we propose and investigate a novel congestion-

avoidance mechanism called Congestion Free Router (CFR). CFR entails the
exchange of feedback between routers at the borders of a network in order to
detect and restrict unresponsive traffic flows before they enter the network,
thereby preventing congestion within the network.

The Internet’s excellent scalability and robustness result in part from the
end-to-end nature of Internet congestion control.however, are unable to
prevent the congestion collapse and unfairness created by applications that
are unresponsive to network congestion. To address these maladies, we
propose and investigate a novel congestion-avoidance mechanism called
Congestion Free Router (CFR).

1.2 Project Scope

1. Implement congestion control mechanism using NBP in other than end-to-
end congestion control.
2. Reset function with more dynamic initial parameters may also be attempted.
3. Prevents congestion within the network.
4. Restrict unresponsive traffic flows.
3
 Congestion Control using Network Based Protocol (NBP)

2. OVERALL DESCRIPTION

2.1 PROJECT FEATURES

1. Maintain the number of packets in the network below the level at which
performance falls off dramatically.
2. No possibility of any undelivered packets present in the network.
3. Fair allocation of bandwidth is ensured.
4. Buffering of packets in carried out in the edge routers.

2.2 OPERATING ENVIRONMENTS

The minimum server specifications for the system are:

Software Environment:

 OS : Windows 7 or Later Versions

 JDK : JDK 1.9 or later version
 J2EE Server : Apache Tomcat-5.0
 NETWORKING PROTOCOLS: Internet Protocol (IP),
Transmission Control Protocol (TCP).

Hardware Environment:

 CPU : Intel Core i3 2.3 GHz speed

 RAM : 4 GB
 DISPLAY : 15’’ Color Monitor
 HARD DISK : 500 GB

4
 Congestion Control using Network Based Protocol (NBP)

3. FUNCTIONAL REQUIREMENTS SPECIFICATIONS

3.1 System Features

1. Identifying a more suitable and reliable transport protocol for WSNs
from available protocols and to tailor the congestion control
2. Mechanisms to improve the performance of WSNs is done in this work.
3. Maximize the utility of the power hungry nodes of WSN in view of the
practical difficulties in reaching them, once deployed.
4. Provisions are available to add new mechanisms in future.
5. It permits the modifications in the available mechanisms to tailor them to
the needs of the designer.
6. Improves the performance of DCCP protocol based WSNs during
congestion, the shortfalls were analyzed and suitable modifications were
proposed during Reset action that takes place during congestion.
7. Improves the associated parameters as long as the congestion level over
the network is relatively less and utilizes the resources effectively.
8. The proposed RC-DCCP algorithms provide overall better performance
than their DCCP counterparts in handling the congestion control in
WSNs with respect to the six standard metrics considered.

3.2 Front end requirements:

JAVA, SERVET, SWINGS, ECLIPSE FRAMEWORK.

3.3 Back end requirements:

NETWORKING PROTOCOLS.

5
 Congestion Control using Network Based Protocol (NBP)

4. NON-FUNCTIONAL REQUIREMENTS SPECIFICATIONS

4.1 Performance Requirements

The project control list guides the iteration steps and keeps track of all tasks
that must be done. The tasks in the list can include redesign of defective
components found during analysis. Each entry in that list is a task that
should be performed in one step of the iterative enhancement process, and
should be simple enough to be completely understood. Selecting tasks in this
manner will minimize the chances of errors and reduce the redesign work .

4.2 Compatibility Requirements

In this Project, we have presented a novel congestion-avoidance mechanism
for the Internet called CFR mechanism. Unlike existing Internet congestion
control approaches, which rely solely on end-to-end control, CFR is able to
prevent congestion collapse from undelivered packets. CFR ensures at the
border of the network that each flow’s packets do not enter the network
faster than they are able to leave it. This allows the transmission rate of all
flows to converge to the network fair share. This project is the one that
contains some of the key aspects of the problem which are easy to
understand and implement, and which forms a useful and usable system. A
project control list is created which contains, in an order, all the tasks that
must be performed to obtain the final implementation. This project control
list gives an idea of how far the project is at any given step from the final
system.

6
 Congestion Control using Network Based Protocol (NBP)

CHAPTER 3: ARCHITECTURE DIAGRAM

1. Data flow diagram:

A data flow oriented method is to provide a systematic approach for the description
of the program structure. The representation of information flow is one element of
requirement analysis. Information may be represented as a continuous flow that
undergoes a series of transforms as it evolves from input to output. The Data Flow
Diagram (DFD) is used as a graphical tool to depict information flow. Data Flow
oriented design defines a number of different mappings that transforms information
flow into program structure. The DFD is designed to aid communication.

Forward Forward

Feedback Feedback

Source Destination

Source OutRouter Destination

InRouter Router

Router Router

Source Destination

Backward Backward

Feedback Feedback
Fig 1.

7
 Congestion Control using Network Based Protocol (NBP)

2. FLOWCHART ANALYSIS:

 Leaky Bucket Algorithm

 Rate Control Algorithm
 Time Sliding Window Algorithm

2.1 Leaky Bucket Algorithm

Fig 2.

8
 Congestion Control using Network Based Protocol (NBP)

2.2 Rate control algorithm

On arrival of backward feedback
packet p from OutRouter router e

Current RTT =Current Time -p.times tamp

False
If
Delta RTT=-Current RTT-
CurrentRTT
<e.baseRTT e.base RTT

True

e.base RTT=Current RTT

RTTs Elapsed= (Current Time-e.last

FeedbackTime)/CurrentRTT

e.last FeedbackTime=Current Time

For each flow f listed in p

Rate Quantum=min (MSS/currentRTT, f.egreesRate/QF)

B
A

Fig 3.

9
 A Congestion Control using Network Based Protocol (NBP)
B

If f.phase

True

False
f.phase=
If
(deltaRTT*f.InRouterRat CONGESTION_
e<MSS*e.hopcount)

True

f.InRouter Rate=f.InRouterRate*2^RTTsElapsed

If f.phase

= = CONGESTION_

False

If f. InRouter Rate=
(deltaRTT*f.InRouterRat
e<MSS*e.hopcount) f.OutRouterRate-
rateQuantum

True

f.InRouterRate=f.InRouter Rate + rate Quantum*RTTsElapsed

NEXT

10
 Congestion Control using Network Based Protocol (NBP)

2.3 Time sliding window algorithm

Arrival of the Forward

Feedback at the
OutRouter Router

Start the timer

No
If Packets Wait until the Packet is
are arrived arrived
Yes

Current Packet is
send

No
If Packets are Wait until the packet is
forwarded forward
Yes

Acknowledgement is
backward to InRouter

Yes
Stop the
If no Packet
timer
to Forwarded

No

Forward the next packet

Fig 4.

11
 Congestion Control using Network Based Protocol (NBP)

CHAPTER 4: PROJECT METHODOLOGIES.

1. Module Developed Team Member Wise:

The various modules in the protocol are as follows:

Module 1: -
SOURCE MODULE.

(Developed by Rajat Gupta)

Module 2: -

INROUTER ROUTER MODULE.

(Developed by Rajat Gupta)

Module 3: -

ROUTER MODULE.

(Developed by Rajat Gupta and Somesh Srivastava)

Module 4: -

OUTROUTER ROUTER MODULE.

(Developed by Somesh Srivastava)

Module 5: -

DESTINATION MODULE.

(Developed by Somesh Srivastava)

12
 Congestion Control using Network Based Protocol (NBP)

2. Modules Description:

2.1. Source Module:-

1. (A) Description:
The task of this Module is to get the message from user in its interface
and converts those messages in the packets and send those packet to the
In-Router router for Propagating over the Network.
1. (B) Process Description:
 Sending data in the form of packet .
 Input data entities: Message to be transmitted from the
source to the destination node in the form of packet with IP
address for its identification.
 Algorithm : not applicable
 Output : formatted packet with the required information
for communicating between the source & the destination
node.
1. (C) Parameters:
Input Parameters:
 Source Machine Name is retrieved from the OS.
 User types destination Machine Name.
 Message is typed by User.
Output Parameters:
 Data Packets.

2.2. InRouter Router Module:-

2. (A) Description:
An edge router operating on a flow passing into a network is called an
In-Router router. CFR prevents congestion collapse through a

13
 Congestion Control using Network Based Protocol (NBP)

combination of per-flow rate monitoring at Out-Router routers and per-

flow rate control at In-Router routers. Rate control allows an In-Router
router to police the rate at which each flow’s packets enter the network.
In-Router Router contains a flow classifier, per-flow traffic shapers
(e.g., leaky buckets), a feedback controller, and a rate controller.

2. (B) Process Description:

Using rate control and leak bucket algorithm to rank the nodes in the
network
 Input data entities: which determine the rate of the packets.
 Algorithm: Leaky bucket.
 Output: All the nodes in the network assigned with a unique
rank.

2. (C) Parameters:
Input Parameters:
 Data Packets from Source Machine.
 Backward feedback from the Router.
Output Parameters:
 Data Packets.
 Forward feedback.

2.3. Router Module:-

3. (A) Description:
 The task of this Module is to accept the packet from the In-Router
router and send it to the Out-Router router.

3. (B) Process Description:

 Input entities: receives data neighboring nodes and transfer into
another neighboring nodes.
 Algorithm: not applicable.
14
 Congestion Control using Network Based Protocol (NBP)

 Output :transfer packets to neighboring nodes

3. (C) Parameters:
Input Parameters:
 Data Packets from In- Router Machine.
 Forward feedback from the Router or In- Router.
 Backward feedback from the Router or Out- Router.
 Hop count.
Output Parameters:
 Data Packets.
 Forward feedback.
 Incremented Hop count.
 Backward feedback.

2.4. OutRouter Router Module:-

4. (A) Description:
An edge router operating on a flow passing out of a network is called
an Out-Router router. CFR prevents congestion collapse through a
combination of per-flow rate monitoring at Out-Router routers and per-
flow rate control at In-Router routers. Rate monitoring allows an Out-
Router to determine how rapidly each flow’s packets are leaving the
network. Rate monitored using a rate estimation algorithm such as the
Time Sliding Window (TSW) algorithm. Out-Router contains a flow
classifier, Rate monitor, and a feedback controller.
4. (B) Process Description:
Using time sliding window and rate monitoring algorithm to rank
the nodes in the network
 Input data entities: which determine the rate of the
packets flow in the network.
 Algorithm : time sliding window and rate monitoring
 Output: packets are sending to destination.

15
 Congestion Control using Network Based Protocol (NBP)

4. (C) Parameters:
Input Parameters:
 Data Packets from Router.
 Forward feedback from the Router.
Output Parameters:
 Data Packets.
 Backward feedback.

2.5. Destination Module:-

5. (A) Description:
The task of this Module is to accept the packet from the Out-Router
router and stored in a file in the Destination machine.
5. (B) Process Description:
Packets are received from the Neighbouring nodes.
 Input data entities: message to be received from the Out router
to the Destination node in the form of packets with IP-address.
 Algorithm: not applicable
 Output: formatted packets with the requirement Information
for communication between Source and destination nodes.
5. (C) Parameters:
 Message received from the Out-Router will be stored in the
corresponding folder as a text file depends upon the Source Machine
Name.

16
 Congestion Control using Network Based Protocol (NBP)

3. Working Aspects of the CFR(Congestion Free Router)

3.1 Mechanism:
 The architectural components, namely, the modified edge routers, which must
be present in the network
 The feedback control algorithm, which determines how and when information
is exchanged between edge route
 The rate control algorithm, which uses the information carried in feedback
packets to regulate flow transmission rates and thereby prevent congestion
collapse in the network.

A. Architectural Components
The only components of the network that require modification by CFR are
edge routers; the input ports of OutRouter routers must be modified to perform per-
flow monitoring of bit rates, and the output ports of InRouter routers must be
modified to perform per-flow rate control. In addition, both the InRouter and the
OutRouter routers must be modified to exchange and handle CFR feedback packets.

Fig 5.

17
 Congestion Control using Network Based Protocol (NBP)

The input ports of OutRouter routers are enhanced in CFR. Fig. 3 illustrates
the architecture of an OutRouter router’s input port. Data packets sent by InRouter
routers arrive at the input port of the OutRouter router and are first classified by
flow. Flow classification is performed by InRouter routers on every arriving packet
based upon a flow classification policy.

An example flow classification policy is to examine the packet’s source and

destination network addresses, and to aggregate all packets arriving on an InRouter
router and destined to the same OutRouter router into the same CFR flow (i.e., a
macro-flow). It could be done by examining the packet’s source and destination
addresses and port numbers.

After classifying packets into flows, each flow’s bit rate is then rate
monitored using a rate estimation algorithm such as the Time Sliding Window
(TSW) algorithm. These rates are collected by a feedback controller, which returns
them in backward feedback packets to an InRouter router whenever a forward
feedback packet arrives from that InRouter router.

Fig 6.

18
 Congestion Control using Network Based Protocol (NBP)

The output ports of InRouter routers are also enhanced in CFR. Each output
port contains a flow classifier, per-flow traffic shapers (e.g., leaky buckets), a
feedback controller, and a rate controller (see Fig. 4). The flow classifier classifies
packets into flows, and the traffic shapers limit the rates at which packets from
individual flows enter the network. The feedback controller receives backward
feedback packets returning from OutRouter routers and passes their contents to the
rate controller. It also generates forward feedback packets that are transmitted to the
network’s OutRouter routers. To prevent congestion collapse, the rate controller
adjusts traffic shaper parameters according to a TCP-like rate-control algorithm, and
the rate-control algorithm used in CFR is described later in this section.

B. Feedback Control Algorithm

The feedback control algorithm in CFR determines how and when feedback
packets are exchanged between edge routers. Feedback packets take the form of
ICMP packets and are necessary in CFR for three reasons. First, forward feedback
packets allow OutRouter routers to discover which InRouter routers are acting as
sources for each of the flows they are monitoring. Second, backward feedback
packets allow OutRouter routers to communicate per-flow bit rates to InRouter
routers. Third, forward and backward feedback packets allow InRouter routers to
detect incipient network congestion by monitoring edge-to-edge round-trip times.

19
 Congestion Control using Network Based Protocol (NBP)

Fig 7.

The contents of feedback packets are shown in Fig. 7.

Contained within the forward feedback packet generated at an InRouter router

are a time stamp and a list of flow specifications for flows originating at the InRouter
router. The time stamp field is used to calculate the round-trip time between two
edge routers, and the list of flow specifications indicates to an OutRouter router the
identities of active flows originating at the InRouter router.

A flow specification is a value uniquely identifying a flow, assigned by the

InRouter router flow classifier. InRouter router adds a flow to its list of active flows
whenever a packet from a new flow arrives; it removes a flow when the flow
becomes inactive. In the event that the network’s maximum transmission unit size is
not sufficient to hold an entire list of flow specifications, multiple forward feedback
packets are used.

20
 Congestion Control using Network Based Protocol (NBP)

C. Rate-Control Algorithm
The CFR rate-control algorithm regulates the rate at which each flow is
allowed to enter the network. Its primary goal is to converge on a set of per-flow
transmission rates (here in after called InRouter rates) that prevents congestion
collapse due to undelivered packets. It also attempts to lead the network to a state of
maximum link utilization and low router buffer occupancies, and it does this in a
manner that is similar to TCP.

Fig 8.

In the CFR rate-control algorithm, shown in Fig. 6, a flow may be in one of

two phases, slow start or congestion avoidance, similar to the phases of TCP
congestion control. The desirable stability characteristics of slow-start and
congestion control algorithms have been proven in TCP congestion control, and CFR
expects to benefit from their well-known stability features. In CFR, new flows
entering the network start with the slow-start phase and proceed to the congestion-
avoidance phase only after the flow has experienced incipient congestion.

The rate-control algorithm is invoked whenever a backward feedback packet

arrives at an InRouter router. Recall that backward feedback packets contain a

21
 Congestion Control using Network Based Protocol (NBP)

timestamp and a list of flows arriving at the OutRouter router from the InRouter
router as well as the monitored OutRouter rates for each flow. Upon the arrival of a
backward feedback packet, the algorithm calculates the current round-trip time
(currentRTT in Fig. 6) between the edge routers and updates the base round-trip time
(e.base RTT), if necessary.

The base round-trip time (e.base RTT) reflects the best-observed round-trip
time between the two edge routers. The algorithm then calculates deltaRTT, which
is the difference between the current round-trip time (currentRTT) and the base
round-trip time (e.baseRTT). A deltaRTT value greater than zero indicates that
packets are requiring a longer time to traverse the network than they once did, and
this can only be due to the buffering of packets within the network.

Propagation delay

Source
Sink

Queuing delay

Round-trip time

The estimated number of round-trip times since the last feedback packet
arrived is denoted as RTTs Elapsed. Doubling the InRouter rate during slow start

22
 Congestion Control using Network Based Protocol (NBP)

allows a new flow to rapidly capture available bandwidth when the network is
underutilized. If, on the other hand, the flow is in the congestion-avoidance phase,
then its InRouter rate is conservatively incremented by one rate Quantum value for
each round trip that has elapsed since the last backward feedback packet arrived
(f.InRouterrate rate Quantum RTTsElapsed). This results in rate growth behavior
that is similar to TCP in its congestion-avoidance phase.

Furthermore, the rate quantum is not allowed to exceed the flow’s current
OutRouter rate divided by a constant quantum factor (QF). This guarantees that rate
increments are not excessively large when the round-trip time is small. When the
rate-control algorithm determines that a flow is experiencing incipient congestion, it
reduces the flow’s InRouter rate.

CFR’s rate-control algorithm is designed to have minimum impact on TCP

flows. The rate at which CFR regulates each flow (f.InRouterRate) is primarily a
function of the round-trip time between the flow’s InRouter and OutRouter routers
(currentRTT). In CFR, the initial InRouter rate for a new flow is set to be
MSS/e.baseRTT, following TCP’s initial rate of one segment per round-trip time.

CFR’s currentRTT is always smaller than TCP’s end-to-end round-trip time.

As a result, f.InRouterRate is normally larger than TCP’s transmission rate when the
network is not congested, since the TCP transmission window increases at a rate
slower than CFR’s f.InRouterRate increases. Therefore, CFR normally does not
regulate TCP flows.

However, when congestion occurs, CFR reacts first by reducing

f.InRouterRate and, therefore, reducing the rate at which TCP packets are allowed
to enter the network. TCP eventually detects the congestion (either by losing packets
or due to longer round-trip times) and then promptly reduces its transmission rate.

23
 Congestion Control using Network Based Protocol (NBP)

From this time point on, f.InRouterRate becomes greater than TCP’s transmission
rate, and therefore, CFR’s congestion control does not regulate TCP sources until
congestion happens again.

D. Leaky bucket Algorithm

The "leaky bucket" algorithm is key to defining the meaning of conformance.

The leaky bucket analogy refers to a bucket with a hole in the bottom that causes it
to "leak" at a certain rate coresponding to a traffic cell rate parameter The "depth"
of the bucket corresponds to a tolerance parameter Each cell arrival creates a "cup"
of fluid flow "poured" into one or more buckets for use in conformance checking.
The Cell Loss Priority (CLP) bit in the ATM cell header determines which bucket(s)
the cell arrival fluid pours into. In the algorithm, a cell counter represents the bucket.
This counter is incremented by one for each incoming cell. The "leak rate" in the
algorithm is the decrement rate which reduces the counter value by one at certain
intervals. This rate is given by the cell rate under consideration
and is governed by the minimum distance between two consecutive cells. The bucket
volume is analogous to the cell counter range, which is represented by the
permissible time tolerance for the incoming cells. This value is determined through
the traffic contract or is set by the network provider and is called CDVT (cell delay
variation tolerance). If the counter exceeds a certain value, the cells are assumed not
to conform to the contract. To counteract this, non-conforming cells can now either
be tagged or dropped. The algorithm is called "dual leaky bucket" if several
parameters are monitored at once, or "single leaky bucket" if only one parameter is
monitored.
In the "Leaky Bucket" analogy the cells do not actually flow through the bucket;
only the check for conformance to the contract does.

24
 Congestion Control using Network Based Protocol (NBP)

CHAPTER 5: SCREENSHOTS
1. Source

Fig 9.
2. InRouter

25
 Congestion Control using Network Based Protocol (NBP)

Fig 10.
3. Router

Fig 11.
4. OutRouter

Fig 12.

26
 Congestion Control using Network Based Protocol (NBP)

Fig 13.

5.Destination

Fig 14.

27
 Congestion Control using Network Based Protocol (NBP)

CHAPTER 6: CONCLUSION AND FUTURE SCOPE

In this project, we have presented a novel congestion-avoidance mechanism

for the Internet called CFR and an ECSFQ mechanism. Unlike existing Internet
congestion control approaches, which rely solely on end-to-end control, CFR is able
to prevent congestion collapse from undelivered packets. ECSFQ complements CFR
by providing fair bandwidth allocations in a core-stateless fashion.

CFR ensures at the border of the network that each flow’s packets do not
enter the network faster than they are able to leave it, while ECSFQ ensures, at the
core of the network that flows transmitting at a rate lower than their fair share
experience no congestion, i.e., low network queuing delay. This allows the
transmission rate of all flows to converge to the network fair share. CFR requires no
modifications to core routers nor to end systems.

Only edge routers are enhanced so that they can perform the requisite per-
flow monitoring, per-flow rate-control and feedback exchange operations, while
ECSFQ requires a simple core-stateless modification to core routers. Simulation
results show that CFR successfully prevents congestion collapse from undelivered
packets. They also show that, while CFR is unable to eliminate unfairness on its
own, it is able to achieve approximate global max-min fairness for competing
network flows when combined with ECSFQ, they approximate global max-min
fairness in a completely core-stateless fashion.

28
 Congestion Control using Network Based Protocol (NBP)

BIBLOGRAPHY

References

[1] S. Floyd and K. Fall, “Promoting the use of end-to-end congestion control
in the internet,” IEEE/ACM Trans. Networking, vol. 7, pp. 458–472,
Aug. 1999.
[2] J. Nagle, “Congestion control in IP/TCP Internet works,” Internet Engineering
Task Force, RFC 896, Jan. 1984.
[3] V. Jacobson, “Congestion avoidance and control,” ACM Comput. Commun. Rev.,
vol. 18, no. 4, pp. 314–329, Aug. 1988.
[4] (1999, Jan.) Real Broadcast Network White Paper. Real Networks, Inc. [Online].
Available: http://www.real.com/solutions/rbn/ whitepaper.html
[5] (1999, Jan.) Real Video Technical White Paper. Real Networks Inc. [Online].
Available: http://www.real.com/devzone/library/whitepapers/ overview.html
[6] A. Habib and B. Bhargava, “Unresponsive flow detection and control in
differentiated services networks,” presented at the 13th IASTED Int. Conf. Parallel
and Distributed Computing and Systems, Aug. 2001.
[10] A. Mustafa and M. Hassan, “End to end IP rate control,” in Recent Advances in
Computing and Communications. New York: McGraw-Hill, Dec. 2000, pp. 279–
282.
[11] A. Rangarajan and A. Acharya, “ERUF: Early regulation of unresponsive best-
effort traffic,” presented at the Int. Conf. Networks and Protocols, Oct. 1999.
[12] S. Robinson, “Multimedia transmission drive net toward gridlock,” New York
Times, Aug. 23, 1999.
[13] A. Demers, S.Keshav, and S. Shenker, “Analysis and simulation of a fair
queuing algorithm,” in Proc. ACM SIGCOMM, Sept. 1989, pp. 1–12.

29