Do incentives build robustness in BitTorrent?

Michael Piatek∗ Tomas Isdal∗ Thomas Anderson∗ Arvind Krishnamurthy∗ Arun Venkataramani†

Technical Report–TR 2006-11-02 / To appear in NSDI 2007

AbstractA fundamental problem with many peer-to-peer systemsis the tendency for users to “free ride”—to consume re-sources without contributing to the system. The popularfile distribution tool BitTorrent was explicitly designedto address this problem, using a tit-for-tat reciprocitystrategy to provide positive incentives for nodes to con-tribute resources to the swarm. We show that althoughBitTorrent has been fantastically successful, its incentivemechanism is not robust to selfish clients. Through per-formance modeling parameterized by real-world traces,we demonstrate that high capacity peers provide low ca-pacity peers with an unfair share of aggregate swarm re-sources. We use these results to drive the design and im-plementation of BitTyrant, a selfish BitTorrent client thatprovides a median 70% performance gain for a 1 Mbitclient on real Internet swarms. We further show that thisselfishness, when applied universally, can hurt averageper-swarm performance compared to today’s BitTorrentclient implementations.

1 IntroductionA fundamental problem with many peer-to-peer systemsis the tendency of users to “free ride”—consume re-sources without contributing to the system. In early peer-to-peer systems such as Napster, the novelty factor suf-ficed to draw plentiful participation from peers. Sub-sequent peer-to-peer systems recognized and attemptedto address the free riding problem; however, their fixesproved to be unsatisfactory, e.g., “incentive priorities” inKazaa could be spoofed; currency in MojoNation wascumbersome; and the AudioGalaxy Satellite model of“always-on” clients has not been taken up. More re-cently, BitTorrent, a popular file distribution tool basedon a swarming protocol, showed that a tit-for-tat strategywas effective at incenting peers to contribute resources tothe system and discouraging free riders.

The tremendous success of BitTorrent suggests thattit-for-tat is successful at inducing contribution from ra-tional peers. Moreover, the bilateral nature of tit-for-tatallows for enforcement without a centralized trusted in-frastructure. The consensus appears to be that “incen-tives build robustness in BitTorrent” [3, 16, 2, 11].

In this paper, we question this widely held belief. Tothis end, we first conduct a large measurement study of

∗Dept. of Computer Science and Engineering, Univ. of Washington†Dept. of Computer Science, Univ. of Massachusetts Amherst

real BitTorrent swarms to understand the diversity of Bit-Torrent clients in use today, realistic distributions of peerupload capacities, and possible avenues of strategic peerbehavior in popular clients. Based on these measure-ments, we develop a simple model of BitTorrent to corre-late upload and download rates of peers. We parametrizethis model with a measured distribution of peer uploadcapacities and discover the presence of significant altru-ism in BitTorrent, i.e., a minority of high capacity peersprovide low capacity peers with an unfair share of aggre-gate swarm resources. Intrigued by this observation, werevisit the following question: can a selfish peer gameBitTorrent to significantly improve its download perfor-mance for the same level of upload contribution?

Our primary contribution is to settle this question inthe affirmative. Based on the insights gained from ourmodel, we design and implement BitTyrant, a modifiedBitTorrent client designed to benefit selfish peers. Weevaluate BitTyrant performance on real swarms, estab-lishing that high and even moderate capacity peers cansignificantly improve download performance while re-ducing upload contributions. For example, a client with1 Mb/s upload capacity receives a median 70% perfor-mance gain from using BitTyrant. Moreover, the strate-gic behavior of BitTyrant is executed simply through pol-icy modifications to existing clients without any changeto the BitTorrent protocol. The key idea is to carefully se-lect peers and contribution rates so as to maximize down-load per unit of upload bandwidth.

How does use of BitTyrant by many peers in a swarmaffect the performance of the swarm? We find that allpeers, regardless of upload capacity, benefit from adop-tion, irrespective of whether or not other peers are usingBitTyrant. Peers not using BitTyrant can experience de-graded performance due to the absence of altruisitic con-tributions from selfish peers. Taken together, these re-sults suggest that in fact “incentives do not build robust-ness in BitTorrent”, at least as currently implemented. Inthe presence of selfish users that constrain upload contri-bution or exploit altruism, performance degrades.

In addition to our primary contribution, BitTyrant, ourefforts to measure and model altruism in BitTorrent areindependently noteworthy. First, although modeling Bit-Torrent has seen a large body of work (see Section 6),our model is both simpler and suffices to capture thecorrelation between upload and download rates for realswarms. Second, existing studies recognizing altruism in

BitTorrent consider small simulated settings or few tor-rents that poorly capture the diversity of deployed Bit-Torrent clients, peer capacities, churn, and network con-ditions. Our evaluation is more comprehensive. We usetrace driven modeling to drive the design of BitTyrant,which we evaluate on more than 100 popular, real worldswarms as well as synthetic swarms on PlanetLab. Fi-nally, we make BitTyrant available publicly as well asanonymized traces gathered in our large-scale measure-ment study, which covers hundreds of torrents and hun-dreds of thousands of IP addresses.

The remainder of this paper is organized as fol-lows. Section 2 provides an overview of the BitTor-rent protocol and our measurement data, which we useto parametrize our model. Section 3 develops a simplemodel illustrating the sources and extent of altruism inBitTorrent. Section 4 presents BitTyrant, a modified Bit-Torrent client for selfish peers, which we evaluate in Sec-tion 5. In Section 6, we discuss related work and con-clude in Section 7.

2 BitTorrent overviewThis section presents an overview of the BitTorrent pro-tocol, its implementation parameters, and the measure-ment data we use to seed our model.

2.1 Protocol

BitTorrent focuses on bulk data transfer, separating theproblems of data lookup and retrieval. All users in a par-ticular swarm are interested in obtaining the same file orset of files. In order to initially connect to a swarm, peersdownload a metadata file, called a torrent, from a con-tent provider, usually via a normal HTTP request. Thismetadata specifies the name and size of the file to bedownloaded, as well as SHA-1 fingerprints of the datablocks (typically 64–512 KB) that comprise the largerfile to be downloaded. These fingerprints are used to ver-ify data integrity. The metadata file also specifies theaddress of an HTTP tracker server for the torrent, whichcoordinates interaction between peers participating in theswarm. Peers contact the tracker upon startup and depar-ture as well as periodically as the download progresses,usually with a frequency of 15 minutes. The trackermaintains a list of currently active peers and delivers arandom subset of these to clients, upon request.

A user in possession of the complete file, called aseed, redistributes small blocks to other participants inthe swarm. Peers exchange blocks and control informa-tion with a set of directly connected peers we call thelocal neighborhood. This set of peers, obtained from thetracker, is unstructured and random, requiring no specialjoin or recovery operations when new peers arrive or ex-isting peers depart. The control traffic required for dataexchange is minimal: each peer transmits messages in-

Figure 1: Cumulative distribution of raw bandwidth ca-pacity for BitTorrent peers as well as the “equal split” ca-pacity distribution for active set peers, assuming clientsuse the reference implementation of BitTorrent.

dicating the data blocks they currently possess and mes-sages signaling their interest in the blocks of other peers.

