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.1 Overview and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Our contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Thesis organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Background 5
2.1 An Overview of multicast . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 IP Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Application layer multicast . . . . . . . . . . . . . . . . . . . . 7
2.2 Application layer multicast methods for P2P live video streaming . . 9
2.2.1 Tree-based approach . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1.1 Single-tree . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1.2 Multiple-tree . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Mesh-based approach . . . . . . . . . . . . . . . . . . . . . . . 12
3 Our method for P2P live video streaming 16
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Overlay construction . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Data distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Fair policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Node failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Experiments and results 26
4.1 Experimental set-up . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.1 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.2 Simulation setting . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Experimental result . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.1 Evaluation of services quality if no churn . . . . . . . . . . . . 29
v

vi TABLE OF CONTENTS
4.2.2 Evaluation of service’s quality if churn is present . . . . . . . . 31
4.2.3 Evaluation of services quality in heterogeneous bandwidth case 33
5 Conclusion 36
A Simulation program 38
A.1 Functions: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.1.1 Input data: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.1.2 Output data: . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.2 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.2.1 Constant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.2.2 Smpl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.2.3 DoSchedule: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.2.4 Network: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.2.5 Node: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.2.6 Message: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 LIST OF FIGURES
4.8 CDF of average parts delay from source to node when participating
nodes have different bandwidth . . . . . . . . . . . . . . . . . . . . . 34
4.9 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] . . 8
3.1 Algorithm of selecting node reply pull request . . . . . . . . . . . . . 23
ix

List of Abbreviations
P2P Peer to Peer
MDC Multiple Description Coding
ALM Application Layer Multicast
ESM End System Multicast
x

