> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <

Throughput Comparison of TCP Reno and TCP Veno in a Tropical Setting

Allan S. Sayana and Jamie Ann P. Zamodio
Abstract As wireless connectivity becomes increasingly relevant in modern networks, finding a more effective and efficient implementation of the transmission control protocol (TCP) becomes significantly more important. Unlike in wired networks, random packet loss due to bit errors in wireless networks is considerably higher, and consequently this causes significant performance degradation in traditional TCP. TCP Veno, created by Dr. Cheng Peng Fu, is a combined algorithm of TCP Reno and TCP Vegas. It is proposed as a simple and effective end-to-end congestion control mechanism for dealing with random packet loss. The thesis investigates the different factors related to random packet loss, most notably rain-induced attenuation. Tests were conducted which included parameters such as distance, the addition of sector antennas, and the presence of rain. The applications Secure Copy and TCPSuite were used to acquire pertinent network performance data such as congestion window size and round trip time. These were done in order to devise a feasible comparison of TCP Reno, the current standard TCP, and TCP Veno, as well as to verify the effectiveness of TCP Veno in a tropical setting. With this, the thesis concludes that given local climate conditions, TCP Veno is comparable, if not even more effective than TCP Reno. Index TermsInformation rates, transmission control protocol (TCP). TCP Reno, TCP Veno, tropical regions.

I. INTRODUCTION IRELESS transmission is becoming an integral part of the Internet, as shown by the increase in the number of wireless local area networks (WLAN), home networks, and cellular networks. However, unlike in wired systems, wireless systems elicit an abundance of performance issues regarding random packet loss. This is mostly due to environmental conditions and terrestrial obstructions and reflections that lead to high and unpredictable error rates. WLAN systems mostly share the characteristics of traditional wireless systems (satellite and terrestrial microwave) such as high error rates, as well as the characteristics of wired systems, like low physical layer propagation delays. Moreover, wireless access networks are usually interconnected using wired backbone networks, and many applications on the networks run on top of the transmission control protocol/Internet protocol (TCP/IP) [1]. TCP is one of the main protocols in TCP/IP networks. Whereas the IP protocol deals only with packets, TCP

Manuscript received February 24, 2006. A. S. Sayana is an undergraduate of the Ateneo de Manila University, Loyola Heights, Quezon City, Philippines (phone: +639166967976; e-mail: allansayana@yahoo.com). J. A. P. Zamodio, is also an undergraduate of the Ateneo de Manila University, Loyola Heights, Quezon City, Philippines (phone: +639064364557; e-mail: japz20@yahoo.com).

