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: Uniform sizing: No steady state:
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 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.