Peer-to-Peer Streaming: An Hierarchical Approach

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)