One hop Reputations for Peer to Peer File Sharing Workloads

Michael Piatek Tomas Isdal Arvind Krishnamurthy Thomas AndersonUniversity of Washington

AbstractAn emerging paradigm in peer-to-peer (P2P) networksis to explicitly consider incentives as part of the proto-col design in order to promote good (or discourage bad)behavior. However, effective incentives are hamperedby the challenges of a P2P environment, e.g. transientusers and no central authority. In this paper, we quantifythese challenges, reporting the results of a month-longmeasurement of millions of users of the BitTorrent filesharing system. Surprisingly, given BitTorrent’s popu-larity, we identify widespread performance and availabil-ity problems. These measurements motivate the designand implementation of a new, one hop reputation proto-col for P2P networks. Unlike digital currency systems,where contribution information is globally visible, or tit-for-tat, where no propagation occurs, one hop reputationslimit propagation to at most one intermediary. Throughtrace-driven analysis and measurements of a deploymenton PlanetLab, we find that limited propagation improvesperformance and incentives relative to BitTorrent.

1 IntroductionPeer-to-peer (P2P) networks have the potential to addresslong-standing challenges in networked systems. Endhosts represent an immense pool of under-utilized band-width, storage, and computational resources that, whenaggregated by a P2P network, can be used to absorb flashcrowds, replicate data intelligently within the network,and externalize bandwidth costs. And unlike network-layer support such as IP multicast, P2P solutions can bedeployed without architectural changes to the underlyingnetwork.

While significant progress has been made towards ad-dressing the technical challenges of building P2P sys-tems, their robustness ultimately depends on convinc-ing users to contribute their resources, a challenge ofincentive design. Early P2P systems such as Gnutellaignored incentives and were plagued by rampant free-riding, i.e., users consuming resources without contribut-ing them [1]. Free-riding degrades system performanceand limits scale. Subsequent systems such as BitTorrentexplicitly built user contribution incentives into their de-sign [4], but recent work has exposed methods of circum-venting BitTorrent’s incentives [11, 12].

Designing robust incentives for P2P networks is chal-lenging due to the constraints of the environment:

• No central control or trust: Many practical problems

in P2P data sharing become trivial if we can assumea “deus ex machina”—some authority that can mintcurrency, perform accounting, and penalize miscre-ants. To date, P2P designs that rely on centralizationof these tasks have not been widely adopted.• Open implementation: Users are free to adopt any

client implementation, even one that attempts to sub-vert incentives or strategize. This makes the P2P de-sign challenge harder, as problems like free-riding canbe defined away if all users must connect using a par-ticular software release.

This paper concerns how best to design future incen-tive strategies for P2P networks. We proceed in twosteps. First, to ground our work, we conducted a mea-surement study of BitTorrent. BitTorrent is a widely usedP2P system and we were able to study the sharing be-havior of tens of thousands of data objects and millionsof users for more than one month. Surprisingly givenBitTorrent’s popularity, we identify widespread perfor-mance and availability problems, along with data on whythese problems arise in practice. We find that problemscannot be wholly attributed to scarcity of potential datasources and/or capacity limitations. Instead, we arguethat ineffective incentives account for the lack of re-sources, a point underscored by our measurement resultthat an average user joining an average swarm can getcomparable download performance with only 1/100ththe contribution.

A key reason for the weakness of current incentives isthe duration for which they are active. Current incentivesin BitTorrent operate within the context of a single objectand only while clients are actively downloading. As a re-sult, users have no reason to contribute once they havesatisfied their immediate demands. This weakness im-plies the need for persistent incentives that operate acrossdata objects and across time. Unfortunately, our mea-surements also show that most pairs of peers interact withone another in just one swarm, suggesting that long-termincentives will not arise from strategies based on directinteractions and local history alone. But, while most P2Pusers are transient, our study shows that a small minorityof peers participate persistently and across many swarms;these users provide a scaffold for a solution.

The second part of the paper concerns our design ofa solution to the problems we found in BitTorrent. Wepropose a new, one hop reputation protocol for P2P net-works. Unlike digital currency systems, where contribu-

tion information propagates globally, or tit-for-tat, whereno propagation occurs, one hop reputations limit propa-gation to at most one level of indirection. Surprisingly,this limited propagation suffices to provide wide cover-age; we find that the majority of peers, while transient,have shared relationships through popular intermediariesone hop removed. We define a protocol that discov-ers these relationships, enabling a broad range of ser-vicing policies using information beyond direct obser-vations and local history. Through trace-driven analy-sis and measurements of a deployment on PlanetLab, weshow that our default one hop system both improves per-formance for users in individual swarms and fosters thelong-term incentives that are necessary for P2P systemsto work well in the long run.

2 Sharing in the wildTo understand the real challenges facing P2P designers,we collected large-scale measurements of BitTorrent inthe wild. Over the course of the study we observed morethan 14 million peers and 60,000 swarms accounting forthousands of terabytes of transfered data. To measurethe strength of contribution incentives, we joined realswarms, exchanged data at varying rates with peers, andcollected information to distinguish unique users suchas client software and version and IP address. We alsotracked the popularity of swarms over time, recordingboth direct observations of peers and second hand ac-counts from coordinating tracker servers, membershipDHT entries, and peer gossip messages.

Our measurements provide insights into the sharingworkload that extend beyond the granularity of perfor-mance for a single user or behavior in a single swarm.Specifically, we show the following:

• Performance and availability in BitTorrent is ex-tremely poor. The median download rate in observedswarms is 14 KBps for a peer contributing 100 KBps,and as many as 25% of swarms are unavailable.

• These performance and availability problems are notfundamental. Our measurements show that sufficientcapacity is available to provide much better perfor-mance than is observed today, and many unpopularobjects would see their availability improve if previ-ous downloaders could be offered sufficient incentivesto persist as replicas.

• Existing incentives in BitTorrent, while designed toencourage contribution, are largely ineffective. Be-cause of the structure of the workload, BitTorrent in-centives permit free-riding and strategic manipulationfor the majority of BitTorrent swarms.

• Simple extensions to BitTorrent’s incentive strategy,e.g., using direct long-term reciprocation for contribu-tions, will not address the observed problems due to

Figure 1: Download performance for different levels ofcontribution in BitTorrent. Each line gives the distribu-tion of download performance for a contribution levelas measured across thousands of real-world swarms intrace BT-1. Significant increases in contribution resultin slight, if any, improvement in download performance.

a lack of repeat interactions in the sharing workload.However, the significant disparity in the popularity ofP2P users points to the promise of new approachesbased on indirect reciprocation.

2.1 Trace methodology

In BitTorrent, each file is split into blocks. Clients ac-tively downloading a file are randomly matched, withmatched peers exchanging data and control informationas to which blocks they have and which they need. Ide-ally, a data source, or seed, only needs to provide eachdata block to a few random clients, and the rest of thework is done by the swarm of peers. Crucially, peers dis-tinguish among competing requests for service accordingto a tit-for-tat policy: each client preferentially uploadsblocks only to those peers that are actively providing datato it (and then, only to those that are providing data at thehighest rate). Tit-for-tat is intended to provide better per-formance for peers that contribute more data.

