Comparative Performance Evaluation of TCP with Identical and Cross ...

International Journals of Advanced Research in Computer Science and Software Engineering ISSN: 2277-128X (Volume-8, Issue-1) a

Research Article

January 2018

Comparative Performance Evaluation of TCP with Identical and Cross-Variant Congestion Control Nahida Nigar* Lecturer, Department of Computer Science & IT, Southern University Bangladesh, Chittagong, Bangladesh [email protected]

Abstract— The Transmission Control Protocol (TCP), a key functional building block of the Internet, operates as a rate-adaptive end-to-end protocol at the Transport Layer of the network protocol stack. It regulates the prevailing load conditions within the network by getting the source node to adapt the packet transfer rate in accord with the processing capacity of the receiver. The regulation is enforced by means of dropping of packets on the part of the receiver. The TCP sender then reduces the packet injection rate so as to allow the network to recover from congestion. The focus of this paper is performance evaluation of certain notable TCP congestion avoidance algorithms, namely, Vegas, Reno and New Reno. Specifically, a number of performance measures have been analysed based on ns-2 simulation data where the scenarios involved TCP flows operating with identical and cross-variant congestion control mechanisms. Congestion window behaviour, packet loss, throughput, transmission delay and jitter are the performance criteria studied with the setup mentioned. In the flows with identical variants, Vegas outperforms other TCP variants. However, TCP Vegas has been observed to contribute to unfair appropriation of the resources in the cross-variant setting. Keywords— TCP; TCP Vegas; TCP Reno; TCP NewReno; Heterogeneous Network; Congestion Control I. INTRODUCTION Transmission Control Protocol is a widely used connection-oriented transport layer protocol which provides a reliable packet delivery over an unreliable network. Originally flow control of TCP was governed simply by the maximum allowed window size, advertised by the receiver and the policy that allowed the sender to send new packets only after receiving the acknowledgement for the previous packet. There has been a significant amount of research toward modelling variants of the Transmission Control Protocol (TCP) in order to understand the impact of this protocol on file transmission times and network utilization. TCP uses a network congestion avoidance algorithm that includes various aspects of an additive increase/multiplicative decrease (AIMD) scheme, with other schemes such as slow-start in order to achieve congestion avoidance. Among these TCP variants, TCP Vegas claims to have a better throughput [4]. Like other TCP congestion control algorithm, Vegas is purely a sender-side algorithm. TCP Vegas uses bandwidth estimation scheme to avoid congestion rather than waiting for congestion to happen to invokes its congestion control mechanism [5]. Like other TCP variants, TCP Vegas control the amount of data injected into the network by using two phases: slow start and congestion avoidance. TCP Vegas reduces queuing and packet loss, and thus reduces latency and increases overall throughput, by carefully matching the sending rate to the rate at which packets are successfully being drained by the network [12]. This paper simulates a computers network with TCP flows on simulation topology. Evaluation using simulation in specified network topologies helps understand the dynamics of the associated parameters in connection with TCP performance. The simulation of the network gives a better perspective on network functionality. With simulations help it is easier to reveal architecture and parameters influence on the network’s behaviour. The previous studies [13] show the performance issue of TCP variants only on the basis of throughput and throughput fairness. This paper studies the network behaviour both in identical and cross-Variant congestion control in wired network. For these, not only throughput but also different performance criterions are considered to evaluate the performance of TCP Vegas, TCP Reno and TCP New Reno. One of the contributions in this paper is to show the network behavior through different performance criterion such as congestion window behaviour, packet loss, average throughput and transmission delay, jitter rate of TCP Variants in such a situation where they share the bottleneck link with TCP variants both in identical and cross-Variant wired network. © www.ijarcsse.com, All Rights Reserved

Page | 163