enables two hosts to establish a connection and exchange streams of data. TCP guarantees delivery of data and also guarantees that packets will be delivered in the same order in which they were sent. TCP Reno, derived from TCP Tahoe, is currently the most widely deployed TCP stack in the Internet, and its essential idea is that the window size is increased progressively when there is no packet loss. When packet loss does happen, its window size is halved and then a linear increase algorithm is implemented until further packet loss is experienced. This additive increase and multiplicative decrease mechanism leads to periodic oscillations in the congestion window. However, TCP Renos conjecture that packet loss implies network congestion does not necessarily apply to wireless networks, in which packet loss can be caused by noise, handoffs, link error, or reasons other than network congestion. This miscalculation causes Reno to back down the sending data rate unnecessarily, resulting in significant performance degradation. In 1994, TCP Vegas was introduced as an alternative protocol that estimates the network condition to prevent packet loss. It boasted up to 71% throughput improvement over Reno. Because of its proactive approach, the window evolution of TCP Vegas is much smoother as compared to TCP Reno. Recent work, however, show that the performance of Vegas connections degrades significantly when they coexist with other concurrent Reno connections. Therefore a new TCP that can coexist harmoniously with Reno connections and at the same time be effective in wireless networks was in order. Fu proposed TCP Veno in a 2001 dissertation as a novel end-to-end congestion control mechanism that is simple and effective for dealing with random packet loss. Utilizing the idea of TCP Vegas estimation of the network condition to prevent packet loss proactively, TCP Veno uses it to determine whether packet losses are likely to be caused by network congestion or random phenomena. Veno also modifies Reno so that it reduces the sending rate less aggressively when random loss is detected, thus preventing unnecessary throughput degradation. It also refines the linear increase algorithm so that the connection can stay longer in an operating region in which the network bandwidth is fully utilized. This results in a slightly longer oscillation period, and hence less oscillations in the congestion window. With these enhancements to TCP Reno, Fu demonstrated that TCP Veno could achieve up to 80% throughput improvements in typical wireless networks in an environment with 1% random packet loss rate.

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < A. Statement of the Problem One of the most interesting TCP-related problems is that of congestion. Hundreds of research articles are published every year analyzing and proposing improvements in this aspect of TCP. However, the algorithms and parameters that are suitable for one environment are not always suitable for other environments, so there is a need for adapting TCP to different conditions [2]. For the past few decades, there have been many studies and proposals on TCP performance improvement. However, when deployed or evaluated over heterogenous networks, most proposals do not compare well with TCP Reno. Hence, Reno remains to be the dominant version used in practice. This study, following Fus directive, is a further attempt to demonstrate TCP Veno as a viable enhancement to Reno. Furthermore, a study of TCP with respect to rain events, which could be a significant source of packet loss in tropical settings, has not been conducted as of yet. B. Objectives The focus of this thesis is the development of a comprehensive study on TCP Reno and Veno performance in a tropical setting. To be able to accomplish this, the group first aims to perform extensive research on the different TCP protocols as well as on wireless transmission. Both shortrange and long-range implementations are to be conducted. For the long-range experimentation, particular scrutiny is going to be put on the effects of rainfall on TCP throughput. The primary objectives of the thesis are to gather network performance data of TCP Reno and Veno. The group also aims to formulate recommendations for the use of a TCP/IP flavor in the context of a tropical setting. The secondary objective of the thesis is to link the collected network performance data of TCP Reno and Veno with quantified rainfall data. C. Significance of the Study There is an ongoing convergence of computing, communications, and control through the IP transport technology. Because of this, people are becoming more and more dependent on TCP/IP services. Many people access some form of TCP/IP networks several times a day, either from fixed locations (office or home) or from a mobile device while on the move. Todays network services range from traditional information gathering to critical business transactions. Long delays due to network inefficiency can cause user irritation and even loss of profit. To maximize the benefit of being online, it is absolutely important to optimize the performance of TCP/IP networks [2]. Live measurement of operational networks is a vital part of building and maintaining high performance TCP/IP networks. In conjunction with this, the study will be the one of the first attempts to investigate the comparative performance of TCP Reno and Veno in a local setting. Moreover, the study will be conducted with an emphasis on the effect of rainfall on link performance. Network statistics will also be accompanied with actual rainfall data in collaboration with other research groups.

D. Scope and Limitations The thesis includes an investigation on rain events and other phenomena relevant to random packet loss. In relation to this, it will also entail a gathering of comparative network statistics during and outside of rain events as well as the addition of reflector antennas and its effect on throughput. Finally, the study involves a comparative analysis involving TCP Reno and TCP Veno running on a FreeBSD server and communicating with a Red Hat Linux client. The thesis implementation, however, will not include testing for end-to-end congestion over heterogeneous networks. It will also be limited to point-to-point testing on a wireless network. Furthermore, the amount of loss in the network environments was not quantified. Finally, the thesis does not take into account mobile clients. II.METHODOLOGY In the gathering of network performance data, the group adopted the client-server configuration for the experimental implementation of TCP Reno and Veno, as shown below.
Wireless Client Wireless Router Server

Wired Network

Fig. 1. The Client-Server Model.

