216 IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 21, NO. 2, FEBRUARY 2003
TCP Veno: TCP Enhancement for Transmission OverWireless Access Networks
Cheng Peng Fu, Associate Member, IEEE, and Soung C. Liew, Senior Member, IEEE
AbstractWireless access networks in the form of wirelesslocal area networks, home networks, and cellular networks arebecoming an integral part of the Internet. Unlike wired networks,random packet loss due to bit errors is not negligible in wirelessnetworks, and this causes significant performance degradationof transmission control protocol (TCP). We propose and studya novel end-to-end congestion control mechanism called TCPVeno that is simple and effective for dealing with random packetloss. A key ingredient of Veno is that it monitors the networkcongestion level and uses that information to decide whetherpacket losses are likely to be due to congestion or random biterrors. Specifically: 1) it refines the multiplicative decreasealgorithm of TCP Renothe most widely deployed TCP versionin practiceby adjusting the slow-start threshold according tothe perceived network congestion level rather than a fixed dropfactor and 2) it refines the linear increase algorithm so that theconnection can stay longer in an operating region in which thenetwork bandwidth is fully utilized. Based on extensive networktestbed experiments and live Internet measurements, we showthat Veno can achieve significant throughput improvementswithout adversely affecting other concurrent TCP connections,including other concurrent Reno connections. In typical wirelessaccess networks with 1% random packet loss rate, throughputimprovement of up to 80% can be demonstrated. A salient featureof Veno is that it modifies only the sender-side protocol of Renowithout changing the receiver-side protocol stack.
Index TermsCongestion control, congestion loss, random loss,transmission control protocol (TCP) Reno, TCP Vegas, TCP Veno,wireless access networks.
WIRELESS communication technology has been makingsignificant progress in the recent past and will beplaying a more and more important role in access networks,as evidenced by the widespread adoption of wireless localarea networks (WLANs), wireless home networks, and cel-lular networks. These wireless access networks are usuallyinterconnected using wired backbone networks, and manyapplications on the networks run on top of the transmissioncontrol protocol/Internet protocol (TCP/IP).
Manuscript received May 1, 2002, revised September 30, 2002. This workwas supported in part by the Area of Excellence in Information Technologyof Hong Kong (AoE/E-01/99), and in part by the Hong Kong Research GrantCouncil under the Competitive Earmarked Grant CUHK 4229/00E. The workof C. P. Fu was done while with the Information Engineering Department, TheChinese University of Hong Kong, Shatin, Hong Kong.
C. P. Fu was with The Chinese University of Hong Kong Shatin, HongKong. He is now with Nanyang Technological University, Singapore (e-mail:Franklin.Fu@ieee.org).
S. C. Liew is with The Chinese University of Hong Kong, Shatin, Hong Kong(e-mail: firstname.lastname@example.org).
Digital Object Identifier 10.1109/JSAC.2002.807336
TCP is a reliable connection-oriented protocol that imple-ments flow control by means of a sliding window algorithm.TCP Tahoe and Reno , , which make use of the slowstart (SS) and congestion avoidance (CA) algorithms to adjustthe window size, have enjoyed much success to date. In par-ticular, Reno is currently the most widely deployed TCP stack,enabling all sorts of Internet applications.
The Reno algorithm, however, is increasingly being stretchedby the emergence of heterogeneity on the Internet in which dif-ferent segments of the network may have widely different char-acteristics. Optical-fiber links are highly reliable while wirelesslinks are subject to high-bit-error rates; asymmetric digital sub-scriber line (ADSL) access lines are asymmetric and have dif-ferent capacities in the two directions; satellite networks canhave much higher propagation delay than terrestrial networks;and wireless access networks may suffer high packet loss rates.
Reno treats the occurrence of packet loss as a manifestation ofnetwork congestion. This assumption may not apply to networkswith wireless channels, in which packet loss is often induced bynoise, link error, or reasons other than network congestion. Asdefined in , we refer to such packet loss as random packetloss. Misinterpretation of random loss as an indication of net-work congestion causes Reno to back down the sending datarate unnecessarily, resulting in significant performance degra-dation , , .
To tackle this problem, we can break it down to two parts:1) How to distinguish between random loss and congestion lossand 2) How to make use of that information to refine the con-gestion-window adjustment process in Reno.
In 1994, TCP Vegas , which employs proactive conges-tion detection, was proposed with the claim of being able toachieve throughput improvement ranging from 37% to 71%compared with Reno. Reference  reproduced the claimsmade in  and showed that by reducing packet loss andsubsequent retransmissions, Vegas could indeed offer higherthroughput than Reno. Recent work , , , however,showed that the performance of Vegas connections degradessignificantly when they coexist with other concurrent Renoconnections. The bias against Vegas is particularly severe inasymmetric networks .
Despite its limitations, an innovative idea in Vegas is that ituses a very simple mechanism to gauge the network condition.Instead of using Vegas estimate on the network conditionto prevent packet loss proactively, we could use it to deter-mine whether packet losses are likely to be due to networkcongestion or random phenomena. Specifically, if a packetloss is detected while the estimate indicates that the networkis not congested, we could declare that the loss is random.
0733-8716/03$17.00 2003 IEEE
FU AND LIEW: TCP VENO 217
Reno could be modified so that it reduces the sending rate lessaggressively when random loss is detected, thus preventingunnecessary throughput degradation. We refer to the algorithmthat combines these ideas from Vegas and Reno as Veno.1
Over the past few decades, TCP has been extensivelystudied , , , , , , , . Numerousproposals , , , , , , , , were presented to improve TCP performance. However,if practical deployment issues and overall evaluation overthe heterogeneous networks were to be considered , mostproposals do not compare well with Reno. Reno remains thedominant version used in practice. This paper is an attempt todemonstrate that Veno is a viable enhancement to Reno.
Based on extensive network testbed experiments and live In-ternet measurements, we show that Veno can achieve signifi-cant throughput improvements without adversely affecting otherconcurrent TCP connections in the same network, includingconcurrent connections that make use of the legacy Reno im-plementation. We present evidence, showing that Veno derivesits improvement from its efficiency in tapping unused band-width, not from hogging network bandwidth at the expense ofother TCP connections. In wireless networks with random lossof 1%, throughput improvement of up to 80% can be demon-strated. Veno involves only modification of Reno on the senderside without requiring any changes of the receiver protocol stackor intervention of the intermediate network nodes. It can there-fore be deployed immediately in server applications over thecurrent Internet, coexisting compatibly with the large installedbase of Reno.
The rest of this paper is organized as follows. Section II de-scribes the Venos mechanism. It presents the observations thatled us to the refined multiplicative decrease and additive in-crease algorithms. In Section III experimental results are firstlypresented to show the ineffectiveness of the refined algorithms,and then a comprehensive evaluation of the Venos performanceover real network and live Internet are demonstrated. Section IVcontains the conclusions and suggestions for future work.
II. TCP VENO
Distinguishing between congestion loss and random loss, andproviding different measures to deal with them, is a fundamentalproblem that remains unsolved for TCP. Veno makes use of amechanism similar to that in Vegas to estimate the state of theconnection, nonetheless, such a scheme is used to deduce whatkind of packet losscongestion loss or random lossis mostlikely to have occurred, rather than to pursue preventing packetloss as in Vega. If packet loss is detected while the connectionis in the congestive state, Veno assumes the loss is due to con-gestion; otherwise, it assumes the loss is random.
Veno makes use of a mechanism similar to that in Vegas toestimate the state of the connection, nonetheless, such a schemeis used to deduce what kind of packet loss congestion loss or
1TCP Veno has been implemented in NetBSD1.1, FreeBSD4.2 and Linux 2.4.Its enhanced version with selective acknowledgement (SACK) option has alsobeen implemented, its source codes are available by email request, for more de-tailed work, please see the reference  and  documented in July 2001, wealso noticed that at same time another modified TCP called Westwood pro-posed an alternative approach to deal with TCP suffering in wireless networks.
random loss -- is most likely to have occurred, rather than topursue preventing packet loss as in Vegas.
A. Distinguishing Between Congestive and NoncongestiveStates
In Vegas , the sender measures the so-called Expected andActual rates
where cwnd is the current TCP window size, BaseRTT isthe minimum of measured rou