Simplified Explanation of “Do incentives build robustness in BitTorrent?”

1. Simplified Explanation of “Do incentives build robustness in BitTorrent?” By James Hoover

2. What will we be looking over? • Overview of motivation • Brief look at BitTorrent • Define key terms used. • Look at measurements taken for later use. • Look at altruism/sources of improvement in BitTorrent • The strategic client BitTyrant • BitTyrant performance • Single client • Real world • PlanetLab • Many clients • All strategic • All selfish • Conclusion

3. Motivation • BitTorrent’s tit-for-tat (TFT) discourages free-riders • It is widely believed that the incentives provided by TFT have built robustness in BitTorrent. • Questioning of the above belief led to the development of a simple model of BitTorrent. • Using this model a significant altruism was discovered In BitTorrent. • All of this led to the question of whether a strategic peer can significantly improve its download rate without changing its upload contribution. • In addition… • Previous studies often used simulated settings that were unrealistic.

4. On to BitTorrent… • Key terms you need to know… • Altruism: Difference between upload and download rates. • Local Neighborhood: A set of directly connected peers which exchange blocks of data and control information. • Obtained via tracker. • Unstructured and random. • Active Set: Current set of peers to which a BitTorrent client is sending data. • Equal Split Set: Each peer provides an equal amount of its upload capacity to each member of its active set. • This varies between client implementations.

5. Difficulty of Measuring BitTorrent’s Behavior • BitTorrent’s behavior is dependent on topology, bandwidth, clock size, churn, data availability, number of directly connected peers, active TFT transfers, and number of optimistic unchokes. • Vary between different client implementations. • May be overridden by user configuration. • Not easy to simulate a real swarm due to this diversity. • Solution: Measure using real swarms.

6. Measurement Data • Used opportunistic measuring techniques upon real swarms. • Connected to a large number of swarms and waited for oppertunistic unchokes. • Used something called the “multiQ tool” estimate the upload rates of clients. • Over a 48 hour period in April ’06 they observed: • 301,595 unique IPs • 3,591 ASes • 160 different countries • Following upload capacities shown in Figure 1. • Implementation distribution shown in Table 1.

7. Figure 1

8. Table 1

9. Altruism in BitTorrent • How much and where does it come from? • Simplified these questions by creating a model based on the observer capacity distribution and assuming the default settings for the “Reference” implementation. • They point out that this is not meant to be predictive but rather just a suggestion of possible altruism sources.

10. Sources • Representative distribution: • High capacity peers tend to finish more quickly and have the resources to join multiple swarms simultaneously. • If a high capacity peer joins only one swarm and leaves upon completion the proportion of low capacity peers increases throughout the lifetime of the swarm. • Uniform sizing: • Aggressive active set sizes tend to lower altruism. • The “Reference” implementation was the most aggressive of the implementations observed. • Due to this the model represents a conservative altruism estimate. • No steady state: • With low churn TFT may match peers of close equal split rate which biases active set draws. • Later shown that BitTorrent is slow to reach a steady-state and is especially slow for high capacity peers. (Shown in Figure 2) • High block availability: • Static active set size set by some clients may lower block availability for high capacity peers.

11. TFT matching time • Figure 2 shows a possible source of altruism in that high capacity clients must take on low capacity peers while they search for better peers using optimistic unchokes. • Typically optimistic unchokes happen at a frequency of two every 30 seconds. • To be “content” with a peer that peer must have equal or greater equal split. • May lose peers you are “content” with when those peers find other peers with a higher split. • Example given: 6,400 KB/s upload capacity client would transfer more than 4GB before reaching a steady-state.

12. Figure 2

13. Reciprocation • Data is only sent to those peers in your active set. • This active set is reevaluated every 10 seconds. • Another source of possible altruism can be seen in Figure 3. • Figure 3 shows that at a split rate of approx. 14KB/s reciprocation is very, very likely. • Anything past this can be seen as altruism.

14. Figure 3

15. Yet another source of altruism… • One would hope that since a high capacity client has a higher upload capacity that such a client would gain the benefit of having a higher download rate. • However… Figure 4…

16. Figure 4

17. Quick Note on Upload Rate • A peer’s upload contribution is not only limited by its upload rate but also by data availability. • When a peer does not have enough data of interest in its local neighborhood its upload capacity goes to waste. • Many popular client implementations use configurable, static active set settings that hurt performance for high capacity clients. (Azureus has a default active set size of 4)

18. Two more Figures on Altruism… • Figure 5 shows altruism when it is defined as “the difference in expected upload rate and download rate”. • Figure 6 shows altruism when it is defined as “any upload contribution that can be withdrawn without loss in download performance”.

19. Figure 5

20. Figure 6

