(Paper Presentation)

ZIGZAG: An Efficient Peer-to-Peer Scheme for

Media Streaming

Duc A. Tran Kien A. Hua Tai Do

School of Electrical Engineering School of Electrical Engineering School of Electrical Engineering

and Computer Science and Computer Science and Computer Science

University of Central Florida University of Central Florida University of Central Florida

Orlando, FL 32816–2362 Orlando, FL 32816-2362 Orlando, FL 32816-2362

Email: dtran@cs.ucf.edu Email: kienhua@cs.ucf.edu Email: tdo@cs.ucf.edu

Presented By:

Rajesh Piryani

South Asian University

21/10/20131

MULTICAST

21/10/20132

Multicasting

A better way to transmit data from one source to many

destinations is to provide a multicast transport service.

With a multicast transport service, a single node can send data

to many destinations by making just a single call on the

transport service.

IP multicast-enabled network provides end-to-end services in

the IP network infrastructure to allow any IP host to send

datagram’s to an IP multicast address that any number of other

IP hosts widely dispersed can receive.

21/10/20133

Multicasting(Continued…)

21/10/20134

Multicast Application

Multicast is useful because

it allows the construction of truly distributed applications.

and provides important performance optimizations over

unicast transmission.

Applications:

real-time audio and video conferencing which can make good use of a

multicast service when it is available

21/10/20135

MAIN PROBLEM

21/10/20136

7

Main Problem

Streaming live bandwidth-intensive media from a single source to a large quantity of receivers on the Internet.

21/10/2013

Video Streaming Solutions

Dedicated Channel: individual

connection to each receiver –

Unicast (server bottleneck)

IP Multicast: Synchronized peers

problem.

Server

C1

C2 …

…

Cn-1

Cn

Server

C1 C2 Cn-1 Cn…

…

21/10/20138

Chaining

Basic Idea

A client can forward its incoming video stream to

serve other clients

Advantages

Each client can now contribute its computing

resource to serve the entire community, rather than

being just a burden to some central server

A new client can be chained to an early client,

making this service model highly scalable

It uses only unicast, but achieves the same effect of

using IP multicast

Since each server stream now can serve many clients,

this strategy is often called Application Layer

Multicast.

Server

C1

C2

C3

21/10/20139

Chaining Problems

End-to-end delay

Tree height: If a tree is too long, the forwarding delay will be large,making it unsuitable for live streaming

Node degree: If a node has high degree, high forwarding bandwidth isrequired

Robustness requirement

A receiver may join and leave at any time

If a forwarding client leaves, its downstream clients must be hooked tosome other clients

Assume peers are indifference

Different bandwidth

Different capacity

21/10/201310

SOLUTIONS

21/10/201311

Solutions

ZIGZAG

Short End-to-End delay

Efficient join and failure recovery

PROMISE

Aggregate peers bandwidth

SASABE

QoS(Quality of Service) consideration and Efficient distribution

21/10/201312

ZIGZAG

21/10/201313

ZIGZAG

ZIGZAG organizes receivers into a hierarchy of bounded-size

clusters and builds the multicast tree based on that.

The connectivity of this tree is enforced by a set of rules,

which guarantees that the tree always has a height O(logkN) and a

node degree O(k2), where N is the number of receivers and k is a

constant.

unpredictable receiver behaviors are handled gracefully without

violating the rules

achieved requiring a worst case control overhead of O(logkN) for the

worst receiver

O(k) for an average receiver.

21/10/201314

ZIGZAG

failure recovery can be done regionally with only impact on a

constant number of existing receivers and no burden on the

source.

21/10/201315

PROPOSED SOLUTION

21/10/201316

17

Proposed Solution

media source as the server and receivers as clients. They all

are referred to as “peers”.

ZIGZAG SCHEMES

Administrative organization

Logical relationships among the peers

The multicast tree

Physical relationships among the peers

The control protocol

Peers exchange state information

