Delay%20Tolerant%20Networks

1
Delay Tolerant Networks

• Arezu Moghadam
• PhD Candidacy Talk
• 12/18/2007

2
Networking expansion
Pervasive computing
P2P overlays
CDN Pub/sub
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
ZebraNet (a real life application)
First deployment in 2004 in Kenya
Sensor Network Attributes ZebraNet Other Sensor Networks
Node mobility Highly mobile Static or moderate mobile
Communication range Miles Meters
Sensing frequency Constant sensing Sporadic sensing
Sensing device power Hundreds of mW Tens of mW
http//www.princeton.edu/mrm/zebranet.html
5
DTN characteristics

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

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

gt
15
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!

MED (Minimum Expected Delay) Modified Dijkstra alg with time varying costs based on average edge waiting time. Contact summery (avg. waiting time until next contact)
gtgt
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?
gtgt
Ref 15 , 16
18
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 (dont wait
for B)
gtgt
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.

B C
.5 .5
A
C
A B D
.4 .2 .4
B
A C D
.4 .1 .5
D
B C
.6 .4
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.

B C
.5 .5
A
C
A B D
.4 .4 .2
B
A C D
.4 .4 .2
D
B C
.6 .4
Ref 10, 12, 13, 14
21
Probabilistic routing
MobySpace 10 Closest mobility pattern. How? (Dimension could grow dramatically!?)
PROPHET 13 Delivery predictability
RPLM 12 Routing with persistent link modeling Cost window
MaxProp 14 Delivery probability Cost of using each node as relay
gt
gt
gtgt
22
Issues of the probabilistic routing.
High rank
Low rank
Packets with hop counts lt thresh Sorted by hop
count
Packets with hop counts gt 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
Model objective Delivery ratio Delay Message redundancy Knowledge
Flooding High Low (the least) High ? Buffer congestion Zero
Knowledge based MF the highest (even higher than ER) Moderate Low Provided to the algorithm
Probabilistic Close to ER with tendency in mobility Close to ER with tendency in mobility Moderate Memory (learning from past)
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
Routing models.
28
Routing models contd
gtgt
29
Performance
Model objective Model objective Delivery ratio Delay Message redundancy Topology Knowledge
Flooding Flooding High (the best) Low High ? Buffer congestion Not required
Tree based Tree based Moderate High Low Required
MF ER GR close to ER Low High Ferry location
MF ER GR Moderate (large group close to ER) Moderate Low Ferry location
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.
• Batched requests 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
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 nodes 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.

MED Dijkstra with time varying costs based on average edge waiting time. Contact summery (avg. waiting time until next contact)
ED (Earliest delivery) Dijkstras with time varying costs based on edge waiting time. Contacts (no knowledge of queues)
EDLQ (ED with local queue) ED with local queuing information. Contacts (data queues for the contact at the current time)
EDAQ ED with global queuing information. Contacts Buffer (queue sizes across entire topology)
LP Linear programming All traffic
39
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 doesnt differentiate between carriers X
  and Y.

42
Erasure Routing

• Transforms a message of n blocks to a message of
  gt 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
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