A Comparative Analysis of TCP Tahoe, Reno, New-Reno, SACK and Vegas Abstract: The purpose of this paper is to losses due to network loss are analyze and compare the different minimal and most of the packet losses congestion control and avoidance are due to buffer overflows at the mechanisms which have been proposed router. Thus it becomes increasingly for TCP/IP protocols, namely: Tahoe, important for TCP to react to a packet Reno, New-Reno, TCP Vegas and loss and take action to reduce SACK. TCP’s robustness is as a result of congestion. it’s reactive behavior in the face of TCP ensures reliability by starting a congestion, and fact that reliability is timer whenever it sends a segment. If it ensured by re-transmissions. All the does not receive an acknowledgement above mentioned implementations from the receiver within the ‘time-out’ suggest mechanisms for determining interval then it retransmits the segment. when a segment should be re-transmitted We shall start the paper by taking a and how should the sender behave when breif look at each of the congestion it encounters congestion and what avoidance algorithms and noting how pattern of transmissions should it follow they differ from each other. In the end to avoid congestion. In this paper we we shall do a head to head comparison to shall discuss how the different further bring into light the differences. mechanism affect the through put and efficiency of TCP and how they compare with TCP Vegas in terms of TCP TAHOE: performance. Tahoe refers to the TCP congestion control algorithm which was suggested by Van Jacobson in his paper. TCP is Introduction: based on a principle of ‘conservation of TCP is a reliable connection oriented packets’, i.e. if the connection is running end-to-end protocol. It contains within at the available bandwidth capacity then itself, mechanisms for ensuring a packet is not injected into the network reliability by requiring the receiver the unless a packet is taken out as well. acknowledge the segments that it TCP implements this principle by using receives. The network is not perfect and the acknowledgements to clock outgoing a small percentage of packets are lost en packets because an acknowledgement route, either due to network error or due means that a packet was taken off the to the fact that there is congestion in the wire by the receiver. It also maintains a network and the routers are dropping congestion window CWD to reflect the packets. We shall assume that packet network capacity. However there are certain issues, which need to be resolved to ensure this equilibrium. 1) Determination of the available bandwidth. Congestion Avoidance: 2) Ensuring that equilibrium is For congestion avoidance Tahoe uses maintained. ‘Additive Increase Multiplicative 3) How to react to congestion. Decrease’. A packet loss is taken as a sign of congestion and Tahoe saves the Slow Start: half of the current window as a TCP packet transmissions are threshold. value. It then set CWD to one clocked by the incoming and starts slow start until it reaches the acknowledgements. However there is a threshold value. After that it increments problem when a connection first starts linearly until it encounters a packet loss. up cause to have acknowledgements you Thus it increase it window slowly as it need to have data in the network and to approaches the bandwidth capacity. put data in the network you need acknowledgements. To get around this Problems: circularity Tahoe suggests that whenever The problem with Tahoe is that it a TCP connection starts or re-starts after take a complete timeout interval to a packet loss it should go through a detect a packet loss and in fact, in most procedure called ‘slow-start’. The reason implementations it takes even longer for this procedure is that an initial burst because of the coarse grain timeout. might overwhelm the network and the Also since it doesn’t send immediate connection might never get started. Slow ACK’s, it sends cumulative starts suggests that the sender set the acknowledgements, there fore it follows congestion window to 1 and then for a ‘go back n ‘ approach. Thus every each ACK received it increase the CWD time a packet is lost it waits for a by 1. so in the first round trip time(RTT) timeout and the pipeline is emptied. This we send 1 packet, in the second we send offers a major cost in high band-width 2 and in the third we send 4. Thus we delay product links. increase exponentially until we lose a packet which is a sign of congestion. When we encounter congestion we TCP RENO: decreases our sending rate and we This Reno retains the basic principle reduce congestion window to one. And of Tahoe, such as slow starts and the start over again. coarse grain re-transmit timer. However The important thing is that Tahoe it adds some intelligence over it so that detects packet losses by timeouts. In lost packets are detected earlier and the usual implementations, repeated pipeline is not emptied every time a interrupts are expensive so we have packet is lost. coarse grain time-outs which Reno requires that we receive occasionally checks for time outs. Thus immediate acknowledgement whenever it might be some time before we notice a a segment is received. The logic behind packet loss and then re-transmit that this is that whenever we receive a packet. duplicate acknowledgment, then his duplicate acknowledgment could have been received if the next segment in sequence expected, has been delayed in reduce the CWND to SSthresh. If we the network and the segments reached had previously received (w-1) duplicate there out of order or else that the packet ACK’s then at this point we should have is lost. If we receive a number of exactly w/2 segments in the pipe which duplicate acknowledgements then that is equal to what we set the CWND to be means that sufficient time has passed at the end of fast recovery. Thus we and even if the segment had taken a don’t empty the pipe, we just reduce the longer path, it should have gotten to the flow. We continue with congestion receiver by now. There is a very high avoidance phase of Tahoe after that. probability that it was lost. So Reno suggest an algorithm called ‘Fast Re- Problems: Transmit’. Whenever we receive 3 Reno perform very well over TCP duplicate ACK’s we take it as a sign that when the packet losses are small. But the segment was lost, so we re-transmit when we have multiple packet losses in the segment without waiting for timeout. one window then RENO doesn’t Thus we manage to re-transmit the perform too well and it’s performance is segment with the pipe almost full. almost the same as Tahoe under Another modification that RENO conditions of high packet loss. The makes is in that after a packet loss, it reason is that it can only detect a single does not reduce the congestion window packet losses. If there is multiple packet to 1. Since this empties the pipe. It enters drop then the first info about the packet into a algorithm which we call ‘Fast-Re- loss comes when we receive the Transmit’. The basic algorithm is duplicate ACK’s. But the information presented as under: about the second packet which was lost 1)Each time we receive 3 duplicate will come only after the ACK for the re- ACK’s we take that to mean that the transmitted first segment reaches the segment was lost and we re-transmit the sender after one RTT. segment immediately and enter ‘Fast- Also it is possible that the CWD is Recovery’ reduced twice for packet losses which 2)Set SSthresh to half the current occurred in one window. Suppose we window size and also set CWD to the send packets 1,2,3,4,5,6,7,8,9 in that same value. order. Suppose packets 1, and 2 are lost. 3)For each duplicate ACK receive The ACK’s generated by 2,4,5 will increase CWD by one. If the increase cause the re-transmission of 1 and the CWD is greater than the amount of data CWD is reduced to 7. Then when we in the pipe then transmit a new segment receive ACK for 6,7,8,9 our CWD is else wait. If there are ‘w’ segments in sufficiently large to allow to us to send the window and one is lost, the we will 10,11. When the re-transmitted segment receive (w-1) duplicate ACK’s. Since 1 reaches the receiver we get a fresh CWD is reduced to W/2, therefore half a ACK and we exit fast-recovery and set window of data is acknowledged before CWD to 4. Then we get two more we can send a new segment. Once we re- ACK’s for 2(due to 10,11) so once again transmit a segment, we would have to we enter fast-retransmit and re-transmit wait for atlease one RTT before we 2 and then enter fast recovery. Thus would receive a fresh acknowledgement. when we exit fast recovery for the Whenever we receive a fresh ACK we second time our window size is set to 2. Thus we reduced our window size twice and sets the number of duplicate ACKS for packets lost in one window. received to zero. Another problem is that if the widow It exits Fast recovery when all the is very small when the loss occurs then data in the window is acknowledged. we would never receive enough duplicate acknowledgements for a fast- Problems: retransmit and we would have to wait for New-Reno suffers from the fact that a coarse grained timeout. Thus is cannot its take one RTT to detect each packet effectively detect multiple packet losses. loss. When the ACK for the first re- transmitted segment is received only then can we deduce which other segment NEW-RENO: was lost. New RENO is a slight modification over TCP-RENO. It is able to detect multiple packet losses and thus is much SACK: more efficient that RENO in the event of TCP with ‘Selective multiple packet losses. Acknowledgments’ is an extension of Like Reno, New-Reno also enters TCP Reno and it works around the into fast-retransmit when it receives problems face by TCP RENO and TCP multiple duplicate packets, however it New-Reno, namely detection of multiple differs from RENO in that it doesn’t exit lost packets, and re-transmission of more fast-recovery until all the data which was than one lost packet per RTT. out standing at the time it entered fast- SACK retains the slow-start and fast- recovery is acknowledged. Thus it retransmit parts of RENO. It also has the overcomes the problem faced by Reno of coarse grained timeout of Tahoe to fall reducing the CWD multiples times. back on, incase a packet loss is not The fast-transmit phase is the same detected by the modified algorithm. as in Reno. The difference in the fast- SACK TCP requires that segments recovery phase which allows for not be acknowledged cumulatively but multiple re-transmissions in new-Reno. should be acknowledged selectively. Whenever new-Reno enters fast- Thus each ACK has a block which recovery it notes the maximums segment describes which segments are being which is outstanding. The fast-recovery acknowledged. Thus the sender has a phase proceeds as in Reno, however picture of which segments have been when a fresh ACK is received then there acknowledged and which are still are two cases: outstanding. Whenever the sender enters If it ACK’s all the segments which fast recovery, it initializes a variable were outstanding when we entered fast- pipe which is an estimate of how much recovery then it exits fast recovery and data is outstanding in the network, and it sets CWD to ssthresh and continues also set CWND to half the current size. congestion avoidance like Tahoe. Every time it receives an ACK it reduces the pipe by 1 and every time it re- If the ACK is a partial ACK then it transmits a segment it increments it by 1. deduces that the next segment in line Whenever the pipe goes smaller than the was lost and it re-transmits that segment CWD window it checks which segments are un received and send them. If there are no such segments outstanding then it acknowledgment to get back. Whenever sends a new packet. Thus more than a duplicate acknowledgement is received one lost segment can be sent in one it checks to see if the (current time- RTT. segment transmission time)> RTT estimate; if it is then it immediately re- Problems: transmits the segment without waiting The biggest problem with SACK is for 3 duplicate acknowledgements or a that currently selective coarse timeout. Thus it gets around acknowledgements are not provided by the problem faced by Reno of not being the receiver To implement SACK we’ll able to detect lost packets when it had a need to implement selective small window and it didn’t receive acknowledgment which is not a very enough duplicate Ack’s. easy task. To catch any other segments that may have been lost prior to the re- transmission, when a non duplicate VEGAS: acknowledgment is received, if it is the Vegas is a TCP implementation first or second one after a fresh which is a modification of Reno. It acknowledgement then it again checks builds on the fact that proactive measure the timeout values and if the segment to encounter congestion are much more time since it was sent exceeds the efficient than reactive ones. It tried to get timeout value then it re-transmits the around the problem of coarse grain segment without waiting for a duplicate timeouts by suggesting an algorithm acknowledgment. Thus in this way which checks for timeouts at a very Vegas can detect multipple packet efficient schedule. Also it overcomes the losses. problem of requiring enough duplicate Also it only reduces its window if acknowledgements to detect a packet the re-transmitted segment was sent after loss, and it also suggest a modified slow the last decrease. Thus it also overcome start algorithm which prevent it from Reno’s shortcoming of reducing the congesting the network. It does not congestion window multiple time when depend solely on packet loss as a sign of multiple packets are lost. congestion. It detects congestion before the packet losses occur. However it still retains the other mechanism of Reno and Congestion avoidance: Tahoe, and a packet loss can still be TCP Vegas is different from all the detected by the coarse grain timeout of other implementation in its behavior the other mechanisms fail. during congestion avoidance. It does not The three major changes induced by use the loss of segment to signal that Vegas are: there is congestion. It determines congestion by a decrease in sending rate New Re-Transmission Mechanism: as compared to the expected rate, as Vegas extends on the re-transmission result of large queues building up in the mechanism of Reno. It keeps track of routers. It uses a variation of Wang and when each segment was sent and it also Crowcroft;s Tri-S scheme. The details calculates an estimate of the RTT by can found in . Thus whenever the keeping track of how long it takes for the calculated rate is too far away from the expected rate it increases transmissions congestion avoidance and slow to make use of the available bandwidth, start algorithms measure whenever the calculated rate comes too incipient congestion and very close to the expected value it decreases accurately measure the available its transmission to prevent over bandwidth available and saturating the bandwidth. Thus Vegas therefore use network resources combats congestion quite effectively and efficiently and don’t contribute to doesn’t waste bandwidth by transmitting congestion. at too high a data rate and creating congestion and then cutting back, which 2)Reno: the other algorithms do. • More than half of the coarse- grained timeouts of Reno are Modified Slow-start: prevented by Vegas as it detects TCP Vegas differs from the other and re-transmits more than one algorithms during it’s slow-start phase. lost packet before timeout The reason for this modification is that occurs. when a connection first starts it has no • It doesn’t have to always wait for idea of the available bandwidth and it is 3 duplicate packets so it can re- possible that during exponential increase transmit sooner. it over shoots the bandwidth by a big • It doesn’t reduce the congestion amount and thus induces congestion. To window too much prematurely. this end Vegas increases exponentially • The advantages that it has in only every other RTT, between that it congestion avoidance and calculates the actual sending through put bandwidth utilization over Tahoe to the expected and when the difference exist here as well. goes above a certain threshold it exits slow start and enters the congestion 3)New-Reno: avoidance phase. • It prevents many of the coarse grained timeouts of New-Reno as it doesn’t need to wait for 3duplicate ACK’s before it retransmits a lost packet. Conclusion: • Its congestion avoidance Thus it is clear that TCP Vegas is mechanisms to detect ‘incipient’ definitely better than congestion are very efficient and 1)Tahoe: utilize nework resources much • Cause it is much more robust in more efficiently. the face of lost packets. It can • Because of its modified detect and retransmit lost packet congestion avoidance and slow much sooner than timeouts in start algorithm there are fewer re- Tahoe. transmits. • It also has fewer re-transmissions since it doesn’t empty the whole 4)SACK: pipe whenever it loses packets. TCP Vegas doesn’t have a clear cut • It is better at congestion advantage over SACK TCP. The only avoidance and its modified fields where it apprears to outperform References: SACK is: V.Jacobson. “Congestion Avoidance • In its estimation of incipient and Control”.SIGCOMM congestion, and its efficient Symposium no Cummunication estimation of congestion by Architecture and protocols. measuring change in throughput rather than packet loss. This would V.Jacobson “Modified TCp result in a better utilization of Congestion Control and Avoidance bandwidth and lesser congestion. Alogrithms”.Technical Report 30,Apr 1990. • Also it appears more stable than SACK. The reason for this being that S.Floyd, T.Henderson “The New- SACK uses packet losses to denote Reno Modification to TCP’s Fast congestion. So that the sender Recovery Algorithm” RFC 2582, continually increase sending rate Apr 1999. until there is congestion and then they cur back. This cycle continues O. Ait-Hellal, E.Altman “Analysis of and the system keeps on oscillating.. TCP Reno and TCP Vegas”. TCP Vegas flattens out its sending rate at the optimal bandwidth K.Fall, S.Floyd “Simulation Based utilization point thus inducing Comparison of Tahoe, Reno and stability. SACK TCP” . • Another advantage of TCP Vegas or L.S.Brakmo, L.L. Peterson, “TCP rather the disadvantage of SACK is Vegas: End to End Congestion that it is not very easy to incorporate Avoidance on a Global Internet”, SACK in the current TCP. We need IEEE Journal on Selected Areas in fields to acknowledge the selective Communication, vol. 13,(1465- segments and this requires changes 1490). at the receiver as well, whereas all the other mentioned algorithms only require changes at the sender side.