We refer to the set of peers to which a BitTorrent clientis currently sending data as its active set. BitTorrent usesa rate-based tit-for-tat strategy to determine which peersto include in the active set. Each round, a peer sendsdata to unchoked peers from which it received data mostrapidly in the past 10 second interval. This strategy is in-tended to provide positive incentives for contributing tothe system and inhibit free-riding. However, peers willalso send data to a small number of randomly chosenpeers who have not “earned” such status. Such peersare said to be optimistically unchoked. Optimistic un-chokes serve to bootstrap new peers into the tit-for-tatgame as well as to facilitate discovery of new, potentiallybetter sources of data. Peers that do not send data quicklyenough to earn reciprocation are removed from the activeset during a tit-for-tat round and are said to be choked.

Modulo TCP effects and assuming last-hop bottlenecklinks, each peer provides an equal share of its availableupload capacity to peers to which it is actively sendingdata. We refer to this rate throughout the paper as a peer’sequal split rate. This rate is determined by the uploadcapacity of a particular peer and the size of its activeset. In the official reference implementation of BitTor-rent, active set size is proportional to

√upload capacity

(details in Appendix); although in other popular BitTor-rent clients, this size is static.

2.2 Measurement

BitTorrent’s behavior depends on a large number of pa-rameters: topology, bandwidth, block size, churn, dataavailability, number of directly connected peers, activetit-for-tat transfers, and number of optimistic unchokes.Furthermore, many of these parameters are a matter ofpeer policy unspecified by the BitTorrent protocol itself.These policies may vary among different client imple-mentations and defaults may be overridden by explicituser configuration. To gain an understanding of BitTor-

2

Implementation Percentage shareAzureus 47%

BitComet 20%µtorrent 15%BitLord 6%

Unknown 3%Reference 2%

Remaining 7%

Table 1: BitTorrent implementation usage as drawn frommeasurement data.

rent’s behavior and diversity of implementation in thewild, we first conducted a measurement study of live Bit-Torrent swarms to ascertain client characteristics.

By making use of the opportunistic measurement tech-niques presented by Madhyastha et al. [13], we gatherempirical measurements of BitTorrent swarms and hosts.Our measurement client connected to a large number ofswarms and waited for an optimistic unchoke from eachunique peer. We then estimated the upload capacity ofthat client using the multiQ tool [10]. Previous charac-terizations of end-host capacities of peer-to-peer partici-pants were conducted by Saroiu, et al. [17]. We updatethese results using more recent capacity estimation tools.We observed 301595 unique BitTorrent IP addresses overa 48 hour period during April, 2006 from 3591 distinctASes across 160 countries. The upload capacity distribu-tion for typical BitTorrent peers is given in Figure 1 alongwith the per-peer upload rate distribution that would arisefrom all peers using the reference BitTorrent implemen-tation with no limit on upload rates.

3 Modeling altruism in BitTorrentBitTorrent’s tit-for-tat reciprocity strategy is designed tocorrelate download performance with upload contribu-tion. A peer with high upload contribution should seethat contribution reflected in high download rates whencompared with peers contributing less. Although tit-for-tat achieves this correlation, in practice the balance ofupload contribution and download rate is often unfair,resulting in altruistic contributions from high capacitypeers. We define altruism per peer as its upload contri-bution in excess of total downloaded data.

We set out to understand fundamental sources of altru-ism in BitTorrent. However, the diversity of implementa-tions and the myriad of parameters makes understandingfundamental properties challenging. In this section, wetake a restricted view and develop a model of altruismin BitTorrent arising from our observed upload capacitydistribution and the default parameter settings of the ref-erence implementation of BitTorrent.

We make several assumptions to simplify our analysisand provide a conservative bound on altruism. Because

our assumptions are not realistic for all swarms, our mod-eling results are not intended to be predictive. Rather,our modeling results suggest potential sources of altru-ism and the reasons they emerge in BitTorrent swarmstoday. We exploit these sources of altruism in the designof our real world selfish client, BitTyrant, discussed inSection 4.

• Representative distribution: The CDF shown in Fig-ure 1 is for bandwidth capacity of observed IP ad-dresses over many swarms. The distribution of a typ-ical swarm may not be identical. For instance, highcapacity peers tend to finish more quickly than lowcapacity peers, but they may also join more swarmssimultaneously. If they join only a single swarm andleave shortly after completion, over the lifetime of atorrent the relative proportion of low capacity peersincreases.

• Uniform sizing: Peers, other than the modified client,use the active set sizing recommended by the referenceBitTorrent implementation. In practice, other BitTor-rent implementations are more popular (see Table 1);These BitTorrent clients have different active set sizes.As we will show, aggressive active set sizes tend todecrease altruism, and the reference implementationuses the most aggressive strategy among the popularimplementations we inspected. As a result, our modelprovides a conservative estimate of altruism.

• No steady state: Active sets are comprised of peerswith random draws from the overall upload capacitydistribution. If churn is low, over time tit-for-tat maymatch peers with similar equal split rates, requiringhigher send rates to receive reciprocation from highcapacity peers. We argue in the next section that Bit-Torrent is slow to reach steady-state, particularly forhigh capacity peers.

• High block availability: Swarm performance is limitedby upload capacity, i.e., peers will always be able tofind interesting data with other peers. We find that al-though the reference BitTorrent implementation is de-signed to ensure high availability of interesting blocks,in practice, poor default settings in some clients maydegrade block availability for high capacity peers.

These assumptions allow us to model altruism in Bit-Torrent in terms of the upload capacity distribution only.The model is built on expressions for the probability oftit-for-tat reciprocation, expected download rate, and ex-pected upload rate. In this section, we focus on the maininsights provided by our model. The precise expressionsare listed in detail in the Appendix.

3.1 Tit-for-tat matching time

Since our subsequent modeling results assume thatswarms do not reach steady state, we first examine the

3

Figure 2: Assuming a peer set of infinite size, the ex-pected time required for a new peer to discover enoughpeers of equal or greater equal split capacity to fill itsactive set.

convergence properties of the tit-for-tat strategy BitTor-rent uses to match peers of similar capacity. By default,the reference BitTorrent client optimistically unchokestwo peers every 30 seconds in an attempt to explore theavailable set of peers in the local neighborhood for bet-ter reciprocation pairings. Since all peers are perform-ing this exploration simultaneously, every 30 seconds apeer can expect to explore two candidate peers and beexplored by two candidate peers. Since we know theequal split capacity distribution, we can express the prob-ability of finding a peer with equal or greater equal splitcapacity—in a given number of 30 second rounds. Tak-ing the expectation and multiplying it by the size of theactive set gives an estimate of how long a new peer willhave to wait before filling its active set with such peers.

Figure 2 shows this expected time for our observedbandwidth distribution. These results suggest that TFTas implemented does not quickly find good matches forhigh capacity peers, even in the absence of churn. For ex-ample, a peer with 50 Mb/s upload capacity would trans-fer more than 4 GB of data before reaching steady state.In practice, convergence time is likely to be even longer.We consider a peer as being “content” with a matchingonce its equal split is matched or exceeded by a peer in itsactive set. However, one of the two peers in any match-ing that is not exact will be searching for alternates andswitching when they are discovered. The long conver-gence time suggests a potential source of altruism: highcapacity clients are forced to peer with those of low ca-pacity while searching via optimistic unchokes.