The reported effectiveness of tit-for-tat has variedwidely in existing work. Theoretical analysis, simula-tion and small testbed studies have pointed to its robust-ness [2, 10, 15] while more recent studies of performancein the wild have exposed circumstances under which tit-for-tat breaks down [11, 12, 16]. For system buildersto design truly robust incentive protocols, a more com-plete understanding of P2P workloads is required. Wecollect and analyze BitTorrent trace data with the over-arching goal of understanding when tit-for-tat incentiveswork and when they don’t, in the wild.

We make reference to two traces of live BitTorrentswarms collected from a cluster of machines at the Uni-versity of Washington. Between January 26th and Febru-ary 3rd, 2007, we measured membership and down-load performance for instrumented clients participatingin 13,353 swarms. We refer to this trace as BT-1. Wecollected a second trace, BT-2, from the same cluster

over the month of August 2007, providing measurementsof 55,523 swarms. In both traces, every hour, a measure-ment coordinator crawled popular BitTorrent websitesthat aggregate information about new swarms, down-loading all of these. Our instrumented clients joinedthese swarms periodically during the trace. We includeinformation for only those swarms we successfully con-nected to at least once. To determine peer downloadrates, we measured the rate at which new blocks ap-peared in the peer’s list of available blocks and alsorecorded availability of blocks. Each client contributedresources to the swarms at a rate of either 1, 30, or100 KBps to examine the performance impact of vary-ing the contribution level.

2.2 BitTorrent performance and availability

The download rate achieved by our measurement clientsas a function of contribution rate is summarized in Fig-ure 1 for trace BT-1. Even on the well-connected aca-demic network used for our data collection, clients down-load slowly; contributing 100 KBps yields a mediandownload rate of just 14 KBps, far short of saturatingeven a modest home broadband connection. Further,25% of the time swarms were completely unavailable,i.e., delivered no data.

The poor performance of P2P networks cannot be ex-plained by users simply lacking the capacity to offerpeers a high average download rate, nor can poor avail-ability be attributed to a long tail of fundamentally un-popular objects. Regarding performance, measurementsof more than 100,000 BitTorrent peers in 2006 put aver-age upload capacity at more than 400 KBps [8]. Skew inthe capacity distribution is significant; the average valueis roughly 10X the median. Regarding availability, ourmeasurement results show that for many seemingly un-popular objects, the existence of replicas is not as mucha problem as the persistence of replicas. The vast major-ity of swarms would have significantly more replicas ifdownloaders would simply continue to share after com-pleting. We evaluate this by comparing available replicasassuming peers persist for either one day or one week af-ter their initial observation. For trace BT-2, the medianincrease in available replicas is a factor of 3.

These measurements point to a problem of incentives.If users could be convinced to contribute all of their ca-pacity, download performance would increase. If userswere convinced to persist as object replicas, availabilitywould improve. Realizing these benefits requires under-standing the causes of today’s weak incentives, the topicwe turn to next.

2.3 Workload causes for weak incentives

The strength of a contribution incentive is the return itprovides for contribution, i.e., the ratio of uploaded to

Figure 2: Cumulative fraction of total capacity (y-axis)attributed to the percentage of total peers rank ordered bycapacity (x-axis). 80% of the total aggregate capacity ofBitTorrent peers comes from the top 10% of users.

downloaded bytes. This section details two workloadproperties that weaken contribution incentives in BitTor-rent. First, we examine how the distribution of band-width capacity among peers influences the incentive theyhave to make that capacity available. Second, we quan-tify the number of swarms for which random, altruisticcontributions dominate performance.Capacity: In BitTorrent, returns are known to diminishas contribution increases [12]. Peers at the low end ofthe capacity spectrum see large returns on their contri-butions, i.e., 10 bytes contributed might earn 15 recip-rocated. This is balanced by reduced returns for peerswith greater capacity. If the disparity between returns forhigh and low capacity peers were limited, contributionincentives would be only slightly weakened. In BitTor-rent, however, the disparity is extreme. In our traces,increasing contributions 100-fold yields a 2-fold medianmarginal improvement in performance (shown for BT-1in Figure 1).

The diminishing returns for contributions is particu-larly damaging for aggregate P2P resources as the ma-jority of capacity is held by a small minority of users.Figure 2 shows the cumulative fraction of total capacityattributable to peers when ordered by individual capac-ity. If they were to contribute fully, the top 10% of peerswould account for 80% of total capacity. Thus, for thehighest capacity peers—those whose increased contribu-tion would most help performance—the contribution in-centive is weakest.Altruism: A user’s downloaded bytes come from eitherother peers actively downloading the object or seeds thathave completed their downloads and continue to makedata available. Because seeds do not have requests, theyhave no tit-for-tat basis for making servicing decisions,often doing so randomly in current implementations. Anoverabundance of seeds weakens contribution incentivesas most users receive data regardless of contribution.Conversely, too few seeds also weakens incentives since

Figure 3: Ratios of seeds to downloading peers forswarms in BT-2. 11% of swarm observations showedno active seeds.

peers quickly run out of data to trade, becoming blocked.Figure 3 summarizes the amount of seed-based altru-

ism in our BT-2 trace. For each swarm, we compute theratio of observed seeds and downloaders. This estimatesthe fraction of data a downloading peer is likely to re-ceive at random, i.e., independent of contribution. Thedata shows that no one circumstance dominates. 11% ofswarm observations show no active seeds (ratio 0) while50% of swarms have just as many randomly contributingseeds as actively downloading peers.

Given the range of operating conditions we observein practice, it is unsurprising that the BitTorrent perfor-mance picture is unclear. Some swarms enjoy a glut ofaltruistic donations, weakening contribution incentivesand enabling free-riding. Other swarms are starved fordata, causing performance to be constrained by availabil-ity rather than contribution. For the minority remainingswarms, the strength of the contribution incentive is tiedto the bandwidth capacity distribution, with the major-ity of capacity being held by peers with little reason tocontribute, leading to slow download rates.

2.4 A straw-man solution

In contrast to the standard game-theoretic tit-for-tat strat-egy, BitTorrent’s variant is rate-based. Instead of tradingwith peers byte for byte, reciprocation for a BitTorrentpeer is decided only relative to its competitors and is ap-portioned equally among successfully competing peers.For instance, if a client C with capacity 20 receives datafrom peers X , Y , and Z at rates 5, 7, and 10 and se-lects only two peers at a time for reciprocation, C willsend data to Y and Z at rate 10 apiece. This approach fa-vors utilization over fairness and stateless operation overstability. Peers simply give away bandwidth if they arepoorly matched in terms of rates and maintain only ashort-term local history about each peer with which tomake servicing decisions, switching peers frequently asshort-term status changes.

An alternative to basing tit-for-tat decisions on rate isinstead basing them on total data volume. This is the ap-

Figure 4: CDF of the frequency of repeat interaction be-tween a pair of peers in the BT-2 trace. Note that they axis is not zeroed and only pairs interacting at leastonce are considered. Even assuming infinite duration inswarms, 91.5% of interacting peers will do so only once.Limiting persistence reduces the chance of repeat inter-action further to less than 1%.

