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

Another problemthat 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 thesys

VIETNAM NATIONAL UNIVERSITY, HANOI

UNIVERSITY OF ENGINEERING AND TECHNOLOGY

BUI THI LAN HUONG

A PUSH-PULL BASED APPLICATION LAYER MULTICAST FOR P2P LIVE

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

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

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

x

Chapter 1

Introduction

1.1 Overview and Motivation

With the rapid growth of multimedia applications and the Internet, ing video over the Internet is becoming more and more attractive to users This

stream-is especially the case for live video streaming Live video streaming applicationsoften require transmitting streaming data to a large number of users IP Multicast[DC90] is probably the most efficient solution for this requirement However, thedeployment of IP multicast remains restricted due to many practical and politicalissues [HASG07] Researchers thus have shifted focus to exploiting application-layermulticast (ALM) for data delivery ALM utilizes the ability of end hosts that act notonly as receivers but also as senders They can forward their received data to otherhosts 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-timeconstraint, especially in live streaming applications

Many application-layer multicast protocols have been proposed recently rent application-layer multicast protocols can be divided into two classes: tree-basedapproach 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

Cur-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 packetoutage in all its descendant nodes

1

due to the variation in arrival times of different sub-streams data Another problemthat 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 thesystem).

Recently, mesh-based P2P streaming approach ([MR10], [MRW07], [VYF06],[ZXBY05], [ZLZY05], [LPA98], [CdSLMM11], [HCC10], [CJW11], [LKHT10]) hasattracted a lot of attention since it can minimize the impact of node churn and lowbandwidth of a neighbour node by pulling necessary data from a number of appro-priate neighbour nodes Each node independently selects some nodes as neighboursand pulls data from them based on an assumption that neighbour nodes may havenecessary 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 datafrom nodes in different sub-trees However, PRIME did not show clearly how is builtthe 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 thebootstrap node must store the whole information about all nodes in the network,which leads to low scalability [LKHT10] shows how to build a decentralized overlaynetwork but with the cost of increased computation complexity In addition, thesestrategies does not address problems such as long buffering time, node churn orfree-riders

Realizing this drawback in current application layer multicast methods for videostreaming, we aim to propose a push-pull based method for lower delay and better

a sub-tree based on a push mechanism Each node will receive from its parent atleast one sub-stream in the pushing phase to ensure the availability Then, a nodepulls 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 ofnodes, how to encourage nodes to contribute resources and how to deal with nodechurn

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 samelevel Here, the level of a node is defined as the path length from a sourcenode to the node Therefore, the time gap between arrival times of pushingdata 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 nodeswith more contribution will be given higher priority to receive data Hence,they can get better quality of service such as shorter buffering time or morereceived 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 eachother

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 oftime to recover from node failure

Chapter 2 presents some background in this area The description issues cludes a review of previous and current work in live video streaming.

in-Chapter 3 describes the proposed push-pull based method for P2P live videostreaming and explain how our method satisfies the problem that mentioned above.Chapter 4 describes how we set-up our simulation experiments and presentsour results and comparisons with other approaches

Chapter 5 present our conclusion and gives future research directions based onthe results obtained so far

Chapter 2

Background

In this chapter, we present the basic concepts of this thesis Firstly, we troduce a briefly overview of multicast and why multicast is the choice for videostreaming application and a comparison between IP Multicast and application layermulticast (ALM) Secondly, we discuss about current ALM solutions for P2P livevideo streaming

in-2.1 An Overview of multicast

In live video streaming applications, a source sends the same video stream to endhosts 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 incomparison with other communication mechanisms such as unicast and broadcast[HASG07] Multicast is mechanism that allows sender to send data to a group ofreceivers [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 streamingapplication Unicast allows a source to send data to a single host Video streamingapplication 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 toreceive data still receives data It causes a waste of network resources

In multicast approach (Fig 1c), data is transmitted to a set of receivers Afterreceiving 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

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 ticast in network layer) and application layer multicast (ALM)

