UFlood: High-Throughput Wireless Flooding

1. UFlood: High-Throughput Wireless Flooding Jayashree Subramanian Collaborators: Robert Morris, Ramakrishna Gummadi, and Hari Balakrishnan

2. Goal of this work • To design a flooding protocol for wireless multi-hop networks • Application: Real-time video distribution • What is a good flooding protocol? • Use least #transmissions • Provide high-throughput for the nodes

3. Challenge in Wireless Flooding • Every transmission is broadcast (Opportunistic Receptions!) • Reception is probabilistic 6 4 A B Delivery probability from Src to B 0.1 src D 4 1 2 2 2 3 5 6 1 1 2 1 2 1 3 C 5 6 3

4. Challenge in Wireless Flooding …contd Challenge: • Who should transmit next? • What packet to transmit? UFlood’s claim: Select best sender – to minimize total #transmissions to complete flooding

5. Contribution of this work • UFlood – Choosing best sender for every transmission maximizes throughput • UFlood performance: • Achieves 2x higher throughput than controlled flooding • Performs close to the benchmark - ExOR unicast routing (multihop transfer to a single receiver)

6. Outline of this talk • Existing Solutions • Key Idea of UFlood • Design of UFlood protocol • Evaluation

7. S A B C Related Work • Flooding in routing • Controlled flooding (AODV, DSR) • Does not maximize throughput • Tree-based flooding • MCDS, LESS • Does not consider opportunism • Gossip-based flooding Tree-based flooding (static decision) 0.1 Wasted transmission!

8. S B A 0.1 0.9 C Related Work … contd • Gossip-based flooding (dynamic decision) • Trickle, Deluge • Does not choose best sender Bad sender choice means more transmissions!

9. Outline of this talk • Existing Solutions • Key Idea of UFlood • Design of UFlood protocol • Evaluation

10. Key Idea Select the best sender - to maximize Useful Receptions Select the best sender - to maximize throughput 4 6 1 1 A B 0.9 Packet availability Delivery probability 0.1 src D 1 3 2 3 5 4 6 1 C 5 6 3 2 1

11. Calculating Useful Receptions U(B,1)=0 U(A,4)= 0.9+0.4+0.6=1.8 4 6 1 1 A B 0.9 0.4 src D 0.6 1 3 2 3 5 4 6 1 C 5 6 3 2 1

12. S 0.5 0.9 A B 0.2 0.1 D C To Flood a Single Packet using UFlood U(S)=1.7 U(S)=0.7 S 0.5 0.5 A U(A)=1.5 B 1 0.2 0.3 U(D)=0.8 D C 0.5 To flood multiple packets calculate utility for every packet!s

13. UFlood is a Local Heuristic • Difficulty:Knowing the packet availability at all nodes • Solution: Local heuristic- Every node knows only about its neighbors (nodes whose packets it can hear!) • Good news: Possibility of spatial reuse!

14. Outline of this talk • Existing Solutions • Key Idea of UFlood • Design of protocol • Evaluation

15. Design of UFlood Information required: Node states - packets available with the neighbors Delivery probabilities of all node pairs in the network

16. Knowing Node States • Node states • Ni- number of neighbors of i • P – # packets flooded • node-state matrix – [NixP] • Method: • Maintain local version • Gossip packet availability using periodic status packets Packet # 1 1 2 2 3 3 Node # 1 1 1 1 1 1 0 2 2 0 0 1 1 0 3 3 0 0 0 0 0

17. N N 1 2 3 1 1 0.3 0.5 2 0.4 1 1 3 0.9 0.6 1 Computing Delivery Probabilities • Delivery probabilities • For all N nodes in the network • Delivery prob matrix – [NxN] • Method – offline experiment • Each node broadcasts continuous probes and rest of the nodes compute:

18. Computing Packet Utility Node states Delivery probabilities

19. Pseudo code of UFlood • Source Node floods all packets • All nodes periodically broadcast status packet • On reception of a new data or status packet: • Update node-state matrix • Calculate utility • Transmit in burst – all packets whose utility is greater than neighbor’s utility • CSMA handles contention (Listen then send or back off)

20. Batching in UFlood • The packets are sent in batches • To reduce overhead • To limit the size of the status packet • Current design considers single batch!

21. Outline of this Talk • Existing Solutions • Key Idea of UFlood • Design of UFlood protocol • Evaluation

22. 20-Node Indoor Test-bed 200 feet 250 feet Source Node

23. Implementation • Meraki mini, 802.11b/g • 2dbi Omni-directional antenna • Transmit power = 60mW • Bit rate = 24Mbps • CLICK software router toolkit • Carrier Sense on

24. Performance Comparison Method: Flood a single batch of 5000-1500B packet Comparison: • UFlood Vs. Controlled Flooding • UFlood Vs. Unicast routing

25. UFlood Vs. Controlled Flooding • Used in routing protocols like AODV and DSR • Method: • Source broadcasts all packet • Every node rebroadcasts only once • Why we used? • Aim: to quickly send the route information

26. Throughput of UFlood = 2x Throughput of Controlled Flooding No Choice of Sender!

27. UFlood Vs. Estimated Unicast • Why unicast? • Multihop transfer to • one receiver Vs many receivers • Method • Setup independent unicast sessions to send a batch of packets from source (node 4) to each node

28. ExOR packet packet packet packet • Decide who forwards after reception • Goal: only closest receiver should forward A B src dst packet packet packet packet packet C

29. Throughput of UFlood = Throughput of Estimated ExOR

30. Why does UFlood Perform good? Second best node transmits! UFlood is a local heuristic – Occasional errors! Best node transmits!

31. Future Work • Implement network-coding, bit-rate adaptation, and batching • UFlood vs. existing high-throughput flooding protocols

32. Conclusion • UFlood’s Key Idea – Choosing best sender for every transmission maximizes throughput • UFlood’s Performance: • Achieves 2x higher throughput than controlled flooding • Performs close to the benchmark - ExOR unicast routing