proach taken by the eDonkey file sharing network, whichstores per-peer state recording the amount of data sentand received, using this to rank peers with competingrequests. From the perspective of strengthening contri-bution incentives, a switch from rate to volume seemspromising, primarily because it offers the potential forlong-term repeat interactions. Seeds might be willingto share files long after completion, improving availabil-ity, because in doing so they would contribute to peerswhose memory of those contributions would induce re-ciprocation if the situation were reversed. Similarly, ifhigh capacity peers were mismatched with low capac-ity peers, the contribution imbalance could be boundedor ignored—assuming repeat interactions would result ineventual repayment.

Unfortunately, volume-based tit-for-tat does not seemto have solved the performance problem in practice.Pucha et al. report a median download rate of 10 Kbpsin the eDonkey network [14]—short of our observedmedian performance for BitTorrent swarms. Althoughnumerous technical differences prohibit an apples-to-apples comparison, we hypothesize that the failureof volume-based tit-for-tat to promote contribution ineDonkey can be traced to a workload property that itlikely shares with BitTorrent—a lack of pairwise repeatinteractions.

We say that two peers share an interaction if eithersends or receives data from the other. Peers exhibit repeatinteractions if they exchange data in multiple swarms.Figure 4 reports the frequency of repeat interactions inthe BT-2 trace, conditioned on a pair having interactedin at least one swarm. Because our trace data providesonly coarse-grained observations of peer membership,i.e., we do not actively probe observed peers repeatedlyto determine departure time, we give the distribution ofrepeat interactions assuming peers persist for either an

Figure 5: The distributions of peers encountered by Bit-Torrent users in the BT-2 trace. Whether assuming infi-nite or limited duration, a small minority of popular peersparticipates broadly.

infinite duration or an 8 hour interval. Assuming infiniteduration overestimates the number of repeat interactions,while assuming an 8 hour duration may underestimate itfor some long-lived peers. In either case, however, thechance of enabling long-term incentives via repeat inter-actions is slim. Even assuming infinite duration, morethan 91.5% of peer pairs that occur in a single swarm donot arise in any other swarm over the course of our trace.

The apparent lack of repeat interactions suggests thatdirect, pairwise exchange based on local history alonewill not suffice to enable the long-term contribution in-centives needed to address the performance and avail-ability problems we observe in the wild. But, al-though direct interactions appear insufficient, our work-load measurements do provide a hint as to the effective-ness of indirect reciprocation; i.e., instead of peer A de-ciding whether to service the requests of B only on thebasis of B’s contributions to A, indirect reciprocationmight see A contributing to B due to B’s contributionsto C, who has previously contributed to A.

Our data shows that most peers share an indirect re-lationship of this type. Further, a small number peersaccount for most of these intermediaries. 97% of allpeers observed in trace BT-2 are connected either di-rectly or through an intermediary among the most popu-lar 2000 peers. This is due to a workload characteristic.Although most peers connect to only hundreds of otherpeers, a small minority is more extensively connected.Figure 5 shows the distribution of peer connectivity intrace BT-2.

The disparity in peer popularity is reflected in the dis-tribution of demand as well. Figure 6 shows the distribu-tion of total demand observed in our trace. We first or-dered peers by popularity, i.e., the number of other peerswith which they share a swarm. Next, we computed thecumulative fraction of demand attributable to these or-dered peers. The top 25% of peers account for 78% ofdemand.

Figure 6: Cumulative fraction of consumption (y-axis)attributed to peers, ordered by popularity (x-axis).

3 One hop indirect reciprocationAlthough repeat interactions are rare for the majority ofpeer pairs, a small minority of popular users have muchwider coverage. In this section, we describe a new, onehop reputation propagation protocol designed to enablelong-term reciprocation beyond this minority via indi-rect reciprocation. The main goal of one hop reputationsis to foster persistent contribution incentives by recog-nizing and rewarding contributions made by users acrossswarms and over time. To achieve this, clients maintain apersistent history of interactions and, upon request, serveas intermediaries attesting to the behavior of others.

The key idea behind our scheme is to restrict theamount of indirection between contributing and recipro-cating peers to at most one level of intermediaries. Thisrestriction limits the propagation of information, promot-ing scalability, and allows for local reasoning about thetrustworthiness of intermediaries, thereby fostering ro-bustness.

While our measurements show that most peers sharea one hop relationship, discovering and using these re-lationships requires more information than is availablethrough direct observation alone. Peers need to nameone another persistently across interactions and exchangemessages about third party behavior. In Section 3.1,we define a protocol for exchanging the information re-quired to discover intermediaries and to mediate indirectreciprocation.

Our protocol provides information but does not pre-scribe how that information must be used, separating themechanism for exchanging information from the policyfor using it. In Section 3.1, we specify a default policydesigned to maximize coverage, i.e., the fraction of pairsof peers that can evaluate one another using one hop rep-utations. We also describe the resistance of our defaultpolicy to various forms of strategic manipulation, but wedo not claim to be robust to all forms of attack. Instead,our design is intended to allow peers to freely evolvetheir strategies independently, and we consider severalpotential alternatives.

Notation Definitionn(x→ y) bytes sent directly from x to yn(x← y) bytes received directly from y by x

n(xy→ ∗) bytes sent to other peers due to y’s

recommendation as the intermediaryn(x

y← ∗) bytes received by x from other peerswith y acting as the intermediary

n(∗ x→ y) summation of all bytes from any peersent to y due to x’s referrals

n(∗ x← y) summation of all bytes sent by y toeach of x’s referrals

rate(x← y) the average rate at which y provideddata to x

Table 1: State at client x for each peer y.

3.1 One hop reputation protocol

Our one hop reputation protocol can be broken down intotwo facets: the state maintained at each peer and mes-sages used to propagate state between peers.Per-peer state: One hop reputations extend volume-based tit-for-tat to incorporate reputation intermediaries.Intermediaries serve two purposes: bootstrapping con-nections between new peer pairs and maintaining ac-counting information regarding indirect reciprocation.Every client records each peer it has interacted with, ei-ther directly during data transfer or indirectly when thatpeer acts as an intermediary attesting to the behavior ofothers. Each peer is identified by a self-generated pub-lic/private key pair. While a peer can freely create newidentities, our default policy rewards long-term persis-tence and includes provisions for mitigating Sybil at-tacks [6], creating little incentive to do so. Table 1 liststhe state maintained by each client, which is indexed bythe public key of its peers.

Figure 7 provides an example of the use of this infor-mation to bootstrap a new connection. In this case, a onehop intermediary I bootstraps the interaction betweenpeers A and B who have not previously interacted. Inthe first two interactions, I exchanges data directly withA and B. These uninformed exchanges are infrequentand serve to bootstrap a reputation. At this point, I canserve as an intermediary between A and B. When theymeet, A and B exchange control traffic (defined below)allowing them to recognize their common relationshipwith I . Because B has contributed to I in the past andA has received prior service from I , A can use its localhistory regarding I to inform its valuation of B.

Because the interactions between A, B, and C maynot occur within the context of a single swarm, peersmay need to contact intermediaries across multiple ses-sions. To aid in this, each client stores its current IP ad-dress and TCP port, indexed by its public key, in a DHT.Many popular P2P services already include a DHT, e.g.,

I

A

3

Interactions

Global state

B

I

A

B

2I

Time

1 42

Figure 7: An example of peer state information used forbootstrapping. A recognizes B’s standing with interme-diary I . Dashed lines indicate prior interactions.

