Capturing Router Congestion and Delay

Abstract:
Using a unique monitoring experiment, we capture all packets crossing a (lightly utilized) operational access router from a node provider, and use them to provide a detailed examination of router congestion and packet delays. The complete capture enables not just statistics as seen from outside the router, but also an accurate physical router model to be identified. This enables a comprehensive examination of congestion and delay from three points of view: the understanding of origins, measurement, and reporting.Our study defines new methodologies and metrics. In particular, the traffic reporting enables a rich description of the diversity of microcongestion behavior, without model assumptions, and at achievable computational cost.



Existing System:

¢ In the existing system, the sender sends the packets without the intermediate station.
¢ The data packets has been losses many and time is wasted.
¢ Retransmission of data packets is difficulty.

In this project Network routers occupy a unique role in modern distributed systems. They are responsible for cooperatively shuttling packets amongst themselves in order to provide the illusion of a network with universal point-to-point connectivity. However, this illusion is shattered - as are implicit assumptions of availability, confidentiality, or integrity - when network routers are subverted to act in a malicious fashion. By manipulating, diverting, or dropping packets arriving at a compromised router, an attacker can trivially mount denial-of-service, surveillance, or man-in-the-middle attacks on end host systems. Consequently, Internet routers have become a choice target for would-be attackers and thousands have been subverted to these ends. In this paper, we specify this problem of detecting routers with incorrect packet forwarding behavior and we explore the design space of protocols that implement such a detector. We further present a concrete protocol that is likely inexpensive enough for practical implementation at scale. Finally, we present a prototype system, called Fatih, that implements this approach on a PC router and describe our experiences with it. We show that Fatih is able to detect and isolate a range of malicious router actions with acceptable overhead and complexity. We believe our work is an important step in being able to tolerate attacks on key network infrastructure components

Proposed System:

We develop END-TO-END packet delay is one of the canonical metrics in Internet Protocol (IP) networks, and is important bothfrom the network operator and application performance pointsof view.

We have designed, developed, and implemented a compromised router detection protocol that dynamically infers, based on measured traffic rates and buffer sizes, the number of congestive packet losses that will occur.

Once the ambiguity from congestion is removed, subsequent packet losses can be attributed to malicious actions. We have tested our protocol in Emulab and have studied its effectiveness in differentiating attacks from legitimate network behavior.

Packet Sequence Numbers
A packet sequence number is a 32 bit number in the range from 1 through 2^32 û 1, which is used to specify the sequential order of a Data packet in a Data Stream. A sender node assigns consecutive sequence numbers to the Data packets provided by the Sender application. Zero is reserved to indicate that the data session has not yet started.
Data Queue
A Data Queue is a buffer, maintained by a Sender or a Repair Head, for transmission and retransmission of the Data packets provided by the Sender application. New Data packets are added to the data queue as they arrive from the sending application, up to a specified buffer limit. The admission rate of packets to the network is controlled by flow and congestion control algorithms. Once a packet has been received by the Receivers of a Data Stream, it may be deleted from the buffer.


Module Description:

1. System Module.

Client-server computing or networking is a distributed application architecture that partitions tasks or workloads between service providers (servers) and service requesters, called clients. Often clients and servers operate over a computer network on separate hardware. A server machine is a high-performance host that is running one or more server programs which share its resources with clients. A client also shares any of its resources; Clients therefore initiate communication sessions with servers which await (listen to) incoming requests.

2.Data Transmission and Retransmission

Data is multicast by a Sender on the Data Multicast Address. Retransmissions of data packets may be multicast by the Sender on the Data Multicast Address or be multicast on a Local Control Channel by a Repair Head. In order to provide NACK suppression and to work with proactive FEC, retransmissions are always multicast. If Generic Router Assist is enabled, the routers may provide NACK suppression and allow dynamically scoped retransmission to just the subset of Receivers and Repair Heads that have missed a packet.
A Repair Head joins all of the Data Multicast Addresses that any of its descendants have joined. A Repair Head is responsible for receiving and buffering all data packets using the reliability semantics configured for a stream. As a simple to implement option, a Repair Head MAY also function as a Receiver, and pass these data packets to an attached application.
For additional fault tolerance, a Receiver MAY subscribe to the multicast address associated with the Local Control Channel of one or more Repair Heads in addition to the multicast address of its parent. In this case it does not bind to this Repair Head or Sender, but will process Retransmission packets sent to this address. If the Receiver's Repair Head fails and it transfers to another Repair Head, this minimizes the number of data packets it needs to recover after binding to the new Repair Head.