A. The Server Computer The server computer was installed with FreeBSD 4.3 along with its complete kernel sources. Totally, FreeBSD 4.3 was installed in two different hard disk drives (HDD), the first installed with TCP Reno and the second with TCP Veno. For our testing, a VIA Network Interface Card (model no. VT6102 Rhine II) was used to connect the server computer to the wireless router. B. The Client Computer For the client side, the Red Hat Linux 9 (Shrike) OS with kernel version 2.20-8 was installed. Also installed in the client, the Linksys Wireless PCI Card (model no. WMP11 ver. 2.7) was used because it is good practice to use wireless routers and cards from the same brand (in this case Linksys). C. The Wireless Router This wireless router (model no. BEFW11S4 ver. 2) was used primarily because it was readily available in the laboratory, and also because it had two antennas for diversity. Meanwhile, two 120 reflector antennas made of smooth aluminum and measuring 10 cm by 10 cm were borrowed from the study Performance of Sector Antennas at WiFi Mobile Stations by Cario, Cazar, and Pangilinan (2005) [3] and were utilized throughout the experimentation. They were used as additional parameters for the wireless router and were arranged in this manner:

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < The antenna to reflector spacing, defined as the distance from the driven element to the corner of the reflector, was set at 5 cm, or 0.4. This value was chosen because at this distance, the antenna exhibits a relatively favorable radiation pattern. D. Testing Applications and Methods Data for the study was acquired using two different applications: Secure Copy and TCPSuite. Secure Copy copies files between hosts on a network using the TCP/IP network protocols. Using this application, a 51203 KB ( 50 MB) file was transferred between the server and the client. After taking samples of TCP Reno with the first hard disk drive (HDD), the server was immediately rebooted with the other HDD to accommodate the next set-up and take samples of TCP Veno. Throughput measurement was relatively straightforward, given by the equation (1) TCPSuite is a set of C language programs developed by Fu, et al. [4] used to capture TCP stack variables. It is composed of SuiteServer.c, which was installed on the server computer, and SuiteClient.c, which was installed on the client computer. Multiple samples, ranging from two to ten, were taken from each set-up and averaged as needed. After taking samples of one TCP protocol, SuiteServer was immediately modified for testing on the other TCP protocol. Although throughput computation for SCP was fairly direct, the computations for TCPSuite were done in two ways using different parameters acquired from the program. This is because the RTT for the Reno experiments are not measured by TCPSuite; hence, the throughput computation given by Fu [5] as (1) could not be obtained and other measures needed to be explored. For the first computation, the throughput was obtained using the formula: (2) No. of segments indicates the number of segments given by the output of TCPSuite. MSS is the maximum segment size, and it is set as 0.512 KB. Total time refers to the transmission time given by TCPSuite that is printed on the clients screen after every sample is taken. Meanwhile, for the second computation, the throughput was obtained using the formula: (3) The total congestion window size of each sample usually exceeds 192 MB; however, some segments from each sample had individual cwnd values equal to the buffer size (64 KB) and some even exceed it by a great number (up to 90 MB). We assumed these were erroneous values and as such removed them from the computation of the total congestion window size. After removal of these values, the total cwnd of the samples were reduced to between one MB to 6 MB. E. Experimental Set-ups The set-up of the experiments is straightforward enough. Essentially, the totality of the tests can be divided into two categories, and these are Short-Range (or Indoor) and LongRange (or Outdoor). Several parameters were considered

throughout the experimentation process, and these were distance, the addition of sector antennas, and the presence of rain. The short-range experiments were conducted within the CTC 208 laboratory. The distance between the wireless router and the wireless client was about five meters. Tests were performed when there were no moving obstructions between router and client to achieve ideal results. However, it is noted that there were several obstructions that could not be removed, such as tables, chairs, and other equipment found in the laboratory. There were two set-ups for this set of experiments, and they were TCP Reno/Veno: (1) Without add-on sector antennas (2) With add-on sector antennas Finally, the router and the sector antennas were positioned such that they were facing in the immediate direction of the client. Meanwhile, the long-range experiments were conducted across two points in the CTC 208 and the SEC C 106 laboratories. The distance between the wireless router and the wireless client was approximately 50 meters, with a vertical difference of 5 meters. Tests were performed during and out of rain events. Again, there were only two set-ups for this set, and they were TCP Reno/Veno with and without add-on reflector antennas. Again, the router and the sector antennas were positioned such that they were facing in the immediate direction of the client. III. RESULTS AND DISCUSSION: SECURE COPY A. Short-Range Experiments As seen in the figure below, TCP Veno had a 2.1% throughput improvement over Reno in the first set-up (without add-on reflector antennas). Meanwhile, in the second set-up (with add-on reflector antennas), Reno performs similarly to Veno and they have the same transmission time. The addition of reflector antennas slightly degraded the performance of both protocols, with 1% degradation in Reno and a 3.1% decrease in Veno. B. Long-Range Experiments without Rain Veno achieved improvements over Reno in both set-ups for this test. In the first, there was a 5.1% gain in throughput while there was a 3.4% gain in the second. There was also significant improvement with the addition of reflector antennas, Reno achieving 29.2% gain and Veno achieving

