1. Multipath TCP in a Lossy ad hoc Wireless Network Medhocnet 2004 Bodrum, June 2004 Jiwei Chen, Kaixin Xu, Mario Gerla UCLA

2. 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

3. 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

4. “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%

5. 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

6. 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

7. 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

8. 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

9. Static Network Only one TCP connection, disjoint paths

10. No Random Loss Time Sequence Number Acked original TCP MultipathTCP

11. With Random Loss: 5% Time Sequence Number Acked original TCP MultipathTCP

12. With Random Loss: 5%(cont.) Time Instantaneous Throughput (bits/s) original TCP MultipathTCP

13. 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

14. Performance w/o random loss

15. Variable Loss Rate [ 0.05; 0.1; 0.15; 0.2] Total Throughput (bits/s) Original TCPMultipath TCP Mobility (m/s)

16. Throughput Gain Mobility(m/s) Throughput Gain 0.1 0.05 0.2 0.15

17. 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

18. 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

19. TCP over Geo-routing Fast vertical motion (nodes in each column move up and down)

20. TCP Performance (GPSR vs AODV) Note: no change in TCP Speed(m/s) Throughput (Kbps) TCP over AODV collapses with increasing speed (RREQ O/H) TCP over Geo-Routing is almost insensitive to speed RTO optimization makes no difference

21. Congestion Aware GPSR Hot spot Problem: Congestion area will cause long packet delay and high loss probability Our approach: 1.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. 2.Study packet delay, the tradeoff between congestion detour and throughput gain.