Scalable Network and Transport Protocols AINS Project review, Aug 4, 2004

1. Scalable Network and Transport ProtocolsAINS Project review, Aug 4, 2004 PI: Mario Gerla Students: Yeng Lee, JS Park, Guang Yang, Kelvin Zhang, Alok Nadan, Jiwei Chen, Ling Jhy Chen, Tony Sun Post Doc: JJ Kong CS Dept,UCLA Network Research Lab gerla@cs.ucla.edu http://www.cs.ucla.edu/NRL

2. The challenges • Tens of thousands of (mobile) nodes • Group communications support • QoS requirements • Hostile environment Project Goals • Scalable, robust and secure protocols (routing, multicast, TCP, video streaming) UCLA/CSD

3. Project Tasks • MAC Protocols: • MIMO and Beamforming features • MIMO MAC; SPACE MAC • Integration of MAC and Network Layer • Scalable Routing: • Leverages group motion • Integration with mobile backbone • QoS support • Robust to mobility • Scalable Multicast: • Team oriented, reliable multicast; • TCP: • fair behavior in an ad hoc environment (NRED) • TCP in mobile, disruptive environments • Delay tolerant delivery • TCP Westwood; CapProbe; Ad Hoc Probe • Adaptive video streaming: • end to end and network feedback (VTP) • Security • Anonymous routing in mobile net; Secure multicast UCLA/CSD

4. What we will do with the $$$ left? • Delay tolerant networking • Robust transport (TCP, streaming) over mobile, unreliable nets • Will not do • Implementation of delay tolerant network protocols • Implementation of MIMO MAC protocols on MIMO radios • Integrated testing of video over dynamic, mobile nets • Integration with other efforts leading do integrated demo UCLA/CSD

5. TCP over Geo-routing in Mobile and Lossy Ad Hoc Nets Mario Gerla and Jiwei Chen

6. Georouting - Key Idea • Each node knows its geo-coordinates (eg, from GPS or Galileo) • Source knows destination geo-coordinates; it stamps them in the packet • Geo-forwarding: at each hop, the packet is forwarded to the neighbor closest to destination • Options: • Each node keeps track of neighbor coordinates • Nodes know nothing about neighbor coordinates UCLA/CSD

7. Geo routing – key elements • Greedy forwarding • Assume each nodes knows own coordinates • Source knows coordinates of destination • Greedy choice – “select” the most forward node UCLA/CSD

8. Got stuck? Perimeter forwarding UCLA/CSD

9. Greedy Perimeter Stateless Routing (GPSR) D is the destination; x is the node where the packet enters perimeter mode; forwarding hops are solid arrows; UCLA/CSD

10. Case #1: vertical motion(nodes in each column move up and down) UCLA/CSD

11. TCP over GPSR and AODV Throughput (Kbps) Speed(m/s) UCLA/CSD

12. Case #2: Random Motion 40 nodes in 1000mx1000m UCLA/CSD

13. TCP over GPSR, AODV, DSR and DSDV Throughput (Kbps) Speed(m/s) UCLA/CSD

14. Conclusions • Georouting is very robust to mobility • In a dense network, even when nodes move, there is always a neighbor in the right direction • TCP is extremely sensitive to path breakage (timeouts etc) • It does very well with georouting • Caveat: georouting requires knowledge of destination geo coordinates UCLA/CSD

15. “Direction” forwarding for mobile, large scale ad hoc networks Mario Gerla, Yeng-Zhong Lee, Biao Zhou, Jason Chen UCLA, CSD, Los Angeles CA Antonio Caruso University of Lecce, Italy

16. Distance Vector routing • Main routing scheme in the Internet • It is the foundation of all dissemination/advertising based schemes • LANMAR, AODV, DSDV, Directed Diffusion etc • It consists of dissemination of scouting pkts from sink; this forms a Tree • the source follows shortest path in the grid UCLA/CSD

