A Push-Pull Based Application Multicast Layer For P2P Live Video Streaming.pdf

VIETNAM NATIONAL UNIVERSITY, HANOI
UNIVERSITY OF ENGINEERING AND TECHNOLOGY

BUI THI LAN HUONG

A PUSH-PULL BASED APPLICATION
LAYER MULTICAST FOR P2P LIVE
VIDEO STREAMING

Major: Computer Science
Code : 60 48 01

MASTER THESIS

Hanoi – 2011


VIETNAM NATIONAL UNIVERSITY, HANOI
UNIVERSITY OF ENGINEERING AND TECHNOLOGY

BUI THI LAN HUONG

A PUSH-PULL BASED APPLICATION
MULTICAST LAYER FOR P2P LIVE VIDEO
STREAMING

BRANCH: INFORMATION TECHNOLOGY
MAJOR: COMPUTER SCIENCE
CODE:
60 48 01

MASTER THESIS

SUPERVISOR: DR. NGUYEN HOAI SON

Hanoi – 2011


Table of Contents
1 Introduction
1.1 Overview and Motivation . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Our contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Thesis organization . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Background
2.1 An Overview of multicast . . . . . . . . . . . . . . . .
2.1.1 IP Multicast . . . . . . . . . . . . . . . . . . . .
2.1.2 Application layer multicast . . . . . . . . . . . .
2.2 Application layer multicast methods for P2P live video
2.2.1 Tree-based approach . . . . . . . . . . . . . . .
2.2.1.1 Single-tree . . . . . . . . . . . . . . . .
2.2.1.2 Multiple-tree . . . . . . . . . . . . . .
2.2.2 Mesh-based approach . . . . . . . . . . . . . . .
3 Our
3.1
3.2
3.3
3.4
3.5

method for P2P live
Overview . . . . . . . .

Overlay construction .
Data distribution . . .
Fair policy . . . . . . .
Node failure . . . . . .

video
. . . .
. . . .
. . . .
. . . .
. . . .

4 Experiments and results
4.1 Experimental set-up . . . .
4.1.1 Topology . . . . . . .
4.1.2 Simulation setting . .
4.2 Experimental result . . . . .
4.2.1 Evaluation of services

streaming
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .

.
.
.
.

.

.
.
.
.
.

.
.
.
.
.

. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
quality if no churn
v

.
.
.
.
.

.
.
.

.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.

.
.

.
.
.
.
.

. . . . . .
. . . . . .
. . . . . .
streaming
. . . . . .
. . . . . .
. . . . . .
. . . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

1
1
3
4

.
.
.
.

.
.
.
.

5
5
6
7
9
9
9
11
12

.
.
.
.
.

16
17
18
20
22
24

.
.

.
.
.

26
26
27
28
29
29


vi

TABLE OF CONTENTS
4.2.2
4.2.3

Evaluation of service’s quality if churn is present . . . . . . . . 31
Evaluation of services quality in heterogeneous bandwidth case 33

5 Conclusion

36

A Simulation program
A.1 Functions: . . . . . .
A.1.1 Input data: .
A.1.2 Output data:
A.2 Classes . . . . . . . .

A.2.1 Constant . . .
A.2.2 Smpl . . . . .
A.2.3 DoSchedule: .
A.2.4 Network: . . .
A.2.5 Node: . . . .
A.2.6 Message: . . .

38
38
38
38
39
39
39
39
39
39
40

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

B Generating input by using GT-ITM

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

41


List of Figures
2.1

Using unicast, broadcast and multicast for video streaming . . . . . .

6

2.2

An example of IP multicast . . . . . . . . . . . . . . . . . . . . . . .

7

2.3

An example of ALM . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.4

Single multicast tree with 10 nodes . . . . . . . . . . . . . . . . . . . 10

2.5

An example of multi-tree based streaming . . . . . . . . . . . . . . . 12

2.6

An example of mesh-based video streaming method . . . . . . . . . . 13

2.7

Prime mechanism [MR10] . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1

