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

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

Presenter: Alper MIZRAK Key observation n 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 n This population heterogeneity suggests that –Performance can be improved –By assigning index state unequally

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

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

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

Presenter: Alper MIZRAK System architecture n 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 sp0 sp1 sp2 sp3 sp4 p0 p1 p2 p3 p4 p5 p25 p26 p27 p28 m4 Superpeer table Peer table sp0sp3

Presenter: Alper MIZRAK p5 sp0 Lookup n When a peer looks up key id n It sends this request directly to its superpeer n If id maps into the superpeers arc, then –Locates the peer that is responsible for id –Returns that peers identity n 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 peers identity sp1 sp2 sp3 sp4 p0 p1 p3 p4 p25 p26 p27 p28 id p2

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

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

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

Presenter: Alper MIZRAK Superpeer disconnection n Superpeer failure is detected through –periodical keep-alive messages between neighbor superpeers n 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 n All other superpeers must be informed about the arcs mapping changes

Presenter: Alper MIZRAK Load balancing n When a superpeers load approaches to capacity, it may share its load with –Its neighbors if they have sufficient excess capacity –New superpeers from the volunteer service n 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 Load balancing n For the capacity of a superpeer –Hard limits not to be exceeded: min, max –Soft limits for the target load: lower, upper n In case of –The load of a superpeer exceeds the hard limits –The cumulative of three neighbor superpeers exceeds their cumulative soft limits n 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 Scalability Analysis Storage Requirement n N A : the number of peers in superpeer As arc n M: the number of superpeers in the inner ring n Storage requirement at superpeer A –S = N A + M n For N=1,000,000 peers and M=1,000 superpeers –Each superpeer maintains 2000 additional records

Presenter: Alper MIZRAK Scalability Analysis Lookup processing n 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 n N A : the number of peers in superpeer As arc n q: uniform lookup process rate in a second n Lookup processing rate at superpeer A –R A = 2qN A n 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 n Easily achievable: i3 system [Stoica], 25,000 queries/sec

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

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

Presenter: Alper MIZRAK Simulator methodology n Synthetic workload PhaseDuration (min) Join rate (peer/sec) Leave rate (peer/sec) Setup a P2P of ~10,800 peers Steady network Heavy leave Heavy join Quiet period

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

Presenter: Alper MIZRAK Simulation results n Average lookup and maintenance message rates

Presenter: Alper MIZRAK Conclusion n 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 n Reasonable design choice for most realistic system deployments

Presenter: Alper MIZRAK Bibliography n 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 n Shubho Sen and Jia Wang. Analyzing Peer-to-Peer Traffic Across Large Networks, In Proc. of ACM SIGCOMM Internet Measurement Workshop, Marseille, France, Nov n 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