Congestion Control Using NBP

Introduction
The Internets excellent scalability and robustness result in part from the endto-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 congestionavoidance 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 Internets excellent scalability and robustness result in part from the endto-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.

Perhaps the best example of the Internet philosophy is TCP congestion control, which is implemented primarily through algorithms operating at end systems. Unfortunately, TCP congestion control also illustrates some of the shortcomings of the end-to-end argument.

System Specification Software Requirements Specifications Java1.4 or More

Swings

Windows 98

Hardware Requirements Specifications Hard disk: 40 GB RAM: 128mb

Processor: Pentium 4 Monitor: 15 color monitor Floppy drive: 1.44 MB Mouse: HCL CD Drive: LG 52X Printer: Laser

Problem Definition i.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.

The first malady congestion collapse from undelivered packets arises when packets that are dropped before reaching their ultimate continually consume bandwidth destinations. The second maladyunfair bandwidth allocation to competing network flowsarises 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. ii.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 flows packets are entering the network faster than they are leaving it, then the network is likely buffering or, worse yet, discarding the flows packets. In other words, the network is receiving more packets than it is capable of handling. CFR prevents this scenario by patrolling the networks borders, ensuring that each flows 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 flows 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, CFRs 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.

5. Project Description PROJECT MODULES

The various modules in the protocol are as follows: Module 1: -

SOURCE MODULE. Module 2: INROUTER ROUTER MODULE. Module 3: ROUTER MODULE. Module 4: OUTROUTER ROUTER MODULE. Module 5: DESTINATION MODULE.

SOURCE MODULE:The task of this Module is to send the packet to the InRouter router. INROUTER ROUTER MODULE:An edge router operating on a flow passing into a network is called an InRouter router. CFR prevents congestion collapse through a combination of per-flow rate monitoring at OutRouter routers and perflow rate control at InRouter routers. Rate control allows an InRouter router to police the rate at which each flows packets enter the network. InRouter Router contains a flow classifier, per-flow traffic shapers (e.g., leaky buckets), a feedback controller, and a rate controller ROUTER MODULE:The task of this Module is to accept the packet from the InRouter router and send it to the OutRouter router. OUTROUTER ROUTER MODULE:An edge router operating on a flow passing out of a network is called an OutRouter router. CFR prevents congestion collapse through a combination of per-flow rate monitoring at OutRouter routers and perflow rate control at InRouter routers. Rate monitoring allows an OutRouter router to determine how rapidly each flows packets are leaving the network. Rate monitored using a rate estimation algorithm such as the Time Sliding Window (TSW) algorithm. OutRouter Router contains a flow classifier, Rate monitor, and a feedback controller.

DESTINATION MODULE:The task of this Module is to accept the packet from the OutRouter router and stored in a file in the Destination machine.

Process Description:

Source module

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 Output : not applicable : formatted packet with the

required information for communicating between the source & the destination node.

InRouter Module 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 Output

: Leaky bucket : All the nodes in the

network assigned with a unique rank.

Router Module Input entities: receives data neighboring nodes And transfer into another neighboring nodes. Algorithm: not applicable. Output :transfer packets to neighboring nodes

Out Module Using time sliding window and rate monitoring algorithm to rank the nodes in the network

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

Destination:

Packets are received from the

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

PARAMETERS Source Module:

Input Parameters: Source Machine Name is retrieved from the OS.

 User types destination Machine Name. Message is typed by User.

Output Parameters: Data Packets.

InRouter Module:

Input Parameters: Data Packets from Source Machine. Backward feedback from the Router.

Output Parameters: Data Packets. Forward feedback.

Router Module: Input Parameters: Data Packets from InRouter Machine. Forward feedback from the Router or InRouter Router. Backward feedback from the Router or OutRouter Router. Hop count. Output Parameters: Data Packets. Forward feedback. Incremented Hop count. Backward feedback.

OutRouter Module:

Input Parameters: Data Packets from Router. Forward feedback from the Router.

Output Parameters: Data Packets. Backward feedback.

Destination Module: Message received from the OutRouter router will be stored in the corresponding folder as a text file depends upon the Source Machine Name.