Pushing connections and pulling connection of a node . . . . . . . . . 18

3.2

Example of changing position of high-bandwidth node . . . . . . . . . 20

3.3

Example of diffusion phase with k = 3 . . . . . . . . . . . . . . . . . 21

3.4

Example of swarming phase, node pulls missing data . . . . . . . . . 22

3.5

Example of replacement of node failure . . . . . . . . . . . . . . . . . 25

4.1

An example of real networks topology [NTks] . . . . . . . . . . . . . 28

4.2

CDF of average variance between the arrival times of different parts
in PRIME and in our method . . . . . . . . . . . . . . . . . . . . . . 30

4.3

CDF of average parts delay and average segment delay from source
to node in PRIME and in our method . . . . . . . . . . . . . . . . . 30

4.4

CDF of missing parts ratio of node in our method when there is leave
and join nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.5

CDF of average variance between the arrival times of different parts
in our method when there is leave and join nodes . . . . . . . . . . . 32

4.6

CDF of average parts delay and average segment delay from source
to node in our method when there are leave and join nodes . . . . . . 32

4.7

CDF of missing parts ratio of our method when participating nodes
have different bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . 33
vii


viii
4.8
4.9

LIST OF FIGURES
CDF of average parts delay from source to node when participating
nodes have different bandwidth . . . . . . . . . . . . . . . . . . . . . 34
CDF of average segment delay from source to node when participating

nodes have different bandwidth . . . . . . . . . . . . . . . . . . . . . 35


List of Tables
2.1

Conceptual comparison between IP Multicast and ALM [HASG07] . .

3.1

Algorithm of selecting node reply pull request . . . . . . . . . . . . . 23

ix

8


List of Abbreviations
P2P
MDC
ALM
ESM

Peer to Peer
Multiple Description Coding
Application Layer Multicast
End System Multicast

x

Chapter 1
Introduction
1.1

Overview and Motivation

With the rapid growth of multimedia applications and the Internet, streaming video over the Internet is becoming more and more attractive to users. This
is especially the case for live video streaming. Live video streaming applications
often require transmitting streaming data to a large number of users. IP Multicast
[DC90] is probably the most efficient solution for this requirement. However, the
deployment of IP multicast remains restricted due to many practical and political
issues [HASG07]. Researchers thus have shifted focus to exploiting application-layer
multicast (ALM) for data delivery. ALM utilizes the ability of end hosts that act not
only as receivers but also as senders. They can forward their received data to other
hosts. However, this solution is challenged by the dynamic join/leave of end hosts,
the existence of free-riders, the heterogeneous of node bandwidth and the real-time
constraint, especially in live streaming applications.
Many application-layer multicast protocols have been proposed recently. Current application-layer multicast protocols can be divided into two classes: tree-based
approach and mesh-based approach. The tree-based approach, organize participating peers into multicast tree for data delivery ([CDK+ 03], [PWC03], [PKT+ 05],
[WXL10], [RD01], [CDKR02], [BBMB+ 10], [LLR09], [THD04]). However, for treebased designs with only one single tree, two major problems can be seen. Firstly, it
is unfair between interior nodes and leaf nodes when leaf nodes do not contribute
to the system. Secondly, the leave/failure of any interior node may cause packet
outage in all its descendant nodes.
1


2

Chapter 1. Introduction