Nigar, International Journal of Advanced Research in Computer Science and Software Engineering 8(1) ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 163-171 Using Awk tool, simulations results can be easily analysed. The results of the simulation are evaluated and analysed and their behaviours are shown by means of graphical manner which will help in future to design more complex and large networks. In 1994, Lawrence S. Brakmo et al. [11] had proposed a new TCP algorithm called TCP Vegas. In their paper, it has been reported [11] that TCP Vegas was able to achieve 37% to 71% better throughput than TCP Reno on the Internet. It also retransmitted between 1/5 and 1/2 as much data as TCP Reno did, both in simulations and in live wide-area Internet measurements. Therefore, it was implied [11] that the improvement in throughput was not achieved by an aggressive retransmission strategy that stole bandwidth from the competing TCP connections. Instead, the improvement in performance was achieved by a more efficient use of the available bandwidth through reduced packet losses and reduced retransmissions. At the end of the paper, the authors also argued that TCP Vegas was at least as fair as TCP Reno was. However, this is only true when TCP Vegas is implemented in identical network. When TCP Vegas is implements in varying network, the performance of TCP Vegas degrades. The previous studies [4] [8] [9] [13] show that competing with other TCP variants, TCP Vegas achieves better throughput. However, this is only true in an identical network that fully involves TCP Vegas. In a heterogeneous network, TCP Vegas performance degrades. TCP Reno and TCP NewReno are more aggressive than TCP Vegas. TCP Vegas was unable to achieve fair bandwidth allocation in Cross-Variant network connection. A.D. Vendictis et al. [9] evaluate the performance of the TCP Vegas behaviour in a heterogeneous network. From their study, they conclude that the fairness of TCP Vegas and TCP Reno cannot be achieved. Although a number of performance criteria have been ignored in the previous studies [4] [8] [9] [13]. This simulation has been done to prove that not only throughput but also other performance criteria have a great impact on the performance of TCP Variants. As like as Reno, the fairness of TCP Vegas and TCP NewReno cannot be achieved. The rest of the paper is organized as follows: Simulation scenarios and parameters are discussed in section II, Simulation results are evaluated and analysed in section III, Concluding statement in section IV. II. SIMULATION WITH NS2 The simulation tool used for this experiment is ns-2 [7]. The simulation has been developed to emphasize the impact on TCP variants. We have used a simple simulation scenario where two FTP connections share a bottleneck link. Simulation is conducted to yield (trace) data. That data is analyzed to obtain certain metrics. The following quantities have been calculated from the trace file: Total transmitted bits and lost packets, jitter rate, average throughput, average end-to-end transmission delay and queuing transmission delay. The simulations have been performed only in a particular case when the background traffic is FTP. For our experiment, we emulate the topology presented in figure 1. Nodes 1 and 2 are used as source and node 4 is used as destination. Packets are lost due to congestion at node 3. To induce congestive loss by adjusting the maximum window size, this simple network can be used (e.g., the receiver's advertised window) for the TCP source at node 1 (i.e., S1 or S2). The link between the TCP senders and node 3 is called as the sender link. The link between node 3 and node 4 is called the bottleneck link. The sender links and the receiver links are a full wired duplex link. The starting time for second flow at node 2 is 10second later than the first flow.

Figure 1: Simulated Topology A. Simulation scenarios The simulation environment is shown in Table I. © www.ijarcsse.com, All Rights Reserved

Page | 164

Nigar, International Journal of Advanced Research in Computer Science and Software Engineering 8(1) ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 163-171 TABLE I. SIMULATION ENVIRONMENT Case Sender (Node 1) Sender (Node 2) 1 Vegas Vegas 2 Reno Reno 3 NewReno NewReno 4 Vegas Reno 5 Vegas NewReno In this simulation experiment, the performance of TCP Variants in identical and cross-variant wired network is evaluated. In identical network, both TCP sender implements the same TCP Variant. In identical wired network three cases are considered in simulation experiment as shown in Table I. The performance of TCP variants in identical network is evaluated in order to analyse the network behaviour. For cross-variant network, we set TCP Vegas as the TCP variant on the sender side of the flow 1. For flow 2, the TCP variant on the sender side is varied. There are two cases considered in the simulation experiments of cross-variant wired network: Vegas/Reno and Vegas/NewReno. TCP Sink is used for the receiver side. The simulation parameters of the network topology are showed in Table II. TABLE II. SIMULATION PARAMETERS

Packet Size Bottleneck link bandwidth Access link bandwidth Queue type Queue limit Access link delay Bottleneck link delay Maximum Window Size

1000 byte 1 Mbps 2 Mbps Drop Tail 30 10 ms 10 ms 30

III. SIMULATION RESULTS AND DISCUSSION In this section, we present the simulation results. In identical network, performance of TCP Vegas is much better than any other TCP variants. On the other hand, when TCP Vegas sender shares the link with TCP Reno and TCP NewReno sender, Vegas decreases its performance. A. Congestion Window behaviour In Fig. 2, Fig. 3 and Fig. 4, congestion window behavior of TCP Vegas, is very different if compared with other variants, because Vegas does not wait for loss to trigger congestion window (cwnd) reductions and keeps track of the time each segment is sent. This concept is employed in Vegas to determine whether the window should be decreased or increased. In Fig. 2, Fig. 3 and Fig. 4 show the congestion window behavior for the TCP variants. Though the second flow starts 10 sec later, the congestion window is greater than the first flow for TCP Vegas. The congestion window for first flow decreases, when the second flow starts.

Figure 2: CWND for two flows in Vegas/Vegas © www.ijarcsse.com, All Rights Reserved

Page | 165

Nigar, International Journal of Advanced Research in Computer Science and Software Engineering 8(1) ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 163-171

Figure 3: CWND for Vegas (flow 1) and Reno (flow 2)

Figure 4: CWND for Vegas (flow 1) and New-Reno (flow 2) From Fig. 2, Fig. 3 and Fig. 4, it can also be seen that congestion window size in cross-variant network is minimum for TCP Vegas comparing with two other variant, as it does not wait for loss to trigger congestion window reductions. But TCP Reno and NewReno wait for loss to trigger congestion window reduction. B. Packet loss From Table III, we can see that for identical network connection there is not even a single packet that has been dropped for TCP Vegas but there are certain packets in TCP Reno and TCP New-Reno that has been dropped. It is because Vegas pro-actively detect congestion in its incipient stages, and then reduce throughput in an attempt to prevent the occurrence of packet losses where for both Reno and NewReno needs to create losses to find the available bandwidth of the connection. But in varying network connection packet drop is detected. Figure 5, 6 shows the packet drop behavior of TCP Reno and NewReno. TABLE III. PACKET LOSS

Simulation Environment Vegas/Vegas Reno/Reno NewReno/NewReno Vegas/Reno Vegas/NewReno © www.ijarcsse.com, All Rights Reserved

Packet Sent 1588 296 302 2015 2105

Dropped Bit 0 16640 16640 2080 2080

Lost Packet 0 16 16 2 2 Page | 166

Nigar, International Journal of Advanced Research in Computer Science and Software Engineering 8(1) ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 163-171

Figure 5: Packet drop behaviour of TCP Reno

Figure 6: Packet Drop behaviour of TCP NewReno C. Average Throughput and Transmission Delay In the identical network, the performance of TCP Vegas is better than other TCP variants. The average throughput of TCP Vegas outperforms the other two TCP variants. By measuring the end-to-end delay, the source can detect an impeding collapse and take measure to reduce the traffic before the collapse happen. TCP Vegas uses delay as congestion indication. The average delay experienced by TCP Vegas is the lowest among the other two TCP variants (Table V). The lower the delay, the faster the packets of data can be transmitted to the destination which improves the efficiency of the network. From Fig. 7, Fig. 8 and Fig. 9, it can be seen that delay between packets is less for TCP Vegas, delay curves for TCP NewReno and TCP Reno respectively are higher.

Figure 7: TCP Vegas/Vegas e2e transmission delay © www.ijarcsse.com, All Rights Reserved

Page | 167

Nigar, International Journal of Advanced Research in Computer Science and Software Engineering 8(1) ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 163-171

Figure 8: TCP Vegas/Reno e2e transmission delay

Figure 9: TCP Vegas / NewReno e2e transmission delay For cross-variant network, the average throughput fairness of TCP Vegas when sharing the bottleneck link with other TCP Variants is analysed. For all the simulation experiments, TCP Vegas achieves better throughput compared with TCP Reno and TCP NewReno (Table IV) at receiving end. TCP Vegas receives the most unfair throughput when it is sharing the bottleneck with cross-variant network. Here, From Fig. 12 and Fig. 13, we can see that the NewReno flow, which starts 10sec later are more aggressive, using a larger fraction of the available buffer space than the Vegas flow which starts earlier at 1sec. The result is that the NewReno flow has higher throughput (Figure 13) and also suffers more losses. The Reno flow has consistently worse performance than the other two, mainly due to the increased number of time outs that it experiences. Though TCP Reno and TCP NewReno starts 10sec later in simulation scenario, prevail most of the available bandwidth of the bottleneck link and being the most unfair to TCP Vegas. From the graph below (Figure 10-14), we can find out that throughput is more consistent for TCP Vegas in identical network rather than TCP Reno and TCP NewReno. After TCP Vegas, it is high for TCP NewReno and then for TCP Reno. From Table IV, we can also see that Vegas causes’ unfair distribution of throughput due to inaccurate measures of baseRTT, which is the minimum recorded RTT. In cross-variant network connection, The TCP Reno/NewReno connection uses most of the buffer space and TCP Vegas backs off, interpreting this as a signal of network congestion. Also there is unfairness between TCP Vegas connections. The Connection that starts up later could observe a larger RTT, causing the congestion window to be lower. Here, from table IV, we can also see that average throughput for second flow (node 2 to 4), which starts at 10 s during simulation have higher throughput than the first flow, i.e., flows which started later are getting higher priority for Vegas connection. But for Reno and NewReno average throughput for first flow have higher than the second flow, i.e. first flow is occupying most of the available bandwidth of the bottleneck link and thus, the second flow getting lower throughput. © www.ijarcsse.com, All Rights Reserved

Page | 168

Nigar, International Journal of Advanced Research in Computer Science and Software Engineering 8(1) ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 163-171 TABLE IV. AVERAGE THROUGHPUT (KBPS)

Simulation Environment Vegas/Vegas Reno/Reno NewReno/NewReno Vegas/Reno Vegas/NewReno

Throughput for node 1 to node 4 (Kbps) 566.593 919.253 917.56 432.281 409.46

Simulation Environment Vegas/Vegas Reno/Reno NewReno/NewReno Vegas/Reno Vegas/NewReno

Average end-to-end transmission delay (sec) 0.0344036 0.123587 0.123822 0.0436504 0.0450174

Throughput for node 2 to node 4 (Kbps) 634.577 116.711 119.165 827.624 864.979

Average Throughput (Kbps) 1201.17 1035.964 1036.725 1259.905 1274.439

TABLE V. AVERAGE TRANSMISSION DELAY

Average queuing transmission delay (sec) 0.0647404 0.235081 0.235536 0.157761 0.16668

Total Transmitted bits 29320000 29378560 29378560 29235200 29311680

Figure 10: Throughput for TCP Vegas/Vegas

Figure 11: Throughput for TCP Reno/Reno © www.ijarcsse.com, All Rights Reserved

Page | 169

Nigar, International Journal of Advanced Research in Computer Science and Software Engineering 8(1) ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 163-171

Figure 12: Throughput for TCP NewReno/NewReno

Figure 13: Throughput for TCP Vegas/NewReno

Figure 14: Throughput for TCP Vegas/Reno D. Jitter A variation in packet transit delay is known as jitter which is caused by queuing, contention and serialization effects on the path through the network. In general, higher levels of jitter are more likely to occur on either slow or heavily congested links. Lots of variation is indication of problem. It often indicates bandwidth saturation (congestion) when not enough bandwidth to handle the traffic loads. Jitter for two FTP flow is given in Table VI. From table we can see that, in identical network, variation is lower for TCP Vegas than other TCP variants. In cross-variant network, for flow 1and flow 2 at sending side TCP Vegas received the most unfair variation compared with TCP Reno and TCP NewReno. © www.ijarcsse.com, All Rights Reserved

Page | 170

Nigar, International Journal of Advanced Research in Computer Science and Software Engineering 8(1) ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 163-171 TABLE VI. JITTER RATE

Simulation Environment Vegas/Vegas Reno/Reno NewReno/NewReno Vegas/Reno Vegas/NewReno

Flow 1 (FTP) 0.11 2.54 2.54 0.63 0.66

Flow 2 (FTP) 0.07 2.37 2.37 0.41 0.43

IV. CONCLUSIONS The simulation experiments here, analyze the performance of TCP variants in term of congestion window behavior, packet loss, average throughput, throughput fairness, average transmission delay and jitter rate in identical and crossvariant wired network. After analyzing the performance from simulated data and depicted figures, we found that TCP Vegas can obtain better performance than any other TCP variants for sending data and information in identical wired network. However, TCP Vegas sender decreases its performance in cross-variant wired network. In essence, according to the window size of sending packets of observed RTTs, TCP Vegas dynamically increase or decrease transmission of data, whereas TCP Reno and NewReno continue to increase their window size until packet loss is detected. For future work, we aim to optimize the network congestion using intelligent agent. REFERENCES [1] M. Allman, V. Paxson, and W. Steven, “TCP congestion control,” RFC 2581, Apr. 1999. [2] C. Samios and M. Vernon. “Modeling the throughput of TCP Vegas”. In Proc. of ACM Sigmetrics, pages 71-81, Jun. 2003. [3] J. Postel, “Transmission Control Protocol Darpa Internet Program Protocol Specification”, Request of Comment 793, Internet Engineering Task Force, September 1981. [4] L. S. Brakmo, L. L. Peterson, “TCP Vegas: End to End Congestion Avoidance on a Global Internet”, In the Proceedings of IEEE Journal On Selected Areas In Communications, 13(8), 1995. [5] L. L. Peterson, S. H. Low and L. Wang, “Understanding Vegas: A duality model”, Journal of the ACM Transactions on Networking,vol.49, no.2, pp 207-235, March 2002. [6] C. Y. Ho, Y. C. Chan, Y. C. Chen, “An Enhanced Slow-Start Mechanism for TCP Vegas”, in the Proceedings of the 11th IEEE International Conference on Parallel and Distributed Systems (ICPADS’05), vol. 1, pp. 405-411, July 2005. [7] Ns-2 simulator [Online]. Available: http://www.isi.edu/nsnam/ns. [8] Postel, J., "Transmission Control Protocol," RFC 793, September 1981. [3] Jacobson, V., Braden, R., and Borman, D., "TCP Extensions for High Performance," RFC 1323, May 1992. [9] A. D. Vendictis, A. Baiocchi, M. Bonacci, “Analysis and Enhancement of TCP Congestion Control in a mixed TCP Vegas and TCP Reno Network Scenario”, Performance Evaluation 53, pp. 225-253, 2003. [10] C. M. Tsang, K. C. Chang, “A Simulation Study on the Throughput Fairness of TCP Vegas”, In the Proceedings of the 9th IEEE International Conference on Networks, vol. 21, pp.469-474 , Oct. 2001. [11] L. S. Brakmo, S. W. O'Malley, and L. L. Peterson. “TCP Vegas: New techniques for congestion detection and avoidance”. In SIGCOMM 94, London, UK, Sept. 1994. [12] Ghassan A. Abed*, Mahamod Ismail and Kasmiran Jumari,”Characterization and observation of (transmission control protocol) TCP-Vegas performance with different parameters over (Long term evolution) LTE networks,” Scientific Research and Essays, vol. 6, pp. 2003-2010, 2011. [13] Ong, Bi Lynn, R. Badlishah, and Prof Madya Dr Ahmad. "Performance evaluation of TCP Vegas versus different TCP variants in homogeneous and heterogeneous wired networks." (2011). [14] S. Floyd and T. Henderson. “The NewReno modification to TCP's fast recovery algorithm,” RFC 2582,April 1999. Also see http://www.aciri.orglfioydltcp_small.html.

© www.ijarcsse.com, All Rights Reserved

Page | 171