Transmission control protocol

Transmission control protocol Comparisons and Evaluation of TCP versions Tahoe, Reno and NewReno Abstract There is been several numbers of transmission control protocols proposed for the past several decades. These proposed TCP versions have been widely acceptable and used in packets switched network. In this paper we will present an overview of Transmission control protocol, discus different versions of transmission control protocols which are current used, explore the challenge faced when deploy these TCP versions and finally compare and evaluate these TCP versions. Index Terms Transmission control protocol (TCP), TCP Tahoe, TCP Reno, TCP Vegas, TCP NewReno, slow start, fast retransmit, fast recovery and congestion avoidance. I. Introduction Transmission control protocol (TCP) is a connection oriented protocol which was designed to facilitate reliable and secure end-to-end communication between to device in a packet switched network [1]. The reliable communication between devices is achieved by TCP through process of assigning sequence number to every packet that is transmitted and record the time used to transmit packets between source and destination, further to that, TCP protocol require Acknowledgment of receiving packets from destination host to complete communication. By using this mechanism transmission control protocol is able to detect the packet lose, damage, duplication or received out of order and be able to correct them or retransmit. Transmission control protocol also use sliding window control mechanism to control the number of packets sender device can send at one time and keep regulating this number for any further changes in a network. This is achieved by requiring the destination device to acknowledge the receiving of all packets sent by sender. This number is usually telling sender device the number of approved packets can be transmitted before get permission to increase or decrease. There are different types of transmission control protocols which were proposed in order to try to improve the transportation of packets in a packets switched network. Some of these TCP versions which were proposed are including TCP Tahoe, TCP Reno, TCP NewReno, TCP Sack and TCP Vegas. II. TCP Tahoe This is a type of TCP version which was proposed to improve the original TCP protocol which was mainly based on assumption that packets lose is only caused by congestion in the system [2][3]. The original TCP protocol used to follow go-back-n automatic repeat request model which was able to detect loss of packets from timeout, retransmit only if there is packet loss and receiver host govern the window control packet flow in order to prevent packet overflow at receiver buffer. This protocol did a little to reduce the congestion if the two end-to-end devices were in different networks or data packet are required to go through a router to get to other end or go through a slow link. In the process of trying to improve the original TCP three traffic management mechanisms slow start, congestion avoidance and fast retransmit were introduced to the original TCP and the new TCP version was named as TCP Tahoe. Slow start Most of the original transmission control protocols were used to start connection followed by sender start injecting several packets to the network until sender reaches the window size allowed by receiver [4]. This approach can work fine if end-to-end devices are within a single Local Area network but in a fast and slow link network with multiple local area networks this approach can encounter problems which may resulted into rapidly reduction of TCP connection network throughput. In order to avoid these problems of throughput reduction slow start mechanism is used in a TCP Tahoe. Slow start operating mode always starting injecting packets into a network with window size of initial value of one then waits for its acknowledgement before increases its window size value. When sender receive the acknowledgement that the packets was received by destination then it increase its congestion window to two and send two packets, if acknowledgement received for these two packets, sender increase its congestion window size to four. Slow start mechanism keep increases its window size every time it receive its acknowledgement of previous sent packets exponentially until it reaches its maximum threshold value and enter congestion avoidance mechanism. By using slow start mechanism TCP Tahoe reduce the rate of congestion in a network. Congestion Avoidance Congestion Avoidance (CA) is another control mechanism used by TCP Tahoe to gently inspect the network for spare capacity [5]. TCP Tahoe enters into congestion avoidance mode when the value of congestion window size is greater than the value of slow start threshold otherwise TCP Tahoe continues working in a slow start mode. If packets loss is detected in the network then TCP Tahoe algorithm will automatic assume there is congestion somewhere in the network, using this assumption TCP Tahoe change its slow start threshold value to half of its current value and set the congestion window size to its initial value and start slow start again. Slow start and congestion avoidance are two independent algorithms with each have their own objectives; but when congestion occurs in the network TCP Tahoe is required to slow down its rate of sending packets into the network by call upon the slow start mode of operation to get thinks going again. Fast retransmit One of the problems with TCP timeout-triggering retransmission mechanism is that the timeout period can be relative long. Subsequently if there is any packet loss in the network, it will take long period of time before sender retransmit the loss packets hence increases end-to-end delay [6]. In order to solve this long timeout period retransmission problem TCP Tahoe uses fast retransmit mechanism to resend any loss packets. It doing so by allowing sender to use so called duplicate Acknowledgements to detect packet loss well before the timeout event occurs. Fast retransmit operating mode in a TCP Tahoe can be triggered when three or more duplicate Acknowledgments are received by sender in a row. If this occurs then TCP Tahoe will perform retransmission of what is assumed to be missing packets without the need to wait for packets retransmission time to expire. During this period of fast retransmit TCP Tahoe adjust its slow start threshold to half of current value and enters the slow sta rt mode of operation and set the congestion window back to its initial value of one. TCP Tahoe problems Due to automatic set back to slow start mode of operation with initial congestion window of one every time packet loss is detected we see TCP Tahoe does not prevent the communication link from going empty. Hence this may have high cost in high bandwidth product links. III. TCP Reno TCP Reno has all three mode of operation integrated into TCP Tahoe like slow start, congestion avoidance and fast retransmit, but in addition to that TCP Reno modify the fast retransmit mode of operation to form fast recovery mode of operation[7]. TCP Reno enters into fast recovery mode of operation when sender receiving three duplicate acknowledgments. Fast recovery operates by assuming congestion is serious in a network if the packets loss is detected due to timeout. If this is true then fast recovery mode set TCP Reno congestion window size to its initial value and enters into slow start mode of operation. But if the congestion is detected due to duplicate acknowledgements then TCP Reno assume the network congestion is not serious. If this is true fast recovery mode set TCP Reno congestion window size to half of its current value and enters congestion avoidance operating mode instead of slow start mode. By entering congestion avoidance mode of operation TCP Reno prevent the commun ication link from going empty after packet loss by avoiding slow start. TCP Reno problems TCP Reno only performs better when there is single packet drop from window of data, because it cannot detect multiple packets drops from single window of data. Due to this if there is multiple packet loss from single window of data then TCP Reno is required to wait for timeout to retransmit the second packet which has been lost, subsequently TCP Reno over high packet loss network does not perform well, it almost works just like TCP Tahoe. IV. TCP NewReno TCP Reno has all the key algorithms found in TCP Reno but in addition to these algorithm TCP NewReno modify the fast recovery algorithm in order to solve the problems of TCP Reno of not be able to detect multiple drop of packets in a single data window [8]. TCP NewReno enters fast recovery mode of operation just like TCP Reno when it receive 3 duplicate acknowledgement, but unlike TCP Reno, TCP NewReno does not exit from fast recovery mode of operation until all the packets which are not acknowledge by the time fast recovery was entered are acknowledged. After receiving acknowledgments of all outstanding packets TCP exit fast recovery mode of operation and set congestion window size to its initial value and finally enters the congestion avoidance mode of operation to get thinks going again. TCP NewReno problems TCP NewReno suffers from the fact that it is taking one round trip time (RTT) to detect each packet loss. Therefore TCP NewReno can only work out which other packet have been lost when sender receive the acknowledgement of first retransmitted packet. V. TCP SACK TCP Reno only work better when there is single loss of packets in a single data window and does not work better when multiple packets get dropped in a single data window without going into timeout retransmission. TCP Sack was implemented in order to solve this problem by improve retransmission efficient when multiple packets losses occurs [9] [10]. It is doing this by introducing Sack option field in a TCP Sack which is used to report out of order block of data which have been received correctly by destination device. Therefore instead of retransmit all non acknowledgment packets TCP Sack retransmit only packets which are missing. Similar to TCP Reno, TCP Sack enters fast retransmit mode of operation when sender receive three duplicate acknowledgements. The sender in TCP Sack retransmits packet losses then reduces its congestion window to half before exit fast recovery only when it receive acknowledge that all outstanding data packet have been acknowledged. VI. TCP VeGAS TCP Vegas is one of the most sophisticated transmission control protocol which uses packets delay to determine the rate at which sender send packet rather than using packet loss as discussed in TCP Tahoe, Reno, and NewReno [11]. It uses the initial increase packets Round Trip Time value to detect the congestion in the system instead of using packets loss. TCP Vegas achieve this by using the following techniques. * More Accurate Round Trip Time (RTT) Calculation * New mechanism for deciding when to retransmit * Modified congestion window sizing mechanism * Modified congestion detection and avoidance mechanism VII. SIMULATIONS In this section we are going to simulate small network using different TCP versions in order to evaluate their performance and see their actual difference between them. The simulation will be carried out between two fast network nodes connected via a slow link. The diagram below shows all the link bandwidth capacity and delays. Source Destination (0)- (1) - (2) - (3) 10Mbps 6ms 1Mbps 10ms 10Mbps 6ms From the diagram above packets was sent from network node 0 to network node 3 via node 1 then node 3 and finally arriving at destination node 3. Tiny acknowledgement packets then were sent back to receiver via the reverse route. Expected bottleneck was form between node 1 and node 2 due to different link speed between node 0 and node 3. The queue discipline used in our simulation was DropTail with the maximum queue size of 8 packets. The simulation also was set to support one way traffic from node 0 to node 3 therefore tiny acknowledgments packets were expected not to be discarded on their way back to sender from receiver. This simulation is intended to support evaluation of TCP traffic control mechanisms such as slow start, congestion avoidance fast retransmit and fast recovery. The simulation was run for 10.5 seconds and the following value was recorded every 1 second and observed throughput in (Mbps) and window size as a function of time. After finish running this simulation gnu-p lot tool was used to display the following results. TCP Tahoe Results From the two diagrams above we see from 0 seconds to 2 seconds TCP Tahoe was in slow start mode of operation, when it got to about 0.4 seconds we see the first packet loss occurs and immediately TCP Tahoe reset its congestion window size to half of its current size (see 3). We also observe the throughput reduced to almost zero when packet loss occurs this is because when packet loss happens TCP Tahoe is required to stop sending packets and go back to slow start phase before start sending packets again hence no transmission. We also see from 2 second onwards TCP Tahoe enters congestion avoidance mode of operation, whereby TCP Tahoe allow the congestion window size to increase exponentially until packet loss occur then go back to slow start mode to start transmission again. TCP Reno Results In 4 and 5 we see TCP Reno enters congestion avoidance mode of operation with fast retransmission from 2 to 10 seconds but at 0.4 second we TCP Reno enters fast retransmission then at 0.6 second come out of fast retransmission and go back to slow start mode of operation which is the same as TCP Tahoe this is because TCP Reno cannot detects more than two one packet loss in a single data window. We also see every time packets loss happens throughput is reduced to almost zero, this is because of the same reason explained above. TCP NewReno Results 6 and 7 show that TCP NewReno enters fast retransmission/ fast recovery mode due to packets loss which occurs around 0.4 seconds and never come out of this mode of operation because it was able to detect multiple packets loss in single data window unlike TCP Reno. But from 2 seconds onwards TCP NewReno behaves the same as in TCP Reno. TCP Sack Results 8 and 9 also show TCP Sack is preventing the communication path from not going empty after packets loss happens at 0.4 seconds by entering fast retransmission mode of operation and not come out until all packets sent in a single data window acknowledge. TCP Sack works the same as TCP NewReno but use selective acknowledgment to retransmit the loss packets. TCP Vegas Results In 10 and 11 we see TCP Vegas manage to achieve the network high bandwidth this is because TCP Vegas uses sophisticated traffic control algorithms to anticipate the congestion of the link rather than reacting to congestion. We also see at 0.1 second TCP Vegas enters slow start mode of operation and packet loss start occurring around 0.6 immediately after packet loss detected TCP Vegas set its window size to 8 packets and at the same time reduce its throughput to 0.5Mbps. From 1 to 10 seconds we see TCP Vegas maintain steady congestion window size of 8 packets and the throughput was increased to 1Mbps which was the maximum throughput set for our simulation. VIII. CONCLUSION In this paper we present an overview of different TCP versions, discuss different traffic control algorithms used by different TCP versions and discuss in general what TCP is. We see these TCP versions perform different depending to network environments. We see TCP Tahoe and TCP Reno perform better when network environments are not of high loss packets while TCP Sack was slight perform better than TCP Tahoe and TCP Reno. We also see TCP Vegas was one of the best TCP Version compare to all versions discussed in this paper. In our simulation we see TCP Vegas was able to reach the maximum throughput and maintain this state for more than 8 seconds of our simulation, this is because TCP Vegas is much more robust over loss packets network and it can detect and retransmit loss packets much earlier than others. The work presented in this paper provides a means of compare and evaluate different transmission control protocol versions. References [1] DARPA, RFC793-Transmission Control Protocol, 1981, cited 6 November 2008, available from http://www.faqs.org/rfcs/rfc793.html. [2] B.Sikdar, S. Kalyanaraman, K.S.Vastola, Analytic Models for Latency and steady-state throughput of TCP Tahoe, Reno, and Sack, 2003 pp 959-971, cited 4 November 2008, available from http://delivery.acm.org.ezproxy.kingston.ac.uk/10.1145/970000/966005/p959-sikdar.pdf?key1=966005key2=4143536221coll=ACMdl=ACMCFID=9935467CFTOKEN=88833439 [3] DARPA, RFC793-Transmission Control Protocol, September 1981, cited 6 November 2008, available from http://www.faqs.org/rfcs/rfc793.html [4] W.Stevens, RFC-TCP Slow Start, Congestion Avoidance, Fast Retransmit. Network Working Group, January 1997, cited 6 November 2008, available from http://www.faqs.org/rfcs/rfc2001.html [5] W.Stevens, RFC-TCP Slow Start, Congestion Avoidance, Fast Retransmit. Network Working Group, January 1997, cited 6 November 2008, available from http://www.faqs.org/rfcs/rfc2001.html [6] James F.Kurose, Keith W.Ross, Computer Networking: A Top down Approach, 3rd ed. Boston, Pearson, 2004. [7] M. Allman, V.Paxson, W.Stevens, RFC2581-TCP Congestion Control. Network Working Group, April 1999, cited 3 November 2008, available from http://www.faqs.org/rfcs/rfc2581.html [8] S.Floyd, T.Henderson, RFC2582 -The NewReno Modification to TCPs Fast Recovery Algorithm, Network Working Group, April 1999, cited 1 November 2008, available from http://www.faqs.org/rfcs/rfc2582.html [9] M.Mathis, J.Mahdavi, S.Floyd, A.Romanow, RFC2018 -TCP Selective Acknowledgements Options, Network Working Group, October 1996, cited 1 November 2008, available from http://www.faqs.org/rfcs/rfc2018.html [10]Kelin Fall, Sally Floyd, Simulation-based Comparisons of Tahoe, Reno and SACK TCP, Vol.26 No.3,July 1996, cited 31 October 2008, page 5-21; available form http://delivery.acm.org.ezproxy.kingston.ac.uk/10.1145/240000/235162/p5-fall.pdf?key1=235162key2=9083536221coll=ACMdl=ACMCFID=9935467CFTOKEN=88833439 [11] S.Brakmo, L.L. Peterson, TCPVegas: End to End Congestion Avoidance on a Global Internet, vol. 13, 1995 page pp 1465-1490, available from http://delivery.acm.org.ezproxy.kingston.ac.uk/10.1145/200000/190317/p24-brakmo.pdf?key1=190317key2=8457936221coll=ACMdl=ACMCFID=9935467CF