(Paper Presentation)ZIGZAG: An Efficient Peer-to-Peer Scheme forMedia Streaming

1. (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

2. MULTICAST
21/10/20132

3. 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

4. Multicasting(Continued…)
21/10/20134

5. 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

6. MAIN PROBLEM
21/10/20136

7. 7
Main Problem
Streaming live bandwidth-intensive media from a single source to
a large quantity of receivers on the Internet.
21/10/2013

8. 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

9. 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

10. 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 is
required
 Robustness requirement
 A receiver may join and leave at any time
 If a forwarding client leaves, its downstream clients must be hooked to
some other clients
 Assume peers are indifference
 Different bandwidth
 Different capacity
21/10/201310

11. SOLUTIONS
21/10/201311

12. 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

13. ZIGZAG
21/10/201313

14. 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

15. 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

16. PROPOSED SOLUTION
21/10/201316

17. 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

18. ZIGZAG SCHEMES
21/10/201318

19. 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

20. 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

21. 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.

22. 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

23. 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)

24. 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

25. Control Protocol
 Maintain the positions and connections in the multicast tree and the
administrative organization.
 Each node X in layer j cluster periodically communicate with its layer j
clustermates, 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

26. 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-0
peer is in [k, 3k-1]
- E.g. Reachable(7) :false
- Reachable and Addable value will be updated based on received
information 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

27. 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

28. 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

29. Client Join (cont.)
join request
Join overhead:
O(max degree × height of multicast tree) = O(k*logkN)
21/10/201329

30. 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

31. 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. 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

33. 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.

34. Split Operation(Continued..)
21/10/201334
 Split overhead:
 step 2:
 step 4: O(degree of Y) = O(k2)
 => O(k2)

35. 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

36. 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. 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. 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

39. PERFORMANCE EVALUATION
21/10/201339

40. 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=5
21/10/2013

41. 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. 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. 43
Degree and Control Overhead
Evaluation
Comments:
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. 44
Failure and Merge Overhead Evaluation
Comments:
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

45. Experiment Result -- NICE comparison
NICE:
Adapt hierarchical peer
clusters, but always receive
content from head.
21/10/201345

46. RELATED WORK
21/10/201346

47. 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 under
network dynamics
 Spreadit has to get the source involved whenever a failure
occurs
 CoopNet puts a heavy control overhead on the source since the
source must maintain full knowledge of all distribution trees.
 Narada emphasizes on small P2P networks.
 NICE focuses on large P2P networks
21/10/2013

48. CONCLUSIONS
21/10/201348

49. 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 because
the multicast tree height is at most logarithm of the client population and
each client needs to forward the content to at most a constant number of
peers.
2.Low control overhead: Since a cluster is bounded in size and the client
degree bounded by a constant, the control overhead at a client is small. On
average, the overhead is a constant regardless of the client population.

50. Conclusions(Continued…)
3.Efficient join and failure recovery: A join can be accomplished without
asking more than O(logN) existing clients, where N is the client population.
Especially, a failure can be recovered quickly and regionally with a
constant number of reconnections and no affection on the server.
4. Low maintenance overhead: Maintenance procedures (merge, split, and
performance refinement) are invoked periodically with very low overhead.
21/10/201350

51. THANK YOU FOR YOUR
COOPERATION
21/10/201351