FairTorrent: Bringing Fairness to Peer-to-Peer Systems - PowerPoint PPT Presentation

1 / 38
About This Presentation
Title:

FairTorrent: Bringing Fairness to Peer-to-Peer Systems

Description:

FairTorrent Azureus New algorithm for fair bandwidth allocation Instrumented all ... peers to request ... Completion Time Dynamic Tests Max ... – PowerPoint PPT presentation

Number of Views:105
Avg rating:3.0/5.0
Slides: 39
Provided by: AlexSh9
Category:

less

Transcript and Presenter's Notes

Title: FairTorrent: Bringing Fairness to Peer-to-Peer Systems


1
FairTorrent Bringing Fairness to Peer-to-Peer
Systems
  • Alex Sherman
  • Jason Nieh
  • Cliff Stein

2
Problem
  • 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 traditional solution
  • 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
Outline
  • Background / Related Work
  • Proposed algorithm FairTorrent
  • Evaluation

5
Background
  • 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
Background (slide 2)
  • 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
Background (slide 3)
  • 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
Background (slide 4)
  • Block-based TFT (Bharambe INFOCOM 06, Pai
    04, Jun EP2PS 05)
  • Upload to any peer as long as
  • upload download lt constant threshold
  • Bharambe , Pai under-utilization of capacity.
    Fix split peers based on bandwidth (hard to
    achieve)
  • Jun many complex tuning parameters

9
Proposed Solution FairTorrent
  • 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
FairTorrent Algorithm Definition
  • 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
FairTorrent Achieves
  • Fast Convergence of data exchange rate between a
    pair of leechers
  • Fast Convergence of a leechers 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
Example
  • 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
Unchoking Behavior
  • BitTorrent client unchokes k peers at a time
    allowes these peers to request data
  • FairTorrent unchokes any peer that may request
    data

14
Measure of Fairness
  • Instantaneous Service Error (of Leecher L_i)
  • Maximum Instantaneous Service Error

15
Hypothesis
  • Assumptions
  • Peers always have data to exchange
  • ( 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
FairTorrent Implementation
  • Requires
  • No apriori knowledge or measurements of peers
    bandwidth
  • No centralized management
  • No special tuning parameters
  • No change to BitTorrent Protocol

17
Methodology
  • 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
Test Parameters
  • 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

19
Max Service Error
20
FairTorrent Rate Convergence
21
Rate Convergence Comparison
BitTorrent
FairTorrent
BitTyrant
Azureus
22
FairTorrent Utilization
23
Utilization Comparison
BitTorrent
FairTorrent
BitTyrant
Azureus
24
Worst Completion Time (seconds)
  • FairTorrent 1347, BitTorrent 1892, Azureus
    1849, BitTyrant 2266 (FT completes 37-68 faster)

25
Standard Deviation
  • FairTorrent exhibits low standard deviation (1.8
    KB/s on average)

26
Skewed Distribution
  • 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
Max Service Error
  • FairTorrent (555KB) BitTorrent (51MB),
    Azureus(31 MB) BitTyrant (113 MB)

28
High Uploader Completion Time
  • High uploader completes in 3-5 times faster in
    FairTorrent

29
Bi-modal Distribution
  • 25 high uploaders 40-50 KB/s
  • 25 free-riders 0-3 KB/s

30
High Uploaders E_max
31
High Uploaders Completion Time
32
Dynamic Tests
  • 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

33
Max Service Error
34
Completion Times
FairTorrent
Azureus
35
Conclusions
  • New algorithm for fair bandwidth allocation

36
Evaluation Parameters
  • 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
Preliminary Results (uniform distribution)
  • 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
Proposed Extensions
  • 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
Write a Comment
User Comments (0)
About PowerShow.com