21. Validating Altruism Observations • The model showed that at least some of the altruism present in BitTorrent was due to the sub-linear growth of download rate as a function of upload rate (Figure 4). • To confirm this they measured the number of ‘have’ messages by a peer over the time that peer was observed. • Figure 7 shows the results of the data drawn from 63,482 peers. • The figure shows an even higher level of altruism that they had predicted.

22. Figure 7

23. BitTyrant • BitTyrant is a strategic client which exploits the presence of altruism. • Based off of the Azureus client in order to foster adoption. • Focused on strategies for increasing performance that an average user could use. • Such strategies include masquerading as multiple low capacity peers and flooding the local neighborhood of high capacity peers. • Does not include coordinating multiple IPs.

24. Maximizing Reciprocation • Three strategies: • Find peers that reciprocate high bandwidth for low offered rates by finding peers with high upload capacity and smaller active sets. • Expand the active set until the benefit gained from adding another peer is outweighed by the lose of reciprocation bandwidth from those already in the set. • Determine what upload contribution to give on a per-connection basis. Give just enough to receive reciprocation and spend the saved upload bandwidth on new connections. • Example: A client with an equal split capacity of 100 KB/s can reduce its rate to 15KB/s and only lose 1% off the probability that it will be reciprocated. However, going from 15KB/s to 10KB/s loses 40%.

25. Figure 8

26. BitTyrant Unchoking

27. Local Neighborhood Size • Typical BitTorrent local neighborhoods are made up of 50 – 100 peers. This number may be too low for high capacity clients. • BitTyrant requires as many peers as possible from the tracker at the maximum allowed frequency. • This requires increased protocol overhead but has been show to only increase from 0.9% of total file data received to 1.9%.

28. Not implemented exploits • Exploiting opportunistic unchokes • Downloading from seeds by falsifying your download rate • Falsifying block availability • These can be stopped with simple client fixes.

29. Evaluating Performance • Single BitTyrant client, single Azureus client. • Real swarms. • Ignored distributing files larger than 1GB. • Swarms were typically for recently released files. • Size ranged from 300 - 800 peers with some having up to 2,000. • Set 128KB/s upload capacity limit • Median performance gain for BitTyrant over default Azureus was a factor of 1.72. • 25% of downloads finished twice as fast. • Showed that BitTyrant’s performance can be hindered by random sets of peers which contain almost all low capacity clients. • Also, BitTyrant was shown to be susceptible to low data availability.

30. Figure 10

31. More Evaluating… • Single BitTyrant client, single Azureus client • PlanetLab • Application layer bandwidth caps • Scaled by 1/10th upload capacity, file size, initial unchoke bandwidth, and block size due to PlanetLab sharing bandwidth between experiments. • Showed that BitTyrant… • both improves performance and gives more consistent performance • Can find the point of diminished returns for high capacity peers • Benefits low capacity peers through strategic peer selection • Was consistent across multiple trials • Yet another Figure…

32. Figure 11

33. More… Evaluating… • 350 nodes • PlanetLab • Scaled distribution simultaneously joining a swarm distributing a 5 MB file with combined seed capacity of 128 KB/s. • Peers depart upon completing the file. • Expected a degradation of performance since high capacity peers could finish quickly and leave. • Actually increased performance and altruism. • High capacity peers require many connections. • Lowered bootstrap time. • Another… Figure…

34. Figure 12

35. Selfish Peers • A peer is said to be selfish if it does not contribute excess upload capacity that does not improve performance. • Can arise when a client is part of multiple swarms or uses that bandwidth for something other than BitTyrant. • BitTyrant’s unchoking algorithm transitions well with clients partaking in multiple swarms. • Instead of allocating bandwidth by swarm it allocates by connection.

36. Evaluating Selfishness • Repeat of previous PlanetLab experiment. • Capped all high capacity peers upload rate to 100 KB/s. (point of diminished returns in Figure 11) • Did decrease average performance. • Decreased more so for low capacity clients. • Average completion time for low end peers went from 314s to 733s. • Average completion time for peers with 100 KB/s capacity went from 108s to 190s. • BitTyrant tends to spread capacity over low end peers which could cause inefficiency due to TCP overhead. • To combat this BitTyrant advertises itself using the Peer ID hash at connection time. BitTyrant peers recognize each other and switch to a block-based TFT which then ramps up send rates. This maintains faireness while requiring fewer connections.

37. Conclusion • TFT does discourage free-riding. • BitTorrent’s performance has little to do with TFT and the dominating factor is instead altruistic contribution. • Selfish peers with even modest resources can reduce their contribution yet still improve their download performance. • BitTorrent is effective simply because most users do not stray from default values and do not try to cheat. • Still unclear whether selfish peers will hurt swarm performance in practice. • Still unknown whether incentives truly build robustness in BitTorrent.