Structured Superpeers: Leveraging Heterogeneity to Provide Constant-Time Lookup

Transcription

1 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

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

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

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

5 Outline System architecture Lookup and query routing Bootstrapping Detecting and managing failure Load balancing Evaluations Analytic scalability analysis Simulation results Conclusion

6 1 System architecture 0 2 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 4 3

7 0 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 p4 p1 p2p3 p0 p5 sp0 1 sp1 2 sp0 Superpeer table superpeer add. range sp0 (0-1] sp1 (1-2] sp2 (2-3] sp3 (3-4] sp4 (4-0] sp3 Superpeer table superpeer add. range sp0 (0-1] sp1 (1-2] sp2 (2-3] sp3 (3-4] sp4 (4-0] m4 4 sp4 p28 p27 sp2 sp3 p25 p26 3 Peer table peer p0 p1 p2 p3 p4 p5 identity IP0 IP1 IP2 IP3 IP4 IP5 Peer table peer p25 p26 p27 p28 identity IP25 IP26 IP27 IP28

8 Lookup 0 p3 p4 p2 p1 p0 id p5 sp0 1 sp1 2 sp4 sp3 sp2 p25 When a peer looks up key id p It sends this request directly to its superpeer id 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 p28 p27

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

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

11 Peer disconnection If peer leaves gracefully It simply contacts its superpeer directly. If peer fails unexpectedly Its neighbor detects this through the periodical keepalive messages It informs the superpeer In any case, superpeer removes the disconnected peer from its peer table

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

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

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

15 Scalability Analysis Storage Requirement N A : the number of peers in superpeer A s arc M: the number of superpeers in the inner ring Storage requirement at superpeer A S = N A + M For N=1,000,000 peers and M=1,000 superpeers Each superpeer maintains 2000 additional records

16 Scalability Analysis Lookup 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 N A : the number of peers in superpeer A s arc q: uniform lookup process rate in a second Lookup processing rate at superpeer A R A = 2qN A 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

17 Scalability Analysis Maintenance 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

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 over an hour Keep-alive period for superpeers is 30 seconds Load balancing (min, lower, upper, max) Determined empirically

19 Simulator methodology Synthetic workload Phase Duration (min) Join rate (peer/sec) Leave rate (peer/sec) Setup a P2P of ~10,800 peers Steady network Heavy leave Steady network Heavy join Steady network Quiet period

20 Simulation results The # of peers, superpeers, and average load/superpeer # of SPs avg # of peers / SPs new SP load sharing SP dismissed SP failure avg # of peers/sp # of SPs # of peers # of peers time(min)

21 Simulation results Average lookup and maintenance message rates 12 1 avg # of lookup mes / SP new SP load s haring SP dism is sed SP failure analytic query rate actual query rate analytic join+leave+keepalive actual join+leave+keepalive actual m aintenance avg # of mainte. mes / SP time(min)

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

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 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