3.1 TCP Tahoe Tahoe refers to the TCP congestion control algorithm.

TCP Tahoe is based on a principle of conservation of packets, i.e. if the connection is running at the available bandwidth capacity then a packet is not injected into the network unless a packet is taken out as well. TCP implements this principle by using the acknowledgements to clock outgoing packets because an acknowledgement means that a packet was taken off the wire by the receiver. It also maintains a congestion window CWND to reflect the network capacity. When congestion encounters it decrease over sending rate and reduced congestion window to one. However there are certain issues, which need to be resolved to ensure this equilibrium. 1. Determination of the available bandwidth. 2)Ensuring that equilibrium is maintained. 3)How to react to congestion The Tahoe TCP implementation added a number of new algorithms and refinements to earlier implementations. The new algorithms include SlowStart, Congestion Avoidance and Fast Retransmit. The refinements include a modification to the round-trip time estimator used to set retransmission timeout values .It isnt very suitable for high band-width product links because of the waiting timeout. Problems: The problem with Tahoe is that it takes a complete timeout interval to detect a packet loss and in fact, in most implementations it takes even longer because of the coarse grain timeout. Also since it doesnt send immediate ACKs, it sends cumulative acknowledgements, therefore it follows a go back n approach. Thus every time a packet is lost it waits for a timeout and the pipeline is emptied. This offers a major cost in high band-width delay product links. 3.2 TCP Reno This Reno retains the basic principle of Tahoe, such as slow starts and the coarse grain re-transmit timer. However it adds some intelligence over it so that lost packets are detected earlier and the pipeline is not emptied every time a packet is lost. Reno requires that we receive immediate acknowledgement whenever a segment is received. The logic behind this is that whenever we receive a duplicate acknowledgment, then his duplicate acknowledgment could have been received if the next segment in sequence expected, has been delayed in the network and the segments reached there out of order or else that the packet is lost. If we receive a number of duplicate acknowledgements then that means that sufficient time have passed and even if the segment had taken a longer path, it should have gotten to the receiver by now. There is a very high probability that it was lost. So Reno suggests an algorithm called Fast Re- Transmit. Whenever we receive3 duplicate ACKs we take it as a sign that the segment was lost, so we re-transmit the segment without waiting for timeout. The basic algorithm is presented as under: 1) Each time we receive 3 duplicate ACKs we take that to mean that the segment was lost and we re-transmit the segment immediately and enter Fast- Recovery 2)Sets ssthresh to half the current window size and also set CWND to the same value. 3) For each duplicate ACK receive increase CWND by one. If the increase CWND is greater than the amount of data in the path then transmit a new segment else wait. Problems: Reno performs very well over TCP when the packet losses are small. But when we have multiple packet losses in one window then RENO doesnt perform too well .The reason is that it can only detect single packet losses. If there is multiple packet drops then the first info about the packet loss comes when we receive the duplicate ACKs. But the information about

the second packet which was lost will come only after the ACK for the retransmitted first segment reaches the sender after one RTT. Another problem is that if the widow is very small when the loss occurs then we would never receive enough duplicate acknowledgements for a fast retransmit and we would have to wait for a coarse grained timeout. .Reno's Fast Recovery algorithm is optimized for the case when a single packet is dropped from a window of data. 3.3 TCP Lite TCP Lite is a service that provides a transport method that interrupts TCP in order to reduce the overhead involved in session management in which no data is transmitted or received. TCP Lite reduces or eliminates pure TCP protocol data units used in the set up and ACK while maintaining order, integrity, reliability and security of traditional TCP. TCP lite uses big window and protection against wrapped sequence numbers. Problems: Lite performs over TCP same as Reno. But when window increases it have some problems to maintain them. 3.4 TCP New Reno New RENO is a slight modification over TCP-RENO. It is able to detect multiple packet losses and thus is much more efficient that RENO in the event of multiple packet losses. Like Reno, New-Reno also enters into fastretransmit when it receives multiple duplicate packets, however it differs from RENO in that it_doesnt exit fast-recovery until all the data which was out standing at the time it entered fast recovery is acknowledged. Thus it overcomes the problem faced by Reno of reducing the CWND multiples times. The fast -transmit phase is the same as in Reno. The difference in the fast recovery phase which allows for multiple re-transmissions in new-Reno. Whenever new-Reno enters fast recovery it notes the maximums segment which is outstanding. The fast-recovery phase proceeds as in Reno, however when a fresh ACK is received then there are two cases: If it ACKs all the segments which were outstanding when we entered fast recovery then it exits fast recovery and sets CWND to ssthresh and continues congestion avoidance like Tahoe. If the ACK is a partial ACK then it deduces that the next segment in line was lost and it re -transmits that segment and sets the number of duplicate ACKS received to zero. It exits Fast recovery when all the data in the window is acknowledged . Problems: New-Reno suffers from the fact that it takes one RTT to detect each packet loss. When the ACK for the first retransmitted segment is received only then can we deduce which other segment was lost. Round-trip time until all of the lost packets from that window has been retransmitted. 3.5 TCP Sack TCP with Selective Acknowledgments (SACK) is an extension of TCP Reno and it works around the problems face by TCP RENO and TCP New-Reno, namely detection of multiple lost packets, and re-transmission of more than one lost packet per RTT. SACK retains the slow-start and fast retransmits parts of RENO. It also has the coarse grained timeout of Tahoe to fall back on, in case a packet loss is not detected by the modified algorithm. SACK TCP enquires that segments not be acknowledged cumulatively but should be acknowledged selectively. Thus each ACK has a block which describes which segments are being acknowledged. Thus the sender has a picture of which segments have been acknowledged and which are still outstanding.

