DRIFT: Efficient Message Ordering in Ad Hoc Networks

1
DRIFT Efficient Message Ordering in Ad Hoc
Networks
Stefan Pleisch
Joint work with Thomas Clouser, Mikhail
Nesterenko, André Schiper EPFL, Kent State
University

• SRDS 2006

2
Background Ad Hoc Networks

• Communication is ad hoc, i.e., no fixed
  communication infrastructure
• Two nodes can communicate if
• they are within transmission range, or
• there is a sequence of intermediate nodes that
  can forward the message from the source to the
  destination (set up by a routing protocol)
• Communication is by broadcast (to all neighbors),
  or by point-to-point (to one neighbor, but still
  a broadcast)
• Shared transmission media and low bandwidth leads
  to interference and message collisions, and thus
  to message losses
• Hidden terminal problem (Allan 1993)
• Maintaining routing information may not be
  feasible if nodes are mobile or have limited
  resources
• flooding is an effective mechanism of reaching
  all nodes in the network without routing
  information
• a source broadcasts a message to its neighbors
• every node rebroadcasts the message once

3
The Need for Total Ordering in Ad Hoc Networks

• Consider a temporary military sensor network
  deployed to protect an extended asset
• communication is multihop and ad hoc
• directives are periodically issued by mobile
  operators
• commands must be delivered in the same order at
  each sensor node to prevent conflicting behavior
  of different network regions
• requires Total Order Multicast
• More applications from traditional fixed
  networks find their way to wireless networks
• Properties of ad hoc networks make total
  ordering of messages challenging

4
Outline

• Total Order Multicast
• Lamports Total Order Multicast Algorithm
• Virtual Flooding
• DRIFT Description
• Example
• Simulation and Experimentation
• Conclusion and Future Work

5
Total Order Multicast

• Communication primitives
• TO-multicast is invoked to send a message to all
  the nodes of the multicast group executed by a
  source node
• TO-deliver is executed to convey the message to
  the application executed by a destination node
• Problem Ensure all messages TO-multicast by any
  source are TO-delivered in the same order at all
  destinations

6
Related Work

• Many total order multicasts in fixed networks,
  see ACM Survey by Defago et al. 2003
• sequencer-based single sequencer decides
  ordering
• asymmetric load on the network
• privilege-based token-holder establishes order
• asymmetric load on the network
• expensive route maintenance among the token users
• destination ordering by agreement among
  destinations
• expensive when man destinations
• communication history ordering based on message
  timestamps
• Few algorithm in ad hoc networks
• sequencer-based in single hop networks
• Bartoli 1998 (Mobile Networks and Applications)
• Anastati et al 1999 (SRDS99)
• privilege-based
• Malpani et al. (IEEE ToMC)
• communication history
• Prakash et al. (ICDCS97), dependency on fixed
  infrastructure
• Lou et al. (IEEE ToMC) use probabilistic
  guarantees

7
Lamports Total Order Multicast Algorithm

• CACM 1978, belongs to the class of communication
  history ordering
• Delivers messages based on the causal order of
  multicasts
• causal relation establishes a partial ordering
• total order achieved by deterministically
  ordering concurrent messages (e.g. by source id)
• Assumes FIFO communication channels and reliable
  messaging, no failures
• Uses logical clocks (Lamports clocks) for
  capturing causal relationship between multicast
  messages
• Source nodes update their logical clock
• prior to sending a multicast
• when the source receives a multicast message it
  has not received before
• Delivery rule Node n can TO-deliver a particular
  message m only after it receives a message with a
  higher or equal timestamp from every source
• Disadvantage the delivery rate of all
  destinations depends on the sending rate of the
  source that multicasts least frequently

8
Virtual Flooding

• Node attaches data to an unrelated message it has
  to broadcast
• Example

Node a has message to physically flood Node
c has a message to virtually flood

• Node a sends m
• Node b forwards m
• Node c attaches virtually flooded message and
  forwards m
• Node d forwards combined message
• Node e forwards combined message

9
DRIFT Key Concepts

• Combines virtual flooding with Lamports
  algorithm to achieve lower delivery latencies
• Virtual flooding propagates the latest logical
  clock of each source
• For node n to TO-deliver message m it is
  sufficient that n learns that it will not receive
  a message from any source with a timestamp less
  than or equal to ms timestamp
• DRIFT assumes reliable flooding, as e.g. in
  DELUGE (Hui and Culler, Sensys04)