A client join/departure

Performance Optimization

21/10/2013

ZIGZAG SCHEMES

21/10/201318

Administrative Organization

used to manage the peers

currently in the system

Peers are organized in a

multilayer hierarchy of

clusters recursively.

H –Number of Layers

K>3 is a constant

21/10/201319

Administrative Organization Rules

Layer H −1 has only one

cluster which has a size in [2,

3k].

A peer in a cluster at layer j <

H is selected to be the head of

that cluster. This head becomes

a member of layer j + 1 if j <

H − 1.

The server S is the head of

any cluster it belongs to.

21/10/201320

Layer 0 contains all peers.

Peers in layer j < H− 1 are

partitioned into clusters of

sizes in [k, 3k].

H =theta (logk N) whereN is no. of peer

Administrative Organization (Continued..)

21/10/201321

any peer at a layer j > 0 must be

the head of the cluster it belongs to

at every lower layer.

Administrative organization in

ZIGZAG does not infer a data

delivery topology.

Terminologies

Subordinate: Non-head peers of a cluster headed by a peer X are called

“subordinate” of X.

Foreign head: A non-head (or server) clustermate of a peer X at layer j >

0 is called a “foreign head” of layer (j-1) subordinates of X.

Foreign subordinate: Layer-(j-1) subordinates of X are called “foreign

subordinates” of any layer-j clustermate of X.

Foreign cluster: The layer-(j-1) cluster of X is called a “foreign cluster”

any layer-j clustermate of X.

21/10/201322

Multicast Tree

Rules:

If a peer isn’t at its highest

layer, it cannot has a link. E.g.

peer 4 at layer 1

A peer at its highest layer can

only link to its foreign

subordinate. E.g. Peer 4 at

layer2

At layer j <H−1: since non-

head members of a cluster

cannot get the content from

their head,

they get the content directly

from a foreign head. E.g.,

non-head peers in layer-0

cluster of peer 1

21/10/201323

k = 4, H (number of layers) = 3

Bound node degree O(k2)

Bound tree height to O(H) = (logkN)

Multicast Tree (Continue…)

Suppose the members of a cluster

always get the content from their

head.

If the highest layer of a node X is j,

X would have links to its

subordinates at each layer, j-1, j-2,

..., 0, that it belongs to.

Since j can be H - 1, the worst-case

node degree would be H× (3k - 1)

= omega(logkN).

Furthermore, the closer to the

source, the larger degree a node

would have.

In other words, the bottleneck

would occur very early in the

delivery path.

This might not be acceptable for

bandwidth-intensive media

streaming.

“Since a peer gets the content from

a foreign head, but not its head,

and can only forward the content

to its foreign subordinates, but not

its subordinates, we named our

technique ZIGZAG.”

21/10/201324

Control Protocol

Maintain the positions and connections in the multicast tree and theadministrative organization.

Each node X in layer j cluster periodically communicate with its layer jclustermates, its children, and parent on the multicast tree.

Periodically communicate with:

If recipient is cluster head, X also sends

a list L = {[X1, d1], [X2, d2], ..}, where [Xi, di] represents

that X is currently forwarding the content to di peers in the

foreign cluster whose head is Xi

Example:-

at layer 1,

peer 5 needs to send a list {[S, 3], [6, 3]} to the head S.

21/10/201325

Control Protocol (Continued..)

If recipient is Parent, then X will send

- Reachable(X):true iff exist a path from X to a layer-0 peer

- Addable(X):true iff X is reachable, and the cluster size of the layer-0peer is in [k, 3k-1]

- E.g. Reachable(7) :false

- Reachable and Addable value will be updated based on receivedinformation from its children

control overhead for an average member is a constant.

The worst node has to communicate with O(logkN) other nodes,

21/10/201326

Control Protocol (cont.)

Node 2: send (2, 6) to 1, 3, 4

send {(1, 3), (3, 3)} list to head 4