(mul-2.1.1 IP Multicast

IP multicast [DC90] is deployed in network layer In this method, source sendsthe message only once; the network then delivers the message to all receivers Eachpacket from source is copied by the network at routers After that, routers deliverthis packet to receivers

Figure 2.2 shows an example of IP multicast Source S sends data to receiverH1, 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 todeliver 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 andits problems such as group management, address location and security For moreinformation, the reader can refer to [DLL+00]

IP Multicast approach makes the most efficient use of network resources becausethe source has to send data only once and the same message is not delivered morethan 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, routersmust be capable of processing and routing IP Multicast packets These requirementsare the main major barrier of IP Multicast’s deployment in global network becausethe cost for changing platforms is too high

2.1.2 Application layer multicast

Because IP Multicast’s deploying limitation as discussed above, many researchersshifted their focus to deploying multicast in application layer (or ALM) In ALM,end hosts are responsible for copying and forwarding data instead of intermediatemeans such as routers as in IP Multicast Each receiver receives a packet fromother receivers Then, it copies that packet and forwards to other receiver withoutknowledge of underlying network topology such as how the packet is transferred viarouter or this link has transmitted this message or not

Figure 2.3 shows an example of ALM, in which, the multicast tree is built asshown 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 Afterthat, H1 copies data and forwards to H4 via links of routers R2R3 and R3R4 H3

Figure 2.3: An example of ALMcopies 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 duplicatedata at the same link leads to waste the network resource and increase networkoverload 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 layerinformation 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 ofALM Table 2.1 shows the conceptual comparison between IP Multicast and ALM[HASG07]

Table 2.1: Conceptual comparison between IP Multicast and ALM [HASG07]

Efficiency in term of delay/bandwidth High Low MediumComplexity or overhead Low Medium - HighEase of deployment Low Medium - HighImplemented 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 P2Plive video streaming Many application-layer multicast protocols for P2P live videostreaming have been proposed recently Based on topology, current application-layer multicast protocols can be divided into two classes: tree-based approach andmesh-based approach

Here, some readers may wonder why we do not choose client-server model forlive video streaming instead of P2P model In fact, client-server model is a simplesolution for live video streaming applications In this approach, a client sets up aconnection to server or local server (such as in Content Delivery Network) and videostream 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-servermethod is very costly

Peer-to-Peer (P2P) approach has recently emerged as a new solution for videostreaming 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 receivesdata from the network, but also forwards this data to other peers This mechanismreduces the bandwidth burden on the server and utilizes the capacity of all peers inthe 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]) andwidely known such as Overcast [JGJ+00], ESM [CRZ00] or ZigZag [THD04] In thisapproach, 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 themulticast tree Nodes that is nearest to the root have level 1, then nodes have linkwith 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 higherlevel

Figure 2.4 shows an example of an application-layer multicast tree with tennodes 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, andforward 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 Themain targets while constructing a multicast tree are reducing the depth of tree andincreasing 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 treeleads 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 istoo 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 Aparticipating node can leave the network at any time without being able to predictcause of computer crashes or connection problems Then all the descendant nodescannot receive the video stream For example, if node 0 (in Fig 2.4) leaves thenetwork, all nodes 2,3,6,7,8 will be affected and could not receive data In order tominimize this impact, multicast tree needs to recover as soon as possible

Many researchers have proposed solutions to optimize tree and reduce recoveringtime In ZigZag [THD04], nodes in same level are organized into groups; each group

2.2 Application layer multicast methods for P2P live video streaming11

will select a head node When a node leaves the network, this child nodes ask headnode to find another replacement quickly However, the case that parent node andhead node leave the network at the same time is not discussed ZigZag also pointsout 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 itsgrandparent node to repair failure of parent node

Thus, some problems of single-tree based approach are solved However, animportant 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 (f

h− 1)

(f − 1) and the number of leaf nodes is f

h Thus, the fraction of leaf nodesincreases with f For example, in a tree with fanout 16, and over 90% of peers areleaves and the burden of deliver content message is carried by less than 10% of thepeers 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, thissolution does not ensure fairness between the nodes and not utilize capacity of allnodes

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 DescriptionCoding [AW01] (MDC) Instead of delivering data through a single multicast tree,source delivers data through multiple trees, each tree delivers a sub-stream Eachparticipating 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 childrenand 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 secondsub-stream to the right child 3 Nodes 1 and 2 continue push the first sub-streamthat is received from node 0 to their children nodes 3, 4, 5 and 6 Similarly, nodes 4and 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 ktimes 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 significantdisadvantages In Splitstream [CDK+03], interior nodes in a multicast tree will bethe leaf nodes of all other multicast trees Here, this design requires that all nodesmust have the same bandwidth This is impossible in real network In addition, ifthere is churn, it will be very difficult to recover multicast tree while satisfying theconstruction constraints

Recently proposal methods [BBMB+10] and [LLR09] construct the multicastbased on the bandwidth that nodes contribute In other words, node can be interiornodes in more than one tree The probability that a node is interior node in atree depends on bandwidth of this node Nevertheless, there is a trade-off betweenefficient and complexity in these methods

In addition, multi-tree based approach still has a disadvantage of long bufferingtime due to the variation in arrival times of different sub-streams’ data Anotherproblem that all multi-tree-based designs have to face is the cost of maintaining andrecovering 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]), eachnode establishes and maintains connections with a set of nodes, call as neighbournodes These connections construct a mesh that covers the entire network The

2.2 Application layer multicast methods for P2P live video streaming13

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 thismethod, when a node wants to join the network, it sends a request to bootstrapnode (that usually is source node) Then, the bootstrap generates a random list ofavailable nodes in the network and sends these nodes’ information to joining node.Joining node makes connections with these nodes and become neighbour of eachother 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 willdiscuss this later in more detail

In data delivery terms, each participating node independently selects some bour nodes and pulls data from them based on an assumption that neighbour nodesmay 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 Figure2.6 show an example of video streaming based on mesh Each node pulls data fromits neighbour node For example, node 2 pulls data from node 6

The mesh-based approach can minimize the impact of low bandwidth of a 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

