Virtual Infrastructure for Collision-Prone Wireless Networks

1. Virtual Infrastructure for Collision-Prone Wireless Networks Seth Gilbert Gregory Chockler Nancy Lynch

2. Wireless Ad Hoc Networks

3. Unreliable communication Contention Collisions Noise Lost messages Unknown Availability Fault-prone devices Ad hoc deployments Unknown topology Unknown participants Mobility Dynamic joining/leaving Wireless Ad Hoc Networks

4. Fixed Infrastructure For Example: Simplifies wireless networks: Communication • Avoids contention and collisions Unknown availability • Reliable overlay • Known topology Mobility • Fixed and predictable cell towers base stations servers

5. Virtual Infrastructure

6. Today’s Topics • Introduction • Modeling • Emulating a virtual node: • Convergent History Agreement • Emulating virtual infrastructure

7. Wireless Networks • Mobile nodes • Crash failures • Location updates • Unreliable wireless broadcast • Synchronous • Collision detection • Contention manager

8. Wireless Networks • Broadcast: within some radius R. • Interference: up to some radius R’. R’ R

9. Wireless Networks • Eventually, if only one nearby node broadcasts in a round, then its message will be delivered.

10. Wireless Networks Bob either: • Gets both messages or • Detects a collision Bob Collin Alice CD A-C: complete, eventually accurate: • Detect if any message is lost. • Eventually no false positives (after stabilization).

11. Collision-Prone Network • Eventually reduces contention/collisions Example: backoff protocol • Advice only: nodes can ignore. • Eventually, if only 1 node broadcasts, then no collisions (after “stabilization”). Each node contends when it wants to broadcast. Each contention manager outputs advice: • active: it is safe for the mobile node to broadcast • passive: the mobile node should not broadcast.

12. Wireless Networks Eventually non-interfering: • Eventually, nearby nodes are not advised to be active. Eventually regionally fair: • Eventually, if: • Only nearby nodes contend. • Any non-failed node contends for sufficiently long. • Then: • Somenon-failed, contending node is advised to be active for sufficiently long.

13. Wireless Networks • Mobile nodes • Crash failures • Location updates • Unreliable wireless broadcast • Synchronous • Collision detection • Contention manager

14. Today’s Topics • Introduction • Modeling • Emulating a virtual node: • Basic Idea • Convergent History Agreement (CHA) • CHA Protocol • Emulating virtual infrastructure

15. Building Virtual Infrastructure

16. Building Virtual Infrastructure

17. Building Virtual Infrastructure Leader / backup Leader sends & receives messages for the virtual node Each participant is a replica. Replicas execute a consistency protocol

18. Consistency: First Attempt • For each virtual round: • Run consensus. • Replicas agree on: • Messages for virtual node to receive. • Message for virtual node to send. • State update. • Update state. • Leader sends message for virtual node.

19. First Attempt Problems: • Consensus does not terminate until collisions stop. • Virtual rounds are non-constant sized • Rounds are unsynchronized! • Virtual nodes do not detect collisions • Delay until collisions stop.

20. Goals • Can communicate with both real and virtual nodes. • Detect collisions when a message is lost. • Emulation of virtual nodes is transparent. • Rounds are synchronized • Rounds are constant length • In each round, replicas have a consistent view • Constant-sized messages

21. Convergent History Agreement • Sequence of instances: • For each instance k: • Each node proposes an input. • Each node receives a history output h, or . CHA k4 h1 propose(x) h2 propose(y) propose(z) CHA k7 CHA k5 CHA k3 CHA k2 CHA k6 CHA k1 CHA k4

22. Convergent History Agreement • A history is a sequence of proposals, one per instance, e.g.: Validity: Each history contains only real proposals. Agreement: Every pair of histories shares a common prefix of proposals/non-proposals. Liveness: Eventually, every instance outputs histories, and every element in the history is a proposal. CHA k7 CHA k5 CHA k3 CHA k2 CHA k6 CHA k1 CHA k4

23. Emulating a Virtual Round • Determine proposals. • Mobile nodes broadcast their messages for the virtual round. • Calculate virtual node’s broadcast message, using most recent history, extended by collisions. • Execute convergent history agreement (CHA). • If CHA outputs a history, then: • Simulate receiving virtual node’s broadcast. • Otherwise: • Report a collisions.

