Building Better Incentives for Robustness in BitTorrent

Building Better Incenti v es for Robustness in BitT orrent Seth James Nielson, Caleb E. Spare, Dan S. W allach seth@sethnielson.com, cespare@rice.edu, dwallach@cs.rice.edu Computer Science Department, Rice Uni versity Abstract BitT orrent is a widely-deployed, peer-to-peer file transfer protocol engineered with a “tit for tat” mechanism that encourages cooperation. Unfortunately , there is little in- centiv e for nodes to altruistically provide service to their peers after they finish downloading a file, and what altru- ism there is can be exploited by aggressi ve clients like Bit- T yrant. This altruism, called seeding, is always beneficial and sometimes essential to BitT orrent’ s real-world perfor- mance. W e propose a new long-term incentiv es mecha- nism in BitT orrent to encourage peers to seed and we e v al- uate its effectiv eness via simulation. W e sho w that when nodes running our algorithm re ward one another for good behavior in previous swarms, they experience as much as a 50% improvement in do wnload times over unrew arded nodes. Even when aggressive clients, such as BitT yrant, participate in the swarm, our rewarded nodes still outper- form them, although by smaller margins. 1 Intr oduction Peer-to-peer file transfer protocols pro vide scalable archi- tectures for distributing large files. The core idea is to hav e peers participating in the download also contrib ute upload service back to the system, thus scaling the avail- able bandwidth as more peers join. Even centralized ser- vices with large netw ork connections can be ov erwhelmed by flash crowds, while p2p services can ostensibly con- tinue to scale, ev en in such extreme scenarios. In the practical world, ho we ver , scalability and stability in p2p systems are limited by the cooperation of the par- ticipants. These systems only have as much bandwidth as is collectiv ely donated. Proper behavior cannot neces- sarily be enforced; participants are going to behave r atio- nally , taking whate ver steps maximize their own benefit without particularly caring about the well-being of other peers. Consequently , the default behavior of most par- ticipants is to consume and not contribute. This is often called the “free rider” problem. BitT orrent [3] mitigates the free rider problem by re- warding uploads by granting faster downloads through a “tit for tat” (TFT) protocol, thus making cooperation a rational behavior . This design has been highly success- ful, enabling BitT orrent’ s wide acceptance in the Inter - net community . While there is no consensus on the true amount of BitT orrent data in-flight today , it is clear that the number is large at some where between one-third and one-half of all Internet traffic [14, 6, 20, 19]. Despite the practical success of BitT orrent, numerous researchers ha ve e xposed weaknesses to the TFT incen- tiv es mechanism [15, 22, 21, 8]. One prominent weakness is the significant lev el of altruism that remains in the sys- tem despite the TFT mechanism. More specifically , many peers still contrib ute significant upload bandwidth without necessarily improving their do wnload performance. Such contributions are produced by asymmetries in upload and download bandwidth as well as by altruistic BitT orrent behaviors like seeding and optimistic unchoking. (Sec- tion 2.3 discusses this “ambient altruism” in detail.) These exploits are not simply theoretical. Bit- T yrant [15] takes advantage of the intrinsic altruism to achiev e high do wnload rates while reducing upload con- tributions. Most BitT orrent clients can be easily con- figured to rely exclusi vely on leeching, and some re- search suggests this is ef fective despite the TFT incen- tiv es [10, 21]. Our goal in this work is to reduce the altruism in Bit- T orrent seeding by adding incentives to the seeding com- ponent of the protocol. W e present the design and ev alu- ation of our seeding reward algorithm which requires a minor change to BitT orrent in the form of a long-term identifier for participating clients. Through simulation we demonstrate that rew arded peers get better performance than unre warded peers. This dif ferential creates an incen- tiv e for rational nodes to switch into the rewarded pop- ulation. W e further show that the rewarding mechanism improv es node performance e ven when some portion of the swarm is composed of BitT yrant nodes. In the remainder of the paper , we first revie w the oper- ations and altruism of BitT orrent in Section 2 as well as 1 an o vervie w of the BitT yrant variant. Sections 3 and 4 present our algorithm and the methodology we use to ev aluate its performance. Our results are detailed in Sec- tion 5 and further analyzed in Section 6. W e close with a discussion of related work in Section 7 and our conclu- sions in Section 8. 2 Backgr ound BitT orrent [3] is a highly successful and popular peer -to- peer protocol which aims to enable ef ficient, rapid distri- bution of potentially large amounts of data to a group of clients. It is designed to utilize the a vailable upload band- width of the clients to scale the capacity of the system to support man y users and has built-in mechanisms to incen- tivize participation in this scheme. 2.1 The BitT orrent Protocol A torrent is a file or a set of files users wish to down- load. The data is divided into equal-sized pieces , typically 256KB, which are further subdi vided into small bloc ks . A central node called the tracker keeps track of the peers participating in the distrib ution of a torrent. The tracker does not serv e the actual content, but instead serves as a rendezvous point for peers to disco ver one another . BitT orrent clients use a file of metadata, called a tor - r ent file , to begin downloading content. This file, typi- cally downloaded from a traditional web server , specifies the address for the tracker as well as information about the files to be downloaded, including names, sizes, and SHA-1 checksums for each piece. The set of clients working on downloading a gi ven tor- rent is referred to as a swarm . Clients notify the tracker as the y join and leav e the sw arm, as well as e very 30 min- utes they are activ e within the swarm. T o discover other clients, a client may query the tracker , which giv es it a random subset of the activ e peers. (A variety of exten- sions e xist which supplement the tracker , including a gos- sip protocol as well two DHT -based schemes.) Once it has a set of peers, a client establishes TCP connections to its peers, forming a neighborhood with whom it shares in- formation about which pieces it has and has not completed downloading. A legitimate publisher might establish one or more official seeds , which provide round-robbin, best- effort service to an yone who asks. These seeds are then supplemented by altruistic peers who seed after they finish their downloads. 2.2 BitT orr ent Strategies Popular BitT orrent clients employ a number of strate gies to encourage fair participation in uploading and to deal with a variety of corner cases [3]. A client only uploads to a small number of peers in its neighborhood at any giv en time. This group of nodes is called the client’ s active set . The size of the active set is typically four , although both the reference implementa- tion and BitT yrant [15] note that this number should scale with maximum upload bandwidth capacity . The majority of the nodes in the acti ve set are the nodes that hav e gi ven the best service over a rolling 20 second average. The client saves one or two slots in the acti ve set for the e xplo- ration of new neighbors. Optimistic unchokes pick a ran- dom peer e very 30 seconds, allowing the client to search for better neighbors while also bootstrapping newly joined clients that hav e not yet downloaded an ything to share. BitT orrent clients share current status information with other clients to indicate which pieces are completely downloaded. Clients will bias their block requests to com- plete one piece before the y begin do wnloading a dif ferent piece. T o pick a piece to download, BitT orrent follo ws a rar est first policy , where a client picks pieces based on lowest av ailability within its neighborhood. The excep- tion to this rule is for new clients, which need a complete piece before they can adv ertise any content for upload. In this case, they instead pick a random piece. When a block has been requested, a client does not reis- sue the request until either the block is received or the re- quest times out. This can be a problem when a user has receiv ed most of the pieces in a file and has just has a few outstanding requests to go. If the final peers are slo w or unresponsiv e, the system might nev er finish. In this case, the client goes into endgame mode and sends redundant requests for any missing blocks to its peers; as they are receiv ed the client sends messages to the remaining peers to cancel unnecessary requests. 2.3 Ambient Altruism and BitT yrant BitT orrent aims to reduce the free-rider problem, but it is not intended to eliminate altruism in the system. Instead, BitT orrent aims to ensure that a node will experience sig- nificantly improved performance if it participates in TFT trading, rather than leeching. Consequently , altruistic fea- tures remain in the protocol and pose two separate, but related, problems. First, a client can reduce or eliminate its own altruistic participation, reducing the overall swarm performance. Second, if a client can recognize peers that are participating altruistically , it may be able to obtain suf- ficient service from these peers to find it unnecessary to deal with those that require cooperation. T wo significant sources of altruistic contributions are seeding and optimistic unchoking. Seeding is inherently altruistic under the current BitT orrent protocol. The al- truism of optimistic unchoking is more complex. The optimistic unchoke operation is BitT orrent’ s method of 2 searching the peer space for better TFT service. An un- choke that results in improv ed service because a better peer is found is clearly not altruistic, but unchokes are performed with random peers, rather than being biased away from known leeches. This means that BitT orrent’ s standard unchoking behavior can still provide a source of altruism, to the benefit of leeches. Differences between peer bandwidth capacities also produce altruism. When a normal BitT orrent client un- chokes a peer , it sends data as fast as the TCP stack will go, so peers with faster network connections will tend to giv e more out than they get in return when dealing with slower peers. Of course, two fast peers with content to trade will be more likely to establish TFT trading with one another than a fast peer and a slo w peer . BitT yrant is a strategic BitT orrent variant that exploits ambient altruism and reduces its o wn altruistic contribu- tions [15]. BitT yrant was designed to download as fast as possible while contributing the minimum amount re- quired to achie ve it. T o achie ve this, BitT yrant abandons BitT orrent’ s policy of giving each member of the acti ve set an equal share of its upload bandwidth. Instead, Bit- T yrant unchokes as many neighbors as possible b ut limits the speed of each upload stream to be only as much as is necessary to obtain reciprocation. This scheme does not work for other BitT yrant nodes, howe ver , and two BitT yrant nodes must enter a special mode when dealing with each other . In Section 5.6, we will describe this special mode in detail and demonstrate how it can be used as part of a defense against BitT yrant’ s behavior . 3 Incentiv es Design Our incenti ves design for seeding in BitT orrent requires that the BitT orrent protocol support some form of long- term identifier . The basic concept for our algorithm is that BitT orrent clients recognize seeders from previous swarms and this is impossible without these IDs. Fortu- nately , the exchange of long-term identifiers can be built into the peer handshaking process in a backwards compat- ible fashion. Clients without a long-term ID are simply assumed to hav e no history . It is also worth noting that some clients [17] already support an optional long-term ID. Our proposed design consists of an observation phase and a reward phase. The observation phase is in effect whenev er the node is receiving seeding bytes, or bytes re- ceiv ed from a neighboring peer without the expectation of TFT reciprocation. The detection of seeding bytes, in our basic implementation, is based on first-hand, verifiable in- formation only . Obviously , it is possible that the neighbor is only pretending to seed, but from the observing node’ s perspectiv e, all bytes receiv ed without giving an y bytes in return are seeded bytes. The reward phase occurs when the node is in seeding mode. The goal is to schedule outbound seeding with higher priority gi ven to peers who ha ve seeded in the past. T o do this, the algorithm first computes a score for each node; nodes who seeded get higher scores. These scores are used to initialize a scheduler , giving more slots to nodes with higher scores. While virtually any scheduling algorithm would suffice, we chose to use lottery schedul- ing [24]. Each peer gets at least one ticket, but peers that seed get additional tickets in proportion to the logarithm of the number of bytes we hav e receiv ed from them in seeding. Obviously , a node that chooses to be a good citizen and seed may not be re warded at all in the future. F or node A to be rewarded by node B , A must seed to B and then B must seed to A in some subsequent swarm. That means that both nodes must interact repeatedly over time. For any real benefit to the algorithm, a group of nodes must interact repeatedly . W e note that a Sybil attack [4] is possible against this protocol. For example, malicious nodes could create a large number of false identifiers, gaining additional shares of the bandwidth. W e deal with this by reserving a per- centage of a seeder’ s upstream bandwidth for other known seeders. Sybil attackers may well fight it out for the re- maining unreserved bandwidth, but there is a larger pool of bandwidth av ailable if they cooperate. Another possible Sybil attack would be a r eincarnation attack [13] where a client sheds an old identifier for a new identifier in every swarm to erase pre viously observed bad behavior . Such behavior would be unhelpful to the node, howe ver , because a fresh identifier be gins with no rewards at all. Re wards only come with observed good beha vior . 4 Methodology 4.1 Simulator W e chose simulation as our primary method for analyzing incentiv es and altruism in BitT orrent. The adv antages of a simulator o ver real world tests or the use of network emu- lation lies primarily in the repeatability of the experiment and the time required to run the experiment. Our research requires comparison of algorithms against one another as well as experimentation with hundreds of combinations of parameters. Repeatability and fast time to completion were both incredibly helpful. Sev eral BitT orrent simulators exist but they did not fully meet our needs. One simulator from MSR [1] does 3 not implement asynchronous communication nor does it capture some BitT orrent details, such as piece chunk transmission, that we deemed necessary . An ns-2 [5] Bit- T orrent simulator was also av ailable, b ut it simulates TCP effects and other network lev el details that were too lo w lev el for our purposes. GPS [25] is a general purpose p2p simulator that includes a BitT orrent module and simulates at about the same lev el of granularity as our work. GPS is written in Jav a and our work appears to run faster . T o meet our objective, we hav e designed an optimized C++ simulator with a Python front end for simulation setup and execution. Our simulator allows swarms of thousands of clients, with several hundred running simul- taneously , many times faster than real-time. T o illustrate this, we ran a series of tests on an Athlon 2.4Ghz dual- processor server with 4GB of RAM and running with the Linux 2.6.9 k ernel. These tests employed a simple swarm where a giv en number of clients arrive simultaneously and join the swarm. There is only a single seed for the swarm. W e fix the file size at 100MB, the seed’ s upload capacity at 512Kbps, and each client’ s bandwidth at 56Kbps, sym- metric for uploads and downloads. The results for various swarm sizes is shown in T able 1. These results show that the time required to simulate the sw arm is proportional to the number of peers. 4.2 Simulation Setup All the e valuations in this paper are based on a flash- crowd, 1GB file BitT orrent swarm. W e used a total popu- lation of 2000 DSL clients with a range of do wnload band- widths from 128Kbps to 5Mbps. Each client’ s upload bandwidth is precisely half of its download bandwidth. T o obtain reasonable churn, we make use of real-world Bit- T orrent traces tak en in 2005 by Johan Pouwelse. These traces provide realistic join times for flash-crowd behav- ior in real swarms. Each simulation is also configured with experiment- specific parameters. The significant parameters are: Seeding Time The 2000 clients of the swarm are as- signed one of three seeding population types. Altruis- tic clients will seed for 24 to 48 hours after their down- load is complete. Standard clients seed for one to two hours. Leech clients terminate their connection imme- diately after do wnloading the object. These values are based on why peers choose to seed; altruistic clients in- tentionally stay around to be helpful, standard clients will continue running until the user notices the down- load is done and kills the client, and leech clients lea ve as quickly as possible. Even though these numbers are guesses, we hav e validated that a swarm with 10% altru- istic nodes and 70% standard nodes yields seed-to-swarm Figure 1: Simulated swarm membership over time based on a real-world trace from a flash-cro wd swarm. ratios similar to those observed in a prior measurement study . (Figure 1 in this paper closely resembles Figure 5 in Pouwelse et al. [16].) Seeding Algorithm Populations in the swarm can be as- signed to use different seeding algorithms. The standard seeding algorithm simply seeds round-robbin to all of the peers in a seed’ s neighborhood. W e also support an “in- centiv es seeding” algorithm, as described in Section 3. Incentives Seeding P arameters For peers using the in- centiv es seeding algorithm, we can vary the bandwidth reservation for rewards as a percentage of the total band- width; all incentiv es seeding nodes will use the same reservation percentage in a given simulation run. Also, for nodes using our re warding seeding algorithm, we in vent a past history for each one, assigning them a number of bytes that they hav e seeded in the past. W e similarly vary what portion of the population are aware of this history , allowing us to simulate e verything from oracular kno wl- edge of e very node’ s past behavior down to fragmentary knowledge that would be a more realistic approximation of prior , first-hand observations. While oracular knowledge is unrealistic in practice, it allows us to place an upper bound on the benefits of seed- ing policies that use this kno wledge. First hand informa- tion is more limited in scope b ut much more difficult to exploit [13]. In our research we are assuming that there are no disjoint cliques of ov erlapping peers. This would seem to adequately capture common classes of real-world behavior as we might expect from people who download related content, such as new episodes of TV shows re- leased on a weekly basis. 4 n Sim T ime (hours) Real T ime (hours) Messages Memory (MB) 10 5.86 0.004 233,950 20 100 4.77 0.07 1,381,715 60 1000 5.24 0.86 13,635,955 492 T able 1: Basic simulator performance as the number of simulated nodes ( n ) grows. T rading Algorithm W e have implemented both the regular BitT orrent TFT and the BitT yrant trading algo- rithms in our simulator . T rading and seeding algorithms may be assigned independently; a peer can use the Bit- T yrant trading algorithm and our incentiv es seeding algo- rithm if desired. 4.3 Incentives Evaluation Our goal is to create an incentive for participants in Bit- T orrent to seed. W e will ev aluate the ef fectiv eness of our algorithm by demonstrating that rewarded populations perform better than unre warded populations in our simu- lated swarms. By running the e xperiments under a v ari- ety of configuration parameters, we wil l characterize how these parameters affect the success of our incenti ves algo- rithm. In ev aluating the performance of a node, our basic mea- surement is the download efficiency , defined as the utiliza- tion of the peer’ s download pipe over its lifetime in the swarm. Efficienc y is a direct measure of the node’ s happi- ness, and it is perfectly normalized. An y node, regardless of speed, cannot be happier than when it has 100% do wn- load utilization. Computing the ef ficiency e is straightforward. Let k be the maximum download capacity of the node measured in bits per second (bps). Then let t 0 be the time the peer con- nected to the swarm and let t d be the time that it finished the do wnload, where both values are measured in seconds. Finally , let n be the number of bits in the download object. Then e = n/ ( t d − t 0 ) k . Of course, when simulating a large population of nodes with various configurations assigned at random, we would expect significant variation in individual nodes’ ef- ficiency , ev en when they have the same configuration. Figure 2 shows cumulativ e distribution functions over nodes’ efficienc y in a simulation with altruistic, standard, and leech nodes. A curv e that stays closer to the bottom of the graph, as the altruistic data series does, represents more nodes operating closer to their peak efficiency . (This experiment shares the same configuration as used later in Figure 12.) While we could potentially generate a figure like this Figure 2: Cumulati ve distribution of efficiency (band- width utilization) over different populations in the same swarm. Figure 3: Cumulati ve distribution of download time ov er different populations in the same swarm. (A different view of the same e xperiment shown in Figure 2.) 5 Median Efficienc y (%) Median Download time (s) Altruistic Standard Leech Altruistic Standard Leech 98.8 48.9 90.1 3304 7443 4402 T able 2: Comparison of median efficienc y and median download time for the same e xperiment. Population A verage Std. Dev 95% Confidence Interval Altruistic 98.0% 1.8% 4.1% Standard 57.9% 8.5% 15.3% Leech 87.6% 4.8% 8.2% T able 3: Median efficienc y , averaged o ver twenty dif ferent experimental runs, dif fering only in the random seed. Population A verage Std. De v 95% Confidence Interval Altruistic 97.9% 1.9% 4.6% Standard 71.1% 7.9% 11.9% “Leech” 71.2% 7.6% 12.9% T able 4: Median efficienc y , a veraged ov er twenty experimental runs as above, with the leech nodes replaced by standard nodes. for e very possible simulation configuration, and ev ery simulation run w ould generate a figure with the same gen- eral shape, this would obscure trends from one simulation to the next. Instead, we observe that the median v alue of each data series (i.e., the efficiency v alue for which the data series reaches 50% on the y -axis) represents an ef- fectiv e proxy for the overall beha vior of the data. If the median values are close, then the curves will be close. If the median values are far apart, then the curves will be f ar apart. For our experiments, then, any giv en set of experimen- tal parameters (as described in Section 4.2) will yield three v alues: the median efficiency of each of the three populations (altruistic, standard, and leech), which we can then plot as we vary the simulation parameters. An alternative to efficienc y would be to consider the download times, without normalizing them for differences in each node’ s a vailable bandwidth. Figure 3 shows CDFs of download times for the same experimental setup as Figure 2. W e added an “optimal” distribution, repre- senting the best that the altruistic nodes could ev er have performed if the y had achiev ed 100% utilization of their download bandwidth. W e could hav e added additional “optimal” lines for each population, but this would make reading the figure more complicated. Furthermore, me- dian values are less meaningful because the underlying distribution of bandwidths would v ary if the random as- signment were done differently . Of course, absolute download time and download effi- ciency are measuring the same underlying phenomenon; improving one metric would clearly improv e the other . T able 2 sho ws the median values from each of these fig- ures. The efficiency values elide unnecessary experimen- tal details and concisely describe the relativ e performance of each population. Lastly , we must convince ourselves that efficienc y is a reliable metric from one experimental run to the next. Since man y of the parameters in our system are as- signed randomly , we experimentally re-ran our experi- ment twenty times, each time with a dif ferent random seed. The results, sho wn in T able 3, sho w significant vari- ation from one run to the next, but the variations among altruistic nodes are smaller than among standard nodes. For an additional experiment, we changed the leech nodes to be standard nodes. W e would expect, then, that they would beha ve the same as standard nodes. T able 4 clearly validates this beha vior . From these measurements, it appears that standard nodes are more likely to be the victims of circumstance, while altruistic nodes and leech nodes are more stable in the face of random variation. As such, the reported per- formance of standard nodes should be considered to be noisier than the reported performance of altruistic or leech nodes. While we could precisely work out the minimum change between different populations that would repre- sent a statistically significant difference, this is insuffi- cient for our needs. Experimentally , we must show that our desired altruistic behavior doesn’t just make a statis- tically significant improvement. W e must show a large enough improvement to incentivize BitT orrent users to 6 Figure 4: The median ef ficiency of the overall sw arm un- der dif ferent compositions of clients. The worst perfor - mance is experienced when there is only one seed. When 70% of the clients seeding for 1-2 hours, the performance improv es significantly . When 10% of the nodes seed for 1-2 days, the median efficienc y approaches 100%. choose clients that follow our desired beha vior . (For the remainder of the paper , we only run each ex- periment a single time for a giv en set of experimental pa- rameters. Since each data point takes as long as a day to compute, we cannot afford to run every experiment twenty different times.) 5 Evaluation In this section, we detail the findings of our research. W e will first demonstrate why seeding is important for swarms of nodes with asymmetric bandwidth. W e will then demonstrate how our algorithm improves perfor- mance for seeding nodes. The next three subsections explore ho w bandwidth reservation, altruistic population size, and re warding node o verlap impact the ef fectiveness of our seeding algorithm. Finally , we analyze the perfor- mance of our algorithm in swarms that include BitT yrant nodes. 5.1 Importance of Seeding Our first objective was to establish the importance of seed- ing to a BitT orrent swarm. W e ran our simulation with three different population configurations. First, we ran the swarm with 1 initial seed and 100% of the swarm composed of our leech clients that do no seeding what- soev er . Next, we ran the swarm with 1 initial seed, 70% of the standard clients that do a small amount of seeding, and 30% of the leech clients. Finally , we ran a simulation with 10% altruistic nodes that seed significantly , 70% of the standard clients, and 20% of the leech clients. The results are shown in Figure 4. There are two reasons why the swarm cannot obtain high ef ficiency without significant seeding contributions. First, the swarm is comprised of nodes with asymmetric bandwidth profiles. In our swarm, the upload is alw ays half of the download capacity . Even with idealized op- erations, a swarm could hope for no more than 50% effi- ciency from TFT trading alone. The second issue is that a BitT orrent swarm is not ideal. V arious factors such as churn reduce the effecti veness of the protocol. Seeding provides enough additional capacity to overcome these deficiencies. Clearly , seeding is essential for nodes in a swarm to maximize their download bandwidth; if we can design a mechanism that incentivizes more BitT orrent users to seed for longer periods, this should ha ve a clear, positiv e im- pact on the system. 5.2 Rewarding Seeding T o e valuate our re ward seeding algorithm, we first ran a baseline simulation. The setup for this simulation was 10% altruistic nodes, 70% of the standard clients, and 20% of the leech clients. All three populations were run- ning the standard BitT orrent trading and seeding algo- rithms, thus we expected all three populations to expe- rience similar performance. As expected, the results for all three populations was near 100% ef ficiency . W e then repeated this baseline experiment with all of the altruistic nodes configured to run our reward seeding algorithm, reserving 75% of their bandwidth for rew ards to prior seeders. The other two populations continued to use normal seeding algorithms. In this version of our ex- periment, we assumed perfect overlap for this altruistic group. In other w ords, ev ery altruistic node had been pre- viously seeded by ev ery other altruistic node, prior to the start of the experiment, and would thus allow the other altruistic nodes to share in the bandwidth reserved for re- wards. The results of this simulation are shown in Fig- ure 5. The altruistic population maintained nearly perfect efficienc y , while the two unrewarded populations experi- enced a significant drop in performance. 5.3 Bandwidth Reservation As described before, our seeding algorithm can reserve bandwidth for the exclusi ve use of nodes being re warded. T o understand the necessity of these bandwidth reserv a- tions, we ran a simulation where we v aried the percentage of reserved vs. unreserv ed seeding bandwidth. The re- sults, shown in Figure 6, show the median ef ficiency of the altruistic, standard, and leech populations in simula- tions with different reserved bandwidth configurations. In all simulations, there are 10% altruistic, 70% standard, and 20% leech clients. The bandwidth reservation applies to altruistic nodes’ seeding bandwidth. For the moment, 7 Figure 5: Median ef ficiency when the altruistic popula- tion reserves 75% of the seeding bandwidth for other al- truistic nodes. we are assuming that altruistic nodes all have prior history and know which other nodes ha ve seeded in the past. One immediate observation is that our seeding algo- rithm, without any bandwidth reservation, does no bet- ter than normal seeding. This seems counter-intuiti ve be- cause the rewarded nodes should still be getting more seeded bytes than their unrewarded peers. One might think that there would be some performance improvement for the altruistic nodes, e ven with 0% reserv ed bandwidth, but the y are already getting nearly 100% efficienc y . W ith bandwidth reserv ations, if there is insuf ficient de- mand from the “reward” population, then that portion of the seeding bandwidth will go unused. In short, our work suggests that the only way to create a performance dif- ferential between rewarded and non-rewarded nodes is to withhold service from unrew arded nodes. There is an interesting trade-off, howe ver . If the reser- vation is too high, then all of the bandwidth is effecti vely being spent on maintaining old relationships rather than establishing ne w ones. As nodes quit old swarms and join new ones on a re gular basis, there is a clear incentiv e to hav e seeded to strangers in the past if there might be a payout in the future. 5.4 Altruistic Population Size W e cannot predict what percentage of nodes in a given swarm might be running our reward seeding algorithm. W e would like to v erify , regardless of the breakdo wn, that incremental growth in the reward seeding group will yield benefits both for those nodes as well as for ev erybody else. This leads to the question of how the system will respond as the population dynamics change. Figure 7 shows how efficienc y changes as a function of the percentage of the altruistic and standard populations in the total sw arm. The leech population is fixed at 20% and the rew arding nodes Figure 6: Median ef ficiency as a function of the reserved bandwidth by the altruistic nodes. Figure 7: Median efficienc y as a function of the percent- age of altruistic nodes in the swarm. Figure 8: Median efficienc y as a function of the percent- age of ov erlap in the altruistic nodes. 8 reserve 75% of their bandwidth. This experiment demonstrates that the performance of the entire swarm improv es as more nodes follow our altru- istic scheme, ev en when reserving 75% of their bandwidth for rew ard seeding. That other 25% is enough to improve things for ev erybody else. At some point, be yond the 30% altruism rate where we terminated our simulation, the standard nodes may ha ve sufficient efficienc y that they would be disincentivized to change to the altruism strategy . By then, the altruism strat- egy would already be the dominant behavior in the swarm. Also, regardless of the rate of altruistic nodes, this exper- iment shows that altruism always wins, and sometimes wins big, ev en with relatively low populations of altruis- tic nodes. 5.5 Overlap In this section, we explore the highly critical overlap pa- rameter . Our algorithm assumes that nodes are rewarding based on first-hand information gleaned from prior inter- actions in prior swarms. In pre vious e xperiments, we ha ve assumed that this knowledge of prior interactions, which we call overlap , is complete. Every node has prior, posi- tiv e interactions with its altruistic peers and thus kno ws to include them in the re ward population during future inter - actions. Such oracular kno wledge is not realistic. For simulation purposes, we wish to vary the degree to which altruistic nodes have had past interactions with other altruistic nodes and thus ha ve the first-hand knowl- edge necessary to giv e rew ard seeding to their peers. T o accomplish this, we partition the altruistic nodes into two sub-groups: re warding and non-rewarding nodes. Re- warding nodes will rew ard all other altruistic nodes, in- cluding non-rewarders, while non-rew arding nodes will rew ard nobody . Non-rew arding nodes still have the same 75% bandwidth reserv ation, but they ne ver use it. By varying the ratio of rew arding to non-rewarding nodes, we can roughly simulate the real-world effects that might be seen as the degree of ov erlap between altruistic nodes varies. Figure 8 shows the efficienc y for each population as a function of the percentage of altruistic nodes that are rew arders. W e maintain a 10% altruistic, 70% standard, and 20% leech population. Reserved bandwidth remains fixed at 75%. Our experiment demonstrates that overlap is clearly necessary to achie ve the benefits of our reward seed- ing strategy . Once the ov erlap reaches 50% (i.e., about half of the seeding interactions between altruistic nodes are rewarded with higher bandwidth), the performance improv ement for the altruistic strategy is undeniable. Whether such an overlap rate can be achiev ed in the real world is unclear . W e discuss some strate gies that might compensate for this in Section 6. 5.6 Seeding Rewards versus BitT yrant In this section, we test the altruistic rew ard seeding al- gorithm against clients running the more aggressi ve Bit- T yrant trading algorithm. BitT yrant clients tend to see im- prov ed performance at the expense of other nodes in the system. (BitT yrant was introduced in Section 2.3.) Our first e xperiment, shown in Figure 9, pits rew arding seeders against tyrannical leeches. This test repeats the bandwidth reservation e xperiment of Section 5.3 with the leeching population configured to use the BitT yrant trad- ing algorithm. All other parameters remain the same. Comparing these results against those of the earlier bandwidth reservation test, we note that BitT yrant-leeches performed as well as the rewarded altruists. At the same time the leeches degraded the performance of the stan- dard nodes significantly . From this we conclude that the reward-seeding algorithm protects against, or at least ameliorates the e xploitation of the BitT yrant protocol, b ut that it does not sufficiently penalize the leeching clients. T o e valuate ho w the size of the altruistic population im- pacts the performance of these populations, we repeated the e xperiment of Section 5.4, again with the re warding altruistic seeders versus the tyrannical leeches. W e hoped that increasing numbers of altruists might be able to pe- nalize the tyrannical leeches. Unfortunately , as shown in Figure 10, the tyrannical leeches still had no trouble achieving near perfect ef ficiency . W e considered the possibility that the leeching nodes would not do so well if the altruistic nodes were more stingy during the TFT trading phase. T o test this, we re- configured the bandwidth reservation test. In this experi- ment, the altruists use the BitT yrant TFT strategy rather than the default BitT orrent TFT strategy , but still per- form the incenti vized reward seeding. The leech popula- tion still practices tyrannical TFT trading and ne ver seeds. The standard population uses standard algorithms for both seeding and TFT trading. All other simulation parameters remained the same. The results are sho wn in Figure 11. Based on these experiments, a rational user might just as well run a tyrannical client as an altruistic client. They will recei ve the same do wnload ef ficiency and they will minimize their upload bandwidth. 5.7 BitT yrant Exploitation In the pursuit of finding a weakness in BitT yrant’ s seem- ingly anti-social beha vior , we discovered a problem with BitT yrant’ s exchange mechanism (also noted by Carra et al. [2]). The original BitT yrant paper [15] says: 9 Figure 9: Altruistic nodes versus tyrants under dif ferent amounts of reserved bandwidth. Figure 10: Altruistic nodes versus tyrants with dif ferent ratios of altruistic nodes in the population. Figure 11: Rew ard-seeding altruists, modified to trade tyrannically before the y be gin seeding, versus tyrant- leeches under different amounts of reserved bandwidth. Figure 12: Median ef ficiency when altruistic nodes refuse to seed anything to tyrannical leech nodes. As such, BitT yrant continually reduces send rates for peers that reciprocate, attempting to find the minimum rate required. Rather than at- tempting to ramp up send rates between high capacity peers, BitT yrant tends to spread a vail- able capacity among many low capacity peers, potentially causing inefficienc y due to TCP ef- fects. T o work around this ... effect, BitT yrant adver- tises itself at connection time using the Peer ID hash. Without protocol modification, BitT yrant peers recognize one another and switch to a block-based TFT strategy that ramps up send rates until capacity is reached. The authors believ e that their weakness is looking for too many low bandwidth flows, or that the many lo w band- width flows are inef ficient because of TCP effects. T o e valuate this, we ran several simulations without the BitT yrant block-level TFT component (i.e., we disabled BitT yrant’ s ability to detect that a peer is also running BitT yrant). BitT yrant nodes did very poorly when com- municating with each other . BitT yrant assumes it is receiving reciprocation when it receiv es an unchoke. This is a valid assumption for Bit- T orrent nodes, but it is not as clear of a signal from another BitT yrant node because it does not indicate ho w much they are willing to upload. So, if two BitT yrant nodes unchoke each other , the y both assume they hav e an esti- mate for the minimum upload speed necessary to achiev e reciprocation. They then both begin to drop their upload rates potentially down to zero in a quest to achiev e lower estimates for the minimum upload speed. BitT yrant solv es this problem by self-identification, disabling the reciprocation-discovery mechanism because it doesn’t really work between two tyrants. This identifi- 10 cation features can be exploited by altruistic nodes to deny service to tyrants! A BitT yrant node cannot lie or obscure that it’ s a tyrant without incurring a penalty when trading with other tyrants. W e re-ran our baseline simulation with 10% altruistic, 70% standard, and 20% leech nodes. The altruistic nodes used the normal trade algorithm and our rew ard seeding algorithm. The leech nodes used the BitT yrant trade algo- rithm. Bandwidth was reserved at 75% and the altruistic nodes ignored tyrants during seeding, b ut interacted with them normally when still downloading the torrent. The results are shown in Figure 12. By ignoring tyrants, the altruistic nodes achie ve a small but significant performance improvement relativ e to the tyrants. There may well be other ways to exploit tyrants, such as refusing to interact with them at all. It is suf fi- cient to say that BitT yrant is vulnerable to exploitation, itself, as a consequence of its necessary self-identification mechanism. 6 Discussion and Futur e W ork The dev elopment of this research gi ves rise to a number of important discussion points that we will address here. These points include issues relating to the practicality of our algorithm to real-life solutions as well as topics of future research. Privacy / Anonymity is of significant concern for many BitT orrent users. Naturally , a long-term identifier would impact anonymity . Howe ver , the BitT orrent protocol was nev er engineered to provide anonymity to BitT orrent users. (They announce their presence to everybody in the swarm, based on their IP address, and adv ertise what pieces they have av ailable to trade!) From this perspec- tiv e, a long-term identifier is not much worse than an IP address. On the other hand, if a BitT orrent user chose to tun- nel BitT orrent through an anonymization system like T or , then the IP address would be obscured, while the long- term identifier would still be advertised. While a number of BitT orrent users do tunnel traf fic through T or, their per- formance will suf fer greatly , as T or was ne ver intended to support the kind of massiv e, sustained traffic flo ws that BitT orrent can generate. Engineering an anonymity ser- vice specifically for BitT orrent would be an interesting opportunity for future research. Bootstrapping and Overlap are the most critical con- cerns for further development of this incentives mecha- nism. The reward mechanisms in our research depend on the same nodes seeing one another , again and again. This may not occur much, in the general case, but it could well happen in particular subcommunities. Existing Small Gr oups : A number of relati vely small (compared to the entire world) communities exist for the purpose of BitT orrent distribution. The traces we de- scribed in Section 4 were collected from filelist.org over a three month period. This community requires a sign-in name which was associated with each download. W e ob- served that 50% of all peers participated in at least tw o of the same swarms. These types of groups would be able to switch over to the seed-rew arding algorithm with very little difficulty and w ould likely hav e sufficient o verlap. Social Gr oups : Existing social communities, brought together by mutual interests on social networks, could be used to lev erage a relati vely small BitT orrent community suitable for the seed-rew arding algorithm. Shar ed Interests : Ev en without explicit social group- ings, one would reasonably expect that many people will follow similar patterns. For example, a variety of tele- vision shows are distributed via BitT orrent. Users who download the current show are likely to download subse- quent shows. Similar affinities w ould be expected around other content that is updated on a regular basis, such as updated Linux distributions. T ransitive T rading and similar methods, may be able to ameliorate the need for extensi ve ov erlap. Transiti ve trading [12, 11] allows two clients that have nev er met to exchange “credits” through a mutual contact. BitT yrant is an important development in BitT orrent because it improv es the efficiency of certain core con- cepts. For example, the optimistic unchoke in standard BitT orrent trading is a searc h method for finding better peers, b ut it simply searches randomly . Howe ver , as we discussed in Section 5.7, BitT yrant clients must identify whether they are speaking to other tyrants and change strategies. Otherwise, the default BitT yrant TFT strat- egy will have both clients dropping their bandwidth all the way to zero. This BitT yrant flaw creates interesting opportunities. Since BitT yrant clients must identify themselves as such, they can be trivially ignored by other clients who, perhaps, do not with to support their tyrannical beha vior . Howe ver , there are many other options. BitT yrant clients (or , re- ally , any BitT orrent client) could publish categorical state- ments about their unchoking policies. For example a node might declare: “If you give me at least X bytes per sec- ond, then I’ll unchoke you and giv e you X in return, up to Y bytes per second max. ” Of course, a tyrant could lie about such policies, but it creates an interesting op- portunity for future research, both in terms of simulation studies and in terms of economic modeling. Carra et al. [2] also examined the strengths of 11 BitT yrant-style beha vior versus simply expanding the number of simultaneous connections in traditional Bit- T orrent clients by simulation. Ho wever , their simula- tion models ignored churn and other real-world conditions leading us to believ e that their results are unreliable. 7 Related W ork The BitT orrent protocol and associated algorithms were introduced by Cohen in 2003 [3] with a reference client implementation. A fluid model for the system was given by Qiu et al. [18], who used it to show that in certain cases a Nash equilibrium can e xist in systems where peers choose upload rates to match their download rates. Stud- ies performed on emulated swarms by Legout et al. [8] validated the ef fectiveness of the BitT orrent unchoking al- gorithm. Legout et al. [9] also concluded from real-world tests that the rarest-first algorithm is very important to sys- tem performance, and argued that the default unchoking algorithm provides adequate rob ustness from free-riders. A fluid-model simulator was used by Bharambe et al. [1] to represent a BitT orrent system in a more abstract manner than our own. The y confirmed the utility of the rarest-first policy for piece selection. They also in vesti- gated unfairness with respect to volume uploaded and ar- gued that the rate-based TFT strategy fails to prev ent such unfairness, especially in systems with a great disparity of bandwidth among peers. They proposed a ne w block- lev el, volume-based TFT trading algorithm, although sub- sequent researchers challenged its effecti veness [9]. De V ogeleer et al. [23], made an event-based simula- tor for BitT orrent based on the algorithms in the reference implementation and used it to model a v ariety of typical swarm scenarios, verifying the performance characteris- tics against the expected behavior of a standard BitT orrent client. A simulation-based study by Eger et al. [5] compared flow-le vel and packet-lev el simulations for BitT orrent-like systems and found that, while flo w-lev el simulations are useful for demonstrating the theoretic performance of the de facto BitT orrent scheme, the delay of TCP packets and other cross-layer effects hav e a significant impact on BitT orrent performance, and these effects require a more granular simulation to be adequately captured. Much research has been performed concerning the robustness of BitT orrent’ s tit-for-tat trading mechanism against selfish beha viors. BitT orrent was modeled as a form of the Iterated Prisoner’ s Dilemma problem by Jun et al. [7], who suggested that the current peer -selection al- gorithm is susceptible to free-riders; they proposed a dif- ferent TFT strategy . Tian et al. [22] used mathematical models as well as simulation-based and real-world exper - iments to argue for a modified TFT algorithm. Sirivianos et al. [21] emulated a strictly free-riding client which contacts the tracker often to gain a large neighborhood from which to free-ride; the y concluded that this attack was feasible in practice. Liogkas et al. [8] use PlanetLab to demonstrate three different exploits: downloading from seeds, downloading from the fastest peers, and advertising fak e pieces. 8 Conclusion At present, BitT orrent’ s seeding mechanism is entirely al- truistic; nodes have no rational reason to offer seeding ser - vice to their peers, yet the additional bandwidth provided by seeding is essential to the efficient operation of BitT or- rent. Anything that can encourage seeding would ha ve an immediate knock-on benefit for BitT orrent users. In this work, we ha ve proposed a method for re warding seeding in BitT orrent by means of long-term identifica- tion. Nodes remember peers that seeded to them in the past and reciprocate by seeding to them in later swarms. T o ev aluate our algorithm and its parameter space, we dev eloped and emplo yed a flo w-level simulator . The al- gorithm was tested on realistic file-sizes and trace-dri ven churn to impro ve its accuracy . W e found that our algo- rithm improv ed the download efficienc y of the BitT orrent nodes from 70% to 95% or better . This improv ement rep- resents the upper bound of our algorithm’ s performance and was based on oracular knowledge that would not be av ailable in real scenarios. W e tested more realistic set- tings and found that our algorithm could still increase the download ef ficiency by ten percentage points. Finally , we ev aluated our seed-re warding algorithm in swarms that had some portion of the population running BitT yrant, a variant on BitT orrent that is aggressive about getting fast downloads with minimal in vestments of up- load bandwidth. W e found that our algorithm could pro- tect nodes from being e xploited by BitT yrant, but could not sufficiently penalize tyrannical behavior to discourage users from choosing to run BitT yrant. Howe ver , le verag- ing a weakness in BitT yrant, where BitT yrant nodes must identify themselves as such, we can ignore tyrants during seeding and reduce their performance. So long as BitT orrent peers hav e sufficient overlap in successive swarms, allowing them to build individual long-term histories of who has seeded in the past, we conclude that BitT orrent peers using our incentivized re- ward seeding algorithm will enjoy better performance for themselves and also improv e performance for their peers, whether running our algorithm or not. By adding in our mechanism, for which peers hav e a genuine incentive to follow , we can build better rob ustness in BitT orrent. 12 Acknowledgements The authors wish to thank Johan Pouwelse for collecting and sharing his traces from many real BitT orrent swarms. W e also acknowledge Ed Knightly , Eugene Ng, Dan San- dler , and Devika Subramanian for many helpful discus- sions on this paper . Scott Crosby of fered incredible assis- tance in performance tuning our simulator . This research was supported, in part, by NSF grants CNS-0524211 and CNS-0509297. Refer ences [1] A. R. Bharambe, C. Herley , and V . N. Padmanabhan. An- alyzing and improving BitT orrent performance. T echnical Report MSR-TR-2005-03, Microsoft Research, Redmond, W A, Feb. 2005. [2] D. Carra, G. Neglia, and P . Michiardi. On the impact of greedy strategies in BitT orrent networks: The case of Bit- T yrant. In Proceedings of the 2008 Eighth International Confer ence on P eer-to-P eer Computing (P2P ’08) , pages 311–320, Aachan, Germany , Sept. 2008. [3] B. Cohen. Incenti ves build rob ustness in BitT orrent. In 1st Internation W orkshop on Economics of P2P Systems (P2PECON ’03) , Berkeley , CA, June 2003. [4] J. R. Douceur . The Sybil attack. In The Fir st Inter- national W orkshop on P eer-to-P eer Systems (IPTPS ’02) , Cambridge, MA, Mar . 2002. [5] K. Eger , T . Hoßfeld, A. Binzenhöfer, and G. Kunzmann. Efficient simulation of large-scale P2P networks: Packet- lev el vs. flow-le vel simulations. In 2nd W orkshop on the Use of P2P , GRID and Agents for the Development of Content Networks (UPGRADE-CN’07) , pages 9–16, Mon- terey , CA, June 2007. [6] Ernesto. BitT orrent: The “one third of all internet traf- fic" myth, Sept. 2006. V iewed at http://torrentfreak.com/ bittorrent- the- one- third- of- all- internet- traffic- myth/ on Jan- uary 8, 2009. [7] S. Jun and M. Ahamad. Incentives in BitT orrent induce free riding. In P2PECON ’05: Pr oceedings of the 2005 A CM SIGCOMM W orkshop on Economics of P eer-to-P eer Systems , pages 116–121, Philadelphia, P A, 2005. [8] A. Legout, N. Liogkas, E. Kohler , and L. Zhang. Cluster- ing and sharing incentives in BitT orrent systems. In Pro- ceedings of the 2007 ACM SIGMETRICS , pages 301–312, San Diego, CA, June 2007. [9] A. Legout, G. Urvoy-K eller , and P . Michiardi. Rarest first and choke algorithms are enough. In Pr oceedings of the 6th ACM SIGCOMM Confer ence on Internet Measurement (IMC ’06) , pages 203–216, Rio de Janeriro, Brazil, Oct. 2006. [10] T . Locher, P . Moor , S. Schmid, and R. W attenhofer . Free riding in BitT orrent is cheap. In F ifth W orkshop on Hot T opics in Networks (HotNets-V) , Irvine, CA, Nov . 2006. [11] A. Nandi, T .-W . J. Ngan, A. Singh, P . Druschel, and D. S. W allach. Scrivener: Providing incentiv es in cooperativ e content distribution systems. In A CM/IFIP/USENIX 6th International Middlewar e Conference (Middle ware 2005) , Grenoble, France, Nov . 2005. [12] T .-W . J. Ngan, A. Nandi, A. Singh, D. S. W allach, and P . Druschel. On designing incentiv es-compatible peer-to- peer systems. In 2nd Bertinor o W orkshop on Futur e Dir ec- tions in Distributed Computing (FuDiCo II: S.O.S.) , Berti- noro, Italy , June 2004. [13] S. Nielson, S. Crosby , and D. W allach. A taxonomy of rational attacks. In The 4th Annual International W ork- shop on P eer-T o-P eer Systems (IPTPS ’05) , Ithaca, NY , Feb . 2005. [14] A. Parker . The T rue Picture of P eer-to-P eer Fileshar - ing . CacheLogic, 2004. No longer av ailable from original site http://www .cachelogic.com/home/pages/studies/2004_ 01.php . Downloaded from archiv e.org on January 8, 2009. [15] M. Piatek, T . Isdal, T . Anderson, A. Krishnamurthy , and A. V enkataramani. Do incentiv es build robustness in Bit- T orrent? In Proceedings of 4th USENIX Symposium on Networked Systems Design & Implementation (NSDI 2007) , Cambridge, MA, April 2007. [16] J. Pouwelse, P . Garbacki, D. Epema, and H. J. Sips. The BitT orrent P2P file-sharing system: Measurements and analysis. In 4th International W orkshop on P eer-to- P eer Systems (IPTPS ’05) , volume 3640, pages 205–216, Ithaca, NY , Feb. 2005. [17] J. Pouwelse, P . Garbacki, J. W ang, A. Bakker , J. Y ang, and A. Iosup. Tribler: A social-based peer -to-peer sys- tem. In Pr oceedings of the 5th International P2P confer- ence (IPTPS ’06) , Santa Barbara, CA, Feb . 2006. [18] D. Qiu and R. Srikant. Modeling and performance anal- ysis of BitT orrent-like peer-to-peer networks. SIGCOMM Comput. Commun. Rev . , 34(4):367–378, 2004. [19] H. Schulze and K. Mochalski. Internet Study 2007 . Ipoque, 2007. Downloaded at http://www .ipoque.com/userfiles/file/ internet_study_2007.pdf on January 8, 2009. [20] R. Singel. Internet Mysteries: How Much F ile Sharing T raffic T ravels the Net? W ired, May 2008. V iewed at http://blog.wired.com/27bstroke6/2008/ 05/how- much- file- s.html on January 8, 2009. [21] M. Siri vianos, J. H. P ark, R. Chen, and X. Y ang. Free- riding in BitT orrent with the large view exploit. In 6th International W orkshop on P eer-to-P eer Systems (IPTPS ’07) , Bellevue, W A, Feb. 2007. [22] Y . T ian, D. W u, and K. W . Ng. Modeling, analy- sis and improv ement for BitT orrent-like file sharing net- works. In Pr oceedings of 25th IEEE International Con- fer ence on Computer Communications (INFOCOM 2006) , Barcelona, Spain, Apr . 2006. 13 [23] K. D. V ogeleer, D. Erman, and A. Popescu. Simulating BitT orrent. In Pr oceedings of the 1st International Confer - ence on Simulation T ools and T echniques for Communica- tions, Networks and Systems W orkshop (SIMUT ools ’08) , pages 1–7, Marseille, France, Mar . 2008. [24] C. A. W aldspurger and W . E. W eihl. Lottery scheduling: flexible proportional-share resource management. In Pr o- ceedings of the 1st USENIX confer ence on Operating Sys- tems Design and Implementation (OSDI ’94) , Monterey , CA, Nov . 1994. [25] W . Y ang and N. Abu-Ghazaleh. GPS: a general peer -to- peer simulator and its use for modeling BitT orrent. In 13th Annual Meeting of the IEEE/ACM International Sympo- sium on Modeling, Analysis, and Simulation of Computer and T elecommunication Systems (MASCOTS 2007) , pages 425–432, Atlanta, GA, Oct. 2005. 14