Encouraging Cooperation in Multi-Hop Wireless Networks

1. Encouraging Cooperation in Multi-Hop Wireless Networks Ratul Mahajan, Maya Rodrig, David Wetherall and John Zahorjan University of Washington, June 2004.

2. Today: High-quality connectivity, but limited areas, high cost Via APs: Carefully planned Separately provisioned Single hop, client to AP All-or-nothing access Single administration Our goal: Inexpensively extend reach Via clients, PCs: Use what you find Shared infrastructure Multi-hop Ubiquitous connectivity Multiple parties Wireless for the masses What is the appropriate system architecture? djw // UW-CSE, 6-23-04

3. This talk is about cheating • Experience shows some people will cheat given motive and opportunity. This is a risk for meshes. • Users must relay each others packets to form a network • Yet an individual gains bandwidth if they don’t relay … • It’s easy to do, hard to detect, and harmful. • Can we mitigate this risk by design? • Our philosophy is to assume a backdrop of cooperation and look for low cost ways to make cheating harder (“90/10”) Goal: Provide a deterrent to cheating that is lightweight and widely applicable. djw // UW-CSE, 6-23-04

4. Outline • Our testbed • How to cheat, and its impact • CATCH, our solution • Some results djw // UW-CSE, 6-23-04

5. 1. In-building 802.11 Testbed • 15 nodes on one floor • Also covered by ~10 APs • Atheros, Prism II.5 based cards • Currently one radio per PC • Wired for manageability 184 feet djw // UW-CSE, 6-23-04

6. Testbed characterization – links Link quality varies with pairs of nodes, some asymmetry djw // UW-CSE, 6-23-04

7. Just discard unwanted packets Watchdog detects but doesn’t punish; not a solution. Simpler, better: just don’t acknowledge connectivity Routes via cheater can’t be inferred due to asymmetry 6 2 8 5 1 3 7 4 2. How to cheat and get away with it 6 2 8 5 1 3 7 4 djw // UW-CSE, 6-23-04

8. The adverse impact of cheating (I) Cheaters gain significantly by cheating, good nodes lose out collectively djw // UW-CSE, 6-23-04

9. The adverse impact of cheating (II) Even a couple of cheaters can partition high-quality links, and rampant cheating ruins connectivity djw // UW-CSE, 6-23-04

10. 3. CATCH, our solution • Goal is to detect cheaters and isolate them for a period • A credible threat to encourage cooperative forwarding • Two difficult problems: • Determine when a node discards packets, even though only the node knows which packets it received • Get neighbors to agree to punish it, even though they must coordinate their actions via the cheating node • Approach/Insight: • Leverage anonymous challenges, where receiver doesn’t know the identity of the sender. Can do this with current hardware. djw // UW-CSE, 6-23-04

11. Key Idea: anonymous challenges • Each node tests it neighbor with anonymous challenges; neighbor must respond or lose the link • Even a cheater requires some connectivity, and so must respond to preserve it, thus revealing true connectivity to all nodes 6 2 8 5 1 3 7 4 djw // UW-CSE, 6-23-04

12. How to detect that a node is cheating • Combine anonymous challenges (which tell you true connectivity) with watchdog (below, which tells you behavior). • These are statistical tests in CATCH. 6 2 8 5 1 3 7 4 djw // UW-CSE, 6-23-04

13. How all nodes can isolate a cheater • Use anonymous challenges and signaling by absence {H12, H13, H17, H18} {H02, H03, H07, H08} {H13, H16, H17, H18} {H03 , ? , H07, H08} H16 {H12, H13, H16, H17} H02 H12 H18 H08 {H02, H03, ? , H07} {H12, H16, H17, H18} H07 H13 H03 {H02, ? , H07, H08} H17 {H12, H13, H16, H18} {H02, H03, ? , H08} djw // UW-CSE, 6-23-04

14. Details I’ve omitted • The rest of the protocol • Statistical tests to handle the impact of real wireless losses • Adding reliability to the control packet exchanges • Case-by-case analysis (e.g.,“What if I drop half the challenges?”) • Implementation • User-level via netfilter, unoptimized • Traffic on testbed is HTTP downloads • More information: • Mail me if you’d like a draft paper. djw // UW-CSE, 6-23-04

15. 4. Results under wireless conditions The more you cheat, the more quickly you are caught. djw // UW-CSE, 6-23-04

16. Overheads, costs • Reasonable bandwidth overhead • Only control packets (1 per link per second per neighbor) • Roughly 24Kbps per node in our testbed • Minimal processing • Some counters etc. but no crypto operations per data packet • We used to run this on IPAQs • Must be able to send anonymous packets and watchdog • No real restrictions on traffic workloads, choice of routing protocol, etc. djw // UW-CSE, 6-23-04

17. More sophisticated cheats • Drop a fraction of packets • Target only some neighbors • Cheat only some of the time • Cheat different neighbors at different times • Combinations of the above … • Or, physical layer hints to undermine anonymity: • Using per packet received signal strength djw // UW-CSE, 6-23-04

18. CATCH with signal-strength cheats Signal strength helps about half the time; CATCH still offers some protection djw // UW-CSE, 6-23-04

19. Conclusion • CATCH provides a lightweight deterrent to cheating • Built on a backdrop of cooperation • Assumptions aren’t too restrictive: watchdogs, omni-directional • Modest overheads, no limits on workloads, currencies, etc. • Raises the bar rather than makes cheating impossible • Future work • Signal-strength cheats, improve robustness even further • Move on to system architecture and protocols … djw // UW-CSE, 6-23-04

20. Questions? djw // UW-CSE, 6-23-04

21. Testbed performance – multi-hop Time for 6MB transfer from node 8 to nodes 4, 6, 14, & 9 djw // UW-CSE, 6-23-04

22. Rapid detection with few false positives A simulation that expands on the prior result. (An ideal result would hug the x-y axis. Note the log scale.) djw // UW-CSE, 6-23-04