Fig. 2. Scp Short-Range Throughput.

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 27.1% gain. C. Long-Range Experiments with Rain In the first set-up, only the Veno data could be obtained because the Reno server was unable to connect to the client. In the second set-up, however, Reno achieved a 8.6% improvement over Veno. Meanwhile, the addition of sector antennas resulted in a very slight increase in Veno throughput for the second set-up (1.5%). D. Summary The short-range experiments show that in a relatively lowloss environment that is, short-range as compared to longrange Veno does not exhibit significant improvement over

For the long-range experiments with rain, it was seen in the second set-up that Reno had a slight throughput improvement to Veno. This is because during a rain event, which can be described as a heavy loss environment, neither TCP Reno nor TCP Veno can maintain its self-clocking. (In Fus experiments, the loss rate was close to 10-1 pkt/s.) Consequently, they both experience frequent timeouts, and for timeout situations, TCP Veno and TCP Reno operate with the same algorithm [5]. This explains their comparable throughput for this set-up. Finally, it is noted that Reno had difficulty connecting for the first set-up in the long-range rain experiments without reflectors while Veno did not. IV. RESULTS AND DISCUSSION: TCPSUITE A. Short-Range Experiments Using the first throughput computation, Veno had higher throughput than Reno in all set-ups, with 35.3% improvement in the first (one antenna without reflector), 59.8% in the second (one antenna with reflector), 86.4% in the third (two antennas without reflectors), and 58.5% in the fourth (two antennas with reflectors). Overall, Renos performance improved with the addition of reflector antennas, with a throughput improvement of up to 27%. Veno also experienced improvement of up to 14%. For the second throughput computation, Veno again had higher throughput than Reno for all set-ups, with 80.3% improvement in the first, 154% in the second, 377% in the third, and 128% in the fourth. Renos throughput degraded by 34% with the addition of reflector antennas for the first set-up but improved by 21% in the two-antenna experiments. Meanwhile, Veno performed slightly better (5%) with one reflector antenna but degraded by 73% with two reflector antennas.

Fig. 3. Scp Long-Range without Rain Throughput.

Reno. This corresponds to Fus findings in his own experiments, where it was found that when the packet loss rate is relatively smaller (< 10-3 pkts/s), the evolutions of Veno and Reno are similar. This is because in low-randomloss situations, the effect of congestion loss dominates, and Veno performs the same window reduction as Reno with a drop factor of 1/2. Meanwhile, it was observed that the addition of reflector antennas in the short-range experiments did not improve performance of both Reno and Veno, but as

Fig. 4. Scp Long-Range with Rain Throughput.

a matter of fact degraded them slightly. In conjunction with Fus findings, Veno exhibited up to 5.13% improvement over Reno in the long-range experiments without rain. According to Fus study, when the loss rate is close to 10-2 pkts/s, Veno shows significant improvements over TCP Reno [5]. This is mainly due to Venos refined multiplicative decrease algorithm, which performs smart window adjustment based on the current state estimation of the connection rather than blindly halving the window after the fast retransmit is triggered [5]. Meanwhile, the addition of sector antennas brought a definite improvement in the long-range experiments, where up to 29.2% throughput increase was observed.

Fig. 5. TCPSuite Short-Range Throughput 1.

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < B. Long-Range Experiments without Rain Using the first throughput computation, Veno had higher throughput than Reno in both set-ups, with 222.4% improvement in the first (without reflectors) and 103.5% in the second (with reflectors). Overall, Renos performance 724%.

