1. Free-riding in BitTorrent Networks with the Large View Exploit Michael Sirivianos, Jong Han Park, Rex Chen and Xiaowei Yang University of California, Irvine Feb 26, 2007 @ IPTPS Feb 26, 2007 @ IPTPS

2. Why free-ride in BitTorrent?  Very successful P2P content distribution system  Built-in incentives for clients to upload positively correlates a client’s download and upload rates  BitTorrent users may still choose to free-ride If they can download as fast as protocol compliant clients Slow uplink, quota on outgoing traffic, less risk of legal action

3. Our contributions  Free-ride while maintaining high download rates Identify an effective free-riding exploit for BitTorrent Implement exploit in Enhanced CTorrent Experimental evaluation  Public swarms  ~300-leecher PlanetLab swarms

4. Outline  Motivation and contribution  BitTorrent overview  The exploit  Experimental evaluation  Related work  Conclusion and Future work

5. BitTorrent overview  File is divided into chunks (e.g. 256KB)  Seeders have all chunks of the file  Leechers have some or no chunks of the file

6. BitTorrent overview  Clients (seeders or leechers) contact the tracker  Tracker has complete view of the swarmViewSeeder Leecher A Leecher B Leecher C

7. BitTorrent overview Partial View Seeder Leecher B ViewSeeder Leecher A Leecher B Leecher C  Tracker sends partial view to clients  Clients connect to peers in their partial view

8. BitTorrent overview  Every 10 sec, seeders sample their peers’ download rates  Seeders unchoke 4-10 interested fastest downloaders

9. BitTorrent overview  Clients announce available chunks to their peers  Leechers request chunks from their peers (locally rarest-first)

10. BitTorrent overview  Rate-based tit-for-tat Every 30 sec, leechers optimistically unchokes 1-2 peers

11. BitTorrent overview  Rate-based tit-for-tat Every 30 sec, leechers optimistically unchoke 1-2 peers Every 10 sec, leechers sample their peers’ upload rates

12. BitTorrent overview  Rate-based tit-for-tat Every 30 sec, client optimistically unchokes 1-2 peers Every 10 sec, seeder samples its peers’ upload rates Leecher unchokes 4-10 fastest interested uploaders

13. Outline  Motivation and contribution  BitTorrent overview  The exploit  Experimental evaluation  Related work  Conclusion and future work

14. Large view exploit  Observations Seeders do not consider whether leechers upload to others Optimistic unchoking is generous (10 sec)  Modify client to exploit altruism Connect from and disconnect to tracker every 15 sec Repeatedly request and obtain a partial view Connect to all clients in the combined large view It is more likely to connect to seeders It is more likely to be optimistically unchoked by leechers

15. Outline  Motivation and contribution  BitTorrent overview  The exploit  Experimental evaluation  Related work  Conclusion and future work

16. Experimental evaluation  Evaluation goals: Determine effectiveness of the large view exploit Determine behavior of swarms as % free-riders increases  Performance metric File download completion time

17. Free-riding in public swarms  Methodology CTorrent free-rider and compliant (unmodified) leecher Compliant leecher connects to at most 50 peers Leechers download ~500MB-2GB files in ~50-650 client swarms Leechers run on two identical machines and in the same LAN Neither leecher is rate-limited Leechers simultaneously join the swarm

18. Free-riding in public swarms  In 12/15 swarms, free-rider does better than compliant client Swarm#seeders#leechers 13964 1491392

19. Free-riding in public swarms Swarm#seeders#leechers 13964 1491392  In 12/15 swarms, free-rider does better than compliant client

20. Free-riding in public swarms Swarm#seeders#leechers 13964 1491392  In 12/15 swarms, free-rider does better than compliant client

21.  Methodology BNBT Easy tracker, and CTorrent clients Clients download a 12MB file ~300 leechers rate-limited at 30KB/sec 1 initial seeder rate-limited at 120KB/sec Leechers remain online after download completion Compliant leechers connect to at most 50 peers Results collected over 10 runs Free-riding in PlanetLab-residing swarms

23.  Experiment 1: 100% compliant clients

24. Free-riding in PlanetLab-residing swarms  Experiment 1: 100% compliant clients  Experiment 2: 10% free-riders that connect to 50 peers only

25. Free-riding in PlanetLab-residing swarms  Experiment 1: 100% compliant clients  Experiment 2: 10% free-riders that connect to 50 peers only  10% free-riders do much worse than 90% compliant

26. Free-riding in PlanetLab-residing swarms  Experiment 1: 100% compliant clients  Experiment 2: 10% free-riders that connect to 50 peers only  10% free-riders do much worse than 90% compliant

27. Free-riding in PlanetLab-residing swarms

28.  Experiment 1: 100% compliant clients

29. Free-riding in PlanetLab-residing swarms  Experiment 1: 100% compliant clients  Experiment 2: 10% free-riders that employ large view exploit

30. Free-riding in PlanetLab-residing swarms  Experiment 1: 100% compliant clients  Experiment 2: 10% free-riders that employ large view exploit  10% free-riders do slightly better than 90% compliant

31. Free-riding in PlanetLab-residing swarms  Experiment 1: 100% compliant clients  Experiment 2: 10% free-riders that employ large view exploit  10% free-riders do slightly better than 90% compliant

32. Free-riding in PlanetLab-residing swarms  Experiment 1: 100% compliant clients  Experiment 2: 10% free-riders that employ large view exploit  10% free-riders do slightly better than 90% compliant  10% free-riders do slightly worse than 100% compliant

