DRIFT Efficient Message Ordering in Ad Hoc Networks






















![Position of Flooding Source (2/2) Average Max Max Single source [350, 350] 2 sources Position of Flooding Source (2/2) Average Max Max Single source [350, 350] 2 sources](https://slidetodoc.com/presentation_image_h/175a3908644803b64f4335df255e13d7/image-23.jpg)




- Slides: 27
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 1
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-topoint (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 2
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 3
Outline • Total Order Multicast • Lamport’s Total Order Multicast Algorithm • Virtual Flooding • DRIFT Description • Example • Simulation and Experimentation • Conclusion and Future Work 4
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 5
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 (SRDS’ 99) – privilege-based • Malpani et al. (IEEE To. MC) – communication history • Prakash et al. (ICDCS’ 97), dependency on fixed infrastructure – Lou et al. (IEEE To. MC) use probabilistic guarantees 6
Lamport’s 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 (Lamport’s 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 7
Virtual Flooding • Node attaches data to an unrelated message it has to broadcast • Example Node a has message physically flood Node c has a message virtually flood to to (1) Node a sends m (2) Node b forwards m (3) Node c attaches virtually flooded message and forwards m (4) Node d forwards combined message (5) Node e forwards combined message 8
DRIFT: Key Concepts • Combines virtual flooding with Lamport’s 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 m’s timestamp • DRIFT assumes reliable flooding, as e. g. in DELUGE (Hui and Culler, Sensys’ 04) 9
Example Initial condition – a and c are sources, b is a destination lc = 0 sn = 0 a b c Rcvd. SN = [0, 0] Seen = { } RCVD = { } DRIFT DLVD = { } TOF DLVD = { } Note: TOF is Lamport’s algorithm 10
Example a TO-multicasts <am 1, a, 1, 1, {<a, 1, 1>}> Source Sequence number (sn) Logical clock (lc) lc = 1 lc = 0 sn = 1 sn = 0 a b c Rcvd. SN = [1, 0] Rcvd. SN = [0, 0] Seen = {} Seen = {} RCVD = { } DRIFT DLVD = { } TOF DLVD = { } 11
Example b has received <am 1, a, 1, 1, {<a, 1, 1>}> lc = 1 lc = 0 sn = 1 sn = 0 a b c Rcvd. SN = [1, 0] Rcvd. SN = [0, 0] Seen = {} Seen = {<a, 1, 1>} Seen = {} RCVD = {am 1} DRIFT DLVD = {} TOF DLVD = {} b updates Rcvd. SN and Seen 12
Example b rebroadcasts <am 1, a, 1, 1, {<a, 1, 1>}> lc = 1 lc = 0 sn = 1 sn = 0 a b c Rcvd. SN = [1, 0] Rcvd. SN = [0, 0] Seen = {} Seen = {<a, 1, 1>} Seen = {} RCVD = {am 1} DRIFT DLVD = {} TOF DLVD = {} 13
Example c has received <am 1, a, 1, 1, {<a, 1, 1>}> lc = 1 lc = 2 sn = 1 sn = 0 a b c Rcvd. SN = [1, 0] Seen = {} Seen = {<a, 1, 1>} RCVD = {am 1} DRIFT DLVD = {} TOF DLVD = {} 14
Example c rebroadcasts <am 1, a, 1, 1, {<a, 1, 1>, <c, 2, 0>}> lc = 1 lc = 2 sn = 1 sn = 0 a b c Rcvd. SN = [0, 0] Rcvd. SN = [1, 0] Seen = {} Seen = {<a, 1, 1>} RCVD = {am 1} DRIFT DLVD = {} TOF DLVD = {} 15
Example b receives <am 1, a, 1, 1, {<a, 1, 1>, <c, 2, 0>}> lc = 1 lc = 2 sn = 1 sn = 0 a b c Rcvd. SN = [0, 0] Rcvd. SN = [1, 0] Seen = {} Seen = {<a, 1, 1>, <c, 2, 0>} Seen = {<a, 1, 1>} RCVD = {am 1} DRIFT DLVD = {am 1} TOF DLVD = {} b TO-delivers am 1 with DRIFT, but not with TOF 16
Example c TO-multicasts <cm 1, c, 3, 1, {<a, 1, 1>, <c, 3, 1>}> lc = 1 lc = 3 sn = 1 a b c Rcvd. SN = [1, 0] Seen = {} Seen = {<a, 1, 1>, <c, 2, 0>} Seen = {<a, 1, 1>} RCVD = {am 1} DRIFT DLVD = {am 1} TOF DLVD = {} 17
Example lc = 4 lc = 3 sn = 1 a b c Rcvd. SN = [1, 1] Seen = {<c, 3, 1>} Seen = {<a, 1, 1>, <c, 2, 0>, <c, 3, 1>, <a, 4, 1> } Seen = {<a, 1, 1>} RCVD = {am 1, cm 1} DRIFT DLVD = {am 1, cm 1} TOF DLVD = {am 1, cm 1} 18
Simulation -- Setup • Using Java-based (v 1. 0. 4) Ji. ST/SWANS network simulator – Developed by Rimon Barr, 2004 (http: //jist. ece. cornell. 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. 11 b, transmission range is set to 88 m • Setup – 100 nodes in a field of 400 x 400 m – Nodes are stationary – Nodes start up at random times and positions. Each node floods 20 messages (128 Bytes) at regular interval (= base rate) through the entire field 19
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) , Lamport’s Algorithm – Total Order multicast with Virtual Flooding (TOVF), DRIFT using physically flooded multicast messages as virtual flooding carriers => Speedup = latency. TOF / latency. TOVF • Unless otherwise noted – the measurement for TOF and TOVF are taken in the same experimental trial 20
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-multicast. Ratei = base. Rate + (i rate. Delay) 21
Position of Flooding Source (1/2) order of network diameter • One to four sources physically flood messages at aggregated frequency 1 s-1 • Other nodes use only virtual flooding Average Max • Varying positions of (physical) flooding source • All nodes are destinations 22 Single source [0, 0]
Position of Flooding Source (2/2) Average Max Max Single source [350, 350] 2 sources [0, 0], [600, 600] 23 4 sources in 4 corners
Gossiping • Number of virtual flooding entries per message • Base rate 10 s • Overhead increases linearly • Speedup decreases with increasing number of transmitted tuples • Applications need to chose a trade-off point between overhead and speedup 24
Experimental Setup • We evaluate the performance of DRIFT using Bench. Net, our wireless sensor testbed • Setup: 16 MICA 2 motes, arranged in a 4 x 4 grid, running the Tiny. OS operating system and programmed using the nes. C 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 • • • 25
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 26
Questions 27