3.2 Probability of reciprocation

A node Q sends data only to those peers in its activetransfer set, reevaluated every 10 seconds. If a peer Psends data to Q at a rate fast enough to merit inclusionin Q’s active transfer set, P will receive data during thenext tit-for-tat round, and we say Q reciprocates with P .

Reciprocation from Q to P is determined by two fac-tors: the rate at which P sends data to Q and the rates

Figure 3: Reciprocation probability for a peer as a func-tion of raw upload capacity as well as reference BitTor-rent equal split bandwidth. Reciprocation probability isnot strictly increasing in raw rate due to the sawtooth in-crease in active set size (see Table 2 in Appendix).

at which other peers send data to Q. If all other peers inQ’s current active set send at rates greater than P , Q willnot reciprocate with P .

Figure 3 gives the probability of reciprocation in termsof both raw upload capacity and, more significantly,equal split rate. The sudden increase in reciprocationprobability suggests a potential source of altruism in Bit-Torrent: equal-split bandwidth allocation among peersin the active set. Beyond a certain equal split rate (∼ 14KB/s in Figure 3), reciprocation is essentially assured,suggesting that further contribution may be altruistic.

3.3 Expected download rate

Each TFT round, a peer P receives data from both TFTreciprocation and optimistic unchokes. Reciprocation ispossible only from those peers in P ’s active set and de-pends on P ’s upload rate, while optimistic unchokes maybe received from any peer in P ’s directly connected peerset, regardless of upload rate. In the reference BitTorrentclient, the number of optimistic unchoke slots defaultsto 2 and is rotated in a round robin fashion among peersin the local neighborhood. As each peer unchokes twopeers per round, the expected number of optimistic un-chokes P will receive is also two for a fixed local neigh-borhood size.

Figure 4 gives the expected download throughput forpeers as a function of upload rate for our observed band-width distribution. The sub-linear growth suggests sig-nificant unfairness in BitTorrent, particularly for high ca-pacity peers. This unfairness improves performance forthe majority of low capacity peers, suggesting that highcapacity peers may be able to better allocate their uploadcapacity to improve their own performance.

3.4 Expected upload rate

Having considered download performance, we turn nextto upload contribution. Two factors can control the up-load rate of a peer: data availability and capacity limit.

4

Figure 4: Expectation of download performance as afunction of upload capacity. Although this represents asmall portion of the spectrum of observed bandwidth ca-pacities, ∼ 80% of samples are of capacity ≤ 200KB/s.

When a peer is constrained by data availability, it doesnot have enough data of interest to its local neighbor-hood to saturate its capacity. In this case, this capacityis wasted and utilization suffers. Because of the depen-dence of upload rate on data availability, it is crucial forgood utilization that BitTorrent clients download at a ratefast enough to saturate their upload capacity. We havefound that indeed this is the case in the reference BitTor-rent client because of the square root growth rate of itsactive set size.

In practice, most popular clients do not follow this dy-namic strategy and instead make active set size a config-urable, but static, parameter. For instance, the most pop-ular BitTorrent client in our traces, Azureus, suggests adefault active set size of four—appropriate for many ca-ble and DSL hosts, but far lower than is required for highcapacity peers. We explore the impact of active set sizingfurther in Section 4.1.

3.5 Modeling altruism

Given upload and download throughput, we have all thetools required to compute altruism. We consider two def-initions of altruism intended to reflect two perspectiveson what constitutes selfish behavior. We first consideraltruism to be simply the difference between expectedupload rate and download rate. Figure 5 shows altruismas a percentage of upload capacity under this definitionand reflects the asymmetry of upload contribution anddownload rate discussed in Section 3.3. The second def-inition is any upload contribution that can be withdrawnwithout loss in download performance. This is shown inFigure 6.

In contrast to the original definition shown in Figure 5,this data suggests that all peers make altruistic contribu-tions that could be eliminated. Sufficiently low band-width peers almost never earn reciprocation, while highcapacity peers send much faster than the minimal rate

Figure 5: Expected percentage of upload capacity whichis altruistic as defined by Equation 5 as a function of rate.The sawtooth increase is due to the sawtooth growth ofactive set sizing and equal split rates arising from integerrounding (see Table 2).

Figure 6: Expected percentage of upload capacity whichis altruistic when defined as upload capacity not resultingin direct reciprocation.

required for reciprocation. Both of these effects can beexploited. Note that low bandwidth peers, despite notbeing reciprocated, still receive data in aggregate fasterthan they send data. This is because they receive indis-criminate optimistic unchokes from other users in spiteof their low upload capacity.

3.6 Validation

Our modeling results suggest that at least part of thealtruism in BitTorrent arises from the sublinear growthof download throughput as a function of upload rate.We validate this key result using our measurement data.Each time a BitTorrent client receives a complete datablock from another peer, it broadcasts a ‘have’ mes-sage indicating that it can redistribute that block to otherpeers. By averaging the rate of have messages over theduration our measurement client observes a peer, we caninfer the peer’s download rate. Figure 7 shows this in-ferred download rate as a function of equal split rate, i.e.the throughput seen by the measurement client when op-timistically unchoked. This data is drawn from our mea-surements and includes 63482 peers.

Comparing these results in Figure 4 suggests an evenhigher level of altruism than that predicted by our model.

5

Figure 7: Measured validation of sublinear growth indownload throughput as a function of rate. Each pointrepresents an average taken over all peers with measuredequal split capacity in the intervals between points. Abest-fit curve for the data is shown.

We believe this is due to more conservative active setsizes in practice than those assumed in our model. Equalsplit rate, the parameter of Figure 7, is a conservativelower bound on total upload capacity, shown in Figure 4.

4 Building BitTyrant: A selfish clientThe modeling results of Section 3 suggest that altruismin BitTorrent serves as a kind of progressive tax. As con-tribution increases, performance improves, but not in di-rect proportion. In this section, we describe the designand implementation of BitTyrant, a modified BitTorrentclient optimized for selfish users. We chose to base Bit-Tyrant on the Azureus client in an attempt to foster adop-tion, as Azureus is the most popular client in our traces.

A natural first approach to gaming BitTorrent’s incen-tive mechanism is the well-known Sybil attack [4]. Ifperformance for low capacity peers is disproportionatelyhigh, a selfish user can simply masquerade as many lowcapacity clients to improve performance. Also, by flood-ing the local neighborhood of high capacity peers, lowcapacity peers can artificially inflate their chances of tit-for-tat reciprocation by dominating the active transfer setof a high capacity peer. In practice, these types of attacksare mitigated by a common client option to refuse multi-ple connections from a single IP address. Resourcefulpeers might be able to coordinate a Sybil attack frommultiple IP addresses, but such an attack is beyond thecapabilities of most users. We focus instead on practi-cal strategies that can be employed by all users of evenlimited technical sophistication and resources.

The unfairness of BitTorrent has been noted in previ-ous studies [2, 5, 7], many of which include protocol re-designs intended to promote fairness. However, a clean-slate redesign of the BitTorrent protocol ignores a differ-ent but important incentives question: how to get usersto adopt it? As shown in Section 3, the majority of Bit-Torrent users benefit from its unfairness today. Designs