Kademlia is used in BitTorrent and eDonkey. Althoughexisting DHTs are generally robust, we do not evaluatetheir resistance to strategic or malicious behavior, insteadopting to use provided values as hints only. Identityis independently verified using cryptographic keys andkey→ IP mappings are locally cached.State propagation: In the example of Figure 7, peerpairs A, I and B, I learn about one another directlythrough data transfer, requiring no explicit signaling.However, when A and B meet, they must exchange mes-sages indicating which peers (possible intermediaries)they share in common and their status with those sharedpeers. In our protocol, this is a multi-step process.

1. First, peers order their local set of possible intermedi-aries to form what we refer to as their top K set. In-clusion in the top K set is a matter of local policy, butordering this list by number of observations (our de-fault policy) promotes the exchange of popular peersas intermediaries, increasing one hop coverage. Peersexchange topK messages upon connection.

2. Next, the intersection of local and remote top K sets iscomputed. This intersection is the set of shared peersthat might be used as intermediaries for indirect recip-rocation, but more information needs to be exchangedto compute the remote peer’s reputation value.

3. For each possible intermediary, peers request attesta-tion receipts of contribution by sending a receipt re-quest message, containing the identity of the interme-diary, to the remote peer. An attestation receipt forpeer B from an intermediary I includes B’s local stateat I , time stamped and signed by I’s private key.

4. Multiple peers can serve as intermediaries to mediate aspecific interaction. If so, byte counts in local historiesare updated fractionally based on the relative weight ofeach intermediary’s valuation at the data source. Thisattribution message, a set of {identifier, weight} tuples,is sent to the receiving peer before data is transferred.

5. Once peers begin exchanging data, receipt messagesare sent periodically from receiver to sender, to pro-vide proof of received data and the corresponding in-crements to the sender’s valuation. Before transmit-ting data, the sending peer dispatches a reserve mes-sage to mediating intermediaries containing the re-questing peer’s identifier and request size. These mes-sages serve to preempt attacks based on using the rec-ommendation of an intermediary multiple times andare optional. Periodically, update messages are sentto intermediaries, batching the reporting of transfersattributed to them, documented by received receipts.

In addition to facilitating identification of common in-termediaries among peer pairs (Steps 1, 2), top K setsalso bootstrap the local histories of new peers in the sys-tem. Each entry in the topK message contains a bit indi-cating whether the entry corresponds to an intermediarythat can mediate a direct transfer or a gossip entry fora popular intermediary with whom the sender does nothave a direct or indirect relationship. This is an optimiza-tion, effectively using two hop propagation to bootstrapone hop reputations. A client relying on direct, local ob-servations alone to derive the coverage of potential in-termediaries would have to directly observe them mul-tiple times in distinct swarms before identifying thosewith high coverage. In the interim, new users would beunable to evaluate the quality of peers in good standingwith popular intermediaries. Instead of relying on directobservations alone, peers may incorporate the gossip in-termediaries included in the top K sets of their directlyconnected peers, combining this information with directobservations in their local history. Care must be takenwhen incorporating this information to prevent strategicmanipulation, an issue we will discuss later.

3.2 Policies

Our state exchange protocol provides information aboutpeers that enables a range of valuation policies. In thissection, we propose a default policy designed to max-imize coverage. However, peers are not required to fol-low this policy, and we present it as just one plausible de-sign point among several alternatives. Other options arepossible, e.g., trading coverage for resistance to strategicmanipulation and collusion.

3.2.1 Default policy

Our default policy is the indirection-enabled analogueof volume-based tit-for-tat. When a peer makes servic-ing decisions, it restricts contribution to only those peerswho have a positive or near positive “balance” with thesystem as a whole. This limits the potential for free-riding, if most peers have a one hop basis for makingdecisions. In this section, we define precisely how eachclient ranks the requests of others using one hop infor-

Figure 8: The default one hop servicing policy.

mation and how membership of possible intermediariesin the top K set is decided.Computing reputations: The value of a one hop rep-utation for peer B from the perspective of a peer A isdetermined by three factors: 1) the volume of data exc-shanged between A and B (if any), 2) A’s valuation ofB’s attesting intermediaries, and 3) B’s reputation witheach attesting intermediary. We denote A’s valuation ofintermediary I as wA(I) and the valuation of peer Bat intermediary I by vI(B), defining these precisely inEquations 1 and 2, respectively.

wA(I) =n(A← I) + n(A I← ∗)

n(A→ I) + n(A I→ ∗)(1)

vI(B) =n(∗ I← B) + n(I ← B)

n(∗ I→ B) + n(I → B)(2)

These expressions allow us to define the indirect reputa-tion value of a peer B from the perspective of a peer A,ivalueA(B), given a set of mutually recognized interme-diaries, I, as:

ivalueA(B) =∑

I∈I wA(I)× vI(B)|I|

(3)

If two peers have a bidirectional relationship, the directreputation value, dvalueA(B), is defined as:

dvalueA(B) =n(A← B)n(A→ B)

(4)

Figure 8 shows how servicing decisions are made re-garding a set of peers requesting data. Our default pol-icy uses direct observations if they exist, relying on onehop indirection only if local history is unavailable (lines2–4). This gives peers an incentive to operate as an in-termediary since doing so increases their value across allpeers directly, removing the need to rely on one hop cov-erage and preempting other peers that need to compete

based on indirect evaluation. If indirection is required,we use a randomly chosen subset1 of shared intermedi-aries to mediate transfers (line 6). Attribution receiptsare requested for each mediator (lines 7–9) before com-puting indirect reputation. After reputations have beencomputed, requests can be serviced. We impose a repu-tation threshold to limit contribution imbalance (line 14).Selected peers receive Attribution messages indicating thefraction of throughput to account for each mediator (line16), normalized by the weight of all mediators (line 15).Servicing rates are assigned proportionally based on rel-ative reputation (line 17), normalized (line 13) across theset of selected peers.Top K membership: Our default policy for populatingtop K sets is based on the number of direct and indi-rect observations of each potential intermediary. When aclient directly observes a peer, its occurrence count is in-cremented by one. In addition to direct observation, ourdefault policy also integrates indirect observations in theform of top K sets from peers. In this case, occurrencecounts are updated fractionally, weighted by the numberof received bytes from the peer reporting an observationrelative to others in the recent past.

If an intermediary is unavailable or refuses an updatemessage, its occurrence count is reduced by 20% or 2,whichever is larger. This AIMD policy is intended topromote agreement on intermediaries with wide cover-age while quickly pruning popular peers that becomeoverwhelmed or unavailable. Overhead concerns aretreated further in Section 4.1.Liquidity: Peers have an incentive to keep in goodstanding with intermediaries that have high coverage.Peers gain standing with a popular intermediary by ei-ther satisfying its direct requests (direct contribution) orcontributing to peers that have satisfied the intermedi-ary’s requests one hop removed (indirect contribution).In the former case, there is a net increase in the sum to-tal of reputation values at the intermediary. In the lat-ter case, the reputation of one peer is simply transferredto another. Thus, the sum total of reputation values atan intermediary—the liquidity the intermediary providesthe system—is limited by the intermediary’s demand.This can result in a disabling shortage. Two peers mayshare many intermediaries that cannot be used becauseof a lack of standing with those intermediaries, reduc-ing the effective coverage of otherwise popular interme-diaries. This situation will arise unless popular interme-diaries generate enough demand to allow one hop tradingin satisfying their requests to cover the remainder of de-mand in the system.

