Performance Enhancement of TFRC in Wireless Networks

The TCP-Friendly Rate Control (TFRC) is used as a streaming media transport protocol. Using the TCP congestionresponsefunction and curr ent network conditions, TFRC adjusts its transmission rate to yield the maximum TCP-Friendly thr oughput when sharing capacity with TCP flows. Since TFRC was designedfor wir ed networks, it doesnot achieve the maximum TCP-Friendly thr oughput in multihop ad hoc wir elessnetworks. The reduced wir elessspatial channel reusedue to hidden terminals in multihop wir elessnetworks inducesTFRC thr oughput reductions. Specifically, TFRC is unaware of MAC layer transmission delaysdue to collisions, retransmissions and MAC layer congestion. This paper illustrates that an unmodified TFRC’s sending rate overloads the multihop wir elessMAC layer, leading to increasedround-trip times, higher loss event rates, and lower thr oughput. We proposean enhancementto TFRC, called RE TFRC, that uses measurementsof the curr ent round-trip time and a model of wir elessdelay to restrict TFRC bitrates fr om overloading the MAC layer, while retaining desirableTCP-Friendly characteristics. RE TFRC requires minimal changesto TFRC and no changesto the MAC layer and evaluation of RE TFRC show substantial impr ovementsover TFRC for somewir elessscenarios. Keywords—TCP-Friendly, TFRC, IEEE 802.11,MAC, Ad Hoc, Multihop, Wir eless I . INTRODUCTION The TransmissionControl Protocol (TCP) is the current de factotransportlayer protocolusedin wirelessad hoc networks. Designedto operateover wired networks, TCP canperformpoorly in 802.11wirelessnetworks, as demonstratedby recentresearch[1], [2], [3], [4], [5], [6], [7]. The TCP-FriendlyRateControl (TFRC) protocol[8],1 which wasdesignedto supportrate-basedstreamingmultimediaand telephony applicationsover wired networks, faceschallengessimilar to thatof TCPin wirelessadhoc The Datagram CongestionControl Protocol (DCCP) has proposed to use TFRC as its congestioncontrol mechanism. See http://www.ietf.cnri.reston.v a.us/html.charters/dccp-charter .html. networks. However, to date, there has beenvery little TFRC-relatedwork donefor wirelessnetworks. At the core of TCP/TRFC’ s wirelesschallengeis the wireless Media AccessControl (MAC) layer of IEEE 802.11. 802.11 uses Carrier SenseMultiple Access with Collision Avoidance(CSMA/CA) anda Request-toSend/Clear -to-Send(RTS/CTS)mechanismto reducehidden terminal collisions. However, when the MAC layer is saturated, contentiondelaysandretransmissions caused by the RTS/CTSmechanismbecomethe major causeof TCP/TFRCperformancedegradation. Theseeffects are referredto asRTS/CTSjamming[9] or RTS/CTS-induced congestion[10]. Furthermore,sinceTFRC observes loss eventsaftertheMAC contentionphase,TFRCis unaware of MAC layercongestionanddoesnot compensatefor it. Consequently , TFRCoverestimatesthemaximumsending rate,overloadstheMAC layerandexacerbatesMAC layer congestion.Eventually, a stablestateis reachedin which throughputandround-triptimesaresub-optimal. Previous researchin TCP performanceimprovements over wirelessad hoc network include investigatinglink breakageandroutingfailure issues[1], [2], [4], link layer solutions[3], [7], MAC layersolutions[5], andTCPprotocol modifications[6]. A few recentpapershave focused on methodologiesto improve TCPthroughputby controlling the total numberof packets in flight. Fu et al [7] presenta link layer approachnamedLink-RED (LRED) thatreducesMAC layercollisionsby limiting TCP’ssending window, while Cali et al [5] limit TCP window sizes directly. While thesesolutionssharea commongoalwith ourresearch, aswindow-basedapproaches they arenotapplicableto TFRC,a rate-basedprotocol. Moreover, none of thesestudiesconsiderpacket round-triptimeandpacket lossasmetricsin their optimizations. Our investigationfocuseson solving the problem of the mis-interactionbetweenTFRC and the MAC layer. Specifically, the objective is to make TFRC aware of RTS/CTS-inducedcongestionsuchthat it choosesa nearoptimalsendingratethatavoidsMAC layersaturation.A