Contribution Incentives for BitTorrentlike Systems

1
Contribution Incentives for BitTorrent-like
Systems

• Nikitas Liogkas
• RÉSCOM 2008
• Saint-Jean-Cap-Ferrat, France
• June 19, 2008

2
Peer-to-Peer Protocols

• structured (Chord, Pastry, Tapestry)
• deterministic mapping data object ? node
• provide lookup guarantees

• unstructured (Gnutella, Kazaa)
• responsibility for data objects not
  pre-determined
• used in popular real-world systems, but suffer
  from extensive free-riding e.g., Adar Huberman
  2000

• hybrid (BitTorrent)
• utilize a centralized control server
• have been shown to be effective in content
  distribution

3
BitTorrent

• incorporates contribution incentives that aim to
  limit free-riding
• fairness those who do not upload to others
  should not be able to receive good service
• robustness in the presence of small numbers of
  free-riders, the system should still provide
  satisfactory service to compliant nodes

• experimental, analytical, and simulation studies
  have attempted to explain BitTorrents success

4
Goals

• Examine how contribution incentives for hybrid
  peer-to-peer systems should be designed

• two subgoals
• understand BitTorrents incentives and how they
  affect peer behavior
• extensive experiments addressing limitations of
  other studies, both on private and public
  BitTorrent sessions
• extend results to a different application
  scenario
• design contribution incentives spanning multiple
  dimensions for another hybrid peer-to-peer system

5
P2P storage for Web applications

• Web applications increasingly popular, but user
  content is currently confined within a single
  application, making data sharing cumbersome

• push storage responsibilities from the
  application provider to clients
• Cloudfarm enables end hosts to store their
  content on other clients
• requires more complex incentives than content
  distribution
• BitTorrent bandwidth only
• Cloudfarm bandwidth, round-trip latency,
  availability, long-term storage

6
Contributions

• BitTorrent incentives
• facilitate formation of clusters of peers with
  similar upload bandwidth
• discourage free-riding by rewarding contributors

• BitTorrent robustness
• identified three selfish BitTorrent exploits and
  showed limitations of BitTorrents incentives
• identified sources of BitTorrents robustness and
  proposed corresponding design principles

• Cloudfarm
• designed and implemented a prototype
• showed that its incentive scheme is effective in
  motivating contributors and that its performance
  acceptable

7
Presentation Outline

• BitTorrent operation and algorithms
• BitTorrent contribution incentives
• BitTorrent robustness
• Cloudfarm

8
Internet content distribution
tracker
client/server model
BitTorrent model

• tracker centralized server that keeps track of
  participating nodes and aids node bootstrapping
• seeds have the entire content
• leechers still downloading (not necessarily
  free-riders)

9
BitTorrent joining a torrent
metainfo file
peer set
join
datarequest
1. obtain the metainfo file
2. contact the tracker
3. obtain a peer set (contains seeds leechers)
4. contact peers in this set for data
10
BitTorrent downloading data
I have
? download data subpieces in parallel
? verify pieces using SHA-1 hashes in
metainfo file
? advertise received pieces to the entire peer set
? download the rarest pieces first
11
BitTorrent contribution incentives
? prefer to upload to those that upload to you
(tit-for-tat)
? regular unchokes leechers calculate download
rates from others periodically, and only
upload to the fastest
? optimistic unchokes periodically select a peer
at random and upload to it, hoping it will
reciprocate
12
Presentation Outline

• BitTorrent operation and algorithms
• BitTorrent contribution incentives
• BitTorrent robustness
• Cloudfarm

13
Experimental methodology

• hypotheses
• clustering of similar-bandwidth peers (supported
  by the analytical model of Qiu et al.
  SIGCOMM04)
• effectiveness of BitTorrent incentives those who
  upload to others receive better service

• experimental setup
• single initial seed, 40 (instrumented) leechers
  on PlanetLab, who disconnect after completion
• limited upload, unlimited download bandwidth

• peer types
• three leecher classes slow 20 kB/s, medium
  100 kB/s, fast 200 kB/s
• initial seed well-provisioned 200 kB/s and
  underprovisioned 100 kB/s

14
Well-provisioned initial seedClustering

• peers prefer to upload to others in the same class

• clustering index ratio of regular unchokes to
  peers in a given class over total number of
  regular unchokes

15
Well-provisioned initial seedContribution
incentives

• BitTorrent incentives are indeed effective
  fastleechers complete download much sooner than
  the rest

• good performance upload utilization is high

16
Underprovisioned initial seedClustering

• no discernible clustering of peers in the same
  class

• fast leechers do not find enough pieces of
  interest at other fast peers start
  interacting also with medium / slow peers,
  breaking any clusters that might be starting to
  form

17
Underprovisioned initial seedContribution
incentives

• incentives make no difference most leechers
  finish around the same time, regardless of
  contributions

• performance still good faster peers assist
  slower ones in completing their download

18
Multiple-seed scenarios

• multiple seeds or non-disconnecting leechers
• aggregate seed upload capacity less than that of
  the fastest leechers similar to a single
  underprovisioned seed