intended to promote fairness globally at the expense ofthe majority of users seem unlikely to be adopted. Ratherthan focus on a redesign at the protocol level, we focuson BitTorrent’s robustness to strategic behavior—can aprotocol-compatible client significantly reduce its owncontribution but exploit the altruism of other peers?

4.1 Maximizing reciprocation

The modeling results of Section 3 and the operationalbehavior of BitTorrent clients suggest the following threestrategies to improve performance.

• Maximize reciprocation bandwidth per connection:The reciprocation bandwidth of a peer is dependenton its upload capacity and its active set size. By dis-covering which peers have large equal split capacities,a client can optimize for a higher reciprocation band-width per connection.

• Maximize number of reciprocating peers: A client canexpand its active set to maximize the number of peersthat reciprocate until the marginal benefit of an addi-tional peer is outweighed by the cost of reduced recip-rocation probability from all peers.

• Deviate from equal split: On a per-connection basis, aclient can lower its upload contribution to a particularpeer as long as that peer continues to reciprocate. Thebandwidth savings could then be reallocated to newconnections, resulting in an increase in the overall re-ciprocation throughput.

The modeling results indicate that these strategies arelikely to be effective. The largest source of altruismin our model is unnecessary contribution to peers in anode’s active set. The reciprocation probability shown inFigure 3 indicates that strategically choosing equal splitbandwidth can reduce contribution significantly for highcapacity peers with only a marginal reduction in recip-rocation probability. A peer with equal split capacity of100 KB/s, for instance, could reduce its rate to 15 KB/swith a reduction in expected probability of reciprocationof only 1%. However, reducing from 15 KB/s to 10 KB/swould result in a decrease of roughly 40%.

The reciprocation behavior points to a performancetrade-off. If the active set size is large, equal splitcapacity is reduced, reducing reciprocation probability.However, an additional active set connection is an addi-tional opportunity for reciprocation. To maximize per-formance, a peer should increase its active set size un-til an additional connection would cause a reduction inreciprocation across all connections sufficient to reduceoverall download performance.

If the equal split capacity distribution of the swarm isknown, we can derive the active set size that maximizesthe expected download rate. For our observed bandwidthdistribution, Figure 8 shows the download rate as a func-

6

Figure 8: Left: The expected download performance of a client with 300 KB/s upload capacity for increasing activeset size. Right: The download performance-maximizing active set size for peers of varying rate. The selfish maximumis linear in upload capacity, while the reference implementation of BitTorrent suggests active size ∼

√rate. Although

several hundred peers may be required to maximize throughput, most trackers return fewer than 100 peers per request.

tion of the active set size for a peer with 300KB/s uploadcapacity as well as the active set size that maximizes it.The graph also implicitly reflects the sensitivity of recip-rocation probability to equal split rate.

Figure 8 is for a single selfish peer and suggests thatselfish high capacity peers can benefit much more by ma-nipulating their active set size. Our example peer withupload capacity 300 KB/s realizes a maximum down-load throughput of roughly 450 KB/s. However, increas-ing reciprocation probability via active set sizing is ex-tremely sensitive—throughput falls off quickly after themaximum is reached. Further, it is unclear if active setsizing alone would be sufficient to maximize reciproca-tion in an environment with several selfish clients.

These challenges suggest that any a priori active setsizing function may not suffice to maximize downloadrate for selfish clients. Instead, they motivate the dy-namic algorithm used in BitTyrant that adaptively mod-ifies the size and membership of the active set and theupload bandwidth allocated to each peer (see Figure 9).

In both BitTorrent and BitTyrant, the set of peers thatwill receive data during the next TFT round is decidedby the unchoke algorithm once every 10 seconds. Bit-Tyrant differs from BitTorrent as it dynamically sizes itsactive set and varies sending rate per connection. Foreach peer p, BitTyrant maintains a measure of the esti-mated upload capacity required for reciprocation, up aswell as the download throughput dp received when p re-ciprocates. Peers are ranked by the ratio dp/up and un-choked in order until the sum of up terms for unchokedpeers exceeds the upload capacity of the BitTyrant peer.

The rationale underlying this unchoke algorithm isthat the best peers are those that reciprocate most for theleast number of bytes contributed to them, given accurateinformation regarding up and dp. Implicit in the strategyare the following assumptions and characteristics:

• The strategy attempts to maximize the download ratefor a given upload budget. The ranking strategy cor-

For each peer p, maintain estimates of expected downloadperformance dp and upload required for reciprocation up.

Initialize up and dp assuming the bandwidthdistribution in Figure 2.

dp is initially the expected equal split capacity of p.

up is initially the rate just above the step in thereciprocation probability.

Each round, rank order peers by the ratio dp/up and unchokethose of top rank until the upload capacity is reached.

d0

u0,d1

u1,d2

u2,d3

u3,d4

u4| {z }choose k |

Pki=0 ui ≤ cap

, ...

At the end of each round for each unchoked peer:

If peer p does not unchoke us: up ← (1 + δ)up

If peer p unchokes us: dp ← observed rate.

If peer p has unchoked us for the last r rounds:up ← (1− γ)up

Figure 9: BitTyrant unchoke algorithm

responds to the value-density heuristic for the knap-sack problem. In practice, the download benefit (dp)and upload cost (up) are not known a priori. The up-date operation dynamically estimates these rates and,in conjunction with the ranking strategy, optimizesdownload rate over time.

• A BitTyrant client is designed to tap into the latentaltruism in most swarms by unchoking the most al-truistic peers. However, it will continue to unchokepeers until it exhausts its upload capacity even if themarginal utility of upload is sublinear. This poten-tially opens BitTyrant itself to being cheated, a topicwe return to later.

7

• The strategy can be easily generalized to handle con-current downloads from multiple torrents. A clientcan optimize the aggregate download rate by order-ing the dp/up ratios of all connections across torrents,thereby dynamically allocating upload capacity to dif-ferent torrents. Torrents can be prioritized using per-torrent weights for the dp/up ratios.

The algorithm is based on the ideal assumptionthat peer capacities and reciprocation requirements areknown. We discuss how to predict them next.

Determining upload contributions: The BitTyrantunchoke algorithm must estimate up, the upload contri-bution to p that induces its reciprocation. We initializeup based on the distribution of equal split capacities seenin our measurements, and then periodically update it de-pending on whether p reciprocates for an offered rate.In our implementation, up is decreased by γ = 10% ifthe peer reciprocates for r = 3 rounds, and increased byδ = 20% if the peer fails to reciprocate after being un-choked during the previous round. We use small multi-plicative factors since the spread of equal split capacitiesis typically small in current swarms. Although a natu-ral first choice, we do not use a binary search algorithm,which maintains upper and lower bounds for upload con-tributions that induce reciprocation, because peer recip-rocation changes rapidly under churn and bounds onreciprocation-inducing uploads would eventually be vi-olated.

Estimating reciprocation bandwidths: For peers thatunchoke the BitTyrant client, dp is simply the rate atwhich data was obtained from p. Note that we do notuse a packet-pair based bandwidth estimation techniqueas suggested by Bharambe [2], but rather consider the av-erage rate of download over a round. Based on our mea-surements, not presented here due to space limitations,we find that packet-pair based bandwidth estimates donot accurately predict peers’ equal split capacities due tovariability in active size sets and end-host traffic shap-ing. The observed rate over a longer period is the onlyaccurate estimate, a sentiment shared by Cohen [3].