17. Distance Vector not robust to mobility • In Distance Vector Routing, node keeps pointer to “predecessor” DV update Predecessor Data flow Source Sink • When the predecessor moves, the path is broken • Alternate paths, even when available, are not used • Current solution is to refresh more frequently -> O/H!!! • Proposed solution: direction forwarding UCLA/CSD

18. Direction Forwarding • Distance Vector update creates not only “predecessor”, but also “direction” entry DV update Predecessor Data flow Source Sink “Direction” to Sink • Select “most productive” neighbor in forward direction • If the network is reasonably dense, the path is salvaged UCLA/CSD

19. How to compute the “direction” • Need “stable” local orientation system (say, virtual compass) to determine direction of update • GPS will do (e.g., neighbors exchange (X, Y) coordinates) • But, if I have GPS, I may as well use Geo Routing (more later) • Several non-GPS coordinate system have been recently proposed • Sextant [Mobihoc ’05]; beacon DV; RFID’s etc • Local (rather than global) reference is required; • Local reference system must be refreshed fast enough to track avg local motion UCLA/CSD

20. “Direction” to a destination C A B Computation of the “direction” Suppose node A receives DV update packets from B & C • Compute the “directions” to predecessors node B & C, respectively, Where the polar angle is the radian from the x-axis that is used as the direction of the predecessor node. Directions to predecessors Computation of the “direction” • Unit vectors are used to combine the two “directions” UCLA/CSD

21. Direction Forwarding vs Geo routing • Geo-routing: • Direction points to destination • This direction may be unfeasible (holes, etc) • Global geo-coordinates (eg, GPS) • Geo Location Server • Robust to mobility • Directional Forwarding • Direction of updates (always feasible) • Local position reference system • Advertisements from destination • Robust to mobility UCLA/CSD

22. Logical Group Landmark Case study: apply Direct Forwarding (DFR) to LANMAR Routing • LANMAR builds upon existing routing protocols • (1) “local ” routing algorithm that keeps accurate routes within local scope < k hops (e.g., OLSR, FSR) • (2) Landmark routes advertised to all mobiles using a Distance Vector approach

23. Logical Subnet Landmark LANMAR (cont) • A packet to “local” destination is routed directly using local tables • A packet to remote destination is routed to Landmark corresponding to logical address • Once the landmark is “in sight”, the direct route to destination is found in local tables.

24. LANMAR +DFR • LANMAR has proved to be very scalable to size • However, as speed increases, performance degrades, even with group mobility! • Problem was traced to failure of DV route advertising in high mobility • We first tried to refresh more frequently: it did not work! • Next step: try DFR UCLA/CSD

25. Simulation Experiments • Simulator: QualNet 3.8 • Standard IEEE 802.11 radio with a channel rate of 2Mbps and transmission range of 367 meters. • Network field size: 2250m by 2250m • LANMAR is the protocol “hosting” DFR • 225 nodes (or 360 nodes) equally distributed in 9 groups • Mobility model: Group Mobility model • Traffic: CBR, 1 packets/sec, 512 bytes/packet • The # of source-destination pairs is varied in the simulations to vary the offered traffic load UCLA/CSD

26. Performance as a function of speed DFR LANMAR Delivery ratio vs. speed (Including packet loss due to disconnected destination) UCLA/CSD

27. Performance as a function of speed (cont.) DFR LANMAR Delivery ratio vs. speed (Excluding packet loss due to disconnected destination) UCLA/CSD

28. Conclusions and Future Work • DFR: new forwarding strategy for table driven routing • Direction Forwarding can improve LANMAR performance dramatically at high speeds • Future Work: • Test LANMAR + DFR under local reference system • Apply DFR concept to AODV • TCP over {LANMAR, AODV} + DFR • Compare DFR with other backup route schemes • Test DFR under more general mobility models UCLA/CSD

29. Thank You !!! http://www.cs.ucla.edu/NRL UCLA/CSD