3.Control Traffic Management
One of the largest challenges for scaleable reliable multicast protocols has been that of controlling the potential explosion of control traffic. There is a fundamental tradeoff between the latency with which losses can be detected and repaired, and the amount of control traffic generated by the protocol. In conjunction with the dynamic global tree parameters, TRACK provides a set of algorithms that carefully control and manage this traffic, preventing control traffic explosion.
Despite their different names, ACKs and NACKs both function as selective acknowledgements of the window of contiguous sequence numbers that have not yet been fully acknowledged. The only difference between the packet headers is a single flag.
ACK packet frequency is controlled by setting a number of tree wide parameters controlling their maximum rate of generation. The primary parameter is the ratio parameter, R, for the maximum number of ACK packets to be generated per data packet sent. The higher R is, the faster positive acknowledgements will be generated all the way back to the sender. This induces more back-channel traffic.

ACKs MUST be enabled for any Data Session. NACKs SHOULD be implemented as part of any implementation, and MAY be enabled for any given Data Session. If enabled, then on detection of a lost packet, a Receiver waits a random interval before sending a NACK. If the Receiver receives the retransmitted data before the NACK timer expires, the Receiver cancels the NACK. This reduces the chance that multiple Receivers generate a NACK for the same packet.
A Repair Head node multicasts a Data packet to its children as soon as it gets a NACK request for that packet, unless it retransmitted that packet previously in a configurable time period. If it does not have the missing packet, it forwards the NACK to its parent, and multicasts a control packet to its children to suppress any further NACKs for that packet from them. The Repair Head forwards only one NACK for a missing Data packet within a specified period of time. If more than one packet has been detected as missing before the NACK is sent, the NACK will request all of the missing packets.

4.Flow and Congestion Control :
Flow and congestion control algorithms act to prevent the Senders from overflowing the Receivers' buffers and to force them to share the network fairly and safely with other TCP and RM connections. ACK uses a combination of a transmission window for flow control, and the dynamic rate control algorithms specified in the Congestion Control (CC) BB for congestion control. These algorithms have been proven to meet all the requirements for flow and congestion control, including being safe for use in a general Internet environment, and provably fair with TCP.
The Sender application provides the minimum and maximum rate limits as part of the global parameters. A Sender will not transmit at lower than the minimum rate (except possibly during short periods of time when certain slow receivers are being ejected), or higher than the maximum rate. If a Receiver is not able to keep up with the minimum rate for a period of time, the CC BB algorithms will cause it to leave the group. Receivers that leave the group MAY attempt to rejoin the group at a later time, but SHOULD NOT attempt an immediate reconnection.

HARDWARE SOFTWARE SPECIFICATION:

Hardware Requirements
¢ SYSTEM : Pentium IV 2.4 GHz
¢ HARD DISK : 40 GB
¢ FLOPPY DRIVE : 1.44 MB
¢ MONITOR : 15 VGA colour
¢ MOUSE : Logitech.
¢ RAM : 256 MB
¢ KEYBOARD : 110 keys enhanced.


Software Requirements

¢ Operating system :- Windows XP Professional
¢ Front End : - Java Technology.

i want ppt of capturing router congestion and delay project

can u give moduls for(capturing router congestion and delay)

i need ppt for capturing router congastin and delay

