View
90
Download
4
Category
Preview:
DESCRIPTION
(Paper Presentation)ZIGZAG: An Efficient Peer-to-Peer Scheme forMedia Streaming
Citation preview
(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
Recommended