send Reachable(2)=true, Addable(2)=true to parent S

receive Reachable(), Addable() from children

k = 4, H (number of layers) = 3, size bound in [4,12]

21/10/201327

Client Join

21/10/201328

D(Y ):- denotes the currently

end-to-end delay from the

server observed by a peer Y ,

and

d(Y , P):- is the delay from

Y to P measured during the

contact

between Y and P

Client Join (cont.)

join request

Join overhead:

O(max degree × height of multicast tree) = O(k*logkN)

21/10/201329

Client Departure

Consider a peer X who departs either purposely or accidentally due to failure.

As a result of the control protocol

the parent peer of X, all subordinates of X (if any),

and all children of X (if any)

are aware of this departure

21/10/201330

Client Departure

Algorithm Steps

1. A peer X who departs

2. If X’s highest layer is layer 0, no further overhead emerges.

3. Suppose that X’s highest layer is j>0

4. For each layer-(j-1) cluster whose non-head members are children of X,

1. the head Y of the cluster is responsible for finding a new parent for them.

5. Y selects Z, a layer-j non-head clustermate, that has the minimum degree

21/10/201331

32

Client Departure (cont.)

Furthermore, since X used to be the head of j clusters at layers 0,

1,…,j-1, they must have new head.

Let X’ be a random subordinate of X at layer 0

X’ will replace X as the new head for each of those clusters

Comment: In the worst

case, the number of peers

that need to reconnect

due to a failure is O(k2)

21/10/2013

Algorithm Steps

1. Split into U, V, where X U with |U|,|V|

[k,3k] is satisfied first and then

is minimized.

2. Delete links of layer j-1 whose parent and

head are in different clusters in layer j.

3. Choose new parents other than X for 2.

4. Select head Y of cluster V with minimum

degree because we want this change to

affect a smallest number of child peers.

(i). Choose new parent for children of Y.

(ii). Place Y into layer j+1 and link to X”.

