1. Alex Sherman Jason Nieh Cliff Stein

2.  Lack of fairness in bandwidth allocation in P2P systems:  Users are not incentivized to contributed bandwidth  Proliferation of free-riders  No QoS guarantee (for file-sharing, live streaming)

3.  No central entity that controls resources  Bandwidth resources are geographically distributed  The amount of resources not know in advance  Resources may very over time

4.  Background / Related Work  Proposed algorithm: FairTorrent  Evaluation

5.  Free-riding inherent to P2P systems. (e.g. In Gnutella 70% of users do not contribute [Adar, 2000])  BitTorrent: introduces tit-for-tat  File is split into “chunks” that peers file-share  Tit-for-tat: a peer reciprocates by uploading to: N-k peers with the best download rate + k optimistically selected peers  Eventually fair under some static workloads ( Legout [SIGMETRICS ’07], Srikant [SIGCOMM ’04])

6.  BitTorrent tit-for-tat can be exploited:  LargeView, Sirivianos et.al.[IPTPS ’07]  BitTyrant, Piatek, et.al [USENIX ’07]  Free-riding, Locher,et.al [HotNets ’05]  Causes:  Long discovery times of like-peers  Optimistic unchoking  Unstable peering relations

7.  Reputation-based systems (e.g. Eigentrust)  Problem with collusion, bootstrapping  Does not translate to fairness  Credit-based systems (eg. Dandelion, Karma)  Heavy management overhead (eg. Credit Service)  Does not guarantee real-time fairness (e.g. if I rack up credit I can free-ride)

8.  Block-based TFT ( Bharambe [INFOCOM ’06], Pai [’04], Jun [EP2PS ’05])  Upload to any peer as long as:  upload – download < constant threshold  Bharambe, Pai: under-utilization of capacity. Fix: split peers based on bandwidth (hard to achieve)  Jun: many complex tuning parameters

9.  FairTorrent: a packet-based scheduling algorithm that achieves fair-bandwidth allocation among peers in a file-sharing swarm, while maximizing capacity utilization.  Built on top of BitTorrent

10.  Terminology  Leechers: peers that are still downloading data  Seeds: peers that only serve data  Each Leecher L_i:  Keeps track of a deficit variable DF_ij with each leecher L_j  DF_ij = Send_ij – Recv_ij  Schedules to send the next packet to a leeacher L_j with the smallest deficit: DF_ij  Each Seed schedules packets using Round- Robin

11.  Fast Convergence of data exchange rate between a pair of leechers  Fast Convergence of a leecher’s total upload rate to its download rate from other leechers  Small standard deviation of download rate  Leads to fairness and predictabled download times  Maximizes capacity utilization

12.  Leechers L_1, L_2, and L_3 with upload capacities 3, 2 and 2 respectively  Upload rates under “equal-split” (left), and fairtorrent (right).

13.  BitTorrent client “unchokes” k peers at a time – allowes these peers to request data  FairTorrent: “unchokes” any peer that may request data

14.  Instantaneous Service Error (of Leecher L_i)  Maximum Instantaneous Service Error

15.  Assumptions: 1) Peers always have data to exchange 2) ( = upload rate of leecher i)  Hypothesis:  (n = # of nodes, p = packet size)  Proof for the 3-node case. Similations / empericals results for the general case.

16.  Requires:  No apriori knowledge or measurements of peers’ bandwidth  No centralized management  No special tuning parameters  No change to BitTorrent Protocol

17.  Implemented FairTorrent on top of BitTorrent python client  Instrumented FairTorrent, BitTorrent, Azureus, BitTyrant to measure service error, performance  Ran tests on the PlanetLab to compare FairTorrent with other clients

18.  32 MB file  10 seeds upload at 25 KB/s  50 leechers  Uniform Distribution (1-50 KB/s)  Skewed Distribution (1 high uploader)  BiModal Distribution (high uploaders, free-riders)  Ran 5 tests for each network (FT, BT, AZ, TY)  Mixed Networks

21. FairTorrent BitTorrent BitTyrantAzureus

23. FairTorrent BitTorrent BitTyrantAzureus

24.  FairTorrent: 1347, BitTorrent: 1892, Azureus: 1849, BitTyrant: 2266 (FT completes 37-68% faster)

25.  FairTorrent exhibits low standard deviation (1.8 KB/s on average)

26.  One high uploading leecher: at 50 KB/s  49 low uploading leechers: at 1-5 KB/s  Ran 5 tests for each of the 4 networks  Ran 5 tests replacing the high uploader with FairTorrent in BitTorrent, Azureus and BitTyrant

27.  FairTorrent (555KB); BitTorrent (51MB), Azureus(31 MB); BitTyrant (113 MB)

28. High uploader completes in 3-5 times faster in FairTorrent

29.  25 high uploaders: 40-50 KB/s  25 free-riders: 0-3 KB/s

32.  Test duration: 7500 seconds  Nodes arrive in 5 second intervals  Upon completion nodes re-join with a clean cache + fresh identity  10 permanent seeds ( 50 KB/s)  100 leechers that leave and re-join

34. FairTorrentAzureus

35.  New algorithm for fair bandwidth allocation

36.  Instrumented all clients to measure service error / fairness and performance  Measured service error, performance, etc  Parameters:  50 leechers with various upload capacities (up to 50KB/s) selected from various distributions: uniform, bimodal, skewed  10 seeds upload at 25 KB/s  Download of a 32MB file

37.  EM was an order of magnitude smaller in the case of FairTorrent (under 1MB)  Completion time of all clients: 40% faster under FT  Bandwidth utilization 95.3% for FairTorrent vs. 82.8% to 93.7% for other clients

38.  Extend FairTorrent to a case where peers participate in multiple downloads (or multiple swarms)  Extend BitTorrent to leverage multiple swarms and FairTorrent for a more optimal bandwidth allocation across swarms