Sustaining Cooperation in Multi-Hop Wireless Networks, Lecture notes of Wireless Networking

Download Sustaining Cooperation in Multi-Hop Wireless Networks and more Lecture notes Wireless Networking in PDF only on Docsity! Sustaining Cooperation in Multi-Hop Wireless Networks Ratul Mahajan Maya Rodrig David Wetherall John Zahorjan University of Washington Abstract – Multi-hop wireless networks are vul- nerable to free-riders because they require nodes to for- ward packets for each other. Deployed routing protocols ignore this issue while proposed solutions incorporate complicated mechanisms with the intent of making free- riding impossible. We present Catch, a protocol that falls between these extremes. It achieves nearly the low mech- anism requirements of the former while imposing nearly as effective barriers to free-riding as the latter. Catch is made possible by novel techniques based on anonymous messages. These techniques enable cooperative nodes to detect nearby free-riders and disconnect them from the rest of the network. Catch has low overhead and is broadly applicable across routing protocols and traffic workloads. We evaluate it on an 802.11 wireless testbed as well as through simulation. 1 Introduction Selfish behavior is an important design consideration whenever parties with varied interests come together to achieve a common goal. Examples where individual be- havior can be at odds with the system goal include free- riding in peer-to-peer file sharing networks [1, 36, 25, 32, 13, 41], cheating in online games [33, 6], ISP competi- tion in Internet routing [38, 12], and network congestion control [16, 17, 37, 23, 4, 26, 28]. As has been observed in many of these systems, some parties will behave self- ishly if there is gain to be had, even to the detriment of others.1 A high-level goal in these systems is to design protocols that ensure the system will work well despite selfish behavior. In this paper, we study the problem of selfish behav- ior in multi-hop wireless networks. The emergence of these networks is being driven by the rapid deployment of 802.11 networks and the advantages of relaying pack- ets between nodes. In infrastructure rich areas, relaying can reduce dead spots, lower power consumption [31], and increase network capacity [19]. In rural or develop- ing areas, multi-hop wireless networks can be deployed more readily and at lower expense than traditional wire- less networks. Research examples of multi-hop networks include MIT’s Roofnet [35], Microsoft’s MUP [2], the Digital Gangetic Plains Project [8], and UCAN [27]. Selfish behavior is a concern in this setting because relaying packets for others consumes bandwidth and en- ergy. Unlike traditional, wired LANs, nodes in these networks are often controlled by independent and poten- tially competing parties, e.g., nearby apartments [2, 35] or villages [8]. In the absence of any pressure to be- have cooperatively, nodes have an incentive to free-ride by sending their own packets without relaying packets for others. This concentrates traffic through the cooper- ative nodes, which decreases both individual and system throughput, and may even partition an otherwise con- nected network. Deployed routing protocols ignore the issue of free- riding. They simply assume that factors external to the routing protocol cause all nodes to cooperate. This in- curs no overhead but unfortunately makes it trivial for a node to free-ride, e.g., by using a simple firewall rule to render itself indistinguishable from a node that lacks the wireless connectivity needed to relay traffic. Moreover, we show experimentally (Section 5.2) that free-riders can obtain substantial benefits. We should reasonably expect free-riding to become prevalent in all but the most benign situations. Proposed solutions typically incorporate enough mechanism in the routing protocol to eliminate free- riding. This often involves some form of distributed ac- counting that allows each node to consume no more for- warding service than it provides. These solutions suf- fer from two serious drawbacks. They require infrastruc- ture that seems unlikely to come about in practice, e.g., centralized clearance services [44, 34] or trusted hard- ware [11]. And they impose overly restrictive require- ments on the system, e.g., uniform traffic rates among all node pairs [39]. Our goal is to combine the strengths of these two approaches while avoiding their weaknesses. Like de- ployed protocols, we assume that most (but not all) nodes will behave cooperatively. Like proposed solutions, we do not rely on trust alone but include mechanisms that actively discourage free-riding. The insight underly- ing this combination is that early users of a system are typically cooperative (as they try to get the system to work at all) while selfish behavior emerges when the user base grows [22]. Evolutionary game theory predicts that free-riding will not flourish if discouraged from an early stage [18]. NSDI ’05: 2nd Symposium on Networked Systems Design & ImplementationUSENIX Association 231 Our solution is called Catch. It uses an existing major- ity of cooperative nodes to collectively discourage a mi- nority of selfish nodes from free-riding. In game theory parlance, Catch assures that cooperation is an evolution- arily stable strategy. To achieve this, Catch uses novel techniques based on anonymous messages (in which the identity of the sender is hidden) to tackle two critical problems. First, Catch allows a cooperative node to de- termine whether its neighbors are free-riding, i.e., drop- ping packets that should be relayed. Second, it enables the cooperative neighbors of a free-rider to disconnect it from the rest of the network. These tasks can be accom- plished even when cooperative nodes can communicate with each other only through potential free-riders. The result is that free-riding that previously succeeded is now deterred in a low-cost manner. We have implemented and evaluated Catch on an in- building 802.11b testbed. This provides a realistic eval- uation environment with the complex link quality factors that affect actual wireless systems. Real wireless condi- tions significantly complicate the implementation of ro- bust mechanisms where nodes monitor the behavior of their neighbors. Yet they have received little attention in earlier work, which to our knowledge is exclusively based on simulation. We find that Catch is able to detect free-riding by individual nodes both quickly and with high accuracy. Its overhead is modest, roughly 24Kbps of control packets per node in our testbed, with no space overhead or cryptographic operations per data packet. The rest of this paper is organized as follows. We describe our problem setting in Section 2, followed by our approach based on anonymous messages in Sec- tion 3. The Catch protocol itself is described in Sec- tion 4. Section 5 describes our evaluation based on the 802.11 testbed. We then report simulation results that analyze Catch across a broad range of parameters in Sec- tion 6. Finally, we present related work in Section 7 and our conclusions in Section 8. 2 Problem We focus on selfish behavior, whereby a node gains at the expense of others, rather than malicious behavior, in which a node actively attacks others, e.g., by jamming its radio transmissions. Consider the simple example of a multi-hop wireless network in Figure 1. Here A may wish to send a message to C, either to communicate with C itself or because C serves as a gateway to additional nodes. Because A and C are not in each other’s radio range, communication between then must rely on B. On the other hand, B may be interested in communicating via C but uninterested in obtaining any service from A. In that case, B may want to avoid the costs of forwarding packets for A. A B C Figure 1: An example multi-hop wireless network topology in which free-riding can take place. B can avoid these forwarding loads in two distinct ways: at the forwarding level and at the routing level. At the forwarding level, B can simply drop some or all of the data packets it receives for forwarding from A. At the routing level, B can refuse to send routing messages that acknowledge connectivity with A. Consequently, B will appear to be a “dead-end” from C’s perspective and unreachable from A’s, and so neither will ever request forwarding of it. This strategy, which we call link con- cealment, is broadly applicable and, to our knowledge, no existing wireless routing protocol or policing scheme counters it. Our protocol, Catch, prevents B from get- ting away with these selfish behaviors in the case that both A and C behave cooperatively. B would appear to be immune from adverse consequences for free-riding, because at best only A is aware of either of these behav- iors (and it cannot communicate with C except through B), and only C can inflict any punishment on B. But we will see that this is not so. Catch relies on three assumptions about nodes. First, most of them are cooperative in that they correctly run a protocol we define. A minority of nodes may be self- ish and attempt to free-ride; we do not consider collu- sion amongst these nodes. Second, we assume omni- directional radio transmitters and antennas, so that nodes can overhear nearby communications. This is true for common 802.11 hardware today. Third, nodes have an unforgeable identity. Such identities are not provided by current hardware but can be implemented by other means, e.g., using one-way hash chains [20] and impos- ing a startup cost for new identities. Catch does not make any assumption regarding the routing protocol, traffic workload, or objectives of the nodes (such as bandwidth maximization or energy con- servation). We believe that it works largely unchanged across these variables. We do not directly consider fair- ness issues but assume that a higher layer protocol de- cides what fraction of packets a node should relay for others. Catch can then be used to enforce that policy. 3 The Power of Anonymity At a high-level, our approach is to use cooperative nodes to monitor for the presence of free-riders and to isolate them from the rest of the network. In this way, free-riding is no longer attractive. However, this approach requires us to tackle two problems, each of which is difficult or impossible to solve in the general case: NSDI ’05: 2nd Symposium on Networked Systems Design & Implementation USENIX Association232 3. Anonymous Neighbor Verification Open (ANV1). Each tester “opens” the two-phase ANV sub- protocol (Section 3.2) by sending an anonymous packet containing a nonce (to prevent replay at- tacks) and a hashed token to the testee for rebroad- casting. 4. Tester Information Exchange. Each tester compares the fraction of its data packets that it overheard and the fraction of its anonymous challenges that it heard reflected. It obtains a one-bit (“sign”) re- sult depending on which is greater: 0 for challenges and 1 for data packets. It then sends its sign bit and identity to the testee for rebroadcasting. 5. Epoch Evaluation and ANV Close (ANV2). Each tester determines whether the testee is operating correctly using its observations and the sign bits from other testers. This is done with a pair of statis- tical tests described in the next subsection. If both tests pass (and the testee correctly rebroadcast the tester’s sign bit), the tester releases its token. Other- wise, it withholds its token. 6. Isolation Decision. An epoch fails for a tester if it withholds its token or it does not receive all ex- pected tokens. If too many epochs fail too quickly (Section 4.3) then the tester decides that the testee is free-riding and punishes it by dropping its pack- ets for a fixed number of epochs. By virtue of the protocol, all testers decide to punish a free-rider at (nearly) the same time, so that it is isolated. We increase the likelihood of all testers seeing all con- trol packets in two ways. First, we use retransmissions if a tester does not hear the rebroadcast. Second, we use cumulative broadcasts, where the testee sends all of the information it has received on every transmission. 4.2 The Per-Epoch Tests Each tester applies two statistical tests per epoch to de- termine whether a testee is behaving correctly. Each test is designed to be sensitive to distinct selfish strategies. The key challenge in both is to avoid mistaking volatile wireless conditions for misbehavior. One selfish strategy is to drop packets from a particu- lar tester in the hope that the consensus across neighbors will be that the free-rider has passed the epoch, since all other testers should find its behavior acceptable. To de- tect this, each tester compares observed forwarding and true connectivity estimates for the last three epochs us- ing the z test [30]. We found that high confidence levels (99% and above) coupled with using measurements from multiple epochs provides a good balance between quick detection of free-riding and a low rate of false positives. The second selfish strategy is to uniformly drop some fraction of the packets received from each tester, mak- ing it hard for any one of them to conclude that free- riding has taken place. To detect this, we employ the sign test [30] using the sign bits exchanged by all testers. This test is based on the idea that the perceived forward- ing and connectivity rates should have identical means if the testee is not deliberately dropping packets. Thus, random fluctuations in each epoch should yield about as many results in which one exceeds the other as the op- posite. Each tester accumulates the one-bit results for all epochs in which it has participated, and applies the sign test to decide if the balance is reasonable. 4.3 The Isolation Decision Isolation of a testee is decided by all testers in parallel. Each maintains a small history of per-epoch test results, represented as a three state finite state automaton (FSA) that moves to the right when an epoch fails and the left when an epoch passes. If the FSA falls off the right edge, the testee is isolated. While it might seem that this scheme allows a node to free-ride for at least half of the epochs, the fact that the per-epoch test results depend on packet accounting data aggregated over the previous three epochs prevents this: free-riding in any one epoch impacts the tests for three consecutive epochs, and is likely to lead to multi- ple failed tests. We more fully explore this issue in Sec- tion 6.3. 4.4 Protocol Fail-safes Because Catch is designed to operate when some nodes act in a selfish manner, we are as concerned about what happens when the protocol is not followed as when it is. In Appendix A we provide a short analysis by message type that shows that selfish nodes cannot undermine the protocol in the absence of collusion. 5 Experimental Evaluation This section describes our experiments with Catch on an 802.11b testbed. This allows us to test how well Catch works in wireless environments that exhibit com- plex packet loss behaviors [24]. 5.1 The Testbed Our testbed is composed of 15 PCs equipped with 802.11b that run Linux 2.4.26. We use NetGear MA311 PCI network adapters (Prism 2.5 chipset), operating in the ad-hoc mode on channel 1 using the hostap driver. Each node also has a wired Ethernet interface to facili- tate remote management of the experiments. The testbed is located on a single floor of an office building, as shown in Figure 4. The building has its own NSDI ’05: 2nd Symposium on Networked Systems Design & ImplementationUSENIX Association 235 Figure 4: Our wireless testbed, consisting of fifteen 802.11b nodes. The node locations are marked with circles. Horizon- tally, the building is 184 ft. long. dense deployment of wireless access points, including ten on the same floor as our testbed, some of which com- pete with us on channel 1. Such a setting is noisy, but realistic [3]. Our system exhibits well-known characteristics of wireless networks, including error rates that are not a simple function of distance, that are strongly asymmet- ric, and that vary widely over time. Figure 5 gives a static summary of these effects. It shows the average one-way delivery rate in each direction for each pair of nodes that were able to communicate at all. To compute these rates, each node broadcast 500 1000-byte packets over two minutes. The other nodes counted how many of those packets they received. The figure shows a wide range of delivery rates rather than a binary state of con- nectedness, which is consistent with prior results [3, 43]. The diameter of our network is between 3 and 5 hops, depending on the threshold of link quality at which two nodes are considered connected. 5.1.1 Catch Implementation We implemented Catch at user-level using the Linux net- filter framework to monitor and manipulate the packets sent, received, and forwarded by a node. The watchdog component of Catch also needs to overhear all packets sent by the node’s neighbors regardless of their intended destination. To capture these packets, we operate our wireless network adapters in promiscuous mode and use the Linux pcap framework. The Catch protocol itself is written in ruby and is completely independent of the un- derlying routing protocol. 0 20 40 60 80 Node Pair 0.0 0.2 0.4 0.6 0.8 1.0 O n e - w a y D e l i v e r y R a t e Better direction Worse direction Figure 5: For each node pair in the testbed, the fraction of sent packets successfully received in each direction. There are 105 pairs total in the testbed. Only node pairs with a non-zero delivery rate between them in at least one direction are shown. One complication is that the watchdog mechanism needs to account for 802.11 MAC-level retransmissions. To see this, consider a tester judging whether the testee forwarded a particular data packet. The quality of the link between the testee and the recipient determines the number of retransmissions done by a cooperative testee. This in turn changes the probability that the tester will overhear the transmission. To correct for this recipient- based variation, we measure the data forwarding rate us- ing only the first transmission as indicated by a bit in the 802.11 MAC header. A complete implementation of Catch would also check that retransmissions are handled consistently to close a secondary loophole. We have not done so yet. We use the following parameters values for our ex- periments; simulations suggest that Catch is not highly sensitive to the exact choices. The length of an epoch is set to one minute. The confidence interval for the z test is 99.999%, and that for the sign test is 99.995%. (Both experiments and simple analysis showed that very high confidence values are most effective.) There are fifteen anonymous ACM messages per epoch, each of which is 1500 bytes, the MTU (maximum transmission unit) size of our network adapters. The loss rate for smaller data packets (such as TCP acknowledgements) can be less than that of the ACM messages. To verify forwarding behavior, our implementation checks that the loss rate for data packets is less than that for ACM messages. 5.1.2 Multi-Hop Performance We first show the potential benefit of relaying packets by comparing the performance of a single, centrally located access point (AP) setup to that of multi-hop routes. To do this we transfer a large file from one node, which acts as the AP (node 8 in Figure 4), to four client nodes (nodes 4, 6, 9 and 14). Each client downloads a 600KB file ten NSDI ’05: 2nd Symposium on Networked Systems Design & Implementation USENIX Association236 62% (83%) 76% (91%) 76% (95%) 78% (90%) Direct (Multi-Hop) Delivery Rate with the AP 0 50 100 150 T r a n s f e r T i m e ( s e c o n d s ) Direct connection Multi-hop connection Figure 6: Time to transfer 6MB from node 8 in Figure 4 by four other nodes via direct and multi-hop connections. The x-axis label gives the delivery rate of the direct connection with node 8, with the delivery rate for the multi-hop path in parentheses. The client nodes, from left to right, are 4, 6, 14, and 9. times. In one set of experiments, the clients communi- cate directly with the AP. In the other, they use multi-hop routes via a single intermediary node, over paths 4:5:8, 6:7:8, 14:10:8, and 9:10:8. We use static routes between nodes to factor out effects that stem mainly from the rout- ing protocols; wireless routing protocols are an open area of research [14]. Figure 6 shows the results. The x-axis labels give the delivery rate of the direct links, averaged over both direc- tions. The parenthesized numbers give an estimate of the quality of the two-hop path, computed as the product of the delivery rate of the individual links. In total, the use of multi-hop paths reduced download time by 16%, with per-node benefits ranging from 30% to -2%. The better performance of the multi-hop routes is due in part to the lower packet loss rates they enjoy. De Couto et al. have studied these issues in more detail [15, 14]. 5.2 The Impact of Free-riders We now consider the performance impact of free-riding, both as benefits to the free-riders and as costs to the co- operative nodes. We do this by contrasting the per-node throughput achieved in a fully cooperative network with those achieved when some nodes are allowed to free-ride. In this experiment, we randomly selected 3 nodes as free-riders. All nodes were trying to download randomly selected files from randomly selected servers. Figure 7 il- lustrates the average amount of data transferred under the two scenarios: “Free-riding Discouraged,” which results in all nodes behaving cooperatively, and “Free-riding Ig- nored,” where free-riders simply do not relay packets for cooperative nodes. Both scenarios were run for 35 min- utes. The two bars in each scenario average the per-node results for twelve nodes that acted cooperatively and for the three free-riders. The data illustrates two key points. Free-riding Discouraged Free-riding Ignored 0 2000 4000 6000 8000 A v e r a g e D a t a T r a n s f e r ( K B ) Cooperative nodes Free-riders Figure 7: Average amount of data transferred per node when free-riding is discouraged and when it is not. None of the nodes free-ride in the former. Nodes 7, 14 and 15 free-ride in the latter. First, there is a very large incentive to free-ride: the free- riders improve their throughput by 400% relative to when they are forced to cooperate. This indicates that there is considerable potential motivation for nodes to behave selfishly in these environments if they can do so with- out retribution. Second, the improved situation for the free-riders comes at the expense of cooperative nodes. The performance of the cooperative nodes is decreased by 25% when 20% of their fellow nodes selfishly mis- behave. While this is only a single example, it clearly demonstrates the need to incorporate protection against free-riding in routing protocols. 5.3 Catch Evaluation In this section we evaluate the effectiveness of Catch. 5.3.1 Detecting Free-riders Our first experiment measures the speed with which Catch detects free-riding. To construct a base case, we selected triplets of nodes such that both the first and the third node had a reasonable (>75%) delivery rate to the second node. The second node was configured to act as a free-rider that randomly dropped a fraction of the packets it received for forwarding. We experimented with differ- ent drop rates; Drop rates less than 100% mimic a sit- uation in which the free-rider tries to evade detection by appearing to be a cooperative but poorly connected node. The first node downloaded randomly selected files rang- ing from 1KB to 3MB in size from the third node. The request and response traffic was relayed through the sec- ond node. Five download sessions ran in parallel so that even in the presence of a high drop rate and TCP back- off dynamics, a minimum amount of traffic (roughly ten packets per epoch) is generated for the statistical tests. Figure 8 presents the results. The line “Drop packets from both” corresponds to the case when the free-rider drops packets from both neighbors. It shows the aver- age number of epochs required to detect a free-rider for NSDI ’05: 2nd Symposium on Networked Systems Design & ImplementationUSENIX Association 237 0 2 4 6 8 10 Number of Cheaters 0.0 0.2 0.4 0.6 0.8 1.0 P r o b a b i l i t y o f P a r t i t i o n i n g Q = 85% Q = 75% Q = 65% Q = 85% Q = 75% Q = 65% Figure 12: Probability that the cooperative nodes are parti- tioned versus varying numbers of (randomly chosen) cheating nodes when running with (dotted lines) and without (solid lines) Catch. Under Catch the cheaters use a signal strength based cheating strategy. Only links with delivery rates at least Q are considered useful. Even though a cheater may expect to reduce its for- warding load by about half using signal strength infor- mation, Catch still helps the cooperative nodes. Fig- ure 12 shows that Catch greatly improves connectivity for those nodes, relative to taking no measures against cheating. It plots the probability that a (randomly se- lected) set of such cheaters would partition the cooper- ative nodes when running with and without Catch. Be- cause Catch forces many cheaters to admit to multiple neighbors, and so to be available for packet forwarding, it significantly reduces the odds that the network is par- titioned. For example, when 20% (3) of the nodes cheat, that probability is lowered from about 60% to about 10% when using the highest quality links. At a 75% link de- livery rate threshold, the odds of a network partition are reduced from about 30% to zero. Of course, these re- sults are specific to our testbed; in general, the extent of protection provided by Catch depends on the degree of overlap between the signal strengths of different neigh- bors. We are currently extending Catch to mitigate such attacks by having testers vary their signal strength as part of the testing. 6 Simulation and Analysis We now extend our analysis of Catch using simulation. 6.1 Simulation Testbed and Metrics We built a simulator to generate packet loss and recep- tion counts for each epoch and to drive the protocol state machine. The simulator does not model the details of packet delivery. The protocol state machine is parameter- ized by the neighborhood topology, its loss rates, and the z and sign statistical test parameters. We focus on pack- ets that are subject to Catch’s statistical tests and ignore 0% 20% 40% 60% 80% 100% Drop Rate 1 10 100 1000 10000 100000 A T I ( E p o c h s ) loss rate: 50% loss rate: 25% loss rate: 10% Avg. time to falsely accuse cooperative node Figure 13: Average time to isolation versus drop rate, for var- ious background network loss rates. (Y-axis on a log scale.) other (control) packets. Our base setting includes a single free-rider with six neighbors. The epoch duration in the simulations is one minute. We set the confidence levels for the z and sign tests to 99.999% and 99.995% respec- tively. Results from the simulator showed that these val- ues achieved the best overall tradeoff between detection speed and false positive rate. To assess the effectiveness of Catch, we use Average Time to Isolation (ATI) as the metric. ATI is measured in units of epochs. An ideal policy would exhibit ATI values of one for nodes that free-ride (at any rate), and infinite ATI values for those that do not. 6.2 Physical Environment Effects We first evaluate Catch’s robustness to two characteris- tics of the physical environment: packet loss and network density. To model free-riding, we use a straightforward strategy in which the free-rider drops packets randomly with fixed probability. Because the packet losses due to the wireless network are also modeled as a random pro- cess, this drop strategy is arguably difficult for our statis- tical tests to detect. 6.2.1 Packet Loss We would expect higher wireless loss rates to make it more difficult to detect free-riding. Figure 13 shows ATI results as a function of drop rate for three different back- ground network loss rates. Each data point shows the average of 40 runs. When there is no free-riding (the y-axis), there is a large isolation time – an average of around 26,000 epochs (about 18 days). These times fall steeply as the drop rate grows, to under 10 epochs for drop rates of 10-20%. The results for loss rates in the range of 10%-25% are in line with those observed in our testbed (Figure 8), except that the homogeneous link qualities in the simulation environment result in much longer false accusation times. Thus, the impact of high NSDI ’05: 2nd Symposium on Networked Systems Design & Implementation USENIX Association240 0 2 4 6 8 10 Number of Neighbors 1 10 100 1000 10000 A T I ( E p o c h s ) cooperative node drop rate: 10% drop rate: 25% drop rate: 50% Figure 14: Average time to isolation versus number of neigh- bors. (Y-axis on a log scale.) wireless loss rates on Catch is quite small. Even at a network loss rate of 50% Catch isolates a free-rider who drops 25% of the packets it needs to forward in seven epochs on average, which is only four epochs more than the fewest possible. 6.2.2 Network Density We would expect Catch to perform better in denser net- works because larger neighborhoods are more likely to make correct statistical decisions. Figure 14 examines the impact of the number of neighbors on detection and false accusation times. We show results for a coopera- tive node (the top line) as well as for free-riders at drop rates from 10-50%. Increasing the number of neighbors from six to ten yields a small decrease in the time to de- tect free-riders, as might be expected: already at 6 neigh- bors there is little room for improvement. More surpris- ingly, reducing the number of neighbors by a factor of three, to only two, increases detection time by only a few epochs. Additionally, the rate at which cooperative nodes are falsely accused is essentially unaffected over the en- tire range. Thus, Catch seems to be robust, working well in both high and low density networks. 6.3 More Sophisticated Cheaters Thus far, we have analyzed a simple drop model in which the free-rider randomly drops packets it is meant to for- ward. We now use our knowledge of the statistical tests to construct packet dropping variations that target poten- tial weaknesses. While we cannot prove the negative re- sult that there are no strategies that might be effective against Catch, we can show that these customized strate- gies yield only very limited success. One variation is targeted free-riding, in which the free- rider drops packets from a time-varying subset of neigh- bors, rather than uniformly from all. This stresses the 2 3 4 5 6 Number of Neighbors Targeted 0 2 4 6 8 10 A T I ( E p o c h s ) on-off + rotation on-off rotation basic free-rider Figure 15: The time to isolation for customized free-riding strategies. The free-rider directs all misbehavior in a single epoch to the number of neighbors given on the x-axis. (Total cheat rate = 20%. Network loss rate = 20%.) z test in Catch, whereas we know that the basic free- rider is most often detected by the sign test. We call this approach “rotation.” A second variation attacks the iso- lation decision process. Since three consecutive failed epoch tests are required to isolate a node, a free-rider may attempt to escape isolation by dropping packets on, say, alternate epochs. We call this the “on-off” strategy. Finally, both attacks may be used at once. Figure 15 plots the number of epochs to isolation for these strategies against the number of nodes targeted, for the difficult environment where the loss rate is as large as the drop rate. (Both were set to 20%.) The graph suggests that these custom-built strategies are only very modestly successful. The most effective strategy for the free-rider is to obtain its overall average drop rate of 20% by dropping 60% of the packets from two of its six neigh- bors, while rotating that pair each epoch. Using that strat- egy, the free-rider is isolated in nine epochs on average, compared to five epochs for the base free-riding strategy. As another variation of the basic free-riding model, we experimented with free-riders that drop packets in a deterministic pattern, rather than randomly. The threat here is that the reduction in variance will help free-riders avoid detection. In fact, the opposite happened: Catch was more effective. 6.4 Assessing Effectiveness To complete this section, we consider how much better it might be possible to do than Catch. This is a difficult question to answer. We address it by comparing Catch to an unrealistically powerful alternative, the Detection Oracle, that serves as an informal upper bound on what might be possible by any technique. The Detection Oracle hears all packet transmissions everywhere in the network, without loss, and so has re- liable knowledge of all externally visible events. Addi- NSDI ’05: 2nd Symposium on Networked Systems Design & ImplementationUSENIX Association 241 0% 20% 40% 60% 80% 100% Drop Rate 1 10 100 1000 10000 100000 A T I ( E p o c h s ) Catch: loss rate 50% Oracle: loss rate 50% Catch: loss rate 10% Oracle: loss rate 10% Avg. time to falsely accuse cooperative node Figure 16: Comparison of the time to isolation with Catch and the Detection Oracle as a function of drop rate for 10% and 50% network loss rates. (Y-axis on a log scale.) tionally, it retains infinite history information, enabling it to apply the Catch statistical tests over this maximal pool of data. In contrast, the nodes in any real system have only imprecise information (due to losses), each one is directly aware of only a subset of the global informa- tion, and history information must be devalued due to the changing environment. Figure 16 compares the Detection Oracle with Catch. It suggests that Catch does nearly as well as possible. The oracle’s advantage exceeds a five epoch reduction in detection time only in the case of high network loss rate (50%) and relatively low (5-25%) drop rates. 7 Related Work Anonymous broadcast was first used as a protocol build- ing block in the Cocaine protocol for auction between mistrustful parties [40]. In a manner similar to Catch, Cocaine combines this building block with one-way hash functions. We apply this approach in a different and prac- tical setting, and our work also hints at the generality of the building block and the approach. Catch belongs to the class of enforcement-based mechanisms that discourage free-riding through the fear of punishment. The watchdog part of our detection mechanism was originally proposed by Marti et al. [29]. It is our use of it in real networks and in conjunction with anonymity to detect misbehavior that is novel. Ex- isting enforcement-based protocols [29, 10, 9] rely on reputation spreading to deal with cheating nodes. This requires global flooding, while Catch limits information spread to single-hop neighborhoods. Moreover, simple flooding requires network redundancy as selfish nodes will not forward incriminating reputation packets. Catch uses anonymity and one-way hash functions to reliably communicate with the neighbors of free-riders. Our use of one-way hash functions is similar to Hu et al.’s work on secure routing in wireless networks [20, 21]. Incentive-based approaches discourage free-riding by making cooperation more attractive. Nodes accumulate virtual currency by forwarding for others, which they can then use for sending their own packets. Examples include Nuglets [11], Sprite [44] and priority forward- ing [34]. These schemes rely on a trusted central au- thority or tamper-proof hardware to ensure the integrity of the currency, and to redistribute wealth so that even nodes that are not in a position to forward for others can send their packets. In contrast, the operation of Catch is completely distributed. Incentives also fail to encourage nodes with very little data of their own to send. This can lead to a disconnected network when light-senders are located at strategic points in the topology. Finally, game-theoretic approaches formulate the for- warding decision such that forwarding at a certain rate becomes the Nash equilibrium [18] for the network. This means that deviation from the recommended forwarding behavior can only result in situations that are worse for the deviant node. Generous Tit-for-Tat (GTFT) is an ex- ample of such an approach [39]. Like GTFT, Catch re- lies on the mechanics of Tit-for-Tat by assuming cooper- ation and punishing free-riders. However, while GTFT requires knowledge about the utilities of all the nodes in the network, Catch relies only on information collected in the one-hop neighborhood of individual nodes. 8 Conclusions We have presented Catch, a protocol to sustain cooper- ation in multi-hop wireless networks comprised of au- tonomous nodes. Catch is much more widely applica- ble than other proposed solutions, needing no central au- thority and placing no restrictions on workloads, rout- ing protocols or node objectives. It uses novel strate- gies based on anonymous messages and statistical tests to detect free-riders with high likelihood and punish them with periods of isolation. Anonymous challenge mes- sages are used to estimate true loss rates, even when deal- ing with untrusted and uncooperative nodes. Anonymous neighbor verification is used to compel a node to for- ward packets, even when the data being carried is con- trary to its interests. While our application of anonymity and neighborhood watch are specific to the wireless do- main, we expect that these techniques are general enough to be applicable in other domains. We implemented Catch in Linux and performed what to our knowledge is the first evaluation of cooperative routing protocols in an 802.11 wireless testbed. We showed that Catch works well despite volatile wireless conditions and requires little bandwidth overhead (and negligible CPU overhead). In our experiments, free- riders are quickly isolated from the network (and more NSDI ’05: 2nd Symposium on Networked Systems Design & Implementation USENIX Association242