Chapter 1
Introduction
1.1 Overview and Motivation
With the rapid growth of multimedia applications and the Internet, stream-
ing 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. Cur-
rent application-layer multicast protocols can be divided into two classes: tree-based
approach and mesh-based approach. The tree-based approach, organize participat-
ing peers into multicast tree for data delivery ([CDK+
03], [PWC03], [PKT+
05],
[WXL10], [RD01], [CDKR02], [BBMB+
10], [LLR09], [THD04]). However, for tree-
based 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 Mul-
tiple 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 op-
timizing 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 recov-
ering 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 appro-
priate 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 send-
ing 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 com-
bining 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 sat-
isfied 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 in-
cludes 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 in-
troduce 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 appli-
cation. 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. There-
fore, 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 (mul-
ticast 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 re-
quires 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

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 im-
mediate deployment over the current Internet. For example, End System Multi-
cast (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 application-
layer 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

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 net-
work. In a balanced tree with fanout f and height h, the number of interior nodes
is
(fh
− 1)
(f − 1)
and the number of leaf nodes is fh
. Thus, the fraction of leaf nodes
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

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

13
Figure 2.6: An example of mesh-based video streaming method
most popular and simplest way to construct a mesh is the random method. In this
method, when a node wants to join the network, it sends a request to bootstrap
node (that usually is source node). Then, the bootstrap generates a random list of
available nodes in the network and sends these nodes’ information to joining node.
Joining node makes connections with these nodes and become neighbour of each
other. This method is simple and easy to deploy. However, random function makes
it difficult to control the operation of the network and increase latency. We will
discuss this later in more detail.
In data delivery terms, each participating node independently selects some neigh-
bour nodes and pulls data from them based on an assumption that neighbour nodes
may have the necessary video data. This pull data strategy is also the most signifi-
cant difference between the tree-based and the mesh-based video streaming. Figure
2.6 show an example of video streaming based on mesh. Each node pulls data from
its neighbour node. For example, node 2 pulls data from node 6.
The mesh-based approach can minimize the impact of low bandwidth of a neigh-
bour node by pulling necessary data from a number of appropriate neighbour nodes.
Furthermore, the impact of node churn can be also reduced since a node can choose
to pull data from another node instead of a failure node. For example, if node 1 in
in Fig 2.6 leaves the network; node 2 can pull data from node 0.
However, the mesh-based method also has some disadvantages. Firstly, there
may exist content bottleneck due to the lack of data at the pulled nodes leading to
an unpredictable mesh. For example, node 2 send pull request to all its neighbour
nodes 0, 1 and 6. If node 2 pulls data from node 6, the delay will longer than

Figure 2.7: Prime mechanism [MR10]
if it pulls data from node 1. This problem leads to increased buffering time and
streaming time, which is not suitable for live video streaming. Pulling data from
a set of nodes can solve this problem but leads to increased network overload and
redundancies.
In order to solve this problem, frequently sending pull requests or frequently
notifying neighbours is proposed. However, there is an efficiency-delay trade-off
since this mechanism will create data overhead in this method ([VYF06], [ZLZY05]).
Frequently sending pull requests or notifications leads a node get data sooner and
quickly repair or detect failure of neighbour node. But frequently sending pull
requests or notifications also increases network overhead.
A recently work (PRIME [MR10]) proposed a hybrid mechanism. These meth-
ods build a mesh overlay network and transmit a video stream, which are split
into several smaller sub-streams, through two phases, diffusion phase and swarming
phase. In diffusion phase, sub-streams are delivered by pushing data via multiple
sub-trees. In swarming phase, each node will pull missing data of other sub-streams
from nodes in different sub-trees. This work can improve bandwidth bottleneck and
content bottleneck, which is a serious problem in mesh-based approach.
Figure 2.7 shows an example of PRIME with 17 participating nodes [MR10].
Data delivering combines diffusion phase and swarming phase. Nodes are divided
into three separate sub-multicast tree. The first multicast tree consists of nodes 1, 4,
5, 10, 11 and 12. The second multicast tree consists of nodes 2, 6, 7, 13, 14 and 15.

15
Finally, the third multicast tree consists of nodes 3, 8, 9, 16, 17. Node 12 receives
the first sub-stream from its parent node 5 through diffusion phase. Then, it pulls
the second sub-stream from node 13 and the third sub-streams from node 17.
However, PRIME did not show clearly how to build the overlay network in
the case that the bandwidth degree constraint does not satisfy an how to build
the overlay network using decentralize mechanism. [CdSLMM11] and [CJW11] pro-
posed 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 methods still have the problem of long buffering time
since the variance between the arrival times of data of different sub-streams is large.
They also do not address the problem of free-riding nodes and node churn.

Chapter 3
Our method for P2P live video
streaming
From discussion in previous chapter, we designed a new live video streaming
system that is a self-organizing overlay network of nodes and fully decentralized.
Any computer that is connected to the Internet and runs the software can act as
a node in our system. Thus, our system can be implemented independently or in
other overlay networks such as Chord, CAN or mesh
In this chapter, we describe how our multicast system is built. It satisfies the
following criteria:
• 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 above levels 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.
• Ensuring the fairness between nodes and encouraging nodes to contribute more
to the network. In our work, a tit-for-tat (like in [Cohom], [SD10], [LCW+
06])
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 receiving data. To enhance the tit-for-tat
policy, we construct of a balanced tree to ensure that nodes belonging to
different sub-trees can provide data to each other.
16

3.1. Overview 17
• Recovering from failure when nodes fail. We keep the number of nodes affected
from a node failure to be small, and minimize the amount of time to recover
from node failure.
• Ensuring scalability: our mechanism is fully large-scale decentralized. It does
not require any node to keep global information about the network.
Firstly, we present a brief overview about our multicast system for P2P live video
streaming.
3.1 Overview
Our method takes the approach of push-pull method. It constructs some separate
diffusion sub-trees such that a node, except the source node, belongs to only one
sub-tree. Assuming that the number of sub-trees is k. These sub-trees have the
same root which is the source node itself. Each node also links to other nodes of
other sub-trees.
The video stream from source node is divided into k sub-stream using Multiple
Description Coding (MDC) [AW01]. Source node progressively generates a new
segment of content once every ∆ seconds. This segment is then encoded into k
parts using MDC and each part belongs to a sub-stream. These k sub-streams will
be delivered through k separated sub-trees in a diffusion phase. At the end of the
diffusion phase of a segment, all nodes in the overlay network have at least one
part of that segment to display. To improve video quality, each node then pulls the
missing parts from other nodes in other sub-trees during a pulling phase. The more
parts a node can pull, the better the playing quality. Therefore, the pulling phase
and the pushing phase can be done simultaneously.
However, the problems here are how to construct the overlay network, how each
node selects a node to pull data and how to deal with node failure. These problems
are essential since they decide the quality of video provided to each node. We must
consider these problems under the assumption that there are selfish nodes that
only want to receive data but not want to contribute bandwidth to other nodes.
Therefore, we design a fair policy to ensure that nodes with more contribution (i.e.
nodes have high output bandwidth) will receive more data and have smaller buffering
time.
The next section will describe our solutions to solve these problems.
Tải bản FULL (54 trang): https://bit.ly/3TVXk6S
Dự phòng: fb.com/TaiHo123doc.net

18 Chapter 3. Our method for P2P live video streaming
Figure 3.1: Pushing connections and pulling connection of a node
3.2 Overlay construction
In our solution, each node maintains two kinds of connections, connections
belonging to a sub-tree (i.e. connections to a parent node and a number of child
nodes) and connections to nodes of different sub-trees. Each node also maintains
the information about the list of its child nodes, the number and the highest level of
its descendant nodes. This information is used to keep the construction of sub-trees
to be well balanced. After a period of time, each node at level i will update this
number to its parent at level i+1, and nodes at level i+1 will update to their parents
at level i+2 and so on.
Our overlay construction method will construct a balanced tree rooted at source
node such that the number of nodes and the highest level in each sub-tree is almost
the same. This property is important since nodes belonging to different sub-trees
must exchange streaming data during the pulling phase. It ensures that there are
enough bandwidth for nodes in different sub-trees to exchange data with each other.
Figure 3.1 shows an example of our method with 15 participating nodes.
When a node wants to join into the network and receive streaming data, it firstly
sends a join request to the source node. The source node selects a level-1 node based
on the following priority:
• The node for which number of descendant nodes is smallest
• The node for which the maximum level of descendant nodes is smallest
Tải bản FULL (54 trang): https://bit.ly/3TVXk6S
Dự phòng: fb.com/TaiHo123doc.net

3.2. Overlay construction 19
Then, then source node sends the information of this node to the join node. If
there are a number of level-1 nodes which have the same parameters, the source
node will send the information of these nodes to the join node, which will select the
topologically nearest node among these nodes to send a join request. When a node
receives a join request, it will check if it has spare out bandwidth for the newly join
node or not. If yes, it will accept the join node as its child node. If no, it will select
one or a number of child nodes based on the above priority and send information of
child nodes to the join node. This procedure is repeated until the join node finds
a node which has spare bandwidth. As the result, the number of nodes will be
balanced among sub-trees.
We consider that users want to keep an amount of bandwidth for their own
quality of streaming service before contributing the rest of their bandwidth to net-
work. Assuming that bwpf is the bandwidth needed to transmit a sub-stream, if the
bandwidth of a node is b * bwpf and the number of sub-trees is k(k ≤ b), the node
will use a bandwidth of (k - 1) * bwpf to send its data received during diffusion
phase to nodes in different sub-trees in a tit-for-tat policy. And it uses a bandwidth
of maximum (b - (k - 1))* bwpf to push data to its child nodes. Therefore, the node
will have maximum b - (k - 1) child nodes. If a node has bandwidth smaller than k
* bwpf, it must be a leaf node and it may have not enough bandwidth to exchange
data with other nodes in other sub-trees due to a tit-for-tat policy.
After joining a sub-tree, a node will establish pulling connections with k - 1
nodes in k - 1 different sub-trees to pull data during pulling phases. To do that,
the node will contact its parent node to get the list of k - 1 nodes in its parent’s
pulling node list. It then sends a pulling request to these k - 1 nodes. A node
which receives a pulling request will check if it accepts the request or not based on
a ”tit-for-tat” policy that we will describe latter. If it does not accept the request,
it will reply the list of its child nodes to the request node. The request node will
send a pulling request to each of these child nodes until it receives a successful reply.
Each node will maintain k - 1 pulling connections to nodes in k - 1 sub-trees and a
list of candidate nodes, which is used to send pulling requests if a pulling connection
is rejected or failed.
We also work on a mechanism to replace interior nodes with low out-bandwidth
by nodes with higher out-bandwidth. The purpose of this mechanism is to reduce
the depth of the tree. It is obvious that data delivering time depends on the delay
time that leaf nodes receive data. The lower the level of leaf nodes, the shorter is the
6816115

A Push-pull based Application Multicast Layer for P2P live video streaming.pdf

Recommended

Recommended

More Related Content

Similar to A Push-pull based Application Multicast Layer for P2P live video streaming.pdf

Similar to A Push-pull based Application Multicast Layer for P2P live video streaming.pdf (20)

More from NuioKila

More from NuioKila (20)

Recently uploaded

Recently uploaded (20)

A Push-pull based Application Multicast Layer for P2P live video streaming.pdf