33. Free-riding in PlanetLab-residing swarms  Experiment 1: 100% compliant clients  Experiment 2: 10% free-riders that employ large view exploit  10% free-riders do slightly better than 90% compliant  10% free-riders do slightly worse than 100% compliant

34. Free-riding in PlanetLab-residing swarms

35.  60% free-riders do worse than 40% compliant Free-riding in PlanetLab-residing swarms

36.  60% free-riders do worse than 40% compliant Free-riding in PlanetLab-residing swarms

37.  60% free-riders do worse than 40% compliant  60% free-riders do much worse than 100% compliant Free-riding in PlanetLab-residing swarms

38.  60% free-riders do worse than 40% compliant  60% free-riders do much worse than 100% compliant Free-riding in PlanetLab-residing swarms

39.  60% free-riders do worse than 40% compliant  60% free-riders do much worse than 100% compliant  Free-riders are compelled to start uploading Free-riding in PlanetLab-residing swarms

40. Outline  Motivation and contribution  BitTorrent overview  The exploit  Experimental evaluation  Related work  Conclusion and future work

41. Related Work  BitThief (HotNets ‘06) Large view is central technique Random chunk scheduling instead of locally rarest-first We evaluate exploit in medium scale PlanetLab swarms  BitTyrant (NSDI ‘07) Connects to many peers too Does not free-ride Strategically selects per peer upload rates

42. Outline  Motivation and contribution  BitTorrent overview  The exploit  Experimental evaluation  Related work  Conclusion and future work

43. Conclusion  The large view exploit is effective A free-rider can achieve better or slightly worse download rates than protocol compliant clients  Selfish (rational) users may opt to free-ride Good download rates without utilizing uplink However, bad download rates when many free-riders in swarm

44. Future work – Is the exploit dangerous?  Can the exploit lead to ``tragedy of the commons” ? Until free-riders realize they obtain bad download rates  What if cooperative clients employ large view too? Not as altruistic (?)   Clients discover fastest peers and neglect slow ones Higher chunk announcement message overhead  More informed rarest-first chunk scheduling All clients get optimistically unchoked equally as often

45. Thank You! Technical report, source code and testbed scripts available at: www.ics.uci.edu/~msirivia/large-view Questions?

46. Why free-ride? 4 users sharing very slow uplink  Other reasons to not upload Access provider imposes quotas on outgoing traffic Reduce risk of legal action for unauthorized content distr.

47. Why free-ride?  Depends on user’s utility function Goal may not be to maximize download rate Goal may be to achieve a certain download rate, while minimizing uplink utilization

48. Future work - Address the exploit  View-limiting Tracker registers each client’s partial view Client is identified by IP Client has only N active peers in registered view  But, view can be obtained from peers too Peer Exchange, Trackerless BitTorrent  Connection verification Client A accepts connection from B A queries tracker whether B has A in its registered view If B does not have A in its registered view, A disconnects from B

49. Public Torrent Composition

50. Why free-ride?

51. Can whitewashing help free-riders?  CTorrent favors for optimistic unchoking Leechers with no chunks Leechers that have not been recently unchoked  Official BitTorrent selects leechers at random  Azureus favors leechers with less byte trade deficit  CTorrent modification to whitewash leechers Disconnect from and reconnect to leecher after being choked Suppress chunk announcements

52.  5% free-riders that don’t whitewash do almost as good as 5% free-riders that whitewash Whitewashing does not help free-riders

53.  5% free-riders that don’t whitewash do almost as good as 5% free-riders that whitewash

54. Whitewashing does not help free-riders  5% free-riders that don’t whitewash do almost as good as 5% free-riders that whitewash  CTorrent’s optimistic unchoking selection is more random than intended

55. Whitewashing does not speed up downloading  10% free-riders still do slightly better than 90% compliant  1% free-riders that whitewash complete in ~650 sec  1% free-riders that don’t whitewash complete in ~640 sec

56. CTorrent Unchoking  Every 10 secs gets the fastest n downloaders. It unchokes them, while it chokes all others, the non-interested and the slowest.  Every 30 secs, it selects the n-1 fastest downloaders and one peer that is not the fastest. It checks each interested peer one by one. The slowest uploader among the so far collected n-1 fastest peers and the new peer is replaced with the so far selected to be optimistically unchoked as follows: If slowest has no data, slowest is selected to be opt unchoked with 75% prob and the so far selected to be opt unchoked peer is selected with 25%. Otherwise, if slowest is choked and so far opt unchoked client is not, or if both are choked but slowest waited longer, or if both are unchoked but slowest had less time unchoked, slowest is selected as follows: slowest is selected if it has no data, or if so far opt unchoked has data, or with 25% prob. If none of the above applies the so far opt unchoked remains unchoked.  Whitewashing harms performance in general because it interferes with clustering of compliant peers. But it does not improve performance for FRs.

57. BitTorrent View Re-request  Official BT client by default allows 80 connections.  The BT code says that if the client accepts incoming connections it only requests view aggressively if clients are less than minpeers/3. if self.last_time > bttime() - self.config['rerequest_interval']: return if self.ever_got_incoming(): getmore = self.howmany() <= self.config['min_peers'] / 3 else: getmore = self.howmany() < self.config['min_peers'] if getmore or bttime() - self.last_time > self.announce_interval: self._announce() by default, minimum 300 sec between requesting view, rerequest_interval = 300 sec, self.announce_interval = 3600

58. BitTorrent modelled as IPD  Tit-for-Tat Cooperate at first round Do what the other player did in previous round  Tit-for-Tat is winning strategy When players do not know number of rounds  Tit-for-Tat not the best strategy When players know how many rounds will play Can play with many players Best strategy may be to defect after first round Obtain large portion of content without cooperating GET RID OF IT?