Your SlideShare is downloading. ×
0
×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Powerpoint

147

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
147
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • what does “incentive” mean?
  • widespread cooperative resource sharing
    users are not generally cooperative
    service degradation / complete system collapse
  • KaZaA: claim anything with the announcements (using software modifications)
    CENTRAL: single pt. of failure
    burden for single peer
    DECENTRAL: reconfiguration stress
    HERE: users who contribute => simultaneous + symmetric service in return
    BARTERING: no bookkeeping / difficult because of “double coincidence of wants”
    OTHER ECONOMIES: money = general means to trade something / more difficult to manage
    => use N-way exchanges
  • large, equal, fixed-size blocks
    partial transfers and different parts from different sources simultaneously
    OBJECT LOOKUP: broadcast (Gnutella) or DHT (Chord)
  • EXPLAIN THE DIFFERENCES BETWEEN TRANSFERS AND REQUESTS IN THE GRAPHS!!!
  • PRIOR to issuing request: does any known peer have oe?
    AFTER receiving (incoming) request: checks only incoming RT but for all objects oe?
  • excess capacity:
    3 slots total
    1 slot bound to exchange (max. transfer rate allowed)
    2 slots for other exchanges
  • LARGER: improve overall performance
    SMALLER: less probable of losing a peer
    2-way exchange is OK. There is no real incentive to look for more.
  • LOCAL BLACKLIST: large + dynamic system
    it suffices to cheat each peer only once
    COOPERATIVE BL: additional mechanisms would be vulnerable to attacks / more complex
    LIMITING DAMAGE:
    trustworthy source of information
    max. benefit will be block size
  • NO TECH DETAILS -> GOTO NXT SLIDE! 
  • WE ASSUME users are NOT GOOD AND NOT BAD
    WE RESPECT DESIRE not to store or share any objects
    A would not be able to participate at all in a pure object exchange
  • the only bottleneck is a peer’s connection
  • uniformly = probability 1/n
    popularity : EXPLAIN ZIPF(-LIKE) and that it approximates REALWORLD SYSTEMS
    local preference = for each of our categories we select how likely we download it from somewhere else
    we select different weights for each category which SUM(weights)=1  uniformly random
  • request rate is reached and held during early point in the simulation
    new request on completed transfer
    object are only deleted when no longer used
  • KEY METRIC = DOWNLOAD TIME!
    system load: best vs. worse = factor 4exchange vs. no-exchange = factor 2
  • explains what we said before… N<=5
    higher order are valuable up to a certain point
  • relative benefit is always significant (independent of pop. factor)
  • persistance if
    many FR
    almost no FR
    NO EXCHANGE IS BASELINE
    no-exchange = sharers when almost everyone is sharing
    INFREQUENT SHARERS REWARD / PREEMPT OTHERS
  • DIFFERENCE IN TIME BETWEEN REQUEST AND START OF TRANSFER
    EXCHANGES DO PROVIDE SIGNIFICANTLY BETTER PERFORMANCE TO SHARING USERS
  • SUPPOSE HIGH % OF FREERIDES BECAUSE OF OTHER STUDIES
    NO EXCHANGES  DIVIDE RESOURCES EVENLY AMONG SHARERS/NON-SHARERS
  • simplistic: SPECIFIC FS MODEL
    IRL: HETERO: there are super-peers
    LATENCY OF SEARCH PROCESS IS IGNORED
    REPLICATION WOULD BE USEFUL BECAUSE PROBABILITY FOR EXCHANGE WOULD GROW
  • eMule- simple two-way credit system- reward = reduce waiting time in upload queue- Queue Rank = f ( upload and download volumes, waiting time )- no communication overhead- tampering with credit file is of no use (in contrast to kazaa)
  • TRANSITIVELY FIND EXCHANGES
    REGULATING THOSE TRANSFERS PROVIDES INCENTIVES
    => THEIR APPROACHES OFFER STRONG INCENTIVES
  • Transcript

    • 1. Exchange-based Incentive Mechanisms for Peer-to-Peer File Sharing Kostas G. Anagnostakis, Michael B. Greenwald J. Marc Roth jmroth@mpi-sb.mpg.de Peer-to-Peer Information Systems January 2005
    • 2. January 25, 2005 Exchange-based Incentive Mechanisms 2/26 Overview  Introduction to Incentive Mechanisms  Exchange Mechanisms Exchange Transfers Preventing Cheating  Simulation & Results  Measurements, Discussion & Related Work  Summary & Conclusion
    • 3. January 25, 2005 Exchange-based Incentive Mechanisms 3/26 Introduction  powerful infrastructure  performance depends on level of cooperation  non-cooperation may have severe impacts  solution: incentive mechanisms = stimulate cooperation (reward people who contribute to the system) ? !?!A B
    • 4. January 25, 2005 Exchange-based Incentive Mechanisms 4/26 Incentive Mechanisms  participation level (e.g. KaZaA)  credit system (monetary economy) centralized vs. decentralized  proposal: exchange system (barter economy) - users trade resources between themselves - high priority for contributing users - not only 2-way but N-way exchanges 2-way 3-way N-way
    • 5. January 25, 2005 Exchange-based Incentive Mechanisms 5/26 Exchange Mechanisms (I) Basics  fixed upload and download capacity  partial transfers  we ignore the object lookup   each peer has an IRQ (incoming request queue) = upload queue
    • 6. January 25, 2005 Exchange-based Incentive Mechanisms 6/26 Exchange Mechanisms (II) Rules  transfer is initiated if 1. local peer has free upload capacity (slot) 2. transfer is an exchange transfer (ET) OR no ETs in IRQ (incoming request queue)  upload slots are preemptively reclaimed by ETs!  fixed-size block transfers  termination of transfer if: - a peer disconnects - source deletes object - 1st transfer completed A B A wants 700 MB from B B wants 4.8 GB from A
    • 7. January 25, 2005 Exchange-based Incentive Mechanisms 7/26 Exchange Transfers (I)  identify feasible exchanges by looking at IRQ  2-way exchanges are simple but frequently do not resolve into convenient pairs  compute feasible N-way exchanges e.g. cycles in (potentially enormous) graph G = (nodes, edges) = (peers, requests) N <= 5 is sufficient 2-way 3-way N-way exchanges
    • 8. January 25, 2005 Exchange-based Incentive Mechanisms 8/26 Exchange Transfers (II)  each peer maintains request tree (RT) - empty IRQ  empty RT - non-empty IRQ  includes other peer’s RTs in their incoming requests  each peer - provides object to predecessor - gets object from successor  A inspects RT - before transmitting - after receiving any request A P1 P2 P4 P11 P9 P3 P5 P6 P10 P7 P8 o1 o2 o3 o4 o5 o6 o7 o8 o9 o10 o11 P9 has object x available for A. The entire request tree is shown. The cycle for the 3-way exchange that A tries to initiate is shown in red. x
    • 9. January 25, 2005 Exchange-based Incentive Mechanisms 9/26 Exchange Transfers (III) in practice  circulate token  invalidation of the ring if - peers offline or crashed - member peers have created own rings  token negotiates transfer rate  least transfer rate is used and excess capacity is transferred to other exchanges
    • 10. January 25, 2005 Exchange-based Incentive Mechanisms 10/26 Exchange Transfers (IV) how to choose  larger rings  - more peers are served - high probability for loss of peer  smaller rings  - lower search cost - higher expected exchange volume  peers usually care less about global performance than about their own benefit
    • 11. January 25, 2005 Exchange-based Incentive Mechanisms 11/26 Preventing Cheating (I)  claim to be exchange but serve junk - local blacklists (bad) - cooperative blacklists (medium)  cheap pseudonyms  limiting the damage: - exchange blocks synchronously with checksum - bad performance: bexchange / trtt bytes/sec - use window protocol - increase window size if good peer  positive effect
    • 12. January 25, 2005 Exchange-based Incentive Mechanisms 12/26 Preventing Cheating (II)  man-in-the-middle attack  C gets high-priority service but does not contribute to the system   bidirectional encryption of transfer using secret key  trusted peer is mediator and verifies data A x C B y I want y I want x “have y, want x” “have x, want y” cheater wants (x) T peer upload has wants A 5 x y B 5 y x C 10 - x
    • 13. January 25, 2005 Exchange-based Incentive Mechanisms 13/26  self-interest vs. maliciousness - solution with better performance at a lower cost - useful for system - respects desire not to participate   generalization to non-ring topologies: not here! Preventing Cheating (III)
    • 14. January 25, 2005 Exchange-based Incentive Mechanisms 14/26 Simulation  200 node file sharing system  50% freeriders (freeloaders)  fixed + asymmetric down-/upload capacity  neglect delay and loss 
    • 15. January 25, 2005 Exchange-based Incentive Mechanisms 15/26  uniformly assign subset m of total categories to each peer  (global) popularity rank for each category c of rank i probability of request for object in category c  distribute objects in categories like categories at peers  uniformly random local preference for each category (independent of its global popularity) Simulation Object Popularity Model ∑ − = = 1 0 m k k c i ci c F F p { }1,,0, 1 1 −∈ ⋅+ = mi fi F c i c  zipf-like distributions 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1 3 5 7 9 11 13 15 17 19 category rank relativepopularity f(c)=1 f(c)=0.2
    • 16. January 25, 2005 Exchange-based Incentive Mechanisms 16/26 Simulation Setup  maximum number of pending requests  request rate is reached and held  maximum # of objects + cleanup
    • 17. January 25, 2005 Exchange-based Incentive Mechanisms 17/26 Simulation Results (I) key metric = download time!  good incentive to deploy the proposed exchange mechanism  reduced upload capacity  longer download time  time to completion increases faster for non-sharing users because exchanges are prioritized
    • 18. January 25, 2005 Exchange-based Incentive Mechanisms 18/26 Simulation Results (II) higher order rings + network size  N=5 better than N=2  as the network grows, difference in performance increases (sharers vs. non-sharers)  N>5: no real improvement N = exchange ring length
    • 19. January 25, 2005 Exchange-based Incentive Mechanisms 19/26 Simulation Results (III) object popularity distribution and performance  difference increases as f approaches 1 (zipf)  2-5 way slightly better than 5-2 way because performance for non-sharers is reduced (longer lived on average)
    • 20. January 25, 2005 Exchange-based Incentive Mechanisms 20/26 Simulation Results (IV) mean download time vs. (non-)sharing peers  until now: 50% freeriders  do the incentives to share always persist?  yes!  non-sharers get a large penalty when almost everyone is sharing  non-sharers tend towards “no-exchange” when no one is sharing  infrequent sharers get big reward
    • 21. January 25, 2005 Exchange-based Incentive Mechanisms 21/26 Simulation Results (V) waiting time  absolute priority for exchanges = key reason for performance
    • 22. January 25, 2005 Exchange-based Incentive Mechanisms 22/26 Real-Life Measurements The eMule network  75% of peers share more than 7 (complete) files  many users refuse uploads even though data is available  most peers however had outgoing requests, i.e. were participating in exchanges
    • 23. January 25, 2005 Exchange-based Incentive Mechanisms 23/26 Discussion  simplistic simulation scenario  limitations & improvements  real exchanges do serve chunks of incomplete objects  probability for exchanges increases  heterogeneity of real-world systems  complexity issues with RT communications  effect on peer behavior (replication of popular objects = $$$ in exchange economy)
    • 24. January 25, 2005 Exchange-based Incentive Mechanisms 24/26 Related Work  MojoNation (centralized payment-based)  karma (distributed cash-based system) - bank-set located via DHT lookup - auction mechanism, limitation of new identities - simulates full-fledged economic system  better performance? (no “double coincidence of wants”)  limitations - high cost in terms of user attention - cash  CPU cycles  lightweight 2-way credit system: eMule  closely related to this proposal: BitTorrent
    • 25. January 25, 2005 Exchange-based Incentive Mechanisms 25/26 Summary & Conclusion  exchange-based approach provides incentives  decentralized  simpler than credit or cash  higher service priority to peers providing simultaneous and symmetric service in return  N-way exchanges  methods for regulating transfers  protection against malicious users  simulations show significant performance advantage to cooperating users, especially in a loaded system  higher-order exchanges offer improvement, if used together with 2-way exchanges
    • 26. January 25, 2005 Exchange-based Incentive Mechanisms 26/26 Thank you for your attention! Any questions?

    ×