1 / 23

Structured Superpeers: Leveraging Heterogeneity to Provide Constant-Time Lookup

Structured Superpeers: Leveraging Heterogeneity to Provide Constant-Time Lookup. Department of Computer Science & Engineering University of California, San Diego. Alper Mizrak (Presenter) Yuchung Cheng Vineet Kumar Stefan Savage. Introduction.

nia
Download Presentation

Structured Superpeers: Leveraging Heterogeneity to Provide Constant-Time Lookup

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. Structured Superpeers:Leveraging Heterogeneityto Provide Constant-Time Lookup Department of Computer Science & Engineering University of California, San Diego Alper Mizrak (Presenter) Yuchung Cheng Vineet Kumar Stefan Savage

  2. Introduction • P2P are designed to distribute functionality and resources among a large number of independent hosts • Distributed index: Chord, Pastry, Tapestry • Each peer maintains O(logN) state, provides O(logN) lookup • No bottleneck, no single point of failure • Centralized index: Napster, Audiogalaxy • Provides a single message lookup • The central index becomes • A potential bottleneck • A single point of failure Presenter: Alper MIZRAK

  3. Key observation • Measurements of deployed P2P systems [Saroiu, Sen] all reveal significant heterogeneity in • The capabilities • The activities of their members • Most peers • Are short-lived • Have minimal bandwidth • A small fraction • Remains connected for extended periods • Have significant storage, memory and bandwidth resources • This population heterogeneity suggests that • Performance can be improved • By assigning index state unequally Presenter: Alper MIZRAK

  4. Our goal • Leveraging heterogeneity to provide • Constant-time O(1) lookup • Reasonable scalability and failure resilience • By assigning additional state to these high-capacity peers, or superpeers • A design point somewhere between fully centralized and fully distributed Presenter: Alper MIZRAK

  5. Outline • System architecture • Lookup and query routing • Bootstrapping • Detecting and managing failure • Load balancing • Evaluations • Analytic scalability analysis • Simulation results • Conclusion Presenter: Alper MIZRAK

  6. 1 0 2 4 3 System architecture • Given a P2P system with N peers • Place each on a circular identifier space, i.e. [0, 5) • Using a traditional DHT such as Chord • M peers with high-capacity are chosen to be superpeers and placed in the inner ring • The outer ring is split into arcs • Each arc is assigned to one superpeer Presenter: Alper MIZRAK

  7. System architecture • Each superpeer is responsible for maintaining • Superpeer Table: The mapping between arcs and their responsible superpeers • Peer Table: The addresses of the peers contained in its arc 1 sp0 sp3 p5 p4 Superpeer table Superpeer table p3 p2 p1 p0 0 2 sp0 sp1 sp4 sp2 Peer table Peer table m4 sp3 p28 p25 3 4 p27 p26 Presenter: Alper MIZRAK

  8. id 1 id p5 p4 p3 Lookup p2 p1 p0 sp1 0 2 sp0 sp2 sp4 • When a peer looks up key id • It sends this request directly to its superpeer • If id maps into the superpeers arc, then • Locates the peer that is responsible for id • Returns that peer’s identity • Otherwise • Forwards the request to the superpeer who is responsible for the enclosing arc for id • The second superpeer • Locates the peer that is responsible for id • Returns that peer’s identity sp3 p28 p25 p27 p26 3 4 Presenter: Alper MIZRAK

  9. How are superpeers selected?Bootstrapping • As the first t peers join the system, they are also commissioned as superpeers • This provides • An initial set of superpeers • A division of the identifier space • Putting the system into a consistent state • Additional peers joining to the system • Obtains the identity of their superpeers from their immediate neighbors in the outer ring Presenter: Alper MIZRAK

  10. How are superpeers selected?Volunteer Service • Keeps track of the resources that a peer is willing and able to contribute to the system • The metric can be based on • The lookup message processing power • Storage capability • Connection duration • It is used to select additional superpeer candidates in response to increased load or failure Presenter: Alper MIZRAK

  11. Peer disconnection • If peer leaves gracefully • It simply contacts its superpeer directly. • If peer fails unexpectedly • Its neighbor detects this through the periodical keep-alive messages • It informs the superpeer • In any case, superpeer removes the disconnected peer from its peer table Presenter: Alper MIZRAK

  12. Superpeer disconnection • Superpeer failure is detected through • periodical keep-alive messages between neighbor superpeers • All of the peers in its arc must be reassigned to some other superpeers • Each superpeer replicates the peer info at k of its inner ring neighbors • Optionally, construct the peer table by traversing the arc from one end to another, using successor list • All other superpeers must be informed about the arcs mapping changes Presenter: Alper MIZRAK

  13. Load balancing • When a superpeer’s load approaches to capacity, it may share its load with • Its neighbors if they have sufficient excess capacity • New superpeers from the volunteer service • If a superpeer has sufficient excess capacity • It may absorb the entire load of a neighbor • Return that neighbor to the volunteer service Presenter: Alper MIZRAK

  14. Load balancing • For the capacity of a superpeer • Hard limits not to be exceeded: min, max • Soft limits for the target load: lower, upper • In case of • The load of a superpeer exceeds the hard limits • The cumulative of three neighbor superpeers exceeds their cumulative soft limits • Load balancing algorithm • Shifts load to neighbors: Unevenly distributed load • Introduces a new superpeer: High load • Dismisses an existing superpeer: Low load Presenter: Alper MIZRAK

  15. Scalability AnalysisStorage Requirement • NA: the number of peers in superpeer A’s arc • M: the number of superpeers in the inner ring • Storage requirement at superpeer A • S = NA + M • For N=1,000,000 peers and M=1,000 superpeers • Each superpeer maintains 2000 additional records Presenter: Alper MIZRAK

  16. Scalability AnalysisLookup processing • Each superpeer has to service • All lookups it receives from the peers in its arc • All lookups it receives from the other superpeers for the peers in its arc • NA: the number of peers in superpeer A’s arc • q: uniform lookup process rate in a second • Lookup processing rate at superpeer A • RA = 2qNA • For N=1,000,000 peers and M=1,000 superpeers and q= 1 lookup/second • Average lookup rate for a superpeer is 2000 lookups/second • Easily achievable: i3 system [Stoica], 25,000 queries/sec Presenter: Alper MIZRAK

  17. Scalability AnalysisMaintenance traffic • Analytically predictable factors • Peer join/leave: Immediate superpeer must be informed • Superpeer keep-alive messages • Analytically unpredictable factors • Topology changes of the inner ring: All superpeers must be informed Presenter: Alper MIZRAK

  18. Simulator methodology • Modified the Chord simulator • Target P2P system with 10,000 peers • Fixed parameters • The redundancy parameter k=2 • Lookup rate q = 1 lookup per 20 seconds • Superpeer failure probability is 0.036 over an hour • Keep-alive period for superpeers is 30 seconds • Load balancing (min, lower, upper, max) • Determined empirically Presenter: Alper MIZRAK

  19. Simulator methodology • Synthetic workload Setup a P2P of ~10,800 peers Steady network Heavy leave Steady network Heavy join Steady network Quiet period Presenter: Alper MIZRAK

  20. Simulation results • The # of peers, superpeers, and average load/superpeer Presenter: Alper MIZRAK

  21. Simulation results • Average lookup and maintenance message rates Presenter: Alper MIZRAK

  22. Conclusion • Our approach • Constant-time lookup • Configurable degree of resilience to failures • Reasonable scalability over 1,000,000 peers • The maintenance traffic is low • Load balancing: An equitable and achievable load distribution • Reasonable design choice for most realistic system deployments Presenter: Alper MIZRAK

  23. Bibliography • Stefan Saroiu, P. Krishna Gummadi, and Steven D. Gribble. “A Measurement Study of Peer-to-Peer File Sharing Systems,” In Proceedings of Multimedia Computing and Networking, 2002 • Shubho Sen and Jia Wang. “Analyzing Peer-to-Peer Traffic Across Large Networks,” In Proc. of ACM SIGCOMM Internet Measurement Workshop, Marseille, France, Nov. 2002 • Ion Stoica, Dan Adkins, Sylvia Ratnasamy, Scott Shenker, Sonesh Surana, Shelley Zhuang. “Internet Indirection Infrastructure,” Proceedings of the First International Workshop on Peer-to-Peer Systems, March 7-8, 2002 Presenter: Alper MIZRAK

More Related