TCP Behavior across Multihop Wireless Networks and the Wired InternetTarget ScenarioTestbed MeasurementsSlide 5Fairness among Multiple TCP FlowsFairness (cont)Lessons learned with TCPTCP Coexistence with Video StreamsCoexistence of TCP/Video streamsSlide 11Summary of the TCP/Video ExperimentsOptimal TCP Window SizeProblems Caused by Wired Part!!SummarySlide 17TCP 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 FellowshipTarget ScenarioConnecting an ad hoc network to the InternetWireless part is an independent, self managed networkMobile node Internet access through multiple gatewaysWeb access, file download, multimedia streamingMultimedia Challenges : TCP: Long propagation delay -> large congestion window; error vs congestion lossVideo Streaming: congestion control; friendly to TCPI n t e r n e tS e r v e rS e r v e rG a t e w a yG a t e w a yG a t e w a yM o b i l e N o d eA n e x a m p l e a d h o c n e t w o r kTestbed MeasurementsTestbed ConfigurationDell 1 GHz Pentium III Inspiron 4000 laptopsLucent Orinoco 802.11 wireless card, 2M bpsFTP server : Located in the Internet, Running RedHat Linux 6.0Wireless client : Mandrake Linux 8.1TCP : TCP New Reno, MSS=1460 bytesPerformance metricsthroughput; fairnessTestbed MeasurementsTwo ScenariosoScenario A: “last hop” wireless network (wireless LAN)Scenario B: multihop ad hoc wireless networkFTP flows in different directions are investigatedEach FTP transmits a 1MB or 8MB fileS c e n a r i o A1 21 3 1 . 1 7 9 . 2 5 . 2 1 1 3 1 . 1 7 9 . 2 5 . 2 61 3 1 . 1 7 9 . 2 5 . 2 4p o s e i d o n . c s r . u n i b o . i tF T P 1F T P 2I n t e r n e t31 3 1 . 1 7 9 . 2 5 . 2 1 1 3 1 . 1 7 9 . 2 5 . 2 21 3 1 . 1 7 9 . 2 5 . 2 4p o s e i d o n . c s r . u n i b o . i tF T P 1F T P 2I n t e r n e t1 3 1 . 1 7 9 . 2 5 . 3 0 1 3 1 . 1 7 9 . 2 5 . 2 64 3 5 21S c e n a r i o BScenario AScenario BFairness among Multiple TCP FlowsScenario A (W-LAN): No significant unfairness (not shown here)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)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:TCP flows from wired to wireless tend to capture the channel from flows in other directionEven when all TCP flows originate from wireless, they cannot share the bandwidth in a fair way TCP flows from wired to wireless can share the bandwidth equallyLessons learned with TCP1 3 1 . 1 7 9 . 2 5 . 2 11 3 1 . 1 7 9 . 2 5 . 2 21 3 1 . 1 7 9 . 2 5 . 2 4p o s e i d o n . c s r . u n i b o . i tF T P / T C PV i d e o / U D PI n t e r n e t1 3 1 . 1 7 9 . 2 5 . 3 01 3 1 . 1 7 9 . 2 5 . 2 44 3 5 21TCP Coexistence with Video StreamsVideo streams: CBR/UDP flows with various ratesScenario B ( multihop)TCP flow: from node 1 to the wired server, transmitting a 8M fileVideo stream: from node 2 to the wired serverDifferent rates of the video streams: from 80Kbps to 800KbpsPacket size: 1460 BytesCoexistence of TCP/Video streamsLow rate video (80Kbps) has minimal impact on TCP performanceWhen the video rate increases (540Kbps), TCP throughput degrades, but no capture is observedTCPVideo80Kbps video stream 540Kbps video streamTCPVideoCoexistence of TCP/Video streamsSurprisingly, when video rate is further increased to 800Kbps, TCP throughput gets better !High rate video streams block themselves at the source nodes The source node and its next hop node compete for the same channelHigh transmission rate from source blocks the next hop (heavy drops!)TCPVideo800Kbps video streamTCP performance is affected by video streams. However, no capture problem is observedAt high tx rate, video performs poorly due to source node and next hop interferenceFor best performance, video rate must be carefully controlled in ad hoc networks (ideally, with feedback control like TCP)Summary of the TCP/Video ExperimentsOptimal TCP Window SizeScenario B, IN + OUT traffic with varying max TCP window sizeThere exists an optimal TCP window size (8 packet in our case): The aggregated throughput reaches upper limit; the two flows share the channel bandwidth fairlyUnfortunately, the optimal max Window cannot be preconfiguredAnd, TCP cannot independently stabilize at such optimal window => unfairness!!!IN flowOUT flowIN + OUT flowProblems Caused by Wired Part!!Repeat last experiment without the wired partCan 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)Problem caused by wired partLarge window is needed (large RTT); cannot preconfigure WIN flowOUT flowIN flow + OUT flow4 5F T P 2F T P 1231Scenario B without wired part (mixed traffic)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/unfairnessVideo streams also are vulnerable to congestion collapseFundamental causes rooted in MAC layer802.11 MAC modifications are investigatedSummaryThank
View Full Document
Unlocking...