To deal with these problems, in SplitStream [CDK+ 03], nodes are structured into
multiple diverse trees such that an interior node in this tree will be a leaf node of
all other trees. Video streams are split into several smaller sub-streams using Multiple Description Coding [AW01] or layered video [LPA98] and each sub-streams
data is delivered by one tree. However, SplitStream requires all nodes to have equal
bandwidth. Otherwise, its performance will be degraded. Some recent tree-based
research ([BBMB+ 10], [LLR09]) overcomes the disadvantage of Splitstream by optimizing the construction of multi trees even when nodes have different bandwidth.
However, multi-tree based approach still has a disadvantage of long buffering time
due to the variation in arrival times of different sub-streams data. Another problem
that all multi-tree-based designs have to face is the cost of maintaining and recovering multicast trees when there is a node churn (there is node join and leave in the
system).
Recently, mesh-based P2P streaming approach ([MR10], [MRW07], [VYF06],
[ZXBY05], [ZLZY05], [LPA98], [CdSLMM11], [HCC10], [CJW11], [LKHT10]) has
attracted a lot of attention since it can minimize the impact of node churn and low
bandwidth of a neighbour node by pulling necessary data from a number of appropriate neighbour nodes. Each node independently selects some nodes as neighbours
and pulls data from them based on an assumption that neighbour nodes may have
necessary video data. However, there is a trade-off between minimum delay by sending pull request and overhead of whole system ([VYF06], [ZLZY05]). Furthermore,
there are may exist content bottleneck due to the lack of data at the pulled nodes.
PRIME [MR10] improves bandwidth bottleneck and content bottleneck by combining a method of pushing data via multiple sub-trees and a method of pulling data
from nodes in different sub-trees. However, PRIME did not show clearly how is built
the overlay network in the case that the bandwidth degree constraint does not satisfied and decentralized. [CdSLMM11], [CJW11] proposed some different strategies
to select connections but all these strategies are built based on the fact that the
bootstrap node must store the whole information about all nodes in the network,
which leads to low scalability. [LKHT10] shows how to build a decentralized overlay
network but with the cost of increased computation complexity. In addition, these
strategies does not address problems such as long buffering time, node churn or
free-riders.
Realizing this drawback in current application layer multicast methods for video
streaming, we aim to propose a push-pull based method for lower delay and better

1.2. Our contribution

3

video quality.

1.2

Our contribution

In this thesis, we design a large-scale decentralized P2P streaming mechanism that
combines pushing and pulling method. Nodes are organized in separate sub-trees
such that a node, except the source node, belongs to only one sub-tree. Each node
also has links to other nodes of other sub-trees. Each sub-stream is delivered through
a sub-tree based on a push mechanism. Each node will receive from its parent at
least one sub-stream in the pushing phase to ensure the availability. Then, a node
pulls other sub-streams from other nodes to improve the quality of service.
In our work, we tackle several problems such as how to reduce buffering time of
nodes, how to encourage nodes to contribute resources and how to deal with node
churn.
The contribution of our work includes:
1. Optimizing packet delivery in pulling phase to reduce buffering time of nodes.
We consider that the playing time of each node depends on the arrival time
of the latest part of a segment. Therefore, in our method, each node will try
to establish pulling connections with nodes in the level above or in the same
level. Here, the level of a node is defined as the path length from a source
node to the node. Therefore, the time gap between arrival times of pushing
data and pulling data is reduced.
2. Ensuring the fairness between nodes and encouraging nodes to contribute more

to the network. In our work, a tit-for-tat policy is designed such that nodes
with more contribution will be given higher priority to receive data. Hence,
they can get better quality of service such as shorter buffering time or more
received data. To enhance the tit-for-tat policy, we construct a balanced tree
to ensure that nodes belonging to different sub-trees can provide data to each
other.
3. Recovering from node failure when there are nodes failed. We keep the number
of nodes affected by a node failure to be small, and minimize the amount of
time to recover from node failure.


4

Chapter 1. Introduction
4. Ensuring scalability: Our mechanism is fully large-scale decentralized. It does
not require any node to keep global information about the network.

We conduct simulations to evaluate performance of our proposed system. The
simulation results show that our proposed system can improve the quality of service
for live video streaming, handle node churn well and ensure the tit-for-tat policy.

1.3

Thesis organization

The rest of this thesis is structured as follows:
Chapter 2 presents some background in this area. The description issues includes a review of previous and current work in live video streaming.
Chapter 3 describes the proposed push-pull based method for P2P live video
streaming and explain how our method satisfies the problem that mentioned above.
Chapter 4 describes how we set-up our simulation experiments and presents