• at least one of the seeds faster than the fastest
  leechers similar to a well-provisioned seed

• when aggregate seed capacity higher than that of
  the fastest leechers, but all seeds individually
  slower depends on duplicate piece uploads

19
Conclusions

• in the common case, incentives are effective
  those that upload more, complete their download
  sooner, and peers with similar upload bandwidth
  tend to cluster together
• when there is not enough seed capacity,
  incentives make no difference
• however, the BitTorrent design leads to the
  breaking of clusters to improve efficiency

20
Presentation Outline

• BitTorrent operation and algorithms
• BitTorrent contribution incentives
• BitTorrent robustness
• Cloudfarm
• Related work

21
Fairness vs. Robustness

• fairness those who do not upload to others
  should not be able to receive good service
• robustness in the presence of small numbers of
  free-riders, the system should still provide
  satisfactory service to compliant nodes
• hypothesis fairness violations are feasible,but
  they do not reduce robustness

22
BitTorrent exploits

• designed three selfish-peer exploits
• implemented them in an existing BitTorrent client
• evaluated their impact in private and public
  torrents

• exploits clearly do not exhaust the complete
  spectrum of possible selfish behavior
• but we believe they are good representatives
• utilized as tools to understand robustness

23
Experimental methodology

• private torrents
• single initial seed, 8 leechers who
  disconnectupon completion
• imposed upload and download limits
• goal measure benefit for selfish peer (fairness
  violation), and impact on compliant peers
  (robustness)

• public torrents
• a selfish and a compliant client join the same
  public torrent at the same time
• goal measure benefit for selfish peer in
  real-world settings

24
Exploit 1 Relying on seeds
peer setrequest
peer set
? download from seeds no need to upload anything
? repeatedly query the tracker for new peer sets
? receive data from seeds and random optimistic
unchokes
25
Exploit 1 evaluation
Leecher download rates

• fast selfish peer, 7 compliant peers

• 22 download improvement (fairness violation)
  when selfish peer is fast
• system robust compliant slowdown normal variability

• 7-20 download improvement in public torrents
  (better with more seeds)

26
Exploit 2 Declaring false information
2
1
1
2
4
!
I have
3
1
2
3
? lie about the pieces you have

• gradually advertise the rarest pieces

? send garbage when you do not have a piece

• pollution is not primary objective

27
Exploit 2 evaluationin private torrents
Observed leecher download rates

• 22 download improvement (fairness violation )
• robustness compliant slowdown normal variability
• some of the compliant leechers even improve their
  rates
• exploit fails in public torrents due to defenses
  by certain clients

28
Robustness causes

• maintaining parallel interactions
• seeds upload to many at the same time
• limits impact of the first exploit
• mechanism for continuous resource discovery
• optimistic unchoking enables the discovery of
  better data-trading partners
• prevents monopolization of seeds
• keeping memory of past interactions
• defends against second exploit in public torrents

29
Robustness principles

• hide node properties
• tell only trustworthy nodes that you are a seed
• export minimal information necessary
• only trust what you can measure yourself
• a peer should not be able to influence another
  peers decision process by declaring false
  information

30
Recent related work

• recent work on free-riding in BitTorrent systems
  confirms our conclusions
• Bharambe et al. Infocom06 tit-for-tat
  algorithm ineffective in preventing free-riding
• Qiu et al. SIGCOMM04 optimistic unchokes may
  be used to free-ride
• BitThief (Locher et al. HotNets-V 2006)
  free-riding easier in torrents with many seeds
• BitTyrant (Piatek et al. NSDI07) lack of
  optimistic unchokes introduces vulnerability

31
Conclusions

• fairness violations by selfish peers are
  possible, to a certain extent
• BitTorrent quite robust despite these fairness
  violations
• identified protocol characteristics that enable
  this robustness, and proposed protocol design
  principles

32
Presentation Outline

• BitTorrent operation and algorithms
• BitTorrent contribution incentives
• BitTorrent robustness
• Cloudfarm
• Related work

33
Motivation

• Web-based applications increasingly popular, but
  user content is currently confined within a
  single application
• tap unused resources on client machines to
  disassociate user content from application
  control
• potential benefits
• enable more flexible content sharing across
  applications
• reuse storage software framework
• reduce costs for application providers

34
What is Cloudfarm best suited for?

• Web application types
• single-user (e.g., email)
• data sharing (e.g., photos or videos)
• collaborative (e.g., document editing)

• Cloudfarm not suited for collaborative
  applications
• typically close to real-time
• strict consistency requirements
• Also not for privacy-sensitive applications
  (e.g., banking)

35
Challenges

• incentive scheme that encourages resource
  contributions (bandwidth, storage)
• multi-dimensional bandwidth (as in BitTorrent),
  round-trip latency, availability, long-term
  storage

• ensure data availability
• peer-monitored failure detection and replication
• primary replica on data creators machine
• ensure data confidentiality and integrity
• all data objects could be optionally encrypted
• cryptographic hashes enable verification of
  received data