To address this problem, the demand recorded in attes-tation receipts obtained for direct contributions is inflated

1Size 10 in our implementation, see Table 2.

by a fixed amount by all intermediaries. Because the in-flation factor depends on the fraction of total demandgenerated by popular intermediaries, its value is work-load dependent. In our traces, the most popular 2000peers account for 1.6% of total demand, suggesting thatan inflation factor of 100 provides sufficient liquidity.

Although the demand of the minority of popular usersrelative to total user demand varies little over the courseof our trace, this may not be a reliable workload char-acteristic. If fixed, a static inflation factor will suffice tomaintain sufficient liquidity even as users join and leavethe system. If not, intermediaries will need to adjust theirvalue at the cost of introducing true economic inflationinto the system. This requires only a policy change. In-termediaries can mint receipts with higher or lower bytevalues which peers can recognize and incorporate intotheir valuation of intermediaries.Intermediary incentives: In addition to providing suf-ficient liquidity, inflating the value recorded in attestingreceipts also creates an incentive to serve as an interme-diary. In the common case that two peers have not di-rectly interacted, their valuation of one another is basedon standing with popular intermediaries, trading in indi-rect attestations 1:1, i.e., 1 byte contributed for 1 byteattested. But, satisfying an intermediary’s requests di-rectly results in a 1:N exchange, where N > 1 is theinflation factor of intermediary receipts. Because of theirhigher returns, peers prioritize the requests of popular in-termediaries. This preferential treatment requires an in-termediary to continue mediating transactions: if it stopsresponding to queries and updates, it will be pruned fromthe set of preferred intermediaries by peers that it ig-nores.

3.2.2 Alternate policies

A large body of work on P2P reputation systems has doc-umented a well-known set of challenges for incentive de-sign. These include bootstrapping new users, Sybil at-tacks, collusion, and free-riding. To date, no compre-hensive solution has emerged that addresses all of theseissues, nor do we claim that our approach does. In-stead, we have explicitly designed our system to separatethe protocol mechanisms of reputation propagation andmaintenance from the policy for acting on that informa-tion. As a result, our scheme supports a range of poli-cies operating at different levels of vulnerability to well-known attacks. Our measurements of BitTorrent sug-gests that vulnerability to attack is a negative attribute,but not necessarily a fatal one. In this section, we detailseveral of these policies and the risks they carry.Direct, deficit 1 block-based tit-for-tat: This is themost conservative policy we consider, ignoring mostavailable information in the interest of (near) strategy-proof operation. Peers make the positive first step in the

traditional tit-for-tat game, sending at most one unrecip-rocated data block to a peer. For strategic adversaries,attacks are limited. Free-riders obtain at most one block,and while they might collect many blocks by repeatingthe game with a large number of peers, our measure-ments show that most swarms have hundreds of peers orfewer while most objects are comprised of thousands ofdata blocks. Sybil attacks are similarly frustrated. Collu-sion carries little benefit—the valuation of a peer is basedonly on the directly observed behavior of that peer. Boot-strapping is straightforward, as adherents to this strategywillingly contribute the single data block needed to startplaying the game. Finally, unfairness in data exchangedis sharply bounded per-peer. The strategic robustness ofthis approach comes primarily at the cost of a lack oflong-term incentives; seeds would limit their contribu-tion to just one block, further reducing availability.Direct, volume-based tit-for-tat: This strategy elimi-nates the bound on unfairness in block deficit tit-for-tat. Peers contribute their full capacity, realizing thatfree-riders / Sybil identities might never reciprocate andseed contributions may never be repaid due to the smallchance of repeat interactions. Willingness to make suchcontributions increases utilization while retaining thecollusion resistance of local reasoning as in deficit tit-for-tat. However, because repeat interactions are infrequent,long-term contribution incentives remain weak.Indirect contribution, reputation > 1.0 −ε: This isour default policy. The value of ε controls the level ofindirect imbalance a peer is willing to tolerate. How-ever, because one hop reputations do not provide preciseglobal accounting, peers contributing data due to third-party standing accept the risk that the intermediaries theychoose to mediate an exchange may not have wide cov-erage. But, as we will show in Section 4, most one hopinteractions can be mediated by multiple intermediarieswith wide coverage for observed workloads.Indirect / random excess contribution: For many typesof strategic behavior, e.g., free-riding, limiting damagedepends on reducing contributions when the reputationof a peer cannot be reliably ascertained. Much like theutilization / robustness tradeoff of deficit n tit-for-tat,peers are faced with a choice when considering what todo with any excess capacity that remains after servic-ing all requests based on one hop information. Continu-ing to service requests—essentially at random—enablesfree-riding behavior, with its effectiveness growing as theamount of random contributions increases.

3.3 Attacks and defenses

Permitting indirection greatly expands the range of at-tacks available to a strategic client or a set of colludingclients. We consider several attacks, but do not claim tomake indirect contribution under our default policy fully

resistant to all forms of strategic or malicious behavior.For increased robustness, clients are free to adopt an al-ternate policy that is more conservative.

• Intermediary collusion to promote peers: A popularintermediary may collude with peers or with Sybilidentities by providing falsely generated attestation re-ceipts. The effectiveness of this attack is amelioratedby the need for the intermediary to have contributedwidely to become popular in the first place. In a sense,its good standing with others is its own reputation tolose, and if it does not continue to directly maintainits standing with enough users through continued con-tributions, the value of good standing with it will di-minish, similarly diminishing the value of its falsifiedreceipts.

• Peer collusion to promote intermediaries: Becausepeers prioritize the requests of popular intermediariesin order to gain receipts with high coverage, collud-ers may attempt to promote a manufactured identitythat has not contributed widely. However, our one hoprestriction requires directly verifiable contribution tocarry out this deception. Because the integration of ex-ternal top K sets with a peer’s local history is weightedby the contributions of the reporting peer, members ofthe colluding set must “pay” an unknown amount forthe promotion of their fraudulent intermediary, balanc-ing the uncertain returns of the scheme against the ini-tial contributions required to carry it out.

• Peer collusion to defraud intermediaries: A peer maycollude with others or with Sybil identities to reportfalse contributions to inflate standing with popular in-termediaries. For example, a peer A that has legit-imately contributed 1 MB to popular intermediary Icould falsely report contributions of 1 GB to colludingidentity B, generating 1 GB worth of indirect contri-bution through I for peer A. Our default intermediarypolicy simply disallows the case of negative net contri-bution enabling this attack, meaning that A can trans-fer the attribution of its 1 MB worth to B but cannotexceed the amount of data that I can directly verify Ahas contributed.

4 EvaluationComprehensive evaluation of incentive systems is oftenfrustrated by an overabundance of metrics. For exam-ple, protocol designers can choose among fairness, uti-lization, bootstrapping time, overhead, and resistanceto strategic or malicious behavior. As we observed inSection 3.3, optimizing for one of these metrics oftencomes at the expense of another. Further, evaluatingthe ability of an incentive strategy to promote long-termincentives—a necessity for increasing availability in P2Psystems—requires a model of user behavior that is itself

Value Definition2000 The number of peers in a top K set

