Structured Superpeers: Leveraging Heterogeneity to Provide Constant-Time Lookup

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