neigh-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, theremay 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 neighbournodes 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 andstreaming 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 andredundancies

In order to solve this problem, frequently sending pull requests or frequentlynotifying neighbours is proposed However, there is an efficiency-delay trade-offsince this mechanism will create data overhead in this method ([VYF06], [ZLZY05]).Frequently sending pull requests or notifications leads a node get data sooner andquickly repair or detect failure of neighbour node But frequently sending pullrequests or notifications also increases network overhead

A recently work (PRIME [MR10]) proposed a hybrid mechanism These ods build a mesh overlay network and transmit a video stream, which are splitinto several smaller sub-streams, through two phases, diffusion phase and swarmingphase In diffusion phase, sub-streams are delivered by pushing data via multiplesub-trees In swarming phase, each node will pull missing data of other sub-streamsfrom nodes in different sub-trees This work can improve bandwidth bottleneck andcontent bottleneck, which is a serious problem in mesh-based approach

meth-Figure 2.7 shows an example of PRIME with 17 participating nodes [MR10].Data delivering combines diffusion phase and swarming phase Nodes are dividedinto 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

2.2 Application layer multicast methods for P2P live video streaming15

Finally, the third multicast tree consists of nodes 3, 8, 9, 16, 17 Node 12 receivesthe first sub-stream from its parent node 5 through diffusion phase Then, it pullsthe 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 inthe case that the bandwidth degree constraint does not satisfy an how to buildthe overlay network using decentralize mechanism [CdSLMM11] and [CJW11] pro-posed some different strategies to select connections but all these strategies are builtbased on the fact that the bootstrap node must store the whole information aboutall nodes in the network, which leads to low scalability [LKHT10] shows how tobuild a decentralized overlay network but with the cost of increased computationcomplexity In addition, these methods still have the problem of long buffering timesince 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

a node in our system Thus, our system can be implemented independently or inother overlay networks such as Chord, CAN or mesh

In this chapter, we describe how our multicast system is built It satisfies thefollowing 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 ofthe latest part of a segment Therefore, in our method, each node will try toestablish 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 tothe node Therefore, the time gap between arrival times of pushing data andpulling 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 higherpriority 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-tatpolicy, we construct of a balanced tree to ensure that nodes belonging todifferent 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 affectedfrom a node failure to be small, and minimize the amount of time to recoverfrom node failure

• Ensuring scalability: our mechanism is fully large-scale decentralized It doesnot require any node to keep global information about the network

Firstly, we present a brief overview about our multicast system for P2P live videostreaming

3.1 Overview

Our method takes the approach of push-pull method It constructs some separatediffusion sub-trees such that a node, except the source node, belongs to only onesub-tree Assuming that the number of sub-trees is k These sub-trees have thesame root which is the source node itself Each node also links to other nodes ofother sub-trees

The video stream from source node is divided into k sub-stream using MultipleDescription Coding (MDC) [AW01] Source node progressively generates a newsegment of content once every ∆ seconds This segment is then encoded into kparts 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 thediffusion phase of a segment, all nodes in the overlay network have at least onepart of that segment to display To improve video quality, each node then pulls themissing parts from other nodes in other sub-trees during a pulling phase The moreparts a node can pull, the better the playing quality Therefore, the pulling phaseand the pushing phase can be done simultaneously

However, the problems here are how to construct the overlay network, how eachnode selects a node to pull data and how to deal with node failure These problemsare essential since they decide the quality of video provided to each node We mustconsider these problems under the assumption that there are selfish nodes thatonly 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 bufferingtime

The next section will describe our solutions to solve these problems

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, connectionsbelonging to a sub-tree (i.e connections to a parent node and a number of childnodes) and connections to nodes of different sub-trees Each node also maintainsthe information about the list of its child nodes, the number and the highest level ofits 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 thisnumber 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 sourcenode such that the number of nodes and the highest level in each sub-tree is almostthe same This property is important since nodes belonging to different sub-treesmust exchange streaming data during the pulling phase It ensures that there areenough 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 firstlysends 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

3.2 Overlay construction 19

Then, then source node sends the information of this node to the join node Ifthere are a number of level-1 nodes which have the same parameters, the sourcenode will send the information of these nodes to the join node, which will select thetopologically nearest node among these nodes to send a join request When a nodereceives a join request, it will check if it has spare out bandwidth for the newly joinnode or not If yes, it will accept the join node as its child node If no, it will selectone or a number of child nodes based on the above priority and send information ofchild 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 bebalanced among sub-trees

We consider that users want to keep an amount of bandwidth for their ownquality 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 thebandwidth of a node is b * bwpf and the number of sub-trees is k(k ≤ b), the nodewill use a bandwidth of (k - 1) * bwpf to send its data received during diffusionphase 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 nodewill 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 exchangedata 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 - 1nodes 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’spulling node list It then sends a pulling request to these k - 1 nodes A nodewhich 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 willsend 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 alist 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 reducethe depth of the tree It is obvious that data delivering time depends on the delaytime that leaf nodes receive data The lower the level of leaf nodes, the shorter is the