D. Summary It can be concluded from the data gathered that in a shortrange scenario (which is a relatively low-loss environment), Veno can still manage to achieve higher throughput than

Fig. 6. TCPSuite Short-Range Throughput 2.

improved with the addition of reflector antennas, with a throughput improvement of 95.8%. Veno also experienced improvement of up to 23.6%. Meanwhile, as seen below, in the second throughput computation, Veno again achieved higher throughput for both set-ups, with 298.8% improvement in the first and 102.5% improvement in the second. The addition of sector antennas improved the performance of both protocols as well, with Reno experiencing 170% improvement and Veno with 37%.

Fig. 9. TCPSuite Long-Range with Rain Throughput 1.

Reno. This throughput improvement is mainly caused by Venos refined additive increase, which slows down the growth rate of additive increase and thus extends connection duration at system equilibrium, resulting in reduced

Fig. 10. TCPSuite Long-Range with Rain Throughput 2.

Fig. 7. TCPSuite Long-Range without Rain Throughput 1.

C. Long-Range Experiments with Rain Unfortunately for the first set-up, Reno was again unable to connect. For the second set-up, however, it was found that Veno performed better than Reno by 234%. However, the addition of reflectors degraded Veno performance by 162%. For the second throughput computation, Veno again achieved better performance than Reno by 389%. However,

Fig. 8. TCPSuite Long-Range without Rain Throughput 2.

the presence of reflectors degraded Veno performance by

congestion loss and reduced timeout [5]. It is hard to say at this time if the sector antennas had a positive or a negative effect on TCP performance in the short-range experiments because of the conflicting nature of the data. Meanwhile, in the long-range experiments without rain (a relatively higher loss environment), Veno achieved significant improvement over Reno for both set-ups. This is mainly achieved by Venos refined multiplicative decrease, which performs less window reduction when the connection is deemed to be in the non-congestive state [5]. In contrast with the short-range experiments, it was found that sector antennas had a definitely positive effect on throughput performance. Meanwhile, for the long-range experiments with rain, Veno had better throughput than Reno in all set-ups . Again, as in the experiments without rain, this is attributed to Venos refined AIMD algorithm. Moreover, according to Fu [5], Veno is a bit more aggressive in lossy networks since it experiences more Fast Retransmits and more packets are retransmitted by employing the refined AIMD algorithm. This aggressiveness allows TCP Veno to achieve improvement over Reno. This aggressive behavior is reasonable since it does not cause any bias to other Renos connections.

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < It was also observed that sector antennas helped in establishing a connection between the server and the client. However, they did not necessarily improve throughput, as seen in some of the experiments. In general, the Venos throughput improvement over Renos is achieved by its efficient utilization of bandwidth, not by aggressively grabbing bandwidth [5]. V. CONCLUSION AND RECOMMENDATIONS Majority of the set-ups verified that TCP Veno does perform better than TCP Reno given local climate settings, with improvements ranging from as little as 2.1% to as large as 389%. Regarding the addition of sector antennas, its effect becomes more pronounced in the long-range scenario, particularly in the set-ups without rain. In the short-range, especially for the scp experiments, there are negligible differences in throughput performance for set-ups with and without reflectors. Unfortunately the same could not be said of the short-range TCPSuite experiments where, depending on the computation used, the antennas had an adverse effect on TCP performance. Meanwhile, for the long-range experiments, the improvement brought by the sector antennas becomes more pronounced (from 23.6% up to 170%). The rain experiments, however, require a slightly different analysis. It was observed repeatedly that TCP Reno was unable to connect without the presence of sector antennas. This is attributed to the fact that adding a sector antenna on the base station improves the overall performance of the wireless network, and in this case it worked to the advantage of the TCP Veno connection. Because of this, only in the second set-up (Reno/Veno with antennas) could a throughput comparison between Reno and Veno be established. Again, for most of the rain experiments, Veno achieved significant improvement over Reno. For the TCPSuite experiments, however, the addition of sector antennas had a negative effect on Veno performance. This could be caused by the rainfall itself, which added complexity to the set-up with the presence of extra reflections from the rain drops themselves, not to mention the effect of wind on the signal. Also, the amount of humidity in the air and water saturation in the foliage outside the SEC C laboratory could have further weakened the connection. All this could account for the sizeable difference in the first and second set-up throughput values for Veno. Meanwhile, it is suggested for future experiments that the following be kept in mind. First, ensure that the position of all equipment, such as wireless routers, reflector antennas, and computers remain constant throughout the duration of the experimentation. This is because the slightest adjustment could affect the results of the experiment. Secondly, it is preferable to gather as much data as possible. It is suggested that the experimentation process be conducted for at least a month on a daily basis, and the results averaged as needed. Thirdly, it is also recommended that the effect of foliage on throughput performance be further investigated. Fourth, it is suggested that bit and/or packet error rate measurements be made accompanying the experimentation. Fifth, it would also be interesting to modify TCP Veno itself to further improve it given local climate conditions.

