+- Free Academic Seminars And Projects Reports (https://easyreport.in)
+-- Forum: Project Ideas And Disscussion (https://easyreport.in/forumdisplay.php?fid=32)
+--- Forum: Engineering Project Ideas (https://easyreport.in/forumdisplay.php?fid=33)
+---- Forum: Computer Science Project Ideas (https://easyreport.in/forumdisplay.php?fid=36)
+---- Thread: Capturing Router Congestion And Delay (/showthread.php?tid=44775)
Pages:
1
2
Capturing Router Congestion And Delay - geemeera - 10-04-2017
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.
Capturing Router Congestion And Delay - Nidhin - 10-04-2017
to get information about the topic " Capturing Router Congestion and Delay" full report ppt and related topic refer the page link bellow
http://seminarsprojects.net/Thread-capturing-router-congestion-and-delay
http://seminarsprojects.net/Thread-capturing-router-congestion-and-delay--20386
http://seminarsprojects.net/Thread-capturing-router-congestion-and-delay?pid=77719
Capturing Router Congestion And Delay - freny john - 10-04-2017
hi
you can see these pages to know the details on capturing router congestion and delay
http://seminarsprojects.net/Thread-capturing-router-congestion-and-delay
http://seminarsprojects.net/Thread-capturing-router-congestion-and-delay--20386
Capturing Router Congestion And Delay - Abioye - 10-04-2017
for more details on apturing router congestion and delay , please visit the following thread.
http://seminarsprojects.net/Thread-capturing-router-congestion-and-delay?pid=25262#pid25262
Capturing Router Congestion And Delay - anoop80686 - 10-04-2017
I am Ragavender. I want the documentation for capturing Router Congestion and Delay Project.
I Know about the Project Details. But I dont know how to prepare the Documentation file.
Capturing Router Congestion And Delay - maithily4u - 10-04-2017
i want ppt presentaion of "capturing router congestion and delay" any one have details please send to my mail id [email protected]
i will we very thank ful to you.
Capturing Router Congestion And Delay - prajna - 10-04-2017
(04-03-2011, 11:08 AM)nai Wrote: we need architectural diagram , url, ER , Activitydiagrams , data flow of Capturing Router Congestion And Delay
Capturing Router Congestion And Delay - annie catherine - 10-04-2017
I want more details about congestion router congestion and delay with modules
modules for capturing router congestion and delay
Capturing Router Congestion And Delay - arpitha - 10-04-2017
we need architectural diagram , url, ER , Activitydiagrams , data flow of Capturing Router Congestion And Delay
Capturing Router Congestion And Delay - sreevas - 10-04-2017
i want architecture in detail for the capturing router congestion and delay as early as possible..
plzz