Whenever the sender enters fast recovery, it initializes a variable pipe which is an estimate of how much data is outstanding in the network, and it also set CWND to half the current size. Whenever the window goes smaller than the CWD window it checks which segments are un received and send them. If there are no such segments outstanding then it sends a new packet [8]. Thus more than one lost segment can be sent in one RTT. Problems: TCP SACK requires that segments not be acknowledged cumulatively but should be acknowledged selectively, each ACK has a block which describes which segments are being acknowledged then the biggest problem with SACK is that its currently selective acknowledgements are not provided by the receiver to implement . It also suffers from the same problems with multiple losses. As in Reno, the SACK TCP implementation enters Fast Recovery when the data sender receives an initial threshold of dup ACKs duplicate acknowledgments. The sender retransmits a packet and cuts the congestion window in half. During Fast Recovery, SACK maintains a variable that represents the estimated number of packets outstanding in the path. 3.6 TCP Vegas Vegas are a TCP implementation which is a modification of Reno TCP Vegas is different from TCP Re no in the sense that 1. A new retransmission mechanism is used 2. An improved congestion avoidance mechanism that controls buffer occupy 3. A modified slow start mechanism 4. That solve the problem of coarse gain timeout TCP Vegas include a modified retransmissions trategy that is based on fire-gained measurements of the RTT (means define d by system clock) as well as new mechanism for congestion detection during slow start andcongestion avoidance In TCP Reno, a rather coarse grained timer is used to estimate the RTT and the variance, which results in poor estimates. Vegas extend Renos retransmission mechanism as follows. As mentioned before, Vegas record the system clock each time a packet is sent. When an ACK is received, Vegas calculate the RTT and use this more accurate estimate to decide to retransmit in the following two situations: 1. When it receives a duplicate ACK, Vegas checks to se e if the RTT is greater than timeout. If it is, then without waiting for the third duplicate ACK, it immediately retransmits the packet 2. When a non-duplicate ACK is received, if it is the first or second ACK after a retransmission, Vegas again checks to see if the RTT is greater than timeout. If it is, then Vegas retransmit the packet. Problems: If there are enough buffer in the routers it means that Vegas congestion avoidance mechanism can function effectively a higher throughput and a faster response time result. As the load increase or the number or router buffer decrease, Vegas congestion avoidance mechanism is not as effective and Vegas start to behave more like Reno. Vegas is less aggressive in its use of router buffer than Reno because Vegas is limited. Finally Vegas congestion detection algorithm depends on the accurate value for Base RTT.

3.7 TCP Westwood The TCP Westwood (TCPW) is a sender -side-only modification to TCP New Reno that is intended to better handle large bandwidth-delay product paths, with potential packet loss due to transmission or other errors, and with dynamic load.TCP Westwood protocol relies on a simple modification of the TCP source protocol behavior for a faster recovery. This is performed by setting both a slow start threshold and a congestion window values that result from the effective connection while congestion is experienced. Hence, TCPW attempts to make a more informed decision, in contrast with TCP Reno, which automatically halves the congestion window after three duplicate ACKs. Like TCP Reno, TCPW cannot distinguish between buffer overflow losses and random losses. However, in presence of random losses, TCP Reno overreacts and reduces the window by half. Problems: TCP West Wood cannot distinguish between buffer overflow and random losses. It does not provide fast recovery mechanism for data packet or ACK. 3.8 TCP Fack The development in TCP SACK with Forward Acknowledgement is identified as TCP FACK .The utilization of TCP FACK is almost identical to SACK but it establishes a little enhancement evaluated to it. It uses SACK option to better estimate the amount of data in transit .TCP FACK introduces a better way to halve the window when congestion is detected. When CWND is immediately halved, the sender stops transmitting for a while and then resumes when enough data has left the network. In this one RTT can be avoided when the window is gradually decreased. When congestion occurs; the window should be halved according to the multiplicative decrease of the correct CWND. Since the sender identifies congestion at least one RTT after it happened, if during that RTT it was in slow start mode, then the current CWND will be almost double than CWND when congestion occurred. Therefore, in this case, CWND is first halved to estimate the correct CWND that should be further decreased. Problems: TCP Fack provides congestion avoidance and fast retransmission mechanism, it faces so many situations for recovery and it cannot implement easily