Do incentives build robustness in BitTorrent?

1. Do incentives build robustness in BitTorrent? Michael Piatek, TomasIsdal, Thomas Anderson, ArvindKrishnamurthy, ArunVenkataramani Szabolcs Nagy, ELTE IK, Prog. Terv. Mat. 2009.05.27.

2. Introduction • A fundamental problem with many peer-to-peer systemsis the tendency of users to “free ride” • Inearly p2p systems: • Napster: novelty factor => plentiful participation from peers • Kazaa: “incentivepriorities” - could be spoofed • BitTorrent:tit-for-tatreciprocitystrategyto provide positive incentives for nodes to contributeresourcestotheswarm

3. Robustness • Robustness requires that performance does not degradeif peers attempt to strategically manipulate the system • The tremendous success of BitTorrent suggests thatTFT is successful at inducing contributions=?> “incentivesbuildrobustnessinBitTorrent” • Average download times currently depend on significantaltruism from high capacity peers that, when withheld,reduces performance for all users • i.e., all peers regularly make contributionsto the system that do not directly improve their performance

4. Table of Contents • BitTorrent overview • Modeling altruism in BitTorrent • Building BitTryant: A strategic client • Evaulation • Conclusion

5. BitTorrent Protocol • Focuses on bulk data transfer • Initiallypeersdownload a metadata file, called a torrent • The torrentspecifies • the name and size of the file tobe downloaded • SHA-1 fingerprints of the datablocks (verifydataintegrity) • address of a tracker (coordinatesinteractions between peers participating in the swarm)

6. BitTorrent Protocol • Peers contact the tracker upon startup and departure aswell as periodically as the download progresses, usuallywith a frequency of 15 minutes • The trackermaintains a list of currently active peers and delivers a random subset of thesetoclients • Users in possession of the complete filearecalled seeds • Peers exchange blocks and control informationwith a set of directly connected peers we call the localneighborhood • control information: messagesindicatingthe data blocks they currently possess and messagessignalingtheir interest • We refer to the set of peers to which a BitTorrent clientis currently sending data as its active set

7. BitTorrent Protocol • A peer sends data tounchoked peers from which it received data most rapidlyintherecentpast • Also send data to asmall number of randomly chosen peers - optimisticallyunchoked • bootstrapnew peers into the TFT game, discovery • Peersthat do not send data quickly enough to earn reciprocationare removed from the active set - choked

8. BitTorrent Protocol • size of active set: proportional to the square root of upload capacity - in the official reference implementation • equal split rate: each peer provides an equal share of its availableupload capacity to peers to which it is actively sending

9. Measurement • BitTorrent’s behavior depends on a large number of parameters: • topology • bandwidth • block size • dataavailability • number of directly connected peers • churn • activeTFT transfers • number of optimistic unchokes • differentclientimplementations • => measurement study of live BitTorrent swarms to ascertain client characteristics

10. Measurement • The measurement client connected to a large number ofswarms and waited for an optimistic unchoke from each unique peer • Then estimated the upload capacity ofthat client using the multiQ tool

11. Measurement

12. Modeling altruism in BitTorrent • How much altruism is present, and what are the sources of altruism? • Answering is complicated => several assumptions to simplify our analysis • Representative distribution:High capacity peers tend to finish more quickly than lowcapacity peers, but they may also join more swarms simultaneously

13. Modeling altruism in BitTorrent • Uniform sizing:Peers, other than the modified client,use the active set sizing recommended by the referenceBitTorrentimplementation • No steadystate: over time TFT may matchpeers with similar equal split rates • Highblockavailability: in practice, static active set sizing in some clients maydegrade block availability for high capacity peers • These assumptions allow us to model altruism in terms of the upload capacity distribution only

14. Tit-for-tat matching time • The convergence properties of the TFT strategy • Reference client optimistically unchokes two peers every 30 seconds => peer can expect to explore two candidate peersand be explored by two candidate peers => estimate of how long a new peerwill have to wait before filling its active set with peerswithequalorgreaterequalsplitcapacity

