peer-to-peer streaming: an hierarchical approach
DESCRIPTION
Peer-to-Peer Streaming: An Hierarchical Approach. Duc A. Tran (with Kien A. Hua and Tai T. Do) Data Systems Group (UCF). Roadmap. What is P2P? Why P2P Streaming? Problem Statement Solution: ZIGZAG Performance Study Future Work. What is P2P?. - PowerPoint PPT PresentationTRANSCRIPT
Peer-to-Peer Streaming: An Hierarchical Approach
Duc A. Tran(with Kien A. Hua and Tai T. Do)
Data Systems Group (UCF)
Roadmap
What is P2P? Why P2P Streaming? Problem Statement Solution: ZIGZAG Performance Study Future Work
What is P2P?
The sharing of computer resources and services by direct exchange between systems:– exchange of information, processing cycles,
cache storage, and disk storage for files. P2P uses existing desktop computing power
and networking connectivity,– allowing economical clients to leverage their
collective power to benefit the entire enterprise
P2P Streaming
Sharing of network bandwidth Streaming: The user plays the data as as it
arrives. Consider a new user A:
– If A is the first user, A gets the stream from the central site
– Else, A can get the stream from the central site or a set of users who have already been receiving the stream
Why P2P Streaming?
source
Oh, I am exhausted!
Client/server approach P2P approach
Problem Statement
Live media streaming
Scalability
Low Overhead
High Liveness
Robustness
Goal 1: High Liveness
source
Don’t make me a bottleneck!
Is it too far?
new
I want to join fast
Goal 2: Robustness
sourceThe server is already busy
Too many reconnections!
Goal 3: Low Control Overhead
A peer may have to periodically exchange information with others to maintain its position and connections.
The overhead of this task should be small and independent of the system size
Goal 4: Scalability
When more peers join the system:– Control overhead may be increased– A peer may have to serve more others– The P2P tree may be deeper– A failure may result in many reconnections
Our goal: Minimizing the above effects
Proposed Solution: ZIGZAG
The 4 goals are achieved, especially:– Peer degree: bounded by a constant– Tree height: logarithmic with the system size– Control overhead: bounded by a constant (on average)– Failure recovery: done regionally,
• affecting at most a constant number of peers• mostly no effect on the server
Administrative Organization (AO): A clustering of peers
Multicast tree: Built atop the AO based on C-rules
Administrative Organization
L2
L1
L0
1 2
43
5
6
7
4
S
S
othershead
S: servervice-head
432 S 5 6 78
9 10
11
12 13
14
15 16
17
18 19
20
21 22
23
24
1
25
26
27 28
29
30 31
Cluster size: [k, 3k], Highest-layer cluster: [2, 3k]
(k 4)
Terms
1 2
21
inferior
Foreign head
Foreign inferiorSuper
peer
3 4
Foreign cluster
Connectivity Rules(C-rules)
L2
L1
L0
1 2
43
5
6
7
4
S
S
othershead
S: servervice-head
432 S 5 6 78
9 10
11
12 13
14
15 16
17
18 19
20
21 22
23
24
1
25
26
27 28
29
30 31
(In this example, k = 4)
C-rules
Rule 1: A peer, when not at its highest layer, neither has a link out nor a link in
Rule 2: Non-head members of a cluster must receive the stream from their vice-head
Rule 3: The vice-head of a cluster, except for the server, must receive the stream from a foreign head
P2P Tree
1 2
3
5
6 7
4
S
8
9 10
11
12 13
14
15 16
17
18 19 20
21 22 23
24 25
26
27 2829
30 31
The tree height is at most 2logkN+1
The node degree is at most 6k-3
Control Overhead
A peer exchanges soft-state information with– Its parent– Its children– Its clustermates
The worst-case control overhead is O(klogkN)
The average control overhead is O(k)
Join
The new user sends a request to the server The request is forwarded down the tree until
reaching a vice-head of a layer-0 cluster of size [k, 3k-1]
Goal: to be as close to the server as possible– Among children to forward the request, choose
Y: Addable(Y) and D(Y)+d(Y,new) is min
Max number of contacts: O(klogkN)
Failure Recovery
A node X at layer j is down:– The parent of X removes its link to X– X is vice-head: the layer-j cluster of X needs to
a new vice-head– The children of X need a new parent to get the
stream– i < j: Each layer-i cluster of X needs a new head
since X no longer exists
Peer 3 fails
L2
L1
L0
1 2
43
5
6
7
4
S
S
432 S 5 6 78
9 10
11
12 13
14
15 16
17
18 19
20
21 22
23
24
1
25
26
27 28
29
30 31
othershead
S: servervice-head
Failure Recovery(peer 3 fails)
1 2
45
6
7
4
S
S
42 S 5 6 78
9 10
11
12 13
1415
16
17
18 19
20
21 22
23
24
1
25
26
27 28
29
30 31
15
Max number of reconnections: 6k-2
othershead
S: servervice-head
Cluster Maintenance
As new peers are added to the administrative organization (AO):– A cluster may become oversize => split this
cluster into two smaller clusters As peers are removed from the AO:
– A cluster may become undersize => merge this cluster with another to make a larger cluster
Goal: The conditions of C-rules must be met
Cluster Split
Lj+1
Lj
U U V
Xhead
Xvice
Xhead
Xvice
After SplitBefore Split
X'head
X'vice
Split algorithm: run by the head Xhead
Max number of reconnections: old cluster size + 6k - 1
Cluster Merge
Lj+1
LjU+VU V
XU
YV
XU
YU
After MergenceBefore Mergence
XV
YV
XV
YU Former layer-jchildren of XV
Merge algorithm: run by the head Xhead
Max number of reconnections: old cluster size + 6k - 1
Performance Study
Underlying network: – 10,000 nodes – Generated by GT-ITM Generator
P2P network: – 5000 peers– Up to 2500 failures
k = 5
Peer Degree
ZIGZAG (max=13, stdev=2.648)
0
2
4
6
8
10
12
14
0 1000 2000 3000 4000 5000 6000
Client ID
Deg
ree
Control Overhead
ZIGZAG (avg=12.497, max=48, stdev=4.9933)
0
10
20
30
40
50
60
0 1000 2000 3000 4000 5000 6000
Client ID
Co
ntr
ol O
verh
ead
Failure Overhead
ZIGZAG (avg=1.0976, max=14, stdev=2.3175)
0
2
4
6
8
10
12
14
16
0 500 1000 1500 2000 2500 3000
Failure ID
Fai
lure
Ove
rhea
d
Split Overhead
ZIGZAG (avg=7.56, max=19, #splits=555)
0
2
4
6
8
10
12
14
16
18
20
1
30
59
88
11
7
14
6
17
5
20
4
23
3
26
2
29
1
32
0
34
9
37
8
40
7
43
6
46
5
49
4
52
3
55
2
Split ID
Sp
lit O
verh
ead
Merge Overhead
ZIGZAG (avg=4.912, max=11, stdev=1.0428)
0
2
4
6
8
10
12
1 9
17
25
33
41
49
57
65
73
81
89
97
10
5
11
3
12
1
12
9
13
7
14
5
Merge ID
Mer
ge
Ove
rhea
d
Join Overhead
ZIGZAG (avg=19.322, max=28)
0
5
10
15
20
25
30
1
262
523
784
1045
1306
1567
1828
2089
2350
2611
2872
3133
3394
3655
3916
4177
4438
4699
4960
Join ID
Join
Ove
rhea
d
ZIGZAG versus NICE
NICE: (Banerjee et. al., Sigcomm 2002)– Administrative organization: there is no “vice-head”– P2P tree: head is always the parent of its clustermates
ZIGZAG:– Administrative organization: “head” and “vice-head”– P2P tree: “vice-head” is the parent of its non-head
clustermates
Peer Degree
0
5
10
15
20
25
30
35
40
0.2 0.3 0.4 0.5 0.6 0.7 0.8
Failure probability p
Max
. Deg
ree
Ove
rhea
d
Proposed
NICE
Control Overhead
0
10
20
30
40
50
60
70
80
0.2 0.3 0.4 0.5 0.6 0.7 0.8
Failure probability
Max
. Co
ntr
ol O
verh
ead
Proposed
NICE
Failure Overhead
0
5
10
15
20
25
30
0.2 0.3 0.4 0.5 0.6 0.7 0.8
Failure probability p
Max
. Fai
lure
Ove
rhea
d
Proposed
NICE
Link Stress
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
0.2 0.3 0.4 0.5 0.6 0.7 0.8
Failure probability p
Avg
. Lin
k S
tres
s
Proposed
NICE
Conclusions
A clustering method for the administrative organization
C-rules: A multicast tree construction method Future Work: Multi-send multi-receiver, client
heterogeneity, Zigzag in MANETs?
JOIN FAILURE DEGREE MERGE/SPLIT CONTROL
NICE O(klogkN) O(klogkN) O(klogkN) O(klogkN) O(klogkN)
ZIGZAG O(klogkN) O(k) O(k) O(k) O(klogkN)