Delay Tolerant Networks

1. Delay Tolerant Networks Arezu Moghadam PhD Candidacy Talk 12/18/2007

2. Networking expansion CDN Pub/sub P2P overlays Pervasive computing Sensor nets wireless DTN Internet 2000 Applications rule! 1990 Internet ATM 1970 1980 B-ISDN OSI

3. Interplanetary communication Ref: [1] Picture: http://www.intel-research.net/berkeley

4. Tracking node with CPU, FLASH, radio and GPS Data Store-and-forward communications Data Data Data ZebraNet (a real life application) First deployment in 2004 in Kenya http://www.princeton.edu/~mrm/zebranet.html

5. Internet environment End-to-end RTT is not large. Some path exists between endpoints. E2E reliability using ARQ works well. Packet-switching is the right abstraction. DTN characteristics Very large delays. Intermittent and scheduled links. Different network architectures. Conversational protocols fail. No ARQ. DTN characteristics Ref: [2], [3]

6. Agenda • Architecture • Routing • Multicast • Implementation • Conclusion

7. Architectural requirements • Asynchronous message delivery. • Naming • Tuples (names): ordered pairs (R, L) • No ARQ • Reliability • At least Hop-by-hop. • Type of links • Scheduled vs. non-scheduled. • Contact, an opportunity to transfer the data. • Predictable vs. opportunistic. Ref: [2], [3], [6]

8. Persistent message storage A Data S R B Intermittent link “Always on” link R provides store-and-forward service Reliability • End-to-end vs. per-hop reliability. • Custody transfer • Not delete a message until delivery to another custodian. • Head of line blocking. • Even “always on” link is blocked. Ref: [4]

9. Interplanetary or satellite GW Internet GW Sensors GW Bus route Suggested architectures • Sequential heterogeneous regions interconnected by gateways. • ParaNet • Users access more than one network over one device. • Different paths for signaling and data. • Challenges • Routing, transport protocol, naming, security over multiple paths and etc. Ref: [2]

10. Data or control information over satellite DTN Store and forward Lightweight cellular network for signaling Suggested architectures • Sequential heterogeneous regions interconnected by gateways. • ParaNet • Users access more than one network over one device. • Different paths for signaling and data. • Challenges • Routing, transport protocol, naming, security over multiple paths and etc. Ref: [5]

11. Agenda • Architecture • Routing • Multicast • Implementation • Conclusion

12. Routing Challenges • Routing objectives: • Minimize delay • Maximize throughput • Per-hop routing vs. source routing. • No end-to-end path • MANET’s routing protocols fail. • Proactive and reactive • Store-carry-forward • Storage constraints • No Topology knowledge • Time varying connectivity graph Ref: [8]

13. Routing Models • Flooding based protocols • Epidemic [18], Erasure coding [11] • Knowledge based routing • Oracle [8], Message Ferrying [15], [16], Practical routing [9] • Probabilistic routing • PROPHET [13], RPLM [12], MaxProp [14], MobySpace [10]

14. Flooding based routing • Epidemic [18] • Exchanging summary vectors (hash values). • Erasure coding [11] • Use r relays wait for one or rxk relays and wait for k • Message can be decoded if k relays make it to the destination. >

15. u v S w D x Knowledge based routing • An oracle which provides topology info. • Contacts, buffer constraints, traffic demands… [8] • Partial topology info. • Message ferrying [15],[16] • Using history to predict future topology. • Practical routing [9] Each edge is a contact meaning an opportunity to transfer data.

16. Routing with global knowledge • Oracle; source of knowledge about topology • How much knowledge to achieve an acceptable delay. • Modified Dijkstra with time varying edge costs. • Source routing. • The more knowledge the better performance. (too obvious!) • Not realistic! Ref: [8] >>

17. Routing with partial knowledge MF: Sparse MANETs with different deployment areas • Message ferrying • Ferries broadcast their situation. • Ferry route design to minimize drops NP hard  reduced to TSP. • Practical routing • Instead of contact schedules uses contact history. • Per-contact routing vs. per-hop routing. 1 2 3 4 Scalability: How increasing number of mobile nodes affects number of ferries? >> Ref: [15] , [16]

18. D D 2 2 2 2 B C B C 3 8 3 0 A A Routing with partial knowledge • Message ferrying • Ferries broadcast their situation. • Ferry route design to minimize drops NP hard  reduced to TSP. • Practical routing • Instead of contact schedules uses contact history. • Per-contact routing. • Update the graph upon contact changes. Practical routing: Source: A dest: D Per-hop or per-source: A-B-D Per-contact: A-C-D (don’t wait for B) >> Ref: [9]

19. Probabilistic routing • Estimate delivery likelihood. • Initially assign a delivery probability to each node. • Update upon meeting a node based on some criteria. • Link state routing to disseminate probability tables. A C B D Ref: [10], [12], [13], [14]

20. Probabilistic routing • Estimate delivery likelihood. • Initially assign a delivery probability to each node. • Update upon meeting a node based on some criteria. • Link state routing to disseminate probability tables. A C B D Ref: [10], [12], [13], [14]

21. Probabilistic routing > > >>

22. Issues of the probabilistic routing. High rank Low rank Packets with hop counts < thresh Sorted by hop count Packets with hop counts > thresh Sorted by delivery likelihood Packets transmitted from here Packets deleted from here • Covered • No a priori knowledge of contacts. • Storage constraint and buffer management. • Network wide acks to free up buffer space or provide reliable delivery. • Not covered • What initial values to start with to converge to reasonable delivery probabilities? • What if nodes change their habits. How adaptive? • No mathematical proof of efficiency of the routing algorithms. Ref: [14], [12]