10
Example
Initial condition a and c are sources, b is a
destination
lc 0 sn 0
lc 0 sn 0
a
c
b
RcvdSN 0,0 Seen
RcvdSN 0,0 Seen RCVD DRIFT DLVD
TOF DLVD
RcvdSN 0,0 Seen
Note TOF is Lamports algorithm
11
Example
Sequence number (sn)
a TO-multicasts ltam1, a, 1, 1, lta, 1, 1gtgt
Logical clock (lc)
Source
lc 1 sn 1
lc 0 sn 0
a
c
b
RcvdSN 1,0 Seen
RcvdSN 0,0 Seen RCVD DRIFT DLVD
TOF DLVD
RcvdSN 0,0 Seen
12
Example
b has received ltam1, a, 1, 1, lta, 1, 1gtgt
lc 1 sn 1
lc 0 sn 0
a
c
b
RcvdSN 1,0 Seen
RcvdSN 1,0 Seen lta,1,1gt RCVD
am1 DRIFT DLVD TOF DLVD
RcvdSN 0,0 Seen
b updates RcvdSN and Seen
13
Example
b rebroadcasts ltam1, a, 1, 1, lta, 1, 1gtgt
lc 1 sn 1
lc 0 sn 0
a
c
b
RcvdSN 1,0 Seen
RcvdSN 1,0 Seen lta,1,1gt RCVD
am1 DRIFT DLVD TOF DLVD
RcvdSN 0,0 Seen
14
Example
c has received ltam1, a, 1, 1, lta, 1, 1gtgt
lc 1 sn 1
lc 2 sn 0
a
c
b
RcvdSN 1,0 Seen
RcvdSN 1,0 Seen lta,1,1gt RCVD
am1 DRIFT DLVD TOF DLVD
RcvdSN 1,0 Seen lta,1,1gt
15
Example
c rebroadcasts ltam1, a, 1, 1, lta, 1, 1gt, ltc, 2,
0gtgt
lc 1 sn 1
lc 2 sn 0
a
c
b
RcvdSN 0,0 Seen
RcvdSN 1,0 Seen lta,1,1gt RCVD
am1 DRIFT DLVD TOF DLVD
RcvdSN 1,0 Seen lta,1,1gt
16
Example
b receives ltam1, a, 1, 1, lta, 1, 1gt, ltc, 2, 0gtgt
lc 1 sn 1
lc 2 sn 0
a
c
b
RcvdSN 0,0 Seen
RcvdSN 1,0 Seen lta,1,1gt, ltc,2,0gt RCVD
am1 DRIFT DLVD am1 TOF DLVD
RcvdSN 1,0 Seen lta,1,1gt
b TO-delivers am1 with DRIFT, but not with TOF
17
Example
c TO-multicasts ltcm1, c, 3, 1, lta, 1, 1gt, ltc, 3,
1gtgt
lc 1 sn 1
lc 3 sn 1
a
c
b
RcvdSN 1,0 Seen
RcvdSN 1,0 Seen lta,1,1gt, ltc,2,0gt RCVD
am1 DRIFT DLVD am1 TOF DLVD
RcvdSN 1,0 Seen lta,1,1gt
18
Example
lc 4 sn 1
lc 3 sn 1
a
c
b
RcvdSN 1,1 Seen ltc,3,1gt
RcvdSN 1,1 Seen lta,1,1gt, ltc,2,0gt,ltc,3,1gt,
lta,4,1gt RCVD am1, cm1 DRIFT DLVD am1,
cm1 TOF DLVD am1, cm1
RcvdSN 1,1 Seen lta,1,1gt
19
Simulation -- Setup

• Using Java-based JiST/SWANS network simulator
  (v1.0.4)
• Developed by Rimon Barr, 2004 (http//jist.ece.cor
  nell.edu)
• Applications written for real deployment can be
  ported to the simulation environment and be
  placed under variety of simulated scenarios
• Communication is by broadcast as defined by IEEE
  802.11b, transmission range is set to 88m
• Setup
• 100 nodes in a field of 400x400m
• Nodes are stationary
• Nodes start up at random times and positions.
  Each node floods 20 messages (128Bytes) at
  regular interval ( base rate) through the entire
  field

20
Simulation Results and Metric

• Message loss due to hidden terminal problem
  minimized due to low base rates
• Results Average of 20 runs with 95 confidence
  interval
• Delivery latency the time needed to TO-deliver
  a message after it was received at a destination
• We compare the performance of
• Total Order multicast with Flooding only (TOF) ,
  Lamports Algorithm
• Total Order multicast with Virtual Flooding
  (TOVF), DRIFT using physically flooded multicast
  messages as virtual flooding carriers
• gt Speedup latencyTOF / latencyTOVF
• Unless otherwise noted the measurement for TOF
  and TOVF are taken in the same experimental trial

21
Rate Delay

• Speedup with different base rates
• Varying rate delay
• The delivery latency is impacted by
• base rate the rate at which the source
  TO-multicast messages
• rate delay the relative difference in the base
  rate between the sources
• To evaluate the effect of relative rate
  differences, for each source i we set the
  TO-multicast rate as follows
• TO-multicastRatei baseRate (i ? rateDelay)

22
Position of Flooding Source (1/2)
order of network diameter

• One to four sources physically flood messages at
  aggregated frequency 1s-1
• Other nodes use only virtual flooding
• Varying positions of (physical) flooding source
• All nodes are destinations

23
Position of Flooding Source (2/2)
Average
Average
Max
Max
Single source 350,350
2 sources 0,0, 600,600
24
Gossiping

• Number of virtual flooding entries per message
• Base rate 10s
• Overhead increases linearly
• Speedup decreases with increasing number of
  transmitted tuples

• Applications need to chose a trade-off point
  between overhead and speedup

25
Experimental Setup

• We evaluate the performance of DRIFT using
  BenchNet, our wireless sensor testbed
• Setup 16 MICA2 motes, arranged in a 4x4 grid,
  running the TinyOS operating system and
  programmed using the nesC programming language
• Each mote is connected via its communication port
  to an Ethernet programming board which allows
  monitoring applications and the motes to
  communicate
• 4 interior nodes are sources, all nodes are
  destinations
• Each source multicasts 10 messages
• Base rate of 30 seconds
• Reliable 1-hop communication emulated
• TOF and TOVF implemented separately

26
Conclusion and Future Work

• DRIFT uses virtual flooding to propagate logical
  clock information
• We demonstrated through simulation and
  experimentation the effectiveness of DRIFT as a
  total order multicast delivery mechanism for ad
  hoc networks
• Although based on flooding, DRIFT can be modified
  to work with structured routing mechanisms
• Virtual flooding can be used to propagate data of
  any type
• Future work
• measure different failure scenarios, especially
  failures of sources
• scale the experimental evaluation up to many nodes

27

• Questions