10 The maximum number of potentialintermediaries in overlappingtop K sets used to mediate transfers

10 MB Data exchanged before intermediarysynchronization updates

100 The multiplicative factor of reportedbytes in intermediary receipts

0.1 ε bound on reciprocation

Table 2: One hop reputation parameters and values usedin our evaluation.

long-term.In this section, we provide a threefold analysis of our

system to partially address these evaluation challenges.First, we describe the key parameters of our prototypeimplementation. These parameters control overhead,which we evaluate for our observed workload. Second,we use trace data to examine the coverage of one hopreputations; coverage distills many existing metrics forthe quality of reputation systems including bootstrappingtime, susceptibility to free-riding, and return on invest-ment. Finally, we report experimental results obtained onPlanetLab using a prototype implementation of our sys-tem that we have layered on top of the popular AzureusBitTorrent client. Our PlanetLab experiments measurethe real-world performance improvement that can be ob-tained by using the additional information one hop repu-tations provide.

4.1 Implementation parameters and overhead

Section 3 describes how reputation information is prop-agated and used by peers, but we have deliberately de-layed assigning several workload-dependent parametersto provide context. These parameters and the values as-signed in our prototype are listed in Table 2. We considerthe influence of each of these parameters.Top K set size: The exchange of top K sets serves twopurposes. First, it allows peers to agree on shared in-termediaries for data exchange. Second, it allows peersto quickly learn which intermediaries have wide cover-age (and are therefore most valuable). When K is large,peers have a higher chance of discovering shared inter-mediaries and information about intermediaries is prop-agated more rapidly. In our implementation, peers ex-change top K sets of size 2000. As each entry in the setis a 128 bit public key identifying an intermediary anda gossip bit, bidirectional exchange requires less than 64kilobytes of data per peer connection, a small fractionof the megabytes of object data typically transferred be-tween peer pairs.Synchronization, mediating intermediaries: The in-tersection of top K sets forms a set of possible intermedi-

Figure 9: Sizes of overlapping top K sets. Pairwiseoverlap gives the distribution of overlap sizes for ran-domly chosen pairs of peers in the BT-2 trace. Ofthese intersection sets, global overlap shows the numbershared with the top 2000 intermediaries overall.

aries that can facilitate indirect reciprocation. Of these,peers in our implementation select a random subset ofsize 10 to act as the mediators for the transfer. Clientssynchronize state with intermediaries after every 10 MBtransferred. This parameter controls the update burdenon the most popular intermediaries, a potential scalabil-ity bottleneck.

We measure the number of updates at popular inter-mediaries using our trace data. Total demand of the 14million peers in our trace, calculated by counting distinctpeers in each swarm and multiplying by swarm file size,is 26,752 terabytes (roughly 2 GB per user). Assum-ing perfect agreement and static membership in top Ksets, each of the most popular intermediaries will needto process 1.4 million updates

(26752 TB

2000×10 MB

). Updates

are signed and include a hash (16 bytes), timestamp (4bytes), 128 bit sender and receiver public keys (32 bytes),and bytes sent and received (16 bytes, 68 bytes total).These updates will be distributed over intermediaries,yielding an overhead of 3 MB per day for each popu-lar intermediary

(1.4 million×68 B

31 days

). In practice, individual

peers will differ in their views of the quality of interme-diaries, reducing load, and will also differ in their rela-tive share of total demand and hence update traffic. Also,data exchange between actively downloading peers willbe mediated by direct tit-for-tat after the initial exchange,further reducing load. Finally, the size of top K sets canbe increased if necessary to further distribute load.

4.2 One hop coverage

For our system to work well, the key factor is whether ornot the majority of interactions have a one hop basis forcomputing reputations. In short, do one hop reputationsprovide good coverage? We find that they do, arriving atthis conclusion using our BT-2 trace of peer interactionsto examine the number of overlapping peers in randomlychosen top K sets, assuming all peers use one hop repu-

Pairwise shared intermediary overlap with the top 2000 intermediaries

Figure 10: The distribution of intermediary overlapbetween the top 2000 intermediaries and 10 randomlychosen shared intermediaries between randomly chosenpeers. Mediating transfer through a small subset ofshared intermediaries suffices to provide wide coverage.

tations and the parameters of Table 2. Figure 9 shows thenumber of shared intermediaries between two randomlychosen peers with local histories built up according toour trace. This data indicates the amount of local historythat peers can build. Some users participate in only a fewswarms, while others participate in hundreds. Applyingone hop reputations provides a measure of both cover-age and convergence. Coverage is measured by pair-wise overlap among the top K sets of randomly matchedpeers. The median number of shared intermediaries is 83and more than 99% of peers have at least one commonentry in their top K sets. The most useful shared inter-mediaries are those with wide coverage, and we say thata top K set has converged if it overlaps with the mostwidely used intermediaries measured over the top K setsof all peers. For some long-lived peers that participate inmany swarms, convergence is high, but other peers par-ticipate in only a few swarms, limiting their view. Whenintermediaries with relatively limited coverage mediatetransfers, the potential for returns is diminished. For-tunately, our data shows that most randomly matchedpeers share several intermediaries that are among the2000 with widest coverage (Global overlap, Figure 9).

Most peers have several choices when deciding whichintermediaries to use to mediate their transfers. Using allavailable intermediaries or only several of the most pop-ular distributes the risk of choosing an intermediary withpoor coverage, but contacting potentially hundreds ofshared intermediaries per-peer increases overhead. Pop-ular intermediaries that become overloaded may refuseupdates from peers that generate too many. To avoidthis, we evaluate a default policy of randomly choos-ing a maximum of ten intermediaries from the sharedset for randomly paired peers. Section 4.1 describeshow this limit controls overhead. In Figure 10, we ex-amine whether good coverage can be maintained giventhis limit, finding that even when randomly subsam-pling shared intermediaries, most interactions will still

Figure 11: The number of top 2000 intermediaries ob-served by a new peer as a function of peers directly con-tacted, averaged over 100 trials with error bars showingthe 5th and 95th percentiles.

be mediated through several with wide coverage. 96% ofrandomly chosen peer pairs share an intermediary thatis among the 2000 most popular when randomly sub-sampling, with a median overlap of size 9.

In the remainder of this section, we describe the im-plications of high one hop coverage on three properties:bootstrapping time for new users, free-riding, and returnon investment for contributions.Bootstrapping new users: Coverage of popular inter-mediaries and convergence of top K sets controls thebootstrapping time of one hop reputations. The results ofFigures 9 and 10 demonstrate that agreement among topK sets is high, assuming local history built up accordingto our trace. This includes peers that have participated inthe system at least once. We next examine how quicklyone hop reputations can bootstrap new peers that have nolocal history. Bootstrapping a one hop reputation is a twostep process. First, clients need enough observations toascertain which intermediaries have high coverage. Sec-ond, they need to encounter peers that have establishedrelationships with high coverage intermediaries. We con-sider both aspects.

• How quickly can a new peer determine intermediaryvalue? We answer this question statistically usingtrace data. First, a new identity with an initially emptytop K set is created. Next, as in previous experiments,we use our trace data to build up representative topK sets for peers already in the system. We then sam-ple these top K sets randomly, integrating them withthat of the newly created identity using randomly as-signed weights drawn from our measured end-host ca-pacity distribution of BitTorrent peers. The results ofthis process are summarized in Figure 11, which givesthe number of entries in a new user’s top K set thatare shared with the 2000 most popular intermediariesglobally as a function of the number of peers observed.Data points are averaged over 100 trials with error barsshowing the 5th and 95th percentiles. These resultsdemonstrate the rapid bootstrapping of one hop rep-