Finally, it is strongly recommended that two sets of clients and servers be run simultaneously for the long-range experiments (one running Reno and the other running Veno), with configurations and set-ups kept as identical as possible. Time is a very important factor especially in the rain experiments, where rain rate, humidity, and foliage saturation changes constantly, and hence two set-ups operating at the same time could yield results more favorable to a study of throughput comparison. However, if this could not be done, the following procedure is thus recommended for single client-server configurations: (1) Boot server computer with TCP flavor 1 and initialize SuiteServer program. (2) Boot client computer and initialize SuiteClient program. (3) Run test until desired amount of data is acquired. (4) After testing, immediately reboot server computer with TCP flavor 2. This will need to be done at regular intervals for example, TCP flavor 1 will be tested at 8:00, TCP flavor 2 at 8:04, TCP flavour 1 at 8:08, and so on. Repeat the process until the desired number of samples for each set-up is obtained. ACKNOWLEDGMENT The authors would like to thank the following distinguished gentlemen. Mr. Jose Claro Monje, our thesis adviser, for his guidance which will always be appreciated, and also for his tolerance of two over-staying (and mighty flighty) super senior students. Dr. Nathaniel Joseph Libatique, for his helpful insight and suggestions that made the study more than it should have been. Dr. Cheng Peng Fu, the creator of TCP Veno, for his brilliance and initiative. Mr. Chunlei Zhang, our collaborator in Singapore, for his invaluable knowledge and insight of the study. And finally, everybody who helped in the creation of this thesis. REFERENCES [1] [2]
[3] Xylomenos, George, George C. Polyzos, Petri Mahonen, and Mika Saaranen. 2001. TCP Performance Issues over Wireless Links. IEEE Communications Magazine 39: No. 4, pp. 52-58. Hassah, Mahbub, and Raj Jain, ed. 2004. High Performance TCP/IP Networking: Concepts, Issues, and Solutions. New Jersey: Pearson Education, Inc. Cario, Nestor Pocholo, Neil Bryan Cazar, and John Paul Pangilinan. 2005. Performance of Sector Antennas at WiFi Mobile Stations. Undergraduate thesis, the Ateneo de Manila University, Quezon City. Fu, Cheng Peng, and Soung Chang Liew. 2003. TCP Veno: TCP Enhancement for Transmission Over Wireless Access Networks. IEEE Journal On Selected Areas in Communications 21 (February): No. 2, p. 216. Fu, Cheng Peng. 2001. TCP Veno: End-to-End Congestion Control Over Heterogeneous Networks. Ph.D. dissertation, the Chinese University of Hong Kong, Hong Kong.

[4]

[5]

Allan S. Sayana graduated from the Ateneo de Manila University in Quezon City, Philippines in 2006 with a degree in Bachelor of Science, major in Electronics and Communications Engineering. He is currently working for Convergys Philippines.

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <

Jamie Ann P. Zamodio also graduated from the Ateneo de Manila University in 2006 with a degree in Bachelor of Science, major in Electronics and Communications Engineering. She is currently studying for the Philippine Electronics and Communications Engineering licensure examination.