Date post: | 29-Mar-2015 |
Category: |
Documents |
Upload: | francisco-muncey |
View: | 216 times |
Download: | 2 times |
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
Presenter: Alper MIZRAK
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
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
Outline
System architecture– Lookup and query routing– Bootstrapping– Detecting and managing failure– Load balancing
Evaluations– Analytic scalability analysis– Simulation results
Conclusion
Presenter: Alper MIZRAK
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
Presenter: Alper MIZRAK
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
Presenter: Alper MIZRAK
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
Presenter: Alper MIZRAK
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
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
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
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
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
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
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
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
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
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
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
Presenter: Alper MIZRAK
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
Presenter: Alper MIZRAK
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
Presenter: Alper MIZRAK
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
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