TCP Behavior across Multihop Wireless Networks and the Wired Internet Kaixin Xu, Sang Bae, Mario Gerla, Sungwook LeeComputer Science DepartmentUniversity of California, Los Angeles, CA 90095(xkx, sbae, gerla, swlee)@cs.ucla.edu, http://www.cs.ucla.edu/NRLThis work is supported in part by ONR “MINUTEMAN” project under contract N00014-01-C-0016 and TRW under a Graduate Student FellowshipMotivationl Connecting ad hoc networks to the Internet¡ Access web, download files, upload data, multimedia streaming etc.¡ TCP efficiency critical l New challenge:TCP performance on wired + multihop wireless path¡ Different from “last hop” wireless networks (e.g. wireless LAN)¡ Different from “pure ad hoc” networks; the wired part introduces high propagation delaysTarget Scenariol Connecting an ad hoc network to the Internet¡ Wireless part is an independent, self managed network¡ Mobile node Internet access through multiple gateways¡ Web access, file download, multimedia streamingl Multimedia Challenges : ¡ TCP: Long propagation delay -> large congestion window; error vs congestion loss¡ Video Streaming: congestion control; friendly to TCPInternetServerServerGatewayGatewayGatewayMobile NodeAn example ad hoc networkTestbed Measurementsl Testbed Configuration¡Dell 1 GHz Pentium III Inspiron 4000 laptops¡Lucent Orinoco 802.11 wireless card, 2M bps¡FTP server : Located in the Internet, Running RedHatLinux 6.0¡Wireless client : Mandrake Linux 8.1¡TCP : TCP New Reno, MSS=1460 bytesl Performance metrics¡throughput; fairnessTestbed MeasurementsTwo Scenarioso Scenario A: “last hop” wireless network (wireless LAN)¡ Scenario B: multihop ad hoc wireless network¡ FTP flows in different directions are investigated¡ Each FTP transmits a 1MB or 8MB fileScenario A1 2131.179.25.21 131.179.25.26131.179.25.24poseidon.csr.unibo.itFTP 1FTP 2Internet3131.179.25.21 131.179.25.22131.179.25.24poseidon.csr.unibo.itFTP 1FTP 2Internet131.179.25.30 131.179.25.264 3 5 21Scenario BScenario AScenario BFairness among Multiple TCP Flowsl Scenario A (W-LAN): No significant unfairness (not shown here)l Scenario B : Significant capture/unfairness when there are OUT flows( OUT flow : wireless->wired, IN flow : wired->wireless)Scenario B : Mixed flows (IN flow captures the channel; OUT flow starts after it)IN flowOUT flowIN flowOUT flowBoth flows transmit a 1M file Both flows transmit a 8M fileFairness (cont)l Unfairness is observed even when there are only OUT flows( OUT flow : wireless->wired)Scenario B : Only OUT flows (Significant unfairness observed)OUT flow 1OUT flow 2Both flows transmit a 1M fileTCP Unfairness:l TCP flows from wired to wireless tend to capture the channel from flows in other directionl Even when all TCP flows originate from wireless, they cannot share the bandwidth in a fair way l TCP flows from wired to wireless can share the bandwidth equallyLessons learned with TCP131.179.25.21131.179.25.22131.179.25.24poseidon.csr.unibo.itFTP/TCPVideo/UDPInternet131.179.25.30131.179.25.244 3 5 21TCP Coexistence with Video Streamsl Video streams: CBR/UDP flows with various ratesl Scenario B ( multihop)l TCP flow: from node 1 to the wired server, transmitting a 8M filel Video stream: from node 2 to the wired serverl Different rates of the video streams: from 80Kbps to 800Kbpsl Packet size: 1460 BytesCoexistence of TCP/Video streamsl Low rate video (80Kbps) has minimal impact on TCP performancel When the video rate increases (540Kbps), TCP throughput degrades, but no capture is observedTCPVideo80Kbps video stream 540Kbps video streamTCPVideoCoexistence of TCP/Video streamsl Surprisingly, when video rate is further increased to 800Kbps, TCP throughput gets better !l High rate video streams block themselves at the source nodes ¡ The source node and its next hop node compete for the same channel¡ High transmission rate from source blocks the next hop (heavy drops!)TCPVideo800Kbps video streaml TCP performance is affected by video streams. However, no capture problem is observedl At high tx rate, video performs poorly due to source node and next hop interferencel For best performance, video rate must be carefully controlled in ad hoc networks (ideally, with feedback control like TCP)Summary of the TCP/Video ExperimentsReasons of TCP Unfairnessl Hidden and Exposed Terminal Problemsl Binary Exponential Backoff (BEB) of 802.11 favors the last successful nodel TCP own timeout and backoff worsen the unfairnessl Lack of “cooperation” between TCP and MAC2 3 4G1link to the wired networkData PacketRTSIN flowOUT flowGatewayIN flowOUT flow2 3 4G1link to the wired networkData PacketRTSOUT flowOUT flowGatewayOUT flowOUT flowHidden and exposed terminal problem with mixed flowsHidden and exposed terminal problem with only OUT flowsOptimal TCP Window Sizel Scenario B, IN + OUT traffic with varying max TCP window sizel There exists an optimal TCP window size (8 packet in our case): The aggregated throughput reaches upper limit; the two flows share the channel bandwidth fairlyl Unfortunately, the optimal max Window cannot be preconfiguredl And, TCP cannot independently stabilize at such optimal window => unfairness!!!IN flowOUT flowIN + OUT flowProblems Caused by Wired Part!!l Repeat last experiment without the wired part¡ Can achieve reasonable fairness in a pure ad hoc network by preconfiguring the maximum TCP window to 1 or 2 packets (typically, performance peaks at W=2; no gain for W>2)l Problem caused by wired part¡ Large window is needed (large RTT); cannot preconfigure WIN flowOUT flowIN flow + OUT flow4 5FTP 2FTP 1231Scenario B without wired part (mixed traffic)l TCP across wired/wireless networks presents new problems (with respect to wired or wireless alone)¡ The wired part introduces long propagation delay and thus the need for large window (for efficiency)¡ TCP flows across wired/wireless experience significant capture/unfairness¡ Video streams also are vulnerable to congestion collapse¡ Fundamental causes rooted in MAC layer¡ 802.11 MAC modifications are investigatedSummaryThank
View Full Document
Unlocking...