36
System components

• tracker
• maintains data location information and aids peer
  bootstrapping
• only has infrequent interactions with peers

• client
• implements local storage, communication,
  incentive scheme, data verification
• exposes this common functionality to applications
  via well-defined API

37
Contribution Incentives

• peers maintain long-term statistics on others
• e.g., service bandwidth, round-trip latency
• no central reputation repository

• peer decisions based on utility metric
• calculated according to an application-provided
  formula, via client components API
• e.g., fastest, lowest latency, trade-off

• limited coverage problem
• peer statistics shared across all applications

38
Design joining the system

• joining client authenticates with tracker,
  sending list of users it is currently storing
  data for
• receives application-specific module and a list
  of peers storing its data
• performs handshake with peers in the list

39
Design data upload

• break up object in chunks calculate unique IDs
  and send them to tracker also ask peers to store
  chunk data

• choose peers with high utility metrics to store
  your data
• remote peers accept such store requests based on
  requesting peers utility metric

40
Design page download

• client sends page request to tracker, who returns
  page skeleton including data chunks unique IDs
• if page objects were not uploaded by requesting
  client, tracker checks access rights, then also
  returns peers storing chunk data

• prefer to request chunks from peers with high
  utility metrics
• remote peers satisfy such requests based on
  requesting peers utility metric

41
Implementation

• tracker component
• 400 lines of PHP, backed by a MySQL database
• communicates with peers over HTTP

• client component
• runs in Firefox as a browser extension (add-on)
• 2500 lines of JavaScript
• utilizes Firefox APIs for opening TCP sockets,
  interacting with local storage (SQLite),
  spawning threads
• JSON is used as the data format for peer messages

• example application
• Coppermine photo gallery, 34,000 lines of PHP
• modified 129, added 245 lines to port it to
  Cloudfarm
• application-specific module 240 lines

42
Incentive evaluation

• hypotheses
• incentives assist in finding good partners
• incentives are effective in punishing free-riders

• PlanetLab experiments
• 15 Cloudfarm client instances are launched at the
  same time, have all data chunks, and are not
  behind a NAT/firewall
• continuously request and download data chunks
  from others
• record the total page download time
• utility metric for ranking peers
  service/round-trip latency

• scenarios
• no incentives just serve the first 7 peers in
  peer set
• Cloudfarm incentives used to rank peers according
  to utility metric, then serve the 6 best, plus
  one at random
• same as scenario 2, with a single free-rider who
  does not upload at all

43
Incentive results
scenario 1
scenario 2

• page download times are significantly reduced
• peer statistics assist in locating the best
  partners

44
Incentive results

• those who upload to others achieve higher utility
  metrics, resulting in more peers serving them

45
Incentive results
scenario 2
scenario 3

• incentives discourage free-riding
• free-riding peer (peer 8) incurs a 50 slowdown,
  as very few peers are willing to serve it (its
  utility metric is 0)
• some other peers perform worse too, as the total
  serving capacity in the system is decreased

46
Page load evaluation

• hypothesis overhead imposed by Cloudfarm
  prototype is acceptable

• PlanetLab-based replicas and local measurement
  client
• all replicas are launched ahead of time, have all
  datachunks for all images, and are not behind a
  NAT/firewall
• measurement client accesses pages containing
  images stored on Web server, and pages
  containing the same images stored on replicas
  (each image consists of 5 chunks)
• measurement client is on a 1.5 Mbps home cable
  connection, tracker on the UCLA network
• peers to request chunks from are selected
  round-robin, modeling a steady-state scenario

47
Page load results

• all values in milliseconds (average/standard
  deviation)

• 10 peers
• 15 peers peers
• handshaking with peers is fast (peers)
• overhead could be further improved by optimizing
  implementation (e.g., JavaScript - C)

48
Limitations

• have run experiments only for utility metrics
  involving bandwidth and round-trip latency, and
  their combinations
• no encryption / access control
• no audits for verifying peers are not lying
  about data they are storing
• no provisions to keep data available after data
  owner logs off

49
Conclusions

• examined BitTorrent incentives effectiveness and
  limitations
• facilitate formation of clusters of peers with
  similar upload bandwidth
• discourage free-riding by rewarding contributors
• do not strictly enforce fairness
• BitTorrent is robust despite fairness violations

• developed incentives for another hybrid P2P
  system
• Cloudfarm peer-to-peer storage for Web
  applications
• showed that the prototypes incentive scheme is
  effective in motivating peers to contribute
  resources, and that it incurs acceptable page
  load overhead

50
Future work

• implement Cloudfarms encryption and access
  control schemes
• port different Web applications to the Cloudfarm
  architecture, and experiment with content sharing
  across applications
• how to incorporate third-party services that run
  Cloudfarm instances on behalf of users (monetary
  incentives)

51
Contribution Incentives for BitTorrent-like
Systems

• Nikitas Liogkas
• RÉSCOM 2008
• Saint-Jean-Cap-Ferrat, France
• June 19, 2008
• Thank you!