Split Operation

))(min(,

VXUX liil

li

xx

U

X

X”Lj+2

Lj+1

Lj

Lj-1

X’

V

21/10/2013 33

Let xil be the number of peers

that are both children of Xi and

layer-(j-1) subordinates of Xl.

Split Operation(Continued..)

21/10/201334

Split overhead:

step 2:

step 4: O(degree of Y) = O(k2)

=> O(k2)

Merge Operation

Merge overhead: step 2: O(2*(3k-1))

step 3: O(degree) =(3k-1)*(3k-1) peers to reconnect O(k2)

=> O(k2)

As the result of many client departures, a cluster might become undersize.

In this case it is merged with another cluster of same layer.

Algorithm Steps

1. Choose new head between X, Y which are heads of two sets being

merged (may use larger degree one)

2. Delete link from parent of lost head at layer j+1, and remove the node.

3. Select new parent of non-head members in U+V.

4. Delete links point to the same cluster at layer j+1.

5. Select new parent different from the new head with minimum degree.

21/10/201335

Performance Optimization

Under the network dynamics, the administrative organization

and multicast tree can be periodically reconfigured in

order to provide better quality of service to clients.

Consider a peer X, in its highest-layer cluster j > 0, is busy serving

many children. It might consider switching its parenthood of

some children to another non-head clustermate which is less busy.

21/10/201336

37

Performance Optimization

Degree Based Switch

A peer X, in its highest-layer cluster j>0, is busy serving many children

X currently has links to foreign clusters C1,…Cm, each Ci having si non-head subordinates, respectively.

Denote The degree of a peer Y by dY

1. For (i = 1; i <= m; i++)

1. Select a non-head clustermate Y :

2. Y is not the head of Ci

1. dX - dY - si > 0

2. dX - dY - si is max

2. If such Y exists

3. Redirect non-members of Ci to Y

4. Update dX and dY accordingly

21/10/2013

38

Performance Optimization (cont.)

Capacity Based Switch

Peers have different bandwidth capacities

Busyness of a peer X to be dx/Bx ,Bx is the bandwidth of X

1. For( i=1 ; i<=m; i++)

2. Select a non-head clustermate Y:

1. Y is not the head of Ci

2. (dx/Bx - dY/BY)2 - ((dx-si)/Bx – (dY+si)/BY)2 > 0

3. (dx/Bx - dY/BY)2 - ((dx-si)/Bx – (dY+si)/BY)2 is max

3. If such Y exists

4. Redirect non-members of Ci to Y

5. Update dx and dY accordingly

21/10/2013

PERFORMANCE EVALUATION

21/10/201339

40

Performance Evaluation

Peer Stretch: (the length of the data path from the server to a

peer in our multicast tree) / (the length of the shortest path

between them in the underlying network)

Link Stress: the number of times the same packet goes

through the link

Use the GT-ITM Generator to create a 3240-node transit-stub

graph as our underlying network topology

2000 clients located randomly

K=521/10/2013

Join Evaluation

Join Overhead:-number of peers that the new client has to

contact before being added to the multicast tree

21/10/201341

42

Join Evaluation

Comment: The join-overhead curve would continue going up slowly as more clients join

until a constant point when it would fall down to a very low value). This behavior would

repeat, making the join algorithm scalable with the client population

21/10/2013

43

Degree and Control Overhead

EvaluationComments:

1.The node degrees in a ZIGZAG

multicast tree are small, but also they are

quite balanced. In the worst case, a peer

has to transmit the content to 22 others,

which is tiny to the client population of

2000 clients.

2.Most peers have to exchange control

states with only 12 others. Those peers at

high layers do not have a heavy control

overhead either; most of them

communicate with around 30 peers, only

1.5% of the population

21/10/2013

44

Failure and Merge Overhead EvaluationComments:

1.Most failures do not affect the system

because they happen to layer-0 peers

(illustrated by a thick line at the bottom of

the graph)

2. For those failures happening to higher

layer peers, the overhead to recover each

of them is small and mostly less than 20

reconnections (no more than 2% of client

population)

3. The overhead to recover a failure does

not depend on the number of clients in the

system.

4. In the worst case, only 17 peers need to

reconnect, which accounts for no more

than 1.7% of the client population.

21/10/2013

Experiment Result -- NICE comparison

NICE:

Adapt hierarchical peer

clusters, but always receive

content from head.

21/10/201345

RELATED WORK

21/10/201346

47

Related Work

Address the problem of streaming media

Overlay-router approach

Peer-to-peer approach

chaining did not address the stability of the system undernetwork dynamics

Spreadit has to get the source involved whenever a failureoccurs

CoopNet puts a heavy control overhead on the source since thesource must maintain full knowledge of all distribution trees.

Narada emphasizes on small P2P networks.

NICE focuses on large P2P networks

21/10/2013

CONCLUSIONS

21/10/201348

4921/10/2013

Conclusions

The key in ZIGZAG’s design is the use of a foreign head other than the head of a cluster to forward the content to the other members of that

cluster.

The benefit of creating algorithm with that idea in mind:

1.Short end-to-end delay: ZIGZAG keeps the end-to-end delay small becausethe multicast tree height is at most logarithm of the client population andeach client needs to forward the content to at most a constant number ofpeers.

2.Low control overhead: Since a cluster is bounded in size and the clientdegree bounded by a constant, the control overhead at a client is small. Onaverage, the overhead is a constant regardless of the client population.

Conclusions(Continued…)

3.Efficient join and failure recovery: A join can be accomplished withoutasking more than O(logN) existing clients, where N is the client population.Especially, a failure can be recovered quickly and regionally with aconstant number of reconnections and no affection on the server.

4. Low maintenance overhead: Maintenance procedures (merge, split, andperformance refinement) are invoked periodically with very low overhead.

21/10/201350

THANK YOU FOR YOUR

COOPERATION

21/10/201351