Of course, this estimate is not available for peers thathave not uploaded any data to the BitTyrant client. Insuch cases, BitTyrant approximates dp for a given peerp by measuring the frequency of block announcementsfrom p. The rate new blocks arrive at p provides an es-timate of p’s download rate, which we use as an esti-mate of p’s total upload capacity. We then divide theestimated capacity by the Azureus recommended activeset size for that rate to estimate p’s equal split rate. Thisstrategy is likely to overestimate the download rates ofunobserved peers, serving to encourage their selectionfrom the ranking of dp/up ratios. At present, this pref-erence for exploration may be advantageous due to the

high-end skew in altruism. Discovering high end peersis rewarding: between the 95th and 98th percentiles, re-ciprocation throughput doubles. Of course, this strategymay open BitTyrant itself to exploitation, e.g. if a peerrapidly announces false blocks. We discuss how to makeBitTyrant robust in Section 4.3 and 5.

4.2 Sizing the local neighborhood

Existing BitTorrent clients maintain a pool of typically50–100 directly connected peers. The set is sized to belarge enough to provide a diverse set of data so peers canexchange blocks without data availability constraints.However, the modeling results of Section 4.1 suggestthat these typical local neighborhood sizes will not belarge enough to maximize performance for high capacitypeers, which may need an active set size of several hun-dred peers to maximize download throughput. Maintain-ing a larger local neighborhood also increases the num-ber of optimistic unchokes received.

To increase the local neighborhood size in BitTyrant,we rely on existing BitTorrent protocol mechanisms andthird party extensions implemented by Azureus. We re-quest as many peers as possible from the centralizedtracker at the maximum allowed frequency. Recently,the official BitTorrent protocol has incorporated a DHT-based distributed tracker that provides peer informationand is indexed by a hash of the torrent. We have in-creased the query rate of this as well. Finally, theAzureus implementation includes a BitTorrent protocolextension for gossip among peers. Unfortunately, theprotocol extension is push-based; it allows for a clientto gossip to its peers the identity of its other peers butcannot induce those peers to gossip in return. As a re-sult, we cannot exploit the gossip mechanism to extractextra peers.

A concern when increasing the size of the local neigh-borhood is the corresponding increase in protocol over-head. Peers need to exchange block availability infor-mation, messages indicating interest in blocks, and peerlists. Fortunately, the overhead imposed by maintainingadditional connections is modest. In comparisons of Bit-Tyrant and the existing Azureus client described in Sec-tion 5, we find that average protocol overhead as a per-centage of total file data received increases from 0.9% to1.9%. This suggests that scaling the local neighborhoodsize does not impose a significant overhead on BitTyrant.

4.3 Additional cheating strategies

We now discuss more strategies to improve downloadperformance. We do not implement these in BitTyrantas they can be thwarted by simple fixes to clients. Wemention them here for completeness.

Exploiting optimistic unchokes: The mainline Bit-Torrent client optimistically unchokes peers randomly,

8

a strategy that is robust to manipulation. Azureus, onthe other hand, makes a weighted random choice thattakes into account the number of bytes exchanged witha peer. If a peer has built up a deficit in the number oftraded bytes, it is less likely to be picked for optimisticunchokes. We observe that high capacity peers are likelyto have trading deficits with most peers as a consequenceof high altruism. A cheating client can exploit this mech-anism by disconnecting and reconnecting with a differentclient identifier, thereby wiping out the past history andincreasing its chances of receiving optimistic unchokes,particularly from high capacity peers. This exploit be-comes ineffective if clients maintain the IP addresses forall peers encountered during the download and maintainpeer statistics after disconnections.

Downloading from seeds: Earlier versions of BitTor-rent clients used a seeding algorithm wherein seeds up-load to peers that are the fastest downloaders, an algo-rithm that is prone to exploitation by fast peers. Morerecent versions use a seeding algorithm that performs un-chokes in a strict round-robin order, spreading data in auniform manner and is therefore more robust.

Falsifying block availability: A client would preferto unchoke those peers that have blocks that it needs.Thus, peers can appear to be more attractive by falsi-fying block announcements and increase the chances ofbeing unchoked. In practice, this exploit is not very ef-fective. First, a client is likely to consider most of itspeers interesting given the large number of blocks in atypical torrent. Second, false announcements could leadto only short-term benefit as a client is unlikely to con-tinue transferring once the cheating peer does not satisfyissued block requests.

5 EvaluationIn this section, we evaluate BitTyrant, exploring the per-formance improvement possible for a single selfish peerin synthetic and current real world swarms as well as thebehavior of BitTyrant when used by all participants insynthetic swarms.

Evaluating altruism in BitTorrent experimentally andat scale is challenging. Traditional wide-area testbedssuch as PlanetLab do not exhibit the highly skewed band-width distribution we observe in our measurements, acrucial factor in determining the amount of altruism.Alternatively, fully configurable local network testbedssuch as Emulab are limited in scale and do not incorpo-rate the myriad of performance events typical of opera-tion in the wide-area. Further, BitTorrent implementa-tions are diverse, as shown in Table 1.

To address these issues, we perform two separate eval-uations. First, we evaluate BitTyrant on real swarms withtorrents drawn from popular aggregation sites to measure

Figure 10: CDF of download performance for 114 realworld torrents. Shown is the ratio between downloadtimes for an existing Azureus client and BitTyrant. Bothclients were started simultaneously on machines at UWand were capped at 128 KB/s upload capacity.

real world performance for a single selfish client. Thisprovides a concrete measure of the performance gainsa user can achieve today. To provide more insight intohow BitTyrant functions, we then revisit these results onPlanetLab where we evaluate sensitivity to various up-load rates and evaluate what happens if BitTyrant is uni-versally deployed.

5.1 Single selfish peer

To evaluate performance under the full diversity of real-istic conditions, we crawled popular BitTorrent aggre-gation websites to find candidate swarms. We rankedthese by popularity in terms of number of active par-ticipants, ignoring swarms distributing files larger than1 GB. These swarms are typically for recently releasedfiles and have sizes ranging from 300–800 peers, withsome swarms having as many as 2000.

We then simultaneously joined the swarm with a Bit-Tyrant client and an unmodified Azureus client with rec-ommended default settings1. We imposed a 128 KB/s up-load capacity cap on each client and compared comple-tion times to represent a relatively well provisioned peerfor which Azureus has a recommended active set size. ACDF of the ratio of original client completion time to Bit-Tyrant completion time is given in Figure 10. These re-sults demonstrate the significant, real world performanceboost that users can realize by switching to BitTyrant.The median performance gain factor for BitTyrant is afactor of 1.72 with 25% of downloads finishing at leasttwice as fast with BitTyrant. We expect relative perfor-mance gains to be even greater for clients with greaterupload capacity.

These results provide insight into the performanceproperties of real BitTorrent swarms, some of which limitBitTyrant’s effectiveness. Because of the random set ofpeers that BitTorrent trackers return and the high skew

1http://www.azureuswiki.com/index.php/Good settings

9

Figure 11: Download times and sample standard devia-tion comparing performance of a single BitTyrant clientand an unmodified Azureus client on a synthetic Planet-Lab swarm.

