16-08-2012, 12:59 PM
Host-to-Host Congestion Control for TCP
Host-to-Host .ppt (Size: 355.5 KB / Downloads: 20)
Abstract
The Transmission Control Protocol (TCP) carries most Internet traffic, so performance of the Internet depends to a great extent on how well TCP works. Performance characteristics of a particular version of TCP are defined by the congestion control algorithm it employs. This paper presents a survey of various congestion control proposals that preserve the original host-to-host idea of TCP—namely, that neither sender nor receiver relies on any explicit notification from the network.
The proposed solutions focus on a variety of problems, starting with the basic problem of eliminating the phenomenon of congestion collapse, and also include the problems of effectively using the available network resources in different types of environments (wired, wireless, high-speed, long-delay, etc.).
Existing System
Existing TCP specification. The standard already requires receivers to report the sequence number of the last in-order delivered data packet each time a packet is received, even if received out of order . For example, in response to a data packet sequence 5,6,7,10,11,12, the receiver will ACK the packet sequence 5,6,7,7,7,7. In the idealized case, the absence of reordering guarantees that an out-of-order delivery occurs only if some packet has been lost. Thus, if the sender sees several ACKs carrying the same sequence numbers (duplicate ACKs), it can be sure that the network has failed to deliver some data and can act accordingly..
Proposed System
The Host to Host congestion control proposals that build a foundation for all currently known host-to-host algorithms. This foundation includes
The basic principle of probing the available network resources,
Loss-based and delay-based techniques to estimate the congestion state in the network,.
Techniques to detect packet losses quickly
TCP standard specifies a sliding window based flow control. This flow control has several mechanisms. First, the sender buffers all data before the transmission, assigning a sequence number to each buffered byte. Continuous blocks of the buffered data are packetized into TCP packets that include a sequence number of the first data byte in the packet. Second, a portion (window) of the prepared packets is transmitted to the receiver using the IP protocol. As soon as the sender receives delivery confirmation for at least one data packet, it transmits a new portion of packets. Finally, the sender holds responsibility for a data block until the receiver explicitly confirms delivery of the block.
Congestion Collapse module
TCP sender’s estimate of the number of data packets the network can accept for delivery without becoming congested. In the special case where the flow control limit (the socalled receiver window) is less than the congestion control limit (i.e., the congestion window), the former is considered a real bound for outstanding data packets .
Although this is a formal definition of the real TCP rate bound, we will only consider the congestion window as a rate limiting factor,assuming that in most cases the processing rate of end-hosts is several orders of magnitude higher than the data transfer rate that the network can potentially offer. Additionally, we will compare different algorithms, focusing on the congestion window dynamics as a measure of the particular congestion control algorithm effectiveness