Figure 12: For a new user, the number of peers observedhaving a direct or one hop relationship with the top 2000peers as a function of contacted peers.

utations under today’s workloads. After only a fewdozen interactions with randomly chosen peers, a newuser can identify intermediaries with wide coverage.

• How quickly can peers gain standing with popular in-termediaries? Simply identifying the value of inter-mediaries does not suffice to enable one hop trading.New peers must encounter and exchange data withpopular intermediaries directly or indirectly throughothers that have directly interacted with them. Fig-ure 12 gives the number of the top 2000 intermediariesin our trace encountered either directly or indirectlyby a new user as a function of the number of peersthe new user encounters. This data is a conservativebound since we do not model the transfer of standingwith the top intermediaries that would occur over time.As with Figure 11, we compute this data statistically,averaging over 100 trials. This data shows that peersobserve popular intermediaries either directly or indi-rectly frequently, allowing a new peer to quickly tradevia intermediaries with wide coverage.

Taken together, these results show that new users arelikely to both encounter an opportunity to gain standingwith a popular intermediary (Figure 12) and recognizethat opportunity (Figure 11).Free-riding: The coverage achieved by one hop reputa-tions for today’s workloads suggests that free-riding canbe deterred without the significant sacrifices in utiliza-tion required by schemes such as deficit 1 block-basedtit-for-tat. Because peers usually have a one hop basis formaking servicing decisions, the majority of each user’scapacity can be allocated to peers that can demonstratetheir contributions. However, we do not claim that onehop reputations prohibit free-riding, as selfish peers inlarge swarms may still be able to scavenge enough altru-istic excess capacity to complete file downloads. Rather,our goal is simply to limit the opportunities for effec-tive free-riding by providing peers with more informa-tion. Under today’s reputation systems, the random con-tributions that enable free-riding are necessary becauseobtaining information about good peers requires making

Figure 13: The number of mediating intermediariesfrom a randomly drawn one hop transfer encountered insubsequent interactions as a function of the number ofsubsequent interactions. A contributing peers sees higherreturns on investment if mediators are chosen that willreappear quickly. Error bars give the standard deviation.

contributions to all peers, beneficial or not.Return on investment: The return on investment forcontributed bytes is the amount of reciprocated bytesgenerated by that contribution. For reputations that per-sist over short time periods, as in BitTorrent’s tit-for-tat,return on investment is immediate and can be measuredor computed. For persistent reputation schemes, how-ever, return on investment can be a misleading measureof incentive strength. For instance, volume-based tit-for-tat maintains state regarding each contribution, providing1:1 returns on all contributions eventually if peers do notleave the system permanently and continue to make re-quests. But, as we observed in Section 2.4, repeat, directinteractions are extremely rare for today’s workloads,suggesting that peers would need to tolerate lengthy de-lays before receiving reciprocation. Particularly in P2Pnetworks, waiting for reciprocation opportunities damp-ens returns as some peer departures are permanent.

Because one hop reputations have persistent memory,we evaluate the returns from contribution in terms ofthe number of interactions required to recoup contributedbytes. Each time a peer contributes data due to indirect,one hop standing, that contribution is mediated througha subset of the shared intermediaries between sender andreceiver. The contributing peer earns reciprocation forthat contribution only if it later can use some of those in-termediaries to mediate another transfer where it acts asreceiver. A contributing peer will see poor returns if itselects a mediating intermediary that has poor coverage.

We use the one hop reputations for peers in our BT-2trace to compute the number of interactions required torepeat the use of an intermediary from the set mediat-ing a random initial contribution. Figure 13 shows re-sults averaged over 1000 trials with error bars showingstandard deviation. For each sample, we compute a size10 random subset of shared intermediaries between tworandomly drawn peers, interpreting this set as the me-

Figure 14: A comparison of performance for bulk filedistribution on PlanetLab. Leveraging the historical rateinformation provided by one hop reputations improvesperformance.

diating intermediaries in a potential transfer. We thenrepeat this process, computing the overlap between sub-sequent mediating sets and the original contribution set.Figure 13 shows that, on average, peers will encounter 8of the 10 initially used intermediaries within a few hun-dred peer interactions. Although this implies that returnsfor one hop contributions are not 1:1 for our default pol-icy, peers do see a higher opportunity for returns on con-tributions when compared with direct, long-term recip-rocation schemes that require tens of thousands of inter-actions before payback occurs, if at all.

4.3 Deployment on PlanetLab

Our evaluation thus far has focused on the ability of onehop reputations to promote strong contribution incentivesthrough wide coverage and returns on contribution, im-proving performance by providing users with a reason tocontribute more capacity. In this section, we focus on theconcrete performance improvement one hop reputationscan provide, regardless of strengthened incentives.

Because one hop reputations include not only an ac-counting of transfers but also the rate of those transfers(ref. Table 1), users can make intelligent decisions aboutwhich peers are likely to disseminate data rapidly. InBitTorrent today, peers do not maintain historical infor-mation about peer capacities and must rely on tit-for-tatto funnel data to high capacity peers. Unfortunately, highcapacity goes unnoticed by tit-for-tat when the data avail-able to trade is the limiting factor for performance, asis the case when a file first becomes available or whenseed capacity is limited. In both cases, quickly utilizingthe full capacity of the swarm depends on high capacitypeers receiving data first so they can quickly replicate it,reducing the amount of time required for other peers togain data to trade.

To measure the performance benefit realized by us-ing rate information, we deployed our prototype one hopreputation implementation on PlanetLab, comparing itsperformance with the original Azureus BitTorrent imple-

mentation on which it is layered. Figure 14 comparesthe completion times for 100 peers downloading a 25MB file using BitTorrent in one trial and one hop reputa-tions in the next with simultaneous arrivals in both trials.Before conducting the one hop download trial, we firstprimed the local histories of participants by distributinga different 25 MB file. We record the download timesrequired to download the second file while using the lo-cal history built up during the priming run. To adhere tothe skewed bandwidth distribution typical of end-hosts inBitTorrent swarms, we used application level bandwidthcapacity limits with values drawn from the percentiles ofthe end-host capacity distribution for BitTorrent clientsgiven in [12].

One hop reputations improve performance for roughly75% of PlanetLab hosts, providing a median reduction indownload time from 972 seconds to 766 seconds. Thisperformance improvement is attributable to the ability ofhistorical information to allow peers to quickly find goodtit-for-tat peerings. This is particularly true for the seed,which distributes data randomly in the reference imple-mentation of BitTorrent. Rather than relying on randomselection, a one hop seed can preferentially give data tousers it knows have high capacity. These peers amplifythe initial contributions of the seed, pumping data intothe systems rapidly and increasing utilization relative tothat of random selection, which may give initial data toslow peers that cannot quickly replicate it.

5 Related workOur focus on incentives has led us to build a protocollayer for exchanging peer reputation information, onethat can be shared across time and across content distri-bution applications. While incentives could be added toany content distribution system, it can be quite difficultto design a robust incentive system when participation isephemeral and identities are not persistent, as we haveseen in BitTorrent.