of real world equal split capacities, BitTyrant cannot al-ways improve performance. For instance, in BitTyrant’sworst-performing swarm, only three peers had averageequal split capacities greater than 10 KB/s. In contrast,the original client received eight such peers. Total down-load time was roughly 15 minutes, the typical minimumrequest interval for peers from the tracker. As a result,BitTyrant did not recover from its initial set of compara-tively poor peers. To some extent, performance is basedon luck with respect to the set of initial peers returned.More often than not, BitTyrant benefits from this, as italways requests a comparatively large set of peers fromthe tracker.

Another circumstance for which BitTyrant cannot sig-nificantly improve performance is a torrent whose ag-gregate performance is controlled by data availabilityrather than the upload capacity distribution. In the wild,swarms are often hamstrung by the number of peers seed-ing the file—i.e. those with a complete copy. If the ca-pacity of these peers is low or if the torrent was onlyrecently made available, there may simply not be enoughavailable data for peers to saturate their upload capaci-ties. In other words, if a seed with 128 KB/s capacity isproviding data to a swarm of newly joined users, thosepeers will be able to download at a rate of at most 128KB/s regardless of their capacity. Because many of theswarms we joined were recent, this effect may accountfor the 12 swarms for which download performance dif-fered by less than 10%.

These scenarios can hinder the performance of Bit-Tyrant, but they account for a small percentage of ourobserved torrents overall. For most real swarms today,users can realize significant performance benefits fromthe selfish behavior of BitTyrant.

Although the performance improvements gained fromusing BitTyrant in the real world are encouraging, theyprovide little insight into the operation of the systemat scale. We next evaluate BitTyrant in synthetic sce-narios on PlanetLab to shed light on the interplay be-

tween swarm properties, selfish behavior, and perfor-mance. Because PlanetLab does not exhibit the highlyskewed bandwidth distribution observed in our traces,we rely on application level bandwidth caps to artificiallyconstrain the bandwidth capacity of PlanetLab nodes inaccordance with our observed distribution. However, be-cause PlanetLab is often oversubscribed and shares band-width equally among competing users, not all nodes arecapable of matching the highest values from our ob-served distribution. To cope with this, we scaled by1/10th both the upload capacity draws from our distribu-tion as well as relevant experimental parameters such asfile size, initial unchoke bandwidth, and block size. Thiswas sufficient to provide overall fidelity to our intendeddistribution.

Figure 11 shows the download performance for a sin-gle BitTyrant client as a function of rate averaged over sixtrials with sample standard deviation. This experimentwas hosted on 350 PlanetLab nodes with bandwidth ca-pacities drawn from our scaled distribution. Three seedswith combined capacity of 128 KB/s were located at UWserving a 5 MB file. We did not change the defaultseeding behavior, and noticed that varying the combinedseed capacity had little impact on overall swarm perfor-mance after exceeding the average upload capacity limit.To provide synthetic churn with constant capacity, eachnode’s BitTyrant client disconnected immediately uponcompletion and reconnected immediately.

The results of Figure 11 provide several insights intothe operation of BitTyrant:

• BitTyrant does not simply improve performance, italso provides more consistent performance acrossmultiple trials. By dynamically sizing the active setand preferentially selecting peers to optimistically un-choke, BitTyrant avoids relying on the randomizationof existing TFT implementations, which have slowconvergence for high capacity peers (Section 3.1).

• There is a rate of diminishing returns for high capac-ity peers, and BitTyrant can discover it. For clientswith high capacity, the number of peers and their avail-able bandwidth distribution are significant factors indetermining performance. Our modeling results fromSection 4.1 suggest that the highest capacity peersmay require several hundred available peers to fullymaximize throughput due to reciprocation. Limitedresources on PlanetLab encumber evaluation at thisscale, and real world swarms are rarely this large. Inthese circumstances, BitTyrant performance is consis-tent, allowing peers to detect and reallocate excess ca-pacity for other uses.

• Low capacity peers can benefit from BitTyrant. Al-though the most significant performance benefit comesfrom intelligently sizing the active set for high capac-

10

ity peers (see Figure 8), low capacity peers can still im-prove performance with strategic peer selection, pro-viding them with an incentive to adopt BitTyrant.

• Fidelity to our specified capacity distribution is con-sistent across multiple trials. Comparability of resultsis often a concern on PlanetLab, but our results sug-gest a minimum download time determined by the dis-tribution that is consistent across trials spanning sev-eral hours. Further, the consistent performance of Bit-Tyrant in comparison to unmodified Azureus suggeststhat the variability observed is due to protocol andstrategy differences and not PlanetLab variability.

5.2 Many selfish peers

We next examine the performance of BitTyrant whenused by all peers in a swarm. Our experimental setupincluded 350 PlanetLab nodes with upload capacitiesdrawn from our scaled distribution simultaneously join-ing a 5 MB torrent with combined seed capacity of 128KB/s with all peers departing immediately upon down-load completion. Initially, we expected fairness to im-prove and performance to degrade since high capacitypeers would finish more quickly, reducing capacity in thesystem. Surprisingly, performance improved overall andaltruism increased. These results are summarized by theCDFs of completion times comparing BitTyrant and theunmodified Azureus client in Figure 12. Although Bit-Tyrant attempts to allocate bandwidth to maximize recip-rocation, bandwidth is not withheld by peers with excesscapacity. As we observe in Figure 11, the point of di-minishing returns in BitTyrant for upload contribution isrealized at a rate far lower than that typical of unmodifiedAzureus swarms. In such a case, a swarm composed en-tirely of BitTyrant clients will not have less capacity, butit may make more efficient use of that capacity due tointelligent peer and rate selection, particularly during theearly bootstrapping phase of a torrent with simultaneousarrivals (as in our experiment) or a flash crowd.

These results are consistent with our model. In aswarm where the upload capacity distribution has signifi-cant skew, high capacity peers require many connectionsto maximize throughput due to reciprocation. However,evaluation of BitTyrant for single torrent performancedoes not reflect typical behavior, as most users partic-ipate in many torrents simultaneously [7]. All popularBitTorrent implementations support simultaneous down-load of multiple torrents, but few make any attempt tointelligently allocate bandwidth among torrents. Thosethat do typically allocate some amount of a global up-load capacity to each torrent, which is then split equallyamong peers in statically sized active sets. A global con-nection limit is often enforced. BitTyrant’s unchoking al-gorithm transitions naturally from single to multiple tor-rents. Rather than allocate bandwidth among torrents, as

existing clients do, BitTyrant allocates bandwidth amongconnections, optimizing aggregate download throughputfor all torrents.

If high capacity peers run BitTyrant and participate inmultiple simultaneous swarms, the performance implica-tions for low capacity and single-torrent peers are signif-icant. Multiple swarms provide a setting where activeset sizes can grow to the sizes necessary for high capac-ity peers. Rather than contributing excess resources toa single swarm, BitTyrant peers participating in multi-ple torrents can allocate excess capacity to other swarms.To model this effect, we limited the upload capacity ofall high capacity peers in our scaled distribution to 100KB/s, the point of diminishing returns observed in Fig-ure 11. A CDF of performance under the capped dis-tribution for an experiment with simultaneous joins isshown in Figure 12. As expected, aggregate performancedecreases. More interesting, however, is that the Bit-Tyrant determined rate is stable, i.e. a higher capacitypeer cannot achieve significantly faster download rates.

