Encouraging Cooperation in MultiHop 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
Wireless for the masses

• 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

What is the appropriate system architecture?
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 dont
  relay
• Its 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.
4
Outline

• Our testbed
• How to cheat, and its impact
• CATCH, our solution
• Some results

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
6
Testbed characterization links
Link quality varies with pairs of nodes, some
asymmetry
7
2. How to cheat and get away with it

• Just discard unwanted packets
• Watchdog detects but doesnt punish not a
  solution.

• Simpler, better just dont acknowledge
  connectivity
• Routes via cheater cant be inferred due to
  asymmetry

6
2
5
8
1
3
7
4
8
The adverse impact of cheating (I)
Cheaters gain significantly by cheating, good
nodes lose out collectively
9
The adverse impact of cheating (II)
Even a couple of cheaters can partition
high-quality links, and rampant cheating ruins
connectivity
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
  doesnt know the identity of the sender. Can do
  this with current hardware.

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
5
8
1
3
7
4
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
5
8
1
3
7
4
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
H12
H02
H18
H08
H02, H03, ? , H07
H12, H16, H17, H18
H13
H03
H07
H02, ? , H07, H08
H17
H12, H13, H16, H18
H02, H03, ? , H08
14
Details Ive 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 youd like a draft paper.

15
4. Results under wireless conditions
The more you cheat, the more quickly you are
caught.
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.

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

18
CATCH with signal-strength cheats
Signal strength helps about half the time CATCH
still offers some protection
19
Conclusion

• CATCH provides a lightweight deterrent to
  cheating
• Built on a backdrop of cooperation
• Assumptions arent 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

20
Questions?
21
Testbed performance multi-hop
Time for 6MB transfer from node 8 to nodes 4, 6,
14, 9
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.)