our results and comparisons with other approaches.
Chapter 5 present our conclusion and gives future research directions based on
the results obtained so far.


Chapter 2
Background
In this chapter, we present the basic concepts of this thesis. Firstly, we introduce a briefly overview of multicast and why multicast is the choice for video
streaming application and a comparison between IP Multicast and application layer
multicast (ALM). Secondly, we discuss about current ALM solutions for P2P live
video streaming.

2.1

An Overview of multicast

In live video streaming applications, a source sends the same video stream to end
hosts. For example, the same video stream is sent to many viewers in IPTV application. Multicast is the most suitable mechanism for video streaming application in
comparison with other communication mechanisms such as unicast and broadcast
[HASG07]. Multicast is mechanism that allows sender to send data to a group of
receivers [Dee92]. The group of receivers is named as host group or multicast group.
Figure 2.1 shows multicast, unicast and broad cast methods for video streaming
application. Unicast allows a source to send data to a single host. Video streaming
application must use multiple unicast connections. Therefore, the number of viewer
is limited by the bandwidth of source node. In broadcast approach (Fig. 1b), data
is sent from source to all end hosts. In this mechanism, node that does not want to
receive data still receives data. It causes a waste of network resources.
In multicast approach (Fig. 1c), data is transmitted to a set of receivers. After
receiving data, a receiver can copy and forward this data to another receiver. Therefore, multicast approach reduces the dependence of system on ability of source node
5

6

Chapter 2. Background

Figure 2.1: Using unicast, broadcast and multicast for video streaming
and utilizes capacities of all nodes in the network.
Current multicast methods are classified in two main class: IP multicast (multicast in network layer) and application layer multicast (ALM).

2.1.1

IP Multicast

IP multicast [DC90] is deployed in network layer. In this method, source sends
the message only once; the network then delivers the message to all receivers. Each
packet from source is copied by the network at routers. After that, routers deliver
this packet to receivers.
Figure 2.2 shows an example of IP multicast. Source S sends data to receiver
H1, H2, H3, H4 and H5. Firstly, source S send data to router R1. At router R1,
data is copied and forwarded to R2, R3, R4 and R5. These routers continue to
deliver data to destination H1, H2, H3, H4 and H5, respectively.
Many IP Multicast models have been proposed such as in [WPD88], [Eri94] and
[DEW97]. In this thesis, we do not discus details of IP Multicast techniques and
its problems such as group management, address location and security. For more
information, the reader can refer to [DLL+ 00].
IP Multicast approach makes the most efficient use of network resources because
the source has to send data only once and the same message is not delivered more
than one at each link [HASG07]. However, implementation of this mechanism requires that the routers are intelligent. In particular, the routers in the network must

2.1. An Overview of multicast

7

Figure 2.2: An example of IP multicast
have the ability to set-up and to tear down IP Multicast sessions. Beside, routers
must be capable of processing and routing IP Multicast packets. These requirements
are the main major barrier of IP Multicast’s deployment in global network because
the cost for changing platforms is too high.

2.1.2

Application layer multicast

Because IP Multicast’s deploying limitation as discussed above, many researchers
shifted their focus to deploying multicast in application layer (or ALM). In ALM,
end hosts are responsible for copying and forwarding data instead of intermediate
means such as routers as in IP Multicast. Each receiver receives a packet from
other receivers. Then, it copies that packet and forwards to other receiver without
knowledge of underlying network topology such as how the packet is transferred via
router or this link has transmitted this message or not.
Figure 2.3 shows an example of ALM, in which, the multicast tree is built as
shown in Fig. 3b. Figure 3a describes delivering of data. Firstly, source S send data
to H1, H3 and H5 via links of routers R1R2, R1R3 and R1R5, respectively. After
that, H1 copies data and forwards to H4 via links of routers R2R3 and R3R4. H3


8

Chapter 2. Background

