1 / 29

On Designing Resource Sharing Peer-to-Peer Systems

This paper discusses the complexities of designing fair resource sharing systems in peer-to-peer (P2P) networks. It explores the challenges of enforcing fair usage policies without a central authority and analyzes the free-riding problem that affects service delivery. The authors propose mechanisms based on strategy-proof designs and altruism to encourage resource sharing among users. By introducing auditing methods and debt-based routing, the work offers innovative solutions to minimize freeloading and improve system robustness, promoting a more equitable sharing environment in decentralized networks.

kelda
Télécharger la présentation

On Designing Resource Sharing Peer-to-Peer Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. On Designing Resource Sharing Peer-to-Peer Systems Johnny Ngan and Dan S. Wallach Rice University

  2. Fair Usage of Resource • Policy decided by administrator • Simple to enforce for conventional systems • E.g. quotas in file servers • Not true for p2p systems SCISS’04

  3. Hardness in P2p Systems • P2p systems are distributed in nature • Hard to enforce policy • Lack of central server • For making decisions and overseeing everything • Nodes can have unpredictable behaviors SCISS’04

  4. Organization • Similarity in economics literature • Rules for designing p2p resource sharing systems • Our designs for storage and bandwidth sharing SCISS’04

  5. Mechanism Design • Each node is an agentacting selfishly • MD asks how to design systems to arrive desired system-wide goal • Also known as inverse game theory SCISS’04

  6. Strategyproof Mechanisms • A mechanism is strategyproof if no one can benefit from deviate behavior • Design incentives directly into the system • Resulted system would • Be stable and predictable • Achieve desired goal SCISS’04

  7. Decentralization • P2p systems are designed to scale • Centralization prevents scalability • Prevent central point of failure and vulnerability SCISS’04

  8. Avoid Gossiping • Nodes may lie • Gossip could be used to spread false information • You can only trust what you see SCISS’04

  9. Robustness Against Collusion • Nodes may collude if they can all benefit • Even bribery is possible! • Do not trust even a group of nodes • Should communicate with large no. of nodes • But still better not to trust SCISS’04

  10. Need for Altruism • Cannot guarantee services will be paid back • Need someone to provide service to start • Some systems, e.g. BitTorrent, need altruism on top of “tit-for-tat” strategy • Altruism could be exploited by freeloaders SCISS’04

  11. Our Designs: Background • Require users to share resources to operate • Users may not have incentives to provide services • Free-riding problem is a real threat [AH00] • 70% of users free ride in Gnutella • Half of requests served by 1% of users SCISS’04

  12. Our Designs • Most widely deployed: file sharing • Limiting resources can be different • Archival system: storage space • Popular file sharing: bandwidth SCISS’04

  13. Storage-Constraining Designs • Consider storage systems • Mainly for archival storage • Assume data encrypted for privacy • Policy: equal exchange of space • No one can tell if one is storing what is required of him • Basic idea: auditing SCISS’04

  14. Auditing • Nodes maintain and publish their own quota information • Called quota file • Auditing to ensure correctness Ngan, Wallach, and Druschel. Enforcing Fair Sharing of Peer-to-Peer Resources. In 2nd International Workshop of Peer-to-Peer Systems (IPTPS), 2003. SCISS’04

  15. F1 F2 Example Remote: F2 Remote: F1 Local: (F1, Alice) Alice Bob Carol Local: (F2, Bob) SCISS’04

  16. Audit Example Remote: F1 Local: (F1, Alice) Alice Bob SCISS’04

  17. Audit Example Remote: F1 Local: (F1, Alice) Alice Bob SCISS’04

  18. Extensions • How to store the first document? • Include “advertised capacity” in quota file • Selling spare capacity • Putting fake files in quota file SCISS’04

  19. Bandwidth-constraining designs • Consider popular file sharing systems • E.g. content distribution systems like BitTorrent [Cohen’03] • Everyone wants to download a popular file! • Goal: worsen freeloaders’ service without affecting other nodes SCISS’04

  20. General Ideas • Nodes maintain information about all nodes it has a relationship • By measuring number of objects sent… • The difference is the credit/debt • The sum is the confidence Ngan, Nandi, and Singh. Fair Bandwidth and Storage Sharing in Peer-to-Peer Networks. In 1st IRIS Student Workshop, 2003. SCISS’04

  21. Pairwise trade • Entertain requests up to a debt threshold • If two parties make requests equally like, expected debt is / √ no. of requests • Choose dynamic debt threshold SCISS’04

  22. Transitive trade • Pairwise trade has limitations • Earned credit is useless if no service requested • Refuse to service due to skewed requests • Need mechanism to leverage credits • Realized by Debt-based Routing to make requests SCISS’04

  23. Transitive Trade Example • A looks for a debt-based path • C sends A the object directly • Every link rearrange their debt A C B SCISS’04

  24. Relationship Throttling • Recall the need for altruism • Necessary: nodes will honor first few requests from each other • Can be abused in large systems • Mature nodes with enough credits can refuse to serve new nodes SCISS’04

  25. Experimental Results • Storage-constraining design • Auditing has low overhead • Scale to large systems • Bandwidth-constraining design • Trivially scalable • Greatly reduced services received by freeloaders SCISS’04

  26. Concluding Remarks • Need to incentivize users to provide good service • Borrow mechanism design from economics • Bring techniques from real life! http://www.cs.rice.edu/~twngan/Incentives/ SCISS’04

  27. Storage Overhead (Nodes) SCISS’04

  28. Storage Overhead (Files) SCISS’04

  29. Bandwidth-Constraining SCISS’04

More Related