Infrastructures for Virtual ISPs, Study notes of Wireless Networking

Download Infrastructures for Virtual ISPs and more Study notes Wireless Networking in PDF only on Docsity! Encouraging Cooperation in Multi-Hop Wireless Networks Ratul Mahajan, Maya Rodrig, David Wetherall and John Zahorjan University of Washington, June 2004. djw // UW-CSE, 6-23-04 Wireless for the masses Our goal: • Inexpensively extend reach Via clients, PCs: • Use what you find • Shared infrastructure • Multi-hop • Ubiquitous connectivity • Multiple parties Today: • High-quality connectivity, but but limited areas, high cost Via APs: • Carefully planned • Separately provisioned • Single hop, client to AP • All-or-nothing access • Single administration What is the appropriate system architecture? djw // UW-CSE, 6-23-04 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 Testbed performance – links Link quality varies with pairs of nodes, some asymmetry djw // UW-CSE, 6-23-04 Testbed performance – multi-hop Time for 6MB transfer from node 8 to nodes 4, 6, 14, & 9 djw // UW-CSE, 6-23-04 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 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 node knows which packets it received – Get neighbors to agree to punish it, even though they must coordinate coordinate their actions via the cheating node • Approach/Insight: – Leverage anonymous challenges, where receiver doesn’t know the the identity of the sender. Can do this with current hardware. djw // UW-CSE, 6-23-04 Key Idea: anonymous challenges • Each node tests it neighbor with anonymous challenges; neighbor must 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 4 1 3 2 5 7 8 djw // UW-CSE, 6-23-04 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?”) • An 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 4. Results under wireless conditions The more you cheat, the more quickly you are caught. djw // UW-CSE, 6-23-04 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 CATCH with signal-strength cheats Signal strength helps about half the time; CATCH still offers some protection djw // UW-CSE, 6-23-04 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