The upload capacity distribution of the swarm definesa stable point of diminishing returns under BitTyrant’sstrategies. Peers with capacity exceeding that rate arelikely to allocate excess bandwidth elsewhere, reduc-ing aggregate capacity and average performance, par-ticularly for low capacity peers. This is reflected incomparing the performance of single clients under thescaled distribution (Figure 11) and single client perfor-mance under the scaled distribution when constrained(Figure 12). The average completion time for a low ca-pacity peer moves from 314 to 733 seconds. Averagecompletion time for a peer with 100 KB/s of upload ca-pacity increases from 108 seconds to 190.

Our evaluation of BitTyrant at scale gives rise to num-ber of concerns arising from selfish behavior:

• Average performance for individual swarms and themajority of peers degrades. If high capacity peerscan participate in many torrents or otherwise limit al-truism, total capacity per swarm decreases. This re-duction in capacity lengthens download times for allusers of a single swarm regardless of capacity. Al-though high capacity peers will see an increase in ag-gregate download rate across many swarms, low ca-pacity peers that cannot successfully compete in mul-tiple swarms simultaneously will see a large reductionin download rates, but each individual peer is incentedto be selfish because their performance improves rela-tive to that of standard clients, even when everyone isselfish.

• New users experience a lengthy bootstrapping period.To maximize throughput selfishly, BitTyrant unchokespeers that send fast. New users without data are boot-strapped by the excess capacity of the system only.

11

Figure 12: Left: CDFs of completion times for a 350 node PlanetLab experiment. BitTyrant and original client usethe original scaled capacity distribution. Capped BitTyrant reduced caps on all high capacity nodes (≥ 100 KB/s) to100 KB/s. Right: The impact of selfish BitTyrant caps on performance. Error bars give sample standard deviationover six trials. Download times at all bandwidth levels increase and very high capacity peers gain little from excesscontribution.

Bootstrapping time may be reduced by reintroducingoptimistic unchokes in BitTyrant, but it is not clear thatselfish peers have any incentive to do so.

• Peering relationships are not stable. BitTyrant was de-signed to exploit the significant altruism that exists inBitTorrent swarms today. As such, it continually re-duces send rates for peers that reciprocate, attempt-ing to find the minimum rate required. Rather thanattempting to ramp up send rates between high capac-ity peers, BitTyrant tends to spread available capacityamong many low capacity peers, potentially causinginefficiency due to TCP effects [15].

To work around this third effect, we propose extendingBitTyrant to advertise itself at connection time using thePeer ID hash. Without protocol modification, BitTyrantpeers can recognize one another and switch to a block-based tit-for-tat strategy that ramps up send rates con-servatively until capacity is reached. This is easily im-plemented and requires no protocol changes. BitTyrantclients can simply choke other BitTyrant peers whoseblock request rates exceeds their send rates. By gradu-ally increasing send and request rates to other BitTyrantclients, fairness can be preserved while maximizing re-ciprocation rate with fewer connections. In this way,BitTyrant can provide a deployment path leading to theconceptually simple strategy of block-based tit-for-tat byproviding a selfish, short-term incentive for adoption byall users—even those that stand to lose from a shift toblock-based reciprocation.

We do not claim that BitTyrant is strategy proof, evenwhen extended with block-based tit-for-tat, and leaveopen the question of whether further strategizing can beeffective as future work. However, a switch to blockbased tit-for-tat among mutually agreeing peers wouldplace a hard limit on altruism and limit the range of pos-sible strategies.

6 Related work

Modeling and analysis of BitTorrent’s incentive mecha-nism and its effect on performance has seen a large bodyof work since Cohen’s [3] seminal paper. Our effort dif-fers from existing work in two fundamental ways. Firstis the conclusion: we refute popular wisdom that BitTor-rent’s incentive mechanism makes it robust to strategicpeer behavior. Second is the methodology: most existingstudies consider small simulated settings that poorly cap-ture the diversity of deployed BitTorrent clients, selfishpeer behavior, peer capacities, and network conditions.In contrast, we explore BitTorrent’s strategy space withour implementation of a selfish client and evaluate it us-ing analytical modeling, experiments under real networkconditions, and testing in the wild.

The canonical tit-for-tat strategy was first evaluatedby Axelrod [1], who showed using a competition thatthe strategy performs better than other submissions whenthere are many repeated games, persistent identities, andno collusion. Qiu and Srikant [16] specifically study Bit-Torrent’s rate-based tit-for-tat strategy. They show that ifpeers strategically limit their upload bandwidth (but splitit equally) while trying to maximize download, then, un-der some bandwidth distributions, the system convergesto a Nash equilibrium where all peers upload at their ca-pacity. These results might lead one to believe that Bit-Torrent’s incentive mechanism is robust as it incentivizesusers to contribute their entire upload capacities. Unfor-tunately, our work shows that BitTorrent fails to attainsuch an equilibrium for typical file sizes in swarms withrealistic bandwidth distributions and churn, which ourselfish client exploits through strategic rate selection.

Bharambe et al.[2] simulate BitTorrent using a syn-thetically generated distribution of peer upload capaci-ties. They show the presence of significant altruism inBitTorrent and propose two alternate peer selection al-gorithms based on (i) matching peers with similar band-

12

width, and (ii) enforcing tit-for-tat at the block level, astrategy also proposed by [9]. Fan et al.propose strate-gies for assigning rates to connections [5], which whenadopted by all members of a swarm would lead to fair-ness and minimal altruism. The robustness of thesemechanisms to strategic peer behavior is unclear. Butmore importantly, these proposals appear to lack a con-vincing evolution path — a peer adopting these strategiestoday will severely hurt its download throughput as themajority of deployed conformant clients will find such apeer unattractive. In contrast, we demonstrate that Bit-Tyrant can drastically reduce altruism for a single selfishclient today incenting its adoption.

Shneidman et al.[18] identify two forms of selfish ma-nipulation based on Sybil attacks [4] and a third basedon uploading garbage data. Liogkas et al.[12] proposedownloading only from seeds and also identify an exploitbased on uploading garbage data. However, there existreasonable fixes to minimize the impact of such “byzan-tine” behavior. A third exploit by Liogkas et al. involvesdownloading only from the fastest peers, but the strat-egy does not take into account the upload contributionrequired to induce reciprocation. In contrast, our self-ish client maximizes download per unit of upload band-width and can drastically reduce its upload contributionby varying the active set size and not sharing its uploadbandwidth uniformly with active peers.

Hales and Patarin [8] argue that BitTorrent’s robust-ness is not so much due to its tit-for-tat mechanism, butmore due to human or sociological factors that cause tor-rents with a high concentration of altruistic peers to bepreserved over selfish ones. They further claim that re-leasing selfish clients into the wild may therefore not de-grade performance due to the underlying natural selec-tion. It is unclear how to validate such hypotheses with-out building and releasing real selfish clients—one of ourcontributions.

Massoulie and Vojnovic [14] model BitTorrent as a“coupon replication” system with a particular focus onefficiently locating the last few coupons. One of theirconclusions is that altruism is not necessary for BitTor-rent to be efficient. However, their study does not ac-count for strategic behavior on part of peers.