Figure 2.3: An example of ALM
copies data and forwards to H2 via link of routers R3R2.
In the example in Fig. 2.3, R2R3 link sends the same data twice. The duplicate
data at the same link leads to waste the network resource and increase network
overload. Beside, ALM methods also increase the streaming time. For example,
H2 can receive data sooner if it is H1’s child. Thus, the lack of underlying layer
information leads to increase of transmission delay and increase of network overload.
However, it is also advantage of ALM. It makes ALM easy and possibly immediate deployment over the current Internet. For example, End System Multicast (ESM) ([ESMgy], [CRZ00]) is one of the currently deployed implementation of
ALM. Table 2.1 shows the conceptual comparison between IP Multicast and ALM
[HASG07].
Table 2.1: Conceptual comparison between IP Multicast and ALM [HASG07]
Issues
IP Multicast
ALM
Efficiency in term of delay/bandwidth
High
Low Medium
Complexity or overhead
Low
Medium - High
Ease of deployment
Low
Medium - High
Implemented layer
Network
Application

2.2. Application layer multicast methods for P2P live video streaming9

2.2

Application layer multicast methods for P2P
live video streaming

Although less efficient than IP Multicast, ALM is increasing in popularity due
to its ease of deployment. In this section we discuss current method ALM for P2P
live video streaming. Many application-layer multicast protocols for P2P live video
streaming have been proposed recently. Based on topology, current applicationlayer multicast protocols can be divided into two classes: tree-based approach and
mesh-based approach.
Here, some readers may wonder why we do not choose client-server model for
live video streaming instead of P2P model. In fact, client-server model is a simple
solution for live video streaming applications. In this approach, a client sets up a
connection to server or local server (such as in Content Delivery Network) and video
stream is delivered to client directly from the server. However, the number of users
is limited by the ability of source video server and the scalability of client-server
method is very costly.
Peer-to-Peer (P2P) approach has recently emerged as a new solution for video
streaming. The key idea of P2P video streaming is to encourage peers to contribute
to the network by acting as both clients and servers. Each peer not only receives
data from the network, but also forwards this data to other peers. This mechanism
reduces the bandwidth burden on the server and utilizes the capacity of all peers in
the network.

2.2.1

Tree-based approach

2.2.1.1

Single-tree

Many video streaming solutions based on single tree have been proposed
([CDK+ 03], [PWC03], [PKT+ 05], [WXL10], [BBMB+ 10], [LLR09], [THD04]) and
widely known such as Overcast [JGJ+ 00], ESM [CRZ00] or ZigZag [THD04]. In this
approach, participating nodes (or end hosts) are organized into a multicast tree.
The root of this multicast tree is source video node. Each participating node has
a level that determined by the number of steps from the root to this node on the
multicast tree. Nodes that is nearest to the root have level 1, then nodes have link
with these nodes have level 2 and so on. Each node receives video stream from its


10

Chapter 2. Background

Figure 2.4: Single multicast tree with 10 nodes
parent node at lower level and forwards this video stream to its child nodes at higher
level.
Figure 2.4 shows an example of an application-layer multicast tree with ten
nodes. There are two level 1 nodes that receive video stream directly from source.
The four level 2 nodes receive video stream from the level 1 nodes 0 and 1, and
forward video they get to the four highest level nodes (leaf nodes).
There are many ways to construct a multicast tree from a set of nodes. The
main targets while constructing a multicast tree are reducing the depth of tree and
increasing the number of children of each node (or fan-out) as much as possible.
Leaf nodes receive data last in the network. Therefore, reducing the height of tree
leads to reduced at streaming time. It is clearly that the greater number of children

in each node, the smaller the height of the tree. However, the number of children
of each node is limited by the bandwidth of each node. Because, if the fan-out is
too large (the number of a node’s child), node’s overload will increase and leading
to longer delay or failure.
Another problem of single tree-based approach is the cost of maintaining tree. A
participating node can leave the network at any time without being able to predict
cause of computer crashes or connection problems. Then all the descendant nodes
cannot receive the video stream. For example, if node 0 (in Fig 2.4) leaves the
network, all nodes 2,3,6,7,8 will be affected and could not receive data. In order to
minimize this impact, multicast tree needs to recover as soon as possible.
Many researchers have proposed solutions to optimize tree and reduce recovering
time. In ZigZag [THD04], nodes in same level are organized into groups; each group


