Experimented Goodput Measurement of Standard TCP Versions over Large-Bandwidth Low-Latency Bottleneck
Content
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG
212
Experimented Goodput Measurement of Standard TCP Versions over Large-Bandwidth Low-Latency Bottleneck
Ghassan A. Abed, Mahamod Ismail, and Kasmiran Jumari
Abstract—Goodput of Transmission Control Protocol (TCP) is the number of useful data bits, transferred by the network elements to a certain destinations, per unit of time. In communications networks, network layer, transport layer, and occasionally data link layer protocol overhead is involved in the throughput, but is excluded from the goodput. Goodput is constantly lesser than the throughput where the throughput means the gross bits rate which is physically transmitted, that mostly is lesser than network access connections rapidity (the link bandwidth or the link capacity). In other side, TCP flow control, congestion avoidance, and slow-start may possibly cause a poorer goodput than the maximum throughput. This article provide an experimented results to the goodput measurement for six TCP source variants, Tahoe, Reno, Newreno, Sack, Fack, and Vegas. The goodput analysis based on using a specific network topology with large-bandwidth and low-latency bottleneck using Network Simulator 2 (NS-2). The obtained results showed the huge differences among the measured goodput for these TCP’s. Index Terms— Goodput, TCP, NS-2, MSS.
——————————
——————————
1 INTRODUCTION
G
OODPUT is defined as the sum of single packets delivered to a finale host in a given time period, as opposed to the overall number of packets transferred in a given time period that includes the retransmitted packets. The rationale behind measuring the goodput is that the end operators of TCP flow are concerned with transferring single packets and do not care about the number of retransmissions cycles executed by the TCP source [1]. Let's say, if a file is transmitted, the goodput that the operator experiences correspond to the size of file in bits divided by the file transferring period of time. Through the previous two decades, several of mechanisms were proposed to enhance the standard TCP versions, Tahoe and Reno. Afterward Jacobson [2] introduced the his algorithm of congestion control, then TCP development grow into actual dynamic and many algorithms have been assumed for congestion control to enhancing the stability, and bandwidth sharing among flows over wired and wireless networks. Actually, currently TCP is not fit appropriate for wireless networks due to losses resulted from using radio channels and the problems are misread as indication of congestion by recent TCP structures and leading to an unnecessary decreasing of the transmission rate. Therefore, TCP needs additional connection layer protocols like using split connections or reliable link layer approach to professionally work in wireless links [3].
————————————————
• Ghassan A. Abed is PhD candidate in Department of Electrical, Electronic, and Systems Engineering Faculty of Engineering and Built Environment, National University of Malaysia, UKM. • Prof. Dr. Mahamod Ismail is with Faculty of Engineering and Built Environment, National University of Malaysia, UKM. • Prof. Dr. Kasmiran Jumari is with Faculty of Engineering and Built Environment, National University of Malaysia, UKM.
In the last years, computer networks and mobile cellular systems have qualified incredible evolution and a lot of computers and other user equipment’s become linked together with most mutual protocol stack used being TCP. Currently, it is hard to recognize the congestion control mechanisms that are applied by different engines in Internet. The header of TCP does not deliver any facts for them. One more imperative problem is the manner that these mechanisms are employed in diverse operating systems [4]. The greatest universal transport protocol involved is the TCP and in the original accomplishment of TCP, a very small number of variants were done to minimalize the congestion in network path. Employment used accumulative confident acknowledgements and the expiration of a retransmission timer to afford reliability based on a modest go-back-n model. Some successive variants of TCP grounded on the mechanisms of congestion control and avoidance have been proposed and established [5]. The object beyond the differences of TCP is that every variant takes certain singular principles. The prime TCP has been called by TCP Tahoe. While TCP Reno complements new technique to improve congestion control of Tahoe, this mechanism called fast recovery. The newest retransmission algorithm was added to Reno to get new TCP termed as Newreno. Fack TCP is a Reno but uses forward acknowledgment technique. The usage of Sacks allows to the receiver to indicate some extra segment that received with non-order during single duplicate ACK, while TCP Vegas assumes its individual exclusive approaches for congestion control [6].
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG
213
TCP congestion control algorithms are the leading object to using the networks applications successfully in spite of source bottlenecks and mostly impulsive the access patterns of users. TCP Reno, Sack, Tahoe, Newreno, Fack and Vegas, are represent the source TCP variants and each variants support different congestion control algorithm. The base of TCP congestion control is grounded on Additive Increase Multiple Decrease (AIMD) algorithm, by halving the window size when congestion window having a loss in packet, and growing the window in one segment for every Round Trip Time (RTT). The second module of congestion control is the retransmission timer, containing the exponential bake-offs of the retransmit timer if the packet that retransmitted is dropped. The third essential module is the slow-start mechanism for the primary exploratory for existing bandwidth. The other congestion control mechanism is the clocking of ACK. Everywhere the acknowledgments arrived to the sender is used to clock-out the transmission for the new next packet. The TCP source variants discussed here, where all share the many features like slow-start, except TCP Vegas, and all follow to the fundamental basis of slow-start, AIMD, retransmit timers, and clocking of ACK.
If the congestion window has constant value, the ACK timing of the sent packets will depend on the ACK of the first set of packets (early packets). TCP sliding window depend on ACK clock which calculate the sender flow rate and when RTT changed with different values, the sliding window will determine the mean sending rate of complete window per average RTT. The transmission window size controlled by dependence on the ACKs received each RTT and these parameters indicate the general differences between TCP versions. The main function of TCP window control is to obtain high packets rate with minimum losses by avoiding network overloading in the same time to provide optimum sharing to the network bandwidth among connections. The optimum bandwidth sharing can changed because the varying amounts of overcrowding between traffics over the network, also it because the varying in network itself like the updates in routing or the time-varying capacity over radio links [9]. TCP Tahoe and TCP Reno are mostly applied over many wireless applications because of the effective congestion control mechanisms. These mechanisms provide varying in size of congestion window depending on ACK status, thus when packets acknowledged the window size is increased and decreased when detect lost in packets. In TCP Tahoe, Reno, and Vegas, the congestion avoidance phase algorithm permit to the window size to increase by one segment every RTT. This increment stop when the window size reaches the congestion point and that will stimulates the window size to decrease and slow-down to the next phase. Basically, TCP seeks to provide reliability to data transmitted between two hosts. TCP is trying to provide reliable data transmission between two entities. TCP applies set of rules to handle lost in packets resulted from physical errors in transmission or because of the congestion in cross traffics [4]. In recent days, the need to provide reliable data transmission over Internet traffics or cellular mobile systems becomes very important. TCP represents the prevailing protocol that provide reliability to data transferring in all end-to-end data stream services on the Internet and many of new networks. Usually, it’s not easy to determine the available bandwidth for TCP packets flow. In fact, it’s very complex problem due to the effects of the congestion control of TCP and the network dynamics. These two factors make the proceedings of exact allocation for the packets flow complicated. The approved mechanism to detect the optimum bandwidth to send packets from TCP sender is congestion control [10]. The understood of TCP behavior and the approaches to enhance the performance of TCP in wireless channels have been many difficulties and challenges. In parallel with this, considerable researches dealt with in detail many proposed development and mechanisms to raise the efficiency of the performance of TCP, some of these problems already solved, but others are still open [11].
2 TCP VARIANTS BACKGROUND
There are many TCP variants that modified and developed with respectively with the communications needs. Most of TCP current versions are include set of algorithms which built to control the congestion in critical links of network with maintaining the network throughput [7]. In present years, TCP has been faced the fast growth in internet in parallel with the demand increasing to transfer the media on high speed links supported TCP. In order to improve its performance TCP cuts down the size of its congestion window resulted in further performance degradation. This is a more serious problem in bursty and highly mobile networks which have rapid topological changes [8]. TCP provides division for sequenced data stream into packets, confirms the packets delivery with the possibility of losing the IP layer loses, retransmit, reorders, or packets duplication, and monitoring the network band capacity to avoiding congestions. TCP protocol can provide over two end points connection, flow rate controlling with bidirectional link and data reliability [9].In addition, each TCP sender can regulates the size of the congestion window using the congestion control mechanism and the TCP can update and dynamically regulate the window size depending on the packets ACK or by indicates the packets losses when occur.
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG
214
The object behind the differences of TCP is that each type has some distinct criteria such as the base TCP has become known as TCP Tahoe. TCP Reno adds one new mechanism called fast recovery to TCP Tahoe. Newreno uses the newest retransmission mechanism of TCP Reno. The use of Sacks permits the receiver to specify several additional data packets that have been received out of order within one dupack. TCP Vegas proposes its own unique retransmission and congestion control strategies. TCP Fack is Reno TCP with forward acknowledgment [12].
TABLE 1 SIMULATION PARAMETERS
3 NETWORK TOPOLOGY AND SIMULATION PARAMETERS
As mentioned before, the experiments performed using NS-2 simulator [13] and grounded on using Tcl script. The proposed topology included four source nodes linked to corresponding four nodes as destination nodes through two routers with single bottleneck. The propagation delay of all topology links set to 3 msec while the bandwidth of the source and destination nodes set to 10 Mbps except the bottleneck which is set to 100 Mbps as shown in Fig.1 where that achieved the large-bandwidth concept. In fact, the large-bandwidth low-latency bottleneck represents the main link in next generation network such as Long Term Evolution (LTE) networks, where the goodput of standard TCP’s can give a premium evaluation to the performance of these variants over next generation networks. The simulation and links parameters are briefed in Table 1.
Parameter Number of Source nodes Number of Source nodes Number of Routers Bandwidth of Bottleneck (R1R2) Propagation delay of all links Bandwidth of Source Nodes (S - R1) Bandwidth of Destination Nodes (D - R1) Packet size Max. window size Queue scheme tcpTick Queue size Simulation time TCP protocol
Value 4 4 2 100 Mbps 3 msec 10 Mbps 10 Mbps 536,1460 Bytes 128 packets Drop-Tail 0.5sec 64 packets 11sec Tahoe, Reno, Newreno, Vegas, Sack, and Fack
The nodes groups S and D are represented the TCP sender and receiver respectively, and the queue size between them is set to 64 packets while the queuing type is chose to be DropTail. In other hand, the maximum bound of TCP window size is set to 128 packets and tcpTick to 0.5 second where tcpTick is the timer clock granularity for measuring RTT intervals (the default value 0.1 sec).
Fig. 1. Proposed Network Topology for Goodput Measurements
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG
215
The general concept of TCP Goodput, that it’s measure the total of TCP payload bytes per second that the system under test can transmit and receive between its ports and the Maximum Segment Size (MSS). Therefore, the maximum segment size effect on the goodput behaviour, that's why, the experiment separately, used two segment sizes, 536 Bytes and 1460 Bytes to achieve high accuracy to the estimated goodput. At last, the simulation duration is fixed to 11sec for each experiment (when MSS= 536 Bytes and when MSS=1460 Bytes).
4 RESULTS AND DISCUSSION
As explained previously, the goodput measurement based on two trials, the first when MSS equal to 536 Bytes and the second when it 1460 Bytes and each experiment test the goodput for Tahoe, Reno, Newreno, Sack, Fack, and Vegas. That because the tests script measures the goodput for each MSS value separately and the MSS changed for each experiment. The full results of the goodput measuring over the proposed topology for TCP source variants are shown in Table 2 and Table 3 while the results are demonstrated in the column chart in Fig. 2 and Fig. 3.
Fig. 2. Demonstration of Different TCP’s Goodput Measurements (MSS=536 Bytes).
TABLE 2 RESULTS OF DIFFERENT TCP’S GOODPUT MMS=536 BYTES
TCP Tahoe Reno Newreno Vegas Sack Fack
Goodput (Mbps) 18.220 21.936 25.044 8.640 22.110 1.369
Fig. 3. Demonstration of Different TCP’s Goodput Measurements (MSS=1460 Bytes).
TABLE 3 RESULTS OF DIFFERENT TCP’S GOODPUT MMS=1460 BYTES
TCP Tahoe Reno Newreno Vegas Sack Fack
Goodput (Mbps) 18.220 21.936 25.044 8.640 22.110 1.369
From these results, Fack TCP provides poorer goodput in both trials, in spite of the goodput for Fack TCP improved when MSS=1460 Bytes, this due to the slow congestion control mechanism used with Fack where it cannot covering the packet losing and after each loss, the congestion window initiated from the initial value and increase the window again. In other side, Newreno perform better than other TCP variants where that because the intelligent congestion control mechanism used in Newreno, where the combination of four phases, slow-start, congestion avoidance, fast recovery, and fast retransmit assist Newreno to covering the packet dropping. In addition, after packet loss, the congestion control start form the half window size and no need to start from the initial window level where all this features assisted Newreno to give high goodput. Reno showed a reasonable goodput compared with other variants but the degradation in Reno goodput is because Reno cannot perform well with high packet loss rate, where this situation expected in our simulation.
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG
216
Tahoe and Sack (Sack is improved Reno version) performed a critical goodput, where Sack used the features of Reno to cover the expected packet loss while Tahoe limitedly covered the packet loss due to Tahoe used fast recovery but the fast retransmit not included in the congestion control mechanism. In Vegas, and because it used a special congestion control approach, Vegas can give high throughput but cannot give a reasonable goodput. This due to the congestion control of Vegas estimate the congestion point according to the current and expected window size, so the packet loss become lesser than other TCP variants but the goodput romans poor as shown in graphical demonstration of the experimented results with two trials, one when MSS=536 Bytes and the other when MSS=1460 Bytes.
[7]
[8] [9] [10]
[11]
[12]
5 CONCLUSION
This paper provided and experimented results to the goodput for six TCP source variants over largebandwidth and low-latency bottleneck of 100 Mbps and 3 msec as a bandwidth and propagation delay. The TCP variants showed a large goodput difference in number of Mbps transferred over the bottleneck in spite that all of them used the same parameters and conditions. Two trials used in the test, one when MSS=536 Bytes and the other when MSS=1460 Bytes, where the two segment size achieve more reality and credibility to the goodput performance. Newreno gave the best goodput compared with other versions while Fack gave the lesser goodput. In fact, the all TCP versions used in the experiments cannot achieve the high level requirements of the next generation networks, especially when an wireless channels and nodes includes in the networks such as the cellular system. For this reasons, and from the obtained results, the congestion control of all standard TCP variants are require to improve to be able to provide an end-to-end reliable connection with lesser packet loss and high goodput level.
[13]
G. A. Abed, M. Ismail, and K. Jumari., "ARCHITECTURE AND FUNCTIONAL STRUCTURE OF TRANSMISSION CONTROL PROTOCOL OVER VARIOUS NETWORKS APPLICATIONS," Journal of Theoretical and Applied Information Technology, vol. 34, 2011. S. Henna, "A Throughput Analysis of TCP Variants in Mobile Wireless Networks," 2009, pp. 279-284. N. Möller, Automatic control in TCP over wireless: School of Electrical Engineering, Royal Institute of Technology, 2005. H. Abrahamsson, O. Hagsand and I. Marsh, "TCP over high speed variable capacity links: A simulation study for bandwidth allocation," 2002, pp. 117-129. X. Chen, H. Zhai, J. Wang and Y. Fang, "A survey on improving TCP performance over wireless networks," Resource management in wireless networking, pp. 657-695, 2005. G. A. Abed, M. Ismail, and K. Jumari, "Behavior of cwnd for TCP source variants over parameters of LTE networks," Information Technology Journal, vol. 10. N. Simulator, "ns-2," 1989.
Ghassan A. Abed received his B.Sc. and M.Sc. degree in Computer Engineering from University of Technology, Baghdad, Iraq, in 1996 and 2003 respectively. He was Head of Transmitters and Receivers Dept. in Microwave Research Centre in Ministry of Sciences and Technology, Iraq. Currently, he is PhD candidate in National University of Malaysia (UKM), Selangor, Malaysia. He is working in Mobile and Computer Wireless Networks and his research interests include developing new TCP mechanisms to improve performance of TCP over 4G systems and beyond.
ACKNOWLEDGMENT
This study is sponsored by Universiti Kebangsaan Malaysia (UKM) through the university research grant OUP2012-182.
REFERENCES
[1] [2] [3] S. Sharma, D. Gillies, and W. Feng, "On the Goodput of TCP NewReno in Mobile Networks," 2010, pp. 1-8. V. Jacobson, "Congestion avoidance and control," 1988, pp. 314-329. L. A. Grieco and S. Mascolo, "Performance evaluation and comparison of Westwood+, New Reno, and Vegas TCP congestion control," ACM SIGCOMM Computer Communication Review, vol. 34, pp. 25-38, 2004. B. Moraru, F. Copaciu, G. Lazar, and V. Dobrota, "Practical analysis of tcp implementations: Tahoe, reno, newreno," 2003, pp. 125–138. B. Qureshi, M. Othman, and N. Hamid, "Progress in various TCP variants (February 2009)," 2009, pp. 1-6. M. S. Islam, M. Kashem, W. H. Sadid, M. A. Rahman, M. N. Islam, and S. Anam, "TCP variants and network parameters: a comprehensive performance analysis," Proceedings of the International MultiConference of Engineers and Computer Scientists, vol. 1, 2009.
Prof. Dr.Mahamod Ismail joined the Department of Electrical, Electronics and System Engineering, Faculty of Engineering and Built Environment, Universiti Kebangsaan Malaysia (UKM) in 1985 and currently he is a Professor in Communication Engineering. He received the B.Sc. degree in Electrical and Electronics from University of Strathclyde, U.K. in 1985, the M.Sc. degree in Communication Engineering and Digital Electronics from University of Manchester Institute of Science and Technology (UMIST), Manchester U.K. in 1987, and the Ph.D. from University of Bradford, U.K. in 1996. He was with the first Malaysia Microsatellite TiungSat Team Engineers in Surrey Satellite Technology Ltd. U.K. for 9 months started in June 1997. His research interests include mobile and satellite communication, and wireless networking particularly on the radio resource management for the next generation wireless communication network. He is currently the Chair of IEEE Malaysia Section.
[4] [5] [6]
Prof. Dr.Kasmiran Jumari received his B.Sc. from National University Malaysia, 1976 and M.Sc. degree from University of Aberdeen, UK, 1977. His Ph.D. received from University of Kent, UK, 1985. Currently he is a Professor at the Department of Electrical, Electronic and Systems Engineering, in National University of Malaysia (UKM) from 2001. His research interests are in computer network security, software engineering, computer engineering, and image processing.
212
Experimented Goodput Measurement of Standard TCP Versions over Large-Bandwidth Low-Latency Bottleneck
Ghassan A. Abed, Mahamod Ismail, and Kasmiran Jumari
Abstract—Goodput of Transmission Control Protocol (TCP) is the number of useful data bits, transferred by the network elements to a certain destinations, per unit of time. In communications networks, network layer, transport layer, and occasionally data link layer protocol overhead is involved in the throughput, but is excluded from the goodput. Goodput is constantly lesser than the throughput where the throughput means the gross bits rate which is physically transmitted, that mostly is lesser than network access connections rapidity (the link bandwidth or the link capacity). In other side, TCP flow control, congestion avoidance, and slow-start may possibly cause a poorer goodput than the maximum throughput. This article provide an experimented results to the goodput measurement for six TCP source variants, Tahoe, Reno, Newreno, Sack, Fack, and Vegas. The goodput analysis based on using a specific network topology with large-bandwidth and low-latency bottleneck using Network Simulator 2 (NS-2). The obtained results showed the huge differences among the measured goodput for these TCP’s. Index Terms— Goodput, TCP, NS-2, MSS.
——————————
——————————
1 INTRODUCTION
G
OODPUT is defined as the sum of single packets delivered to a finale host in a given time period, as opposed to the overall number of packets transferred in a given time period that includes the retransmitted packets. The rationale behind measuring the goodput is that the end operators of TCP flow are concerned with transferring single packets and do not care about the number of retransmissions cycles executed by the TCP source [1]. Let's say, if a file is transmitted, the goodput that the operator experiences correspond to the size of file in bits divided by the file transferring period of time. Through the previous two decades, several of mechanisms were proposed to enhance the standard TCP versions, Tahoe and Reno. Afterward Jacobson [2] introduced the his algorithm of congestion control, then TCP development grow into actual dynamic and many algorithms have been assumed for congestion control to enhancing the stability, and bandwidth sharing among flows over wired and wireless networks. Actually, currently TCP is not fit appropriate for wireless networks due to losses resulted from using radio channels and the problems are misread as indication of congestion by recent TCP structures and leading to an unnecessary decreasing of the transmission rate. Therefore, TCP needs additional connection layer protocols like using split connections or reliable link layer approach to professionally work in wireless links [3].
————————————————
• Ghassan A. Abed is PhD candidate in Department of Electrical, Electronic, and Systems Engineering Faculty of Engineering and Built Environment, National University of Malaysia, UKM. • Prof. Dr. Mahamod Ismail is with Faculty of Engineering and Built Environment, National University of Malaysia, UKM. • Prof. Dr. Kasmiran Jumari is with Faculty of Engineering and Built Environment, National University of Malaysia, UKM.
In the last years, computer networks and mobile cellular systems have qualified incredible evolution and a lot of computers and other user equipment’s become linked together with most mutual protocol stack used being TCP. Currently, it is hard to recognize the congestion control mechanisms that are applied by different engines in Internet. The header of TCP does not deliver any facts for them. One more imperative problem is the manner that these mechanisms are employed in diverse operating systems [4]. The greatest universal transport protocol involved is the TCP and in the original accomplishment of TCP, a very small number of variants were done to minimalize the congestion in network path. Employment used accumulative confident acknowledgements and the expiration of a retransmission timer to afford reliability based on a modest go-back-n model. Some successive variants of TCP grounded on the mechanisms of congestion control and avoidance have been proposed and established [5]. The object beyond the differences of TCP is that every variant takes certain singular principles. The prime TCP has been called by TCP Tahoe. While TCP Reno complements new technique to improve congestion control of Tahoe, this mechanism called fast recovery. The newest retransmission algorithm was added to Reno to get new TCP termed as Newreno. Fack TCP is a Reno but uses forward acknowledgment technique. The usage of Sacks allows to the receiver to indicate some extra segment that received with non-order during single duplicate ACK, while TCP Vegas assumes its individual exclusive approaches for congestion control [6].
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG
213
TCP congestion control algorithms are the leading object to using the networks applications successfully in spite of source bottlenecks and mostly impulsive the access patterns of users. TCP Reno, Sack, Tahoe, Newreno, Fack and Vegas, are represent the source TCP variants and each variants support different congestion control algorithm. The base of TCP congestion control is grounded on Additive Increase Multiple Decrease (AIMD) algorithm, by halving the window size when congestion window having a loss in packet, and growing the window in one segment for every Round Trip Time (RTT). The second module of congestion control is the retransmission timer, containing the exponential bake-offs of the retransmit timer if the packet that retransmitted is dropped. The third essential module is the slow-start mechanism for the primary exploratory for existing bandwidth. The other congestion control mechanism is the clocking of ACK. Everywhere the acknowledgments arrived to the sender is used to clock-out the transmission for the new next packet. The TCP source variants discussed here, where all share the many features like slow-start, except TCP Vegas, and all follow to the fundamental basis of slow-start, AIMD, retransmit timers, and clocking of ACK.
If the congestion window has constant value, the ACK timing of the sent packets will depend on the ACK of the first set of packets (early packets). TCP sliding window depend on ACK clock which calculate the sender flow rate and when RTT changed with different values, the sliding window will determine the mean sending rate of complete window per average RTT. The transmission window size controlled by dependence on the ACKs received each RTT and these parameters indicate the general differences between TCP versions. The main function of TCP window control is to obtain high packets rate with minimum losses by avoiding network overloading in the same time to provide optimum sharing to the network bandwidth among connections. The optimum bandwidth sharing can changed because the varying amounts of overcrowding between traffics over the network, also it because the varying in network itself like the updates in routing or the time-varying capacity over radio links [9]. TCP Tahoe and TCP Reno are mostly applied over many wireless applications because of the effective congestion control mechanisms. These mechanisms provide varying in size of congestion window depending on ACK status, thus when packets acknowledged the window size is increased and decreased when detect lost in packets. In TCP Tahoe, Reno, and Vegas, the congestion avoidance phase algorithm permit to the window size to increase by one segment every RTT. This increment stop when the window size reaches the congestion point and that will stimulates the window size to decrease and slow-down to the next phase. Basically, TCP seeks to provide reliability to data transmitted between two hosts. TCP is trying to provide reliable data transmission between two entities. TCP applies set of rules to handle lost in packets resulted from physical errors in transmission or because of the congestion in cross traffics [4]. In recent days, the need to provide reliable data transmission over Internet traffics or cellular mobile systems becomes very important. TCP represents the prevailing protocol that provide reliability to data transferring in all end-to-end data stream services on the Internet and many of new networks. Usually, it’s not easy to determine the available bandwidth for TCP packets flow. In fact, it’s very complex problem due to the effects of the congestion control of TCP and the network dynamics. These two factors make the proceedings of exact allocation for the packets flow complicated. The approved mechanism to detect the optimum bandwidth to send packets from TCP sender is congestion control [10]. The understood of TCP behavior and the approaches to enhance the performance of TCP in wireless channels have been many difficulties and challenges. In parallel with this, considerable researches dealt with in detail many proposed development and mechanisms to raise the efficiency of the performance of TCP, some of these problems already solved, but others are still open [11].
2 TCP VARIANTS BACKGROUND
There are many TCP variants that modified and developed with respectively with the communications needs. Most of TCP current versions are include set of algorithms which built to control the congestion in critical links of network with maintaining the network throughput [7]. In present years, TCP has been faced the fast growth in internet in parallel with the demand increasing to transfer the media on high speed links supported TCP. In order to improve its performance TCP cuts down the size of its congestion window resulted in further performance degradation. This is a more serious problem in bursty and highly mobile networks which have rapid topological changes [8]. TCP provides division for sequenced data stream into packets, confirms the packets delivery with the possibility of losing the IP layer loses, retransmit, reorders, or packets duplication, and monitoring the network band capacity to avoiding congestions. TCP protocol can provide over two end points connection, flow rate controlling with bidirectional link and data reliability [9].In addition, each TCP sender can regulates the size of the congestion window using the congestion control mechanism and the TCP can update and dynamically regulate the window size depending on the packets ACK or by indicates the packets losses when occur.
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG
214
The object behind the differences of TCP is that each type has some distinct criteria such as the base TCP has become known as TCP Tahoe. TCP Reno adds one new mechanism called fast recovery to TCP Tahoe. Newreno uses the newest retransmission mechanism of TCP Reno. The use of Sacks permits the receiver to specify several additional data packets that have been received out of order within one dupack. TCP Vegas proposes its own unique retransmission and congestion control strategies. TCP Fack is Reno TCP with forward acknowledgment [12].
TABLE 1 SIMULATION PARAMETERS
3 NETWORK TOPOLOGY AND SIMULATION PARAMETERS
As mentioned before, the experiments performed using NS-2 simulator [13] and grounded on using Tcl script. The proposed topology included four source nodes linked to corresponding four nodes as destination nodes through two routers with single bottleneck. The propagation delay of all topology links set to 3 msec while the bandwidth of the source and destination nodes set to 10 Mbps except the bottleneck which is set to 100 Mbps as shown in Fig.1 where that achieved the large-bandwidth concept. In fact, the large-bandwidth low-latency bottleneck represents the main link in next generation network such as Long Term Evolution (LTE) networks, where the goodput of standard TCP’s can give a premium evaluation to the performance of these variants over next generation networks. The simulation and links parameters are briefed in Table 1.
Parameter Number of Source nodes Number of Source nodes Number of Routers Bandwidth of Bottleneck (R1R2) Propagation delay of all links Bandwidth of Source Nodes (S - R1) Bandwidth of Destination Nodes (D - R1) Packet size Max. window size Queue scheme tcpTick Queue size Simulation time TCP protocol
Value 4 4 2 100 Mbps 3 msec 10 Mbps 10 Mbps 536,1460 Bytes 128 packets Drop-Tail 0.5sec 64 packets 11sec Tahoe, Reno, Newreno, Vegas, Sack, and Fack
The nodes groups S and D are represented the TCP sender and receiver respectively, and the queue size between them is set to 64 packets while the queuing type is chose to be DropTail. In other hand, the maximum bound of TCP window size is set to 128 packets and tcpTick to 0.5 second where tcpTick is the timer clock granularity for measuring RTT intervals (the default value 0.1 sec).
Fig. 1. Proposed Network Topology for Goodput Measurements
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG
215
The general concept of TCP Goodput, that it’s measure the total of TCP payload bytes per second that the system under test can transmit and receive between its ports and the Maximum Segment Size (MSS). Therefore, the maximum segment size effect on the goodput behaviour, that's why, the experiment separately, used two segment sizes, 536 Bytes and 1460 Bytes to achieve high accuracy to the estimated goodput. At last, the simulation duration is fixed to 11sec for each experiment (when MSS= 536 Bytes and when MSS=1460 Bytes).
4 RESULTS AND DISCUSSION
As explained previously, the goodput measurement based on two trials, the first when MSS equal to 536 Bytes and the second when it 1460 Bytes and each experiment test the goodput for Tahoe, Reno, Newreno, Sack, Fack, and Vegas. That because the tests script measures the goodput for each MSS value separately and the MSS changed for each experiment. The full results of the goodput measuring over the proposed topology for TCP source variants are shown in Table 2 and Table 3 while the results are demonstrated in the column chart in Fig. 2 and Fig. 3.
Fig. 2. Demonstration of Different TCP’s Goodput Measurements (MSS=536 Bytes).
TABLE 2 RESULTS OF DIFFERENT TCP’S GOODPUT MMS=536 BYTES
TCP Tahoe Reno Newreno Vegas Sack Fack
Goodput (Mbps) 18.220 21.936 25.044 8.640 22.110 1.369
Fig. 3. Demonstration of Different TCP’s Goodput Measurements (MSS=1460 Bytes).
TABLE 3 RESULTS OF DIFFERENT TCP’S GOODPUT MMS=1460 BYTES
TCP Tahoe Reno Newreno Vegas Sack Fack
Goodput (Mbps) 18.220 21.936 25.044 8.640 22.110 1.369
From these results, Fack TCP provides poorer goodput in both trials, in spite of the goodput for Fack TCP improved when MSS=1460 Bytes, this due to the slow congestion control mechanism used with Fack where it cannot covering the packet losing and after each loss, the congestion window initiated from the initial value and increase the window again. In other side, Newreno perform better than other TCP variants where that because the intelligent congestion control mechanism used in Newreno, where the combination of four phases, slow-start, congestion avoidance, fast recovery, and fast retransmit assist Newreno to covering the packet dropping. In addition, after packet loss, the congestion control start form the half window size and no need to start from the initial window level where all this features assisted Newreno to give high goodput. Reno showed a reasonable goodput compared with other variants but the degradation in Reno goodput is because Reno cannot perform well with high packet loss rate, where this situation expected in our simulation.
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG
216
Tahoe and Sack (Sack is improved Reno version) performed a critical goodput, where Sack used the features of Reno to cover the expected packet loss while Tahoe limitedly covered the packet loss due to Tahoe used fast recovery but the fast retransmit not included in the congestion control mechanism. In Vegas, and because it used a special congestion control approach, Vegas can give high throughput but cannot give a reasonable goodput. This due to the congestion control of Vegas estimate the congestion point according to the current and expected window size, so the packet loss become lesser than other TCP variants but the goodput romans poor as shown in graphical demonstration of the experimented results with two trials, one when MSS=536 Bytes and the other when MSS=1460 Bytes.
[7]
[8] [9] [10]
[11]
[12]
5 CONCLUSION
This paper provided and experimented results to the goodput for six TCP source variants over largebandwidth and low-latency bottleneck of 100 Mbps and 3 msec as a bandwidth and propagation delay. The TCP variants showed a large goodput difference in number of Mbps transferred over the bottleneck in spite that all of them used the same parameters and conditions. Two trials used in the test, one when MSS=536 Bytes and the other when MSS=1460 Bytes, where the two segment size achieve more reality and credibility to the goodput performance. Newreno gave the best goodput compared with other versions while Fack gave the lesser goodput. In fact, the all TCP versions used in the experiments cannot achieve the high level requirements of the next generation networks, especially when an wireless channels and nodes includes in the networks such as the cellular system. For this reasons, and from the obtained results, the congestion control of all standard TCP variants are require to improve to be able to provide an end-to-end reliable connection with lesser packet loss and high goodput level.
[13]
G. A. Abed, M. Ismail, and K. Jumari., "ARCHITECTURE AND FUNCTIONAL STRUCTURE OF TRANSMISSION CONTROL PROTOCOL OVER VARIOUS NETWORKS APPLICATIONS," Journal of Theoretical and Applied Information Technology, vol. 34, 2011. S. Henna, "A Throughput Analysis of TCP Variants in Mobile Wireless Networks," 2009, pp. 279-284. N. Möller, Automatic control in TCP over wireless: School of Electrical Engineering, Royal Institute of Technology, 2005. H. Abrahamsson, O. Hagsand and I. Marsh, "TCP over high speed variable capacity links: A simulation study for bandwidth allocation," 2002, pp. 117-129. X. Chen, H. Zhai, J. Wang and Y. Fang, "A survey on improving TCP performance over wireless networks," Resource management in wireless networking, pp. 657-695, 2005. G. A. Abed, M. Ismail, and K. Jumari, "Behavior of cwnd for TCP source variants over parameters of LTE networks," Information Technology Journal, vol. 10. N. Simulator, "ns-2," 1989.
Ghassan A. Abed received his B.Sc. and M.Sc. degree in Computer Engineering from University of Technology, Baghdad, Iraq, in 1996 and 2003 respectively. He was Head of Transmitters and Receivers Dept. in Microwave Research Centre in Ministry of Sciences and Technology, Iraq. Currently, he is PhD candidate in National University of Malaysia (UKM), Selangor, Malaysia. He is working in Mobile and Computer Wireless Networks and his research interests include developing new TCP mechanisms to improve performance of TCP over 4G systems and beyond.
ACKNOWLEDGMENT
This study is sponsored by Universiti Kebangsaan Malaysia (UKM) through the university research grant OUP2012-182.
REFERENCES
[1] [2] [3] S. Sharma, D. Gillies, and W. Feng, "On the Goodput of TCP NewReno in Mobile Networks," 2010, pp. 1-8. V. Jacobson, "Congestion avoidance and control," 1988, pp. 314-329. L. A. Grieco and S. Mascolo, "Performance evaluation and comparison of Westwood+, New Reno, and Vegas TCP congestion control," ACM SIGCOMM Computer Communication Review, vol. 34, pp. 25-38, 2004. B. Moraru, F. Copaciu, G. Lazar, and V. Dobrota, "Practical analysis of tcp implementations: Tahoe, reno, newreno," 2003, pp. 125–138. B. Qureshi, M. Othman, and N. Hamid, "Progress in various TCP variants (February 2009)," 2009, pp. 1-6. M. S. Islam, M. Kashem, W. H. Sadid, M. A. Rahman, M. N. Islam, and S. Anam, "TCP variants and network parameters: a comprehensive performance analysis," Proceedings of the International MultiConference of Engineers and Computer Scientists, vol. 1, 2009.
Prof. Dr.Mahamod Ismail joined the Department of Electrical, Electronics and System Engineering, Faculty of Engineering and Built Environment, Universiti Kebangsaan Malaysia (UKM) in 1985 and currently he is a Professor in Communication Engineering. He received the B.Sc. degree in Electrical and Electronics from University of Strathclyde, U.K. in 1985, the M.Sc. degree in Communication Engineering and Digital Electronics from University of Manchester Institute of Science and Technology (UMIST), Manchester U.K. in 1987, and the Ph.D. from University of Bradford, U.K. in 1996. He was with the first Malaysia Microsatellite TiungSat Team Engineers in Surrey Satellite Technology Ltd. U.K. for 9 months started in June 1997. His research interests include mobile and satellite communication, and wireless networking particularly on the radio resource management for the next generation wireless communication network. He is currently the Chair of IEEE Malaysia Section.
[4] [5] [6]
Prof. Dr.Kasmiran Jumari received his B.Sc. from National University Malaysia, 1976 and M.Sc. degree from University of Aberdeen, UK, 1977. His Ph.D. received from University of Kent, UK, 1985. Currently he is a Professor at the Department of Electrical, Electronic and Systems Engineering, in National University of Malaysia (UKM) from 2001. His research interests are in computer network security, software engineering, computer engineering, and image processing.
