200 likes | 346 Views
Multipath TCP in a Lossy ad hoc Wireless Network. Medhocnet 2004 Bodrum, June 2004 Jiwei Chen, Kaixin Xu, Mario Gerla UCLA. Background. In a mobile ad hoc network subject to interference the predominant cause of packet loss is not buffer overflow or congestion , rather :
E N D
Multipath TCP in a Lossy ad hoc Wireless Network Medhocnet 2004 Bodrum, June 2004 Jiwei Chen, Kaixin Xu, Mario Gerla UCLA
Background • In a mobile ad hoc network subject to interference the predominant cause of packet loss is not buffer overflow or congestion, rather : • Path breakage due to mobility • Random errors caused by interference, jamming, path obstruction, etc • Conventional TCP performs poorly in “random” loss: • Loss triggers RTO (Retx Time Out) • RTO Exponential backoff -> reduced throughput • Enter: Multipath TCP
Previous Work on Using Multiple Paths • Alternate use (primary and backup) • It works OK for CBR traffic (eg, Bypass - DSR, Node Disjoint M-path AODV, BSR, etc) • TCP does not get much benefit • Backup path is used only after timeout; not efficient in mobility/errors ? • Concurrent use (ie, packet scattering) • MSR • TCP does well in a static, error free net with long patths (up to 50% improvement) • With mobility & errors, TCP suffers; out-of-order problems because of RTT difference on the two paths
“TCP Performance on multiple paths in ad hoc nets..” Liaw et al ICC 2004 Static net, no errors, opt W: max improvement 50%; typical improvement between 8% and 18%
Multiple Path TCP • Improve end-to-end route robustness when single route is not stable: • Replicate packet on multiple paths • Combat random, non correlated link losses • Combat path breakage
Multipath TCP with Packet Replicas • First step: Find Non-Interfering Paths in DSR • Modified version of DSR • Every node forwards duplicate RREQ if and only if the RREQ includes a path shorter than the previous RREQ (currently, all dup RREQs are dropped) • Interim nodes stamp neighbor info in RREP • The destination will reply (with RREP) only if the new path is not interfered by first path • Sender selects the first two non interfering paths
Overhead • Routing overhead • More RREQs sent, but only on shorter paths • Neighbor maintenance, passively listening, negligible • More RREPs, negligible O/H • TCP data packet duplication on multiple paths • This is definitely a major overhead penalty • Acceptable if only one connection is using the medium • May introduce less O/H than repeated end to end retransmissions
Simulation Experiments • NS-2 simulation • Static and dynamic scenarios • With and w/o random errors • 802.11b • DSR disjoint (non interfering) multipath • 50 nodes in 3000m x 500m
Static Network Only one TCP connection, disjoint paths
original TCP MultipathTCP No Random Loss Sequence Number Acked Time
original TCP MultipathTCP With Random Loss: 5% Sequence Number Acked Time
original TCP MultipathTCP With Random Loss: 5%(cont.) Instantaneous Throughput (bits/s) Time
Dynamic Network • 50 nodes randomly placed within a 3000m x 500m area • Each node moves continuously • Speed ranges from 10m/s to 40m/s • 25 different trace files for each speed • 25 simulation runs for each trace file • Average results are shown
Variable Loss Rate [ 0.05; 0.1; 0.15; 0.2] Total Throughput (bits/s) Mobility (m/s) Original TCP Multipath TCP
Conclusions • Multipath TCP: • Sender-side only modification; TCP must not “overreact” to duplicates ACKs (due to duplicate deliveries) • Limited extra routing O/H; • needs new DSR header field for neighbor info • Positive result: it improves end to end reliability when net is very lossy • Negative result: does not work well in very mobile environment (ie, predominant cause of loss is path breakage) • The overhead introduced by frequent multiple path break up and re-computation offsets the benefit of path redundancy
Future Work • Monitor loss rate and decide when to use multipath. • Eliminate duplicate ACKs caused by data replication. • Limited Flooding scheme, eg. ODMRP • Need a “motion robust” routing scheme: • Enter Geo Routing
TCP over Geo-routing Fast vertical motion(nodes in each column move up and down)
TCP Performance (GPSR vs AODV)Note: no change in TCP Throughput (Kbps) Speed(m/s) • TCP over AODV collapses with increasing speed (RREQ O/H) • TCP over Geo-Routing is almost insensitive to speed • RTO optimization makes no difference
Hot spot Congestion Aware GPSR • Problem: • Congestion area will cause long packet delay and high loss probability • Our approach: • Go around the congestion area will decrease the delay, but detour path is usually longer than the shortest path. Going through the long path will cause throughput loss. • Study packet delay, the tradeoff between congestion detour and throughput gain.