24. CHA Protocol Each client begins with a proposal for the current instance. Round 1: [Ballot] • Ifadvice=activethenbroadcast(ballot) Round 2: [Veto-1] • If“collision”thenbroadcast(veto) Round 3: [Veto-2] • If“collision”thenbroadcast(veto) • Update state

25. Ballot Veto 1 Veto 2 Result green yellow orange red Update State Accept Reject

26. Ballot Veto 1 Veto 2 Result green yellow orange red Update State Accept Tentative Accept Tentative Reject Reject

27. Ballot Veto 1 Veto 2 Result green yellow orange red Update State ballot={proposal, last green/yellow round} Accept Tentative Accept Tentative Reject Reject

28. Ballot history • Reconstructing the history Example:

29. Ballot history • Reconstructing the history Example:

30. Ballot history • Reconstructing the history Example:

31. Ballot history • Reconstructing the history Example:

32. Ballot history • Reconstructing the history Example: History: 1. propose(P) 2. propose(O) 3. propose(D) 4. propose(C) => PODC

33. CHAP Output • If round is green: • Output history. • Include proposal where indicated, otherwise. • Else if round is not green: • Output .

34. Analysis: Key Idea (1) • If some instance is green, then all accept that instance’s ballot. • All histories agree on the same execution. • If a history is output for some instance, then all replicas receive the proposal for that instance. • If a ballot is red, then all the replicas reject it. • If a proposal is not received, then no history outputs it. The color at any two replicas differs by at most one shade.

35. Analysis: Key Idea (2) • When the underlying network is well-behaved, then there are no vetos. • Used to prove that the virtual node satisfies: • Eventual collision freedom. • Eventual accuracy of the collision detector. • Contention manager eventually well-behaved. After the network, collision detector, and contention manager stabilize: Eventually, every round is green.

36. Today’s Topics • Introduction • Modeling • Emulating a virtual node: • Convergent History Agreement • Emulating virtual infrastructure

37. Virtual Infrastructure Problems: • Virtual nodes communicate with each other. • Sender adds message to send to proposal. • Receiver adds messages to receive to proposal. • Both run agreement. • If sender-agreement fails, then receiver cannot receive the message. • Too late!! • Virtual node emulators may interfere with each other. • Contention managers are insufficient.

38. Virtual Infrastructure • Choose a schedule for all the virtual nodes: • Non-conflicting: no neighboring virtual nodes scheduled at the same time. • Fair: every virtual node is scheduled. • Use schedule to avoid contention in the emulation. ** Not sufficient to emulate each virtual node according to the schedule, since virtual nodes communicate.

39. Virtual Infrastructure Four part protocol: • Data phases: • Client phase: clients broadcast messages to vns, each other. • VN phase: representative emulator sends msg for vn. • Scheduled Agreement Instance • Scheduled virtual nodes run the 3 phase agreement protocol, all at once. • Unscheduled Agreement Instance • Unscheduled virtual nodes run the 3 phase agreement protocol. • Lasts for s +2 rounds, where s is the size of the schedule. • Join + Reset phases.

40. Virtual Infrastructure • Bounded round emulation • 10 + (size of schedule) • Constant overhead • After stabilization, constant message overhead. • Can be optimized further.

41. Ongoing and Future Work

42. Ongoing and Future Work • Optimization • Smaller messages • Less redundant communication • Shorter virtual rounds • Implementation aspects • Collision detectors • Contention managers • Synchronization

43. Ongoing and Future Work • Coordination Problems • Traffic Coordination • Air traffic control • Rescue worker / military scenarios • Control Problems • Actuated sensors • Real-time applications • Mobile Sensors • Floating / submergible devices • Zebranet-like scenarios

44. Ongoing and Future Work • Malicious Devices • Can we emulate virtual infrastructure in the presence of non-cooperative mobile nodes? • Can we keep the state of the system secret from the participants? • Cryptography • Frequency hopping

45. Ongoing and Future Work • Energy Efficiency • How efficiently can we implement virtual infrastructure? • Mobile nodes share the work of implementing the virtual nodes. • More efficient replication via coding theory techniques?

46. Summary Virtual Infrastructure • Simple abstraction for dependable ad hoc networks • Convergent History Agreement • CHA Protocol / VI Emulation • Collision detectors, contention managers • Efficient: constant overhead, constant time

47. The End

48. The End