15. Tit-for-tat matching time

16. Tit-for-tat matching time • In practice, convergence time is likely to be even longer • The long convergence time suggests a potentialsource of altruism: high capacity clients are forced topeer with those of low capacity while searching for better peers via optimistic unchokes

17. Probability of reciprocation • Reciprocation from Q to P is determined by two factors: • the rate at which P sends data to Q • the ratesat which other peers send data to Q • If all other peers inQ’s current active set send at rates greater than P, Q will not reciprocate with P

18. Probability of reciprocation

19. Probability of reciprocation • Beyond a certain equal split rate (14 KB/s), reciprocation is essentially assured, suggestingthat further contribution may be altruistic

20. Expected download rate • A peer P receives data from both TFT reciprocation and optimistic unchokes • Reciprocation is possible only from those peers in P’s active set and dependson P’s upload rate, while optimistic unchokes maybe received from any peer in P’s local neighborhood, regardless of upload rate

21. Expected download rate

22. Expected download rate • The sub-linear growth suggests significant unfairness in BitTorrent • 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

23. Expected upload rate • Two factors can control the uploadrate of a peer: data availability and capacity limit • Itis crucial that a client downloads new data at a rate fastenough, so that the client can redistribute the downloadeddata and saturate its upload capacity • This is the case in the reference BitTorrent clientbecause of the square root growth rate of its active setsize

24. Expected upload rate • Popular clients: active set size is a configurable, but static, parameter • default is far lower than is required for high capacity peers

25. Modeling altruism • Two perspectives: • consider altruism to be simply the difference between expectedupload rate and download rate • any upload contribution that can be withdrawnwithout loss in download performance

26. Modeling altruism

27. Modeling altruism

28. Modeling altruism • The latter figure suggests that all peers make altruistic contributions: • low bandwidth peers almost never earn reciprocation • high capacity peers send much faster than the minimal rate required for reciprocation • Both of these effects can be exploited

29. Validation • At least part of the altruismin BitTorrent arises from the sub-linear growthof download throughput as a function of upload rate • Validating this key result using the measurement data:By averaging the rate of have messagesinfer the peer’s download rate • These results indicate an even higher level of altruismthan that predicted by the model

30. Building BitTyrant: A strategic client • Protocol redesign:Majority of Bit-Torrent users benefit from its unfairness today. Designsintended to promote fairness globally at the expense ofthe majority of users seem unlikely to be adopted • Rather focus on BitTorrent’s robustness to strategic behavior

31. Building BitTyrant: A strategic client • Optimized for strategic users • Performance for low capacity peers is high =>strategic user can simply exploit this • by masquerading as many low capacity clients • by flooding the local neighborhood of high capacity peers (dominating the active transfer set) • Common option to refuse multiple connections from a single IP address

32. Maximizing reciprocation • Maximize reciprocation bandwidth per connection: • a node can improve its performanceby finding peers that reciprocate with highbandwidth for a low offered rate • Maximize number of reciprocating peers: • expand until benefit of an additional peer is outweighed by the cost of reduced reciprocation probability from other peers

33. Maximizing reciprocation • Deviate from equal split: • on a per-connection basis, aclient can lower its upload • If the equal split capacity distribution of the swarm isknown, we can derive the active set size that maximizes the expected download rate

34. Maximizing reciprocation

35. Maximizing reciprocation • BitTyrantdynamicallymodifiesthe size and membership of the active set and theupload bandwidth allocated to each peer • Foreachpeer p, BitTyrant maintains estimates of: • the upload raterequired for reciprocation, Up • the downloadthroughput, Dp, received when p reciprocates • Peers areranked by the ratio Dp/Up and unchoked in order until thesum of up terms for unchoked peers exceeds the uploadcapacity of the BitTyrant peer

36. Maximizing reciprocation • Implicit assumptions and characteristics: • unchoking the most altruistic peers: it will continue to unchoke peers until it exhausts its upload capacity • the strategy can be easily generalized to handle concurrent downloads from multiple swarms • the strategy attempts to maximize the download ratefor a given upload budget, but in practice Dp and upload cost Up are not known a priori

