structured superpeers: leveraging heterogeneity to provide constant-time lookup alper mizrak...

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

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


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


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


Outline

System architecture– Lookup and query routing– Bootstrapping– Detecting and managing failure– Load balancing

Evaluations– Analytic scalability analysis– Simulation results

Conclusion


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

0

1

2

3 4


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

0

1

2

3 4

sp0 sp1

sp2sp3

sp4

p0

p1p2

p3p4p5

p25p26p27p28

m4

superpeer add. rangesp0 (0 - 1]sp1 (1 - 2]sp2 (2 - 3]sp3 (3 - 4]sp4 (4 - 0]

Superpeer tablesuperpeer add. range

sp0 (0 - 1]sp1 (1 - 2]sp2 (2 - 3]sp3 (3 - 4]sp4 (4 - 0]

Superpeer table

peer identityp0 IP0p1 IP1p2 IP2p3 IP3p4 IP4p5 IP5

Peer tablepeer identityp25 IP25p26 IP26p27 IP27p28 IP28

Peer table

sp0 sp3


p5

sp0Lookup

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

0

1

2

3 4

sp1

sp2sp3

sp4

p0p1

p3p4

p25p26p27

p28

id

id

p2


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


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


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


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


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


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


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


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


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


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


Simulator methodology

Synthetic workloadPhase Duration

(min)

Join rate

(peer/sec)

Leave rate (peer/sec)

1 120 1.5 0

2 60 1.0 1.0

3 20 0.3 3.0

4 60 1.0 1.0

5 20 3.0 0.3

6 60 1.0 1.0

7 10 0 0

Setup a P2P of ~10,800 peersSteady network

Steady network

Steady network

Heavy leave

Heavy join

Quiet period


Simulation results The # of peers, superpeers, and average load/superpeer

0

20

40

60

80

100

120

140

160

0 30 60 90 129 159 189 219 261 291 321

time(min)

# o

f S

Ps

av

g #

of

pe

ers

/ S

Ps

0

2000

4000

6000

8000

10000

12000

# o

f p

ee

rs

new SPload sharingSP dismissedSP failureavg # of peers/SP# of SPs# of peers


Simulation results

Average lookup and maintenance message rates

0

2

4

6

8

10

12

0 30 60 90 129 159 189 219 261 291 321

time(min)

av

g #

of

loo

ku

p m

es

/ S

P

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

av

g #

of

ma

inte

. m

es

/ S

P

new SPload sharingSP dism issedSP failureanalytic query rateactual query rateanalytic join+leave+keepaliveactual join+leave+keepaliveactual m aintenance


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


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

structured superpeers: leveraging heterogeneity to provide constant-time lookup alper mizrak...

Documents

superpeer n

system n

n peers n place

arcs n

chord n

bootstrapping n

upper n

neighbor superpeers