23. Mobility model and performance analysis • Node mobility characteristic  better performance analysis. • Algorithms developed for specific scenarios. • Random with core aided nodes. • Community based. • Mixture of RWP and ferries. Ref: [17], [7]

24. Performance evaluation Ref: [7], … , [17]

25. Agenda • Architecture • Routing • Multicast • Implementation • Conclusion

26. Multicast requirements and challenges. • Disaster recovery, battlefield… • Distribution of news to a group of users; • Who is the recipient? • Group membership changes during data transfer. • Routing is the most challenging problem. • Multicast semantics • Temporal membership: each message contains a membership interval. • Delivery interval as well as membership interval. • Current member: receiver should be a member at delivery time. Ref: [19]

27. Group-based routing (UBR) Broadcast-based routing (BBR) R2 R1 R2 R1 S S Epidemic routing to all nodes [19] Forwarding group [19] Routing models.

28. R F Tree-based routing (TBR) R R R R R1 MFER; MF with Epidemic routing [20] R2 R F S R Along the spanning tree containing all receivers [19] R R R MFGR; MF with group routing [20] Routing models contd… >>

29. Performance Ref: [21] , [20] , [19]

30. Agenda • Architecture • Routing • Multicast • Implementation • Conclusion

31. TEK system • Searching WWW using email. • Email-based communication protocol. • TEK server located at MIT. • TEK client a Java proxy server. • Batchedrequests are emailed to the server. Remote TEK Client Req ISP Web Browser TEK Proxy Store-and-forward WWW Rep TEK Server MIT Ref: [23] , [25], [22]

32. Internet 7DS • Based on epidemic routing. • Utilizing opportunistic contacts to pass email messages. • Basic platform to develop store-and-forward applications. Ref: [26]

33. Agenda • Architecture • Routing • Multicast • Implementation • Conclusion

34. Conclusions and future directions • A killer application! • Implementation efforts have been limited to specific not everyday life applications. • When Joint tactical radio system becomes available? [25] • ParaNet!? • Challenges: topology estimation and routing. • So far research focus on predictable network topologies. • Knowledge based approaches requiring a global view of the network are unrealistic. • Hybrid of MF with probabilistic routing!? • Absence of real world mobility patterns in algorithms evaluations. • Security issues still not discussed! • Lack of common APIs to abstract DTN.

35. References • Papers list

36. Back up slides…

37. Probabilistic routing criteria • PROPHET • Delivery predictability calculation. • Routing with Persistent Link Modeling (RPLM) • Monitors link connectivity to calculate its cost. • Dijkstra to find a minimum cost path. • MaxProp • Assigning a cost value to each destination based on probability. • Priority queue  younger messages higher chances. • MobySpace • MobyPoint  each node’s coordinates or mobility pattern. • Distance on each axes probability of contacts or presence in a location.

38. Routing with global knowledge • Message arrival time at a node must be predicted. • Predicted arrival time is used to determine the cost • At light load ED performance comparable to EDAQ and EDLQ. • Heavy traffic results in congested queues  Algorithms with queue knowledge are the winners.

39. H T T T H H VANETS • Propagation of location specific information. • Directional propagation protocol • Custody transfer protocol • Inter-cluster routing protocol • Intra-cluster routing protocol • Routing based on local parameters and TTL • Routing in the absence of a global naming scheme. • Ex: traffic data to cars 5 miles away… West East

40. PROPHET • Delivery predictability is calculated at each node for all destinations B; P(A,B) • When node A encounters node B the parameter P(A,B) is updated. • Packet transfer if delivery predictability at new node is higher than current one.

41. Link Cost History • Idea is cost is related to the duration of connectivity. • Link with high transitions will get connected soon. • Compared with PROPHET • Single forwarding • Multi-forwarding • PROPHET doesn’t differentiate between carriers X and Y.

42. Erasure Routing • Transforms a message of n blocks to a message of > n blocks. • Receiver can recover the original message from a subset of blocks • Fraction of the required blocks is the ratio r. • 1/r blocks are necessary • Instead of propagating among r relays as in srep distributes them among rk • Whether to use r relays and wait for one to succeed or to use rk relays and wait for k to succeed? • Worst case scenario

43. D D 2 2 2 2 B C B C 3 8 3 0 A A Practical routing • MEED Minimizing estimated expected delay. • Using the contact history instead of contact schedule. • Nodes record connection and disconnection periods over a sliding window. • Propagating link state table. • Per-contact routing instead of source or per-hop routing.

44. Practical routing simulation • Wireless LAN traces converted into a DTN scenario • Nodes are connected when associated to the same AP

45. Message Ferrying – Single • Node Initiated MF • The ferry moves according to a specific route • Nodes make proactive movement to meet up with ferry • Message drops: buffer overflow or message time out • Nodes task time vs. meeting the ferry Ferry Initiated MF • Long range radios in nodes. • Service_Request • Location_Update • Ferry trajectory control based on minimizing message drop rate along the path. • NP-hard problem • Nearest Neighbor • Traffic aware

46. Message Ferrying – Multiple • To allow scalability in traffic load • Single ferry single point of failure • Different scenarios • No interaction • Ferry relaying • Node relaying • Designing the ferry routes to minimize weighted delay.

47. Ferry route design • Assigning nodes to ferries to minimize weighted delay. • Optimization problem with BW constraints • The higher the data rate the longer the route length.

48. Multicasting with MF • Long-duration partitions makes multicast forwarding structure spanning all group members difficult. • Hybrid approach for Ferry initiated MC • Message Ferry with Epidemic Routing • Message Ferry with Group Routing • Adaptive Scheme