37. Maximizing reciprocation • We initialize Up based on the distribution of equal split capacities seenin our measurements, and then periodically update it dependingon whether p reciprocates for an offered rate • Use small multiplicative factors since the spread of equal split capacitiesis typically small in current swarms

38. Maximizing reciprocation

39. Estimatingreciprocationbandwidths • Considertheaverage download rate over a TFT round • Forpeersthathave not uploaded any data to the BitTyrant client: • measuring the frequency of block announcementsfrom p => estimate of p’s download rate, which we use as an estimateof p’s total upload capacity • thendividetheestimated capacity by the Azureus recommended activesetsize • Itis likely to overestimate the upload capacitiesof unobserved peers, serving to encourage their selection

40. Sizing the local neighborhood • Clients maintain a pool of typically 50–100 directlyconnectedpeers • Willnot be large enough to maximize performance for high capacitypeers • Requestas many peers as possible from the centralizedtracker at the maximum allowed frequency • DHT: distributed tracker that provides peer information and isindexed by a hash of the torrent • Fortunately, the overhead imposed by maintainingadditionalconnections is modest

41. Additional cheating strategies • Not implemented in BitTryant - can be thwarted by simple fixes to clients • Exploiting optimistic unchokes: • Azureusmakes a weighted randomchoice that takes into account the number of bytes exchanged with a peer • can exploit this by disconnecting and reconnecting • becomes ineffectiveif clients maintain the IP addresses

42. Additional cheating strategies • Downloadingfromseeds: • inearlyversionsseedsuploadto peers that are the fastest downloaders • falsify download rate by emitting ‘have’ messages • more recentversions: unchokesrandomly • Falsifyingblockavailability • can appear to be more attractive, increasethechances of being unchoked • onlyshort-termbenefit and a client is likely to consider most of itspeersinteresting

43. Evaluation • Two separate evaluations: • on real swarms drawn from popular aggregation sites to measure realworld performance for a single strategic client • PlanetLab: • revisit these results, evaluate sensitivity to various upload rates • what would happen if BitTyrant is universally deployed

44. Single strategic peer • Selectingtorrents: • crawledpopularBitTorrentaggregationwebsites • ignoring swarms distributing files larger than 1 GB • sizes ranging from 300–800 peers • Simultaneously joined each swarm with a Bit-Tyrant client and an unmodified Azureus (defaultsettings) • imposed a 128 KB/s uploadcapacity limit • The median performance gain for BitTyrant is afactor of 1.72 with 25% of downloads finishing at leasttwice as fast with BitTyran

45. Single strategic peer

46. Single strategic peer • These results provide insight into the performanceproperties of real BitTorrent swarms, some of which limitBitTyrant’seffectiveness: • to some extent, performance canbe based on luck with respect to the set of initial peersreturned • Forinstance, inBitTyrant’sworst-performing swarm, only three peers had averageequal split capacities greater than 10 KB/s. In contrast,the unmodified client received eight such peers. Totaldownload time was roughly 15 minutes, the typical minimumrequest interval for peers from the tracker

47. Single strategic peer • a swarm’s aggregate performance can be controlled by data availabilityrather than the upload capacity distribution • simply not be enough available data for peers to saturate their upload capacities • These scenarios can hinder the performance of BitTyrant, but they account for a small percentage of our observed swarms overall

48. Single strategic peer - PlanetLab • To cope with restrictions, relevant experimental parameters such as file size, initialunchoke bandwidth, and block size, upload capacity are scaled by 1/10th • each node’s BitTyrant client disconnected immediately upon completion and reconnected immediately

49. Single strategic peer - PlanetLab

50. Single strategic peer - PlanetLab • As the model suggested the highest capacity peers mayrequire several hundred available peers to fully maximize throughput due to reciprocation • Low capacity peers can still improveperformance with strategic peer selection