[attachment=13188]
1. INTRODUCTION
1.1 Introduction to Project:
END-TO-END packet delay is one of the canonical metrics in Internet Protocol (IP) networks, and is important both from the network operator and application performance points of view. For example the quality of Voice Over IP is directly dependent on delay, and network providers may have Service Level Agreements (SLAs) specifying allowable values of delay statistics across the domains they control. An important component of end-to-end delay is that due to forwarding elements, the fundamental building block of which is the delay incurred when a packet passes through a single IP router.
The motivation for the present work is a detailed knowledge and understanding of such “through-router” delays. A thorough examination of delay leads inevitably to deeper questions about congestion, and router queueing dynamics in general. We provide a comprehensive examination of these issues from three points of view: the understanding of origins, measurement, and reporting, all grounded in a unique data set taken from a router in the access network of a Tier-1 provider.
Although there have been many studies examining delay statistics and congestion measured at the edges of the network, very few have been able to report with any degree of authority on what actually occurs at switching elements. In an analysis of single hop delay on an IP backbone network was presented. Only samples of the delays experienced by packets, on some links, were identified. I single hop delays were also ob-tained for a router. However since the router only had one input and one output link, which were of the same speed, the internal queueing was extremely limited. In this paper we work with a data set recording all IP packets traversing a Tier-1 access router over a 13 hour period. All input and output links were monitored, allowing a complete picture of congestion, and in particular router delays, to be obtained.
This paper is based on a synthesis of material first presented in two conference papers and based on the above data set. Section VI-A contains new results. In part because it is both costly and technically challenging to collect, this data set, although now a few years old, to the best of our knowledge remains unique. Consequently, the same is true of the kind of analyzes it enables as presented here. What we emphasize in this presentation are the methodologies and approaches which have generic value. However, we believe that the detail and depth of the data analysis also makes this study worthwhile from the data archival point of view. Our specific conclusions are strictly speaking limited to a single data set with low loss and delay. However, since Tier-1 networks tend to be under provisioned, we believe it remains representative of backbone access routers and their traffic today. This conjecture requires testing against more data sets.
The first aim of this paper is a simple one, to exploit this unique data set by reporting in detail on the magnitudes, and also the temporal structure, of delays on high capacity links with nontrivial congestion. The result is one of the most comprehensive pictures of router delay performance that we are aware of. As our analysis is based on empirical results, it is not reliant on assumptions on traffic statistics or router operations.
Our second aim is to use the completeness of the data as a tool to investigate how packet delays occur inside the router. In other words, we aim to provide a physical model capable of explaining the observed delay and congestion. Working in the context of the popular store and forward router architecture, we are able to justify the commonly held assumption that the bottleneck of such an architecture is in the output buffers, and thereby validate the fluid output queue model relied on routinely in the field of active probing. We go further to define a refined model with accuracy close to the limits of time stamping precision, which is robust to many details of the architecture under reasonable loads.
Packet delays and congestion are fundamentally linked, as the former occur precisely because periods of temporary resource starvation, or microcongestion episodes, are dealt with via buffering. Our third contribution is an investigation of the origins of such episodes, driven by the question, “What is the dominant mechanism responsible for delays?”. We use a powerful methodology of virtual or “semi-” experiments, that exploits both the availability of the detailed packet data, and the fidelity of the router model. We identify, and evaluate the contributions of, three known canonical mechanisms:
i. Reduction in page link bandwidth from core to access;
ii. Multiplexing of multiple input streams;
iii. Burstiness of the input traffic stream(s).
To our knowledge, such a taxonomy of page link congestion has not been used previously, and our findings for this specific data set are novel and sometimes surprising. Our broader contribution however is the methodology itself, including a set of metrics which can be used to examine the origins of congestion and hence delay.
The fourth part of the paper gives an innovative solution to a nontrivial problem: how the complexities of microcongestion and associated delay behavior can be measured and summarized in a meaningful way. We explain why our approach is superior to attempting to infer delay behavior simply from utilization, an approach which is in fact fatally flawed. In addition, we show how this can be done at low computational cost, enabling a compact description of congestion behavior to form part of standard router reporting. A key advantage is that a generically rich description is reported, without the need for any traffic assumptions.
2. SYSTEM ANALYSIS
2.1 INTRODUCTION:
Using a unique monitoring experiment, we capture all packets crossing a (lightly utilized) operational access router from a Tier-1 provider, and use them to provide a detailed examination of router congestion and packet delays. The complete capture enables not just statistics as seen from outside the router, but also an accurate physical router model to be identified. This enables a comprehensive examination of congestion and delay from three points of view: the understanding of origins, measurement, and reporting. Our study defines new methodologies and metrics. In particular, the traffic reporting enables a rich description of the diversity of micro congestion behavior, without model assumptions, and at achievable computational cost.
2.2 EXISTING SYSTEM:
END-TO-END packet delay is one of the canonical metrics in Internet Protocol (IP) networks, and is important both from the network operator and application performance points of view. For example the quality of Voice Over IP is directly dependent on delay, and network providers may have Service Level Agreements (SLAs) specifying allowable values of delay statistics across the domains they control. An important component of end-to-end delay is that due to forwarding elements, the fundamental building block of which is the delay incurred when a packet passes through a single IP router.
2.3PROPOSED SYSTEM:
The motivation for the present work is a detailed knowledge and understanding of such “through-router” delays. A thorough examination of delay leads inevitably to deeper questions about congestion, and router queueing dynamics in general. We provide a comprehensive examination of these issues from three points of view: the understanding of origins, measurement, and reporting, all grounded in a unique data set taken from a router in the access network of a Tier-1 provider.
The first aim of this paper is a simple one, to exploit this unique data set by reporting in detail on the magnitudes, and also the temporal structure, of delays on high capacity links with nontrivial congestion. The result is one of the most comprehensive pictures of router delay performance that we are aware of. As our analysis is based on empirical results, it is not reliant on assumptions on traffic statistics or router operations. Our second aim is to use the completeness of the data as a tool to investigate how packet delays occur inside the router. In other words, we aim to provide a physical model capable of explaining the observed delay and congestion. Working in the context of the popular store and forward router architecture, we are able to justify the commonly held assumption that the bottleneck of such an architecture is in the output buffers, and thereby validate the fluid output queue model relied on routinely in the field of active probing. We go further to define a refined model with an accuracy close to the limits of time stamping precision, which is robust to many details of the architecture under reasonable loads.
Packet delays and congestion are fundamentally linked, as the former occur precisely because periods of temporary resource starvation, or micro congestion episodes, are dealt with via buffering. Our third contribution is an investigation of the origins of such episodes, driven by the question, “What is the dominant mechanism responsible for delays?” We use a powerful methodology of virtual or “semi-” experiments, that exploits both the availability of the detailed packet data, and the fidelity of the router model. We identify, and evaluate the contributions of, three known canonical mechanisms: i) reduction in page link bandwidth from core to access; ii) multiplexing of multiple input streams; iii) burstiness of the input traffic stream(s).
2.4 MODULES:
• CLIENT
• SERVER
MODULE DESCRIPTION:
SERVER:
Server is main module in this project, server receive the data sent by client & calculate the congestion parameters for the client like delay, bandwidth, busy & status of client.
CLIENT:
Client sends the data to server & if client is free at server, data is successfully sent .Otherwise the data is in queue until previous data is send.
2.5 FEASIBILITY REPORT:
Preliminary investigation examine project feasibility, the likelihood the system will be useful to the organization. The main objective of the feasibility study is to test the Technical, Operational and Economical feasibility for adding new modules and debugging old running system. All system is feasible if they are unlimited resources and infinite time. There are aspects in the feasibility study portion of the preliminary investigation:
• Technical Feasibility
• Operational Feasibility
Economical Feasibility
2.5.1 TECHNICAL FEASIBILITY:
The technical issue usually raised during the feasibility stage of the investigation includes the following:
• Does the necessary technology exist to do what is suggested?
• Do the proposed equipments have the technical capacity to hold the data required to use the new system?
• Will the proposed system provide adequate response to inquiries, regardless of the number or location of users?
• Can the system be upgraded if developed?
• Are there technical guarantees of accuracy, reliability, ease of access and data security?
Earlier no system existed to cater to the needs of ‘Secure Infrastructure Implementation System’. The current system developed is technically feasible. It is a web based user interface for audit workflow at NIC-CSD. Thus it provides an easy access to the users. The database’s purpose is to create, establish and maintain a workflow among various entities in order to facilitate all concerned users in their various capacities or roles. Permission to the users would be granted based on the roles specified. Therefore, it provides the technical guarantee of accuracy, reliability and security. The software and hard requirements for the development of this project are not many and are already available in-house at NIC or are available as free as open source. The work for the project is done with the current equipment and existing software technology. Necessary bandwidth exists for providing a fast feedback to the users irrespective of the number of users using the system.