The research community has made considerableprogress towards understanding BitTorrent dynamics; weuse many of these insights in the design of our onehop reputation system. Qui and Srikant [15] analyti-cally model the BitTorrent protocol, showing that in cer-tain conditions, it achieves a Nash equilibrium. Unfor-tunately, our measurements show that these conditionsare typically not met in practice in live BitTorrent us-age. Bharambe et al. [2] use simulation to show thatBitTorrent engages in progressive taxation, taking fromhigh capacity peers to give unreciprocated bandwidthto low capacity peers. BitTyrant [12] exploits this ob-servation, showing that clients can strategically deploytheir upload bandwidth to significantly improve their lo-cal performance, and in the bargain, reduce performanceof the swarm. Locher et al. [11] and Sirivianos et al. [16]

made similar points, showing that BitTorrent providesweak protection against free riding clients. Our mea-surement results of BitTorrent in the wild are compati-ble with the results of those papers, expanding on previ-ous studies of only a subset of swarms with a large num-ber of active downloaders. Our data is broader, showingthat in most BitTorrent swarms incentives are inoperable.Wang et al. [18] and Tribler [13] argue for using thirdparty helpers to improve client performance in BitTor-rent. While we show that increased upload contribuiononly marginally improves download rates in BitTorrent,instead we generalize the notion of helpers, using onehop reputations to provide an incentive for third partiesto do work on behalf of others.

Our work has the most in common with recent work onthe design of reputation systems for various P2P applica-tions. Karma [17] focuses on building a robust, incentivecompatible distributed hash table as a basis for trading adigital currency. DHTs are a particularly difficult venuefor robust incentives, as peers are both ephemeral andhave little repeated interaction. To address this, Karmasets up a replicated system of banks on top of the DHTto serve as reputation authorities. In our one hop reputa-tion system, popular nodes serve as a kind of ad-hoc bankwithout any additional mechanism beyond peer gossip ofpopular nodes and signed receipts. Our use of indirectionis similar in some respects to EigenTrust [9] and multi-level tit-for-tat [21]. EigenTrust focused on the problemof inauthentic files, computing a global reputation forevery participant. Reputations in our system are local,and clients are free to evolve their strategy independentlyover time. Multi-level tit-for-tat demonstrated that muchof the value of EigenTrust can be achieved with only afew levels of indirection, an insight we use in the designof one hop reputations.

Finally, we observe that our protocol for propagatingreputations allows peers to make their own policy deci-sions, making it possible for peers to choose among poli-cies for allocating their bandwidth. As such, the one hopprotocol may also be able to incorporate a number of pre-viously proposed reputation systems, such as Bayesianestimation [3], PPay [20], PeerTrust [19], among oth-ers [5, 7]. However, we must leave the full explorationof these issues to future work.

6 ConclusionTo deliver on their potential benefits, P2P systems needrobust contribution incentives. In this paper, we have de-scribed the pitfalls undermining currently deployed in-centive strategies, finding that decisions based on di-rect observations and local history will not suffice toovercome the performance and availability problems onwhich today’s P2P networks falter. Our measurementsmotivate the design of one hop reputations, a protocol

for propagating reputations that extends the informationpeers have available for making servicing decisions. Wepropose a default policy for the use of this information,finding that for observed workloads, one hop reputationscan provide wide coverage and positive, long-term con-tribution incentives. Through deployment on PlanetLab,we show that one hop reputations can improve short-termdownload performance for peers as well.

AcknowledgmentsWe would like to thank the anonymous reviewers andour shepherd, Emin Gun Sirer, for their valuable feed-back. This research was partially supported by the Na-tional Science Foundation, CSR-PDOS #0720589.

References[1] E. Adar and B. A. Huberman. Free riding on Gnutella. First

Monday, October 2000.[2] A. Bharambe, C. Herley, and V. N. Padmanabhan. Analyzing and

improving a BitTorrent network’s performance mechanisms. InProc. of INFOCOM, 2006.

[3] S. Buchegger and J.-Y. L. Boudec. A robust reputation systemfor P2P and mobile ad-hoc networks. In Proc. of IPTPS, 2004.

[4] B. Cohen. Incentives build robustness in BitTorrent. In Proc. ofP2P-ECON, 2003.

[5] F. Cornelli, E. Damiani, S. D. C. di Vimercati, S. Paraboschi, andP. Samarati. Choosing reputable servents in a P2P network. InProc. of WWW, 2002.

[6] J. R. Douceur. The Sybil attack. In Proc. of IPTPS, 2002.[7] M. Gupta, P. Judge, and M. Ammar. A reputation system for

peer-to-peer networks. In Proc. of NOSSDAV, 2003.[8] T. Isdal, M. Piatek, A. Krishnamurthy, and T. Anderson. Lever-

aging BitTorrent for end host measurements. In Proc. of PAM,2007.

[9] S. D. Kamvar, M. T. Schlosser, and H. Garcia-Molina. The eigen-trust algorithm for reputation management in P2P networks. InProc. of WWW, 2003.

[10] A. Legout, N. Liogkas, E. Kohler, and L. Zhang. Clustering andsharing incentives in BitTorrent systems. In SIGMETRICS Per-form. Eval. Rev., 2007.

[11] T. Locher, P. Moor, S. Schmid, and R. Wattenhofer. Free Ridingin BitTorrent is Cheap. In Proc. of HotNets, 2006.

[12] M. Piatek, T. Isdal, A. Krishnamurthy, and T. Anderson. Do in-centives build robustness in BitTorrent? In Proc. of NSDI, 2007.

[13] J. Pouwelse, P. Garbacki, J. Wang, A. Bakker, J. Yang, A. Iosup,D. H. J. Epema, M. Reinders, M. van Steen, and H. Sips. Tribler:A social-based peer-to-peer system. In Proc. of IPTPS, 2006.

[14] H. Pucha, D. G. Andersen, and M. Kaminsky. Exploiting simi-larity for multi-source downloads using file handprints. In Proc.of NSDI, 2007.

[15] D. Qiu and R. Srikant. Modeling and performance analysis ofBitTorrent-like peer-to-peer networks. In Proc. of SIGCOMM,2004.

[16] M. Sirivianos, J. H. Parka, R. Chen, and X. Yang. Free-ridingin BitTorrent networks with the large view exploit. In Proc. ofIPTPS, 2007.

[17] V. Vishnumurthy, S. Chandrakumar, and E. Sirer. Karma: A se-cure economic framework for peer-to-peer resource sharing. InProc. of P2P-ECON, 2003.

[18] J. Wang, C. Yeo, V. Prabhakaran, and K. Ramchandran. On therole of helpers in peer-to-peer file download systems: design,analysis, and simulation. In Proc. of IPTPS, 2007.

[19] L. Xiong and L. Liu. Peertrust: Supporting reputation-based trustfor peer-to-peer electronic communities. IEEE Trans. On Knowl-edge and Data Engineering., 2004.

[20] B. Yang and H. Garcia-Molina. PPay: Micropayments for peer-to-peer systems. In Proc of CCS, 2003.

[21] Q. L. Yu. Robust incentives via multi-level tit-for-tat. In Proc. ofIPTPS, 2006.