Other studies [2, 7, 11] have pointed out the presenceof significant altruism in BitTorrent or suggest preserv-ing it [11]. In contrast, we show that the altruism is nota consequence of BitTorrent’s incentive mechanism andcan in fact be easily circumvented by a selfish client.

7 ConclusionWe have revisited the issue of incentive compatibilityin BitTorrent and arrived at a surprising conclusion: al-though tit-for-tat discourages free riding, the bulk of Bit-Torrent’s performance has little to do with tit-for-tat. The

dominant performance effect in practice is altruistic con-tribution on the part of a small minority of high capacitypeers. More importantly, this altruism is not a conse-quence of tit-for-tat; selfish peers—even those with mod-est resources—can significantly reduce their contributionand yet improve their download performance. Thus, Bit-Torrent works so well simply because most people faith-fully use downloaded client software as-is without tryingto cheat the system.

Based on the insights gathered from a simple model ofBitTorrent’s altruism, we built BitTyrant, a selfish clientthat cleverly selects peers so as to optimize the amountof download per unit of upload bandwidth. We foundthat BitTyrant improves performance for all peers thatuse it. Nevertheless, in practice, BitTyrant will hurt theperformance of individual swarms as high capacity peersreach a point of diminishing returns and are incented toeither withhold their upload contribution or invest it inother swarms. Low capacity peers do not enjoy such aluxury. As the majority of peers have low capacity, theywill see degraded performance compared to BitTorrenttoday.

The BitTyrant source code and distribution are pub-licly available athttp://BitTyrant.cs.washington.edu/

References[1] R. Axelrod. The Evolution of Cooperation. Basic Books,

1985.[2] A. Bharambe, C. Herley, and V. Padmanabhan. Analyz-

ing and Improving a BitTorrent Network’s PerformanceMechanisms. In IEEE INFOCOM, 2006.

[3] B. Cohen. Incentives build robustness in BitTorrent. InProceedings of the Workshop on Economics of Peer-to-Peer Systems, Berkeley, CA, USA, 2003.

[4] J. R. Douceur. The Sybil attack. In International Work-shop on Peer-to-Peer Systems, 2002.

[5] B. Fan, D.-M. Chiu, and J. Liu. The Delicate Tradeoffs inBitTorrent-like File Sharing Protocol Design. In Proc. ofICNP, 2006.

[6] GNU Scientific Library. http://www.gnu.org/software/gsl/.

[7] L. Guo, S. Chen, Z. Xiao, E. Tan, X. Ding, and X. Zhang.Measurements, analysis, and modeling of BitTorrent-likesystems. In Proceedings of the ACM SIGCOMM InternetMeasurement Conference, 2005.

[8] D. Hales and S. Patarin. How to Cheat BitTorrent andWhy Nobody Does. Technical Report UBLCS 2005-12,Computer Science, University of Bologna, 2005.

[9] S. Jun and M. Ahamad. Incentives in BitTorrent inducefree riding. In Proc. of P2PECON, 2005.

[10] S. Katti, D. Katabi, C. Blake, E. Kohler, and J. Strauss.MultiQ: Automated detection of multiple bottleneck ca-pacities along a path. In Proceedings of the ACM SIG-COMM Internet Measurement Conference, 2004.

[11] A. Legout, G. Urvoy-Keller, and P. Michiardi. RarestFirst and Choke Algorithms are Enough. In Proc. of IMC,2006.

13

Label Definition Meaningω 2 Number of simultaneous optimistic unchokes per peerλ 80 Local neighborhood size (directly connected peers)b(r) Figure 1 Probability of upload capacity rate rB(r)

∫ r

0b(r)dr Cumulative probability of a upload capacity rate r

active(r) b√

0.6rc − ω Size (in peers) of the active transfer set for upload capacity rate rsplit(r) r

active(r)+ω Per-connection upload capacity for upload capacity rate r

s(r) Figure 1 Probability of an equal-split rate r using mainline active(r) sizingS(r)

∫ r

0s(r)dr Cumulative probability of an equal-split rate r

Table 2: Functions used in our model and their default settings in the official BitTorrent client.

[12] N. Liogkas, R. Nelson, E. Kohler, and L. Zhang. Exploit-ing BitTorrent for fun (but not profit). In Proc. of IPTPS,2006.

[13] H. V. Madhyastha, T. Isdal, M. Piatek, C. Dixon, T. An-derson, A. Krishnamurthy, and A. Venkataramani. iPlane:An information plane for distributed services. In Proc. ofOperating Systems Design and Implementation, 2006.

[14] L. Massoulie; and M. Vojnovic. Coupon replication sys-tems. SIGMETRICS Perform. Eval. Rev., 33(1):2–13,2005.

[15] R. Morris. TCP behavior with many flows. In Proceed-ings of ICNP, 1997.

[16] D. Qiu and R. Srikant. Modeling and performance analy-sis of BitTorrent-like peer-to-peer networks. In Proceed-ings of Sigcomm, 2004.

[17] S. Saroiu, P. K. Gummadi, and S. D. Gribble. A mea-surement study of peer-to-peer file sharing systems. InProceedings of Multimedia Computing and Networking,2002.

[18] J. Shneidman, D. Parkes, and L. Massoulie. Faithfulnessin internet algorithms. In Proc. of PINS, 2004.

A Modeling notesAll numerical evaluation was performed with the GSLnumerics package [6]. Refer to Section 3 for assump-tions and Table 2 for definitions.Upload / download: Probability of reciprocation for apeer P with upload capacity rP from Q with rQ:

p recip(rP , rQ) = 1− (1− S(rP ))active(rQ) (1)

Expected reciprocation probability for capacity r:

recip(r) =∫

b(x)p recip(r, x)dx (2)

Expected download and upload rate for capacity r:

D(r) = active(r)[∫

b(x)p recip(r, x)split(x)dx

]+

ω

[∫b(x)split(x)dx

](3)

U(r) = min(r, (active(r) + ω) dl(r)

)(4)

Altruism: Altruism when defined as the difference be-tween upload contribution and download reward

altruism gap(r) = max(0, U(r)−D(r)

)(5)

Altruism per connection when defined as upload contri-bution not resulting in direct reciprocation.

altruism conn(r) =∫ (b(x)

((1− p recip(r, x))split(r)+ (6)

p recip(r, x) max(0, split(r)− split(x))))

dx

Total altruism not resulting in direct reciprocation.

altruism(r) = (active(r) + ω)altruism conn(r) (7)

Convergence: Probability of a peer with rate r discover-ing matched TFT peer in n iterations:

c(r, n) = 1− S(r)n 2ω (8)

Time to populate active set with matched peers given up-load capacity r. Note, s = split(r), and T = 30s is theperiod after which optimistic unchokes are switched.

convergence time(r) = (9)

T · active(r)(c(s, 1)+

∞∑n=2

n c(s, n)n−1∏i=1

(1− c(s, i)))

Unchoke probability: The distribution of number of op-timistic unchokes is binomial with success probability ω

λ .Because overhead is low, λ � active(r) in BitTyrant, weapproximate λ − active(r) by λ. The expected numberof optimistic unchokes per round is ω.

Pr[unchokes = x] =(

λ

x

) (ω

λ

)x (1− ω

λ

)(λ−x)

(10)

∴ E[unchokes] = λω

λ= ω

14