2.2. Application layer multicast methods for P2P live video streaming
11
will select a head node. When a node leaves the network, this child nodes ask head
node to find another replacement quickly. However, the case that parent node and
head node leave the network at the same time is not discussed. ZigZag also points
out a mechanism to reduce the height of tree by pushing high bandwidth nodes
in lower level. Other solutions [MZ04] and [TJ07] proposed reduce recovering time
by storing information about the ancestor nodes. Then, a node can contact its
grandparent node to repair failure of parent node.
Thus, some problems of single-tree based approach are solved. However, an
important problem of this solution is that leaf nodes do not contribute to the network. In a balanced tree with fanout f and height h, the number of interior nodes
(f h − 1)
and the number of leaf nodes is f h . Thus, the fraction of leaf nodes
is
(f − 1)
increases with f. For example, in a tree with fanout 16, and over 90% of peers are

leaves and the burden of deliver content message is carried by less than 10% of the
peers. Assuming that each node has the same input bandwidth, each node will have
to upload the data volume by 16 times the amount of data it receives. Thus, this
solution does not ensure fairness between the nodes and not utilize capacity of all
nodes.
2.2.1.2

Multiple-tree

In order to solve the problem that leaf nodes do not contribute to the network,
multicast-based trees are proposed in [CDK+ 03] and [KRAV03]. In this approach,
the source video node divides into several sub-streams using Multiple Description
Coding [AW01] (MDC). Instead of delivering data through a single multicast tree,
source delivers data through multiple trees, each tree delivers a sub-stream. Each
participating node joins into all multicast trees to receive the complete video.
Figure 2.5 shows an example of streaming based on multi-tree with 2 children
and 7 nodes. The source node divides the video stream into two video sub-streams.
Then the source node pushes the first sub-stream to the left child 0 and the second
sub-stream to the right child 3. Nodes 1 and 2 continue push the first sub-stream
that is received from node 0 to their children nodes 3, 4, 5 and 6. Similarly, nodes 4
and 5 receive the second video sub-stream from node 3 and upload this sub-stream
to nodes 0, 1, 2 and 6.
In comparison with the single tree designs, the multiple tree designs increase k
times the inbound bandwidth of each node (in the case fan-out of all nodes is k ) and


12

Chapter 2. Background

Figure 2.5: An example of multi-tree based streaming
distribute overload to all nodes. Besides, if there is a churn (node join or leave), only
a single multicast tree will be affected. However, this method also has significant
disadvantages. In Splitstream [CDK+ 03], interior nodes in a multicast tree will be
the leaf nodes of all other multicast trees. Here, this design requires that all nodes
must have the same bandwidth. This is impossible in real network. In addition, if
there is churn, it will be very difficult to recover multicast tree while satisfying the
construction constraints.
Recently proposal methods [BBMB+ 10] and [LLR09] construct the multicast
based on the bandwidth that nodes contribute. In other words, node can be interior
nodes in more than one tree. The probability that a node is interior node in a
tree depends on bandwidth of this node. Nevertheless, there is a trade-off between
efficient and complexity in these methods.
In addition, multi-tree based approach still has a disadvantage of long buffering
time due to the variation in arrival times of different sub-streams’ data. Another
problem that all multi-tree-based designs have to face is the cost of maintaining and
recovering multicast trees when there is a node churn.

2.2.2

Mesh-based approach

In the mesh-based P2P streaming approach ([MR10], [MRW07], [VYF06],
[ZXBY05], [ZLZY05], [LPA98], [CdSLMM11], [HCC10], [CJW11], [LKHT10]), each
node establishes and maintains connections with a set of nodes, call as neighbour
nodes. These connections construct a mesh that covers the entire network. The