HYBRID PULL PUSH PEER TO PEER VIDEO STREAMING

VIETNAM NATIONAL UNIVERSITY, HANOI
STUDENT SCIENTIFIC RESEARCH CONTEST
2012
PROJECT:
HYBRID PULL PUSH PEER TO PEER VIDEO STREAMING
Student: Trinh Hai Hoa Gender: Male
Class: K53CA Faculty: Computer Science
Supervisor: Dr. Nguyen Dai Tho
2
ABSTRACT
The Peer to Peer Streaming System is using more popular in this world but most
of that existing systems still can provide the services for non-interactive
environment on the Internet. Besides, there are many ways to deal with P2P
system, which a regular way is the usage of pull and push protocols. Some
researches have investigated on these two protocols and how to interleave them
to obtain the better performances of real time streaming in peer to peer
network. In these works, they used pull protocol as to retrieve pieces of data and
push protocol as to spread the data to the entire network. These two protocols
were set to two-phase cycle which continuously switches from one push to one
pull and so on. The problem is how we know exactly that interleaving protocols
like that will give best performances or doing more pull then switch to some
push is better. In this paper, we consider a two pull and one push cycle and test
its performance on many kinds of configured network with simulator
environment.
3
PROJECT SUMMARY
Project: Hybrid Pull-Push Peer to Peer Video Streaming
Research time: 11/2011 – 3/2012
1. Motivation
Out motivation is to determine a best scenario in interleaving pull protocol and
push protocol using in video streaming. The research is around the work of choose

a suitable number of pull request before switching to send a suitable number of
push request.
2. Main content
In this project, we focus on the main properties of interleaving pull-push protocol,
depend on the piece and neighborhood selection policies; following up by
performance of peersim simulator to examine the research.
3. Research result
- Experience three scenarios of interleaving a number of pull and push request
with different type of networks in the event – based mechanism.
- With the result, the original scenario is still the best choice.
4
Table of contents
Table of figures
5
I. INTRODUCTION
Nowadays, peer to peer network is becoming more and more necessary for streaming
in human life due to some disadvantage of client-server model before. While client-
server model must need a server to control the network, and cannot spent the power of
clients computer, therefore, it cause waste to the network resources. Oppositely, peer
to peer network can build easily on the Internet, does not need much resources but it
still can serve millions users in the world. This kind of network use clients as the peer
to spread streaming data to other peers that connected to them. The most important
thing is these peers can exchange data themselves and does not need a server to
control their work, that make constructing the network is faster and also easy to
upgrade.
Besides the power of peer to peer system, along the development of the Internet,
many different P2P system were build for file-sharing like Napster, Gnutella, Kazaa
or for delivery content and video like Skype…etc. Therefore, human requirement for
streaming system is harder day by day, especially on streaming delay and bandwidth.
In order to improve the performance of peer to peer system, researchers make a lot of

works on these existing networks, about the network topology and the fundamental
properties of them, which are mentioned in [1]. In the paper the author showed that
application can be file-based or stream-based. The file-based services can be used
only when the total file is transferred, so that average throughput and also total delay
are the concern of performance. In the stream-based application, the key is how to
minimum the throughput and the latency of streaming information. Besides, in peer to
peer network, the data can be split to many smaller chunks or pieces, which make
easier transmission, also called chunk-based system.
The chunk-based peer to peer network overlay can be classified into three main
classes:
6
Push: One peer (parent) can pass a piece to its children (another peer) without
asking them which one to push. Therefore, it is efficiently when multiples pieces is
push only to same peer but others never arrive in the non-structured system. Push
is popular for the structured or tree-based network model that has long-lasting
relationship between peers.
Pull: One peer (child) instead of waiting for chunks pushed by their parent, it
actively asks for pieces from other peer (parent) but also without knowledge of
which chunks their parent have. Thus, the requested pieces may be server or not,
in the worse case, the child cannot found that piece in any of their parent, then the
data is missing at last. Pull system can deal with unstructured network, where the
peer can seek for multiple parents, exchange the information they have, and then
complete the request data.
Status-based: The peer exchange status signal to describe the download process.
For example, zero for a missed chunk and one for available chunk.
An interesting approach is interleaving the two protocols above, pull protocol and push
protocol to make a combined protocol which can give better delay guaranteed. There
are a few paper concerns about combining pull and push protocol, such as [3] and [4].
However, they used pull system to fill the entire stream data or building a structured
tree in network and push system to spread data content faster. These works does not

consider about how to interleave these two protocol mechanisms.
[1] provided a way to interleave two protocols and give examination on testing in
simulation using a piece selection policy. Depend on that, [2] make some
improvements on the selection policies, which give better performance for the peer to
peer network, especially the total delay and completion time.
Nevertheless, in this interleaving method, also the other combination methodologies,
the researchers only work on one to one protocol, that means the system did a pull and
switch to push, so on. Therefore, a problem can be seen here is: “Is the one to one pull
push combination system best for chunk based peer to peer network?” Along the result
of one to one interleaving mechanisms given in [1] and [2], this paper will do more on
simulation, and examine the different configure of peer to peer network with two pull
7
and one push strategy, then determine which is better between this and the original one
pull to one push above.
The organization of remain parts is as follow. In Section II, we describe the piece
selection policies of interleaving mechanism. Some brief description about Peersim-the
Simulator using in this paper include in section III. Section IV presents the result from
simulation and the last part, Section V will conclude the paper and give our future
works.
II. PIECES SELECTION POLICY
First, we consider that the network has only one source to produce the chunks from
total data to spread to other neighborhood. The produced pieces can be exchange
independently through the network, which are generated from source at a constant
rate, push to other peers with the determined streaming rate as simulation. At network
nodes (normal peers) the pieces can be push away to its neighbor, or can be pulled by
its neighbor too. That means each node alternate the cycle with pull and pushes
mechanism, switch between two modes, fill up their data and also spread data to other
nodes. Each node has its own contact list with size k, which is the ID of neighborhood
node that can be received the pull and push requests from it. However, a node can be
received request from another node that is not in its contact list.

In normal combination, the pieces selection policies are:
- Pull mode: a node P takes a neighbor Q and a piece randomly then send request to
pull that piece from neighbor Q. Q will accept the pull request if it has available
upload bandwidth and the requested pieces, otherwise, the request will be refused.
- Push mode: a node P selects a piece and push to a random neighborhood Q. The
neighbor Q also download that piece if it does not have it at that time and not
downloading other pieces, otherwise, the request will be refused.
The policy above has the problem when randomly select piece and neighbor, the
efficiency is not much. Therefore, in [1], the author gave the better pieces selection
strategy as below:
- In pull mode, a node P asks its neighbor for the lowest sequence number pieces, in
order to full fill the information holes in stream data.
8
- In the push mode, a node P pushes the pieces with highest sequence number
among the pieces which it received via push from its neighbor.
Here is the pseudo code of the algorithm presented in [1] for sending the pull or push
request by a node:
9
Figure : Sending out request interleaving algorithm
10
Nevertheless, the policy in [1] got problem that neighborhood selection is still
random. Thus, in research of hybrid pull and push protocol, [2] studied about a better
way to choose the neighbor as long as using the pieces selection strategies in [1]. In
this work, they provide a parameter called pushmaxID, which is an array in each node
to store the maximum ID of the chunks that exchanged between this node and its
neighborhoods. Depend on that parameter, each node can determine which neighbor
has better chance to have the chunks it need to pull or better chance to need the
chunks it want to push. Here are the algorithm graphs given in [2]:
11
Figure : Pull Cycle with full action

12
Figure : Push Cycle with full action
The given policies are:
- Pull mode: a node P chooses the chunk with lowest sequence number to pull. After
that, it chooses the neighbor in contact list which has pushmaxID bigger than the
ID of the needed piece. If the pushmaxID is zero or there are no satisfied
neighbors, the algorithm returns a random neighborhood to salvage the cycle.
13
- Push mode: a node P chooses the chunk with highest sequence number it has to
push. After that, it chooses the neighbor in contact list which has the pushmaxID
smaller than the ID of the pushed piece. If there are no satisfied neighbors, the
algorithm will return a random neighborhood to salvage the cycle.
III. SIMULATION
1. Introduction to Peersim [6]:
In [1] and [2] the researchers use peersim as the simulator to examine their works.
Peersim is a java-based system which allows users to configure much kind of
networks and simulation scenes. All we need to do is set up the parameters in
configuration file then let the simulator do the rest. Besides, Peersim is the
modulo-design, thus, developers can add more class or module to support their
own purpose, like building a new protocol or else.
2. Simulation model:
Peersim support two kind of simulation model, which are cycle based and event
based. In cycle based model, all nodes are synchronized and they work in cycle. In
each cycle, each node is activated continuously and a node can only be activated
when there are no others nodes are working. Therefore, this model can help
abstract protocols can easily be constructed and executed.
The second kind is event based model, which has the independency between all
nodes. All nodes can be work simultaneously and follow the protocol rules. The
node can add event into the queue of simulation cycle depend on the
configuration. These events can affect other nodes. This model must be

configuring some mandatory parameters such as switch time delay, event
processing protocol, network size, control protocol…etc.
3. Peersim Interfaces:
The important interfaces of Peersim are: Control, Node, Protocol, Linkable,
CDProtocol and EDProtocol.
14
o Control Interface: include two main classes: Initializers and Observers.
The Initializers class configure the initial parameters of simulation and the
Observers class is used to monitor all the actions caused by simulator.
o Node Interface: set up the network node and based attributes such as
network address, protocol. In simulation, nodes can be add or remove
automatically.
o Protocol Interface: use to identify the type of protocol, linking method
between nodes and provide ways for nodes to access their neighborhood.
o Linkable Interface: identify whether the connection between network
nodes is symmetric or asymmetric.
o CDProtocol Interface: use for cycle based simulation model.
o EDProtocol Interface: use for event based simulation model.
4. Peersim Classes:
o OverlayGrap: use for construct the linking methodology between network
nodes, which implements Linkable Interface. In simulation, OverlayGrap is
edited to build a symmetric k level network with N nodes.
o Transport: a general transmission interface that help delivery the
information from source to other nodes. Besides, there is a class called
UniformRandomTransport which help configure reliable transmission
protocol. This class has two important parameters: minimum and maximum
value of packet latency.
UnreliableTransport: allows combination with other Transport classes, for
example, UniformRandomTransport, to simulate the loss of information.
The parameter “Drop probability” in configuration file determines the

probability that information can be loss during the simulation.
o Message: also known as the simple events, which can be add o queue in a
somehow delay. The simulator will execute each event continuously in
queue follow the simulation time with a suitable protocol.
15
IV. EXPERIMENTS
1. Parameter for evaluating the performance
There are three main performance attributes:
o Completion time: is the time that a node receives all pieces of data, count
for all nodes in the network
o Maximum delay: especially in live streaming, the piece latency is so
important as the primary index of the performance. We compute the delay
for each node with all pieces. The maximum delay is the highest value of
delay between all nodes, computed by the formula:
o Successful delivery rate: because each peer alternately execute the pull
and push action, thus, we compute the successful rate of these two protocol
over the pieces:
2. Configuration file
We can easily configure the simulation by changing the parameters values in the
configuration file:
### Simulation seed
SEED 8789789465436
### MAX Simulation time
CYCLE SIZE*CHUNKS*NEW_CHUNK_DELAY
### Verbosity level
DEBUG 0
### Number of nodes in the network
SIZE 10000
### Number of chunks to transmit
CHUNKS 500

### Chunk size in bits
CHUNK_SIZE 40000
### Time in milliseconds to produce a new chunk
NEW_CHUNK_DELAY 300
16
### Nodes degree
DEGREE 32
### Message delay: min and max
MINDELAY 5
MAXDELAY 25
### Observer Step in milliseconds
OBSERVER_STEP 10000
## Time in millisecond needed for a node to switch between states:
## push -> pull and vice-versa
SWITCHTIME 4
### Maximum number of push and pull attempts
PUSHRETRY 1
PULLRETRY 1
## Dropping rate [0:1]
## Currently, this protocol does not implement any form of "message recovery"
## therefor we are working on reliable channel.
DROP 0
## Maximum number of active connections in upload and download
## Active means that the node issues either a push or pull to a target node
## push for upload and pull for download.
ACT_UP 4
ACT_DW 4
## Maximum number of passice connections in upload and download
## Passive means that the node is the target node which receives either a push or
pull request

## therefor it will either receive a chunk via push or satisfy a pull request.
PAS_DW 4
PAS_UP 4
## Window size for either push or pull active message,
## the node either proposes PUSH_WIN chunks in push
## or PULL_WIN for pull
PUSH_WIN 10
PULL_WIN 10
#- - - - - - P R O T O C O L S - - - - - -#
#############Random Generator#############
random p4s.util.RandomRLC
random.seed SEED
##########Simulator parameter#########
network.size SIZE
simulation.endtime CYCLE
17
simulation.experiments 1
simulation.timebits 16
simulation.logtime OBSERVER-STEP
simulation.stdout p4s.util.PrintLogs
## Overlay network used
protocol.link RandomizedNeighbor
protocol.link.capacity DEGREE
## Protocol used for chunks distribution
protocol.int Alternate
protocol.int.linkable link
protocol.int.transport urt
## Transport protocol used
protocol.urt UniformRandomTransportP4S
protocol.urt.mindelay MINDELAY

protocol.urt.maxdelay MAXDELAY
## Bandwidth protocol used
protocol.bwp bandwidth.BandwidthAwareProtocol
#- - - - - - I N I T I A L I Z E R S - - - - - -#
## Overlay network initializer
init.rndlink WireKOutUnd
init.rndlink.k DEGREE
init.rndlink.protocol link
## Bandwidth protocol initializer
init.bwi bandwidth.BandwidthAwareInitializer
init.bwi.protocol bwp
init.bwi.debug DEBUG
## CDF of bandwidth distribution
## separeted by commas:
## 128000,180000,290000
## 0.3,0.7,1
init.bwi.uploadBw 128000,180000,256000
init.bwi.downloadBw 640000,640000,640000
init.bwi.bandwidthPr 0.3,0.7,1
init.bwi.active_upload ACT_UP
init.bwi.active_download ACT_DW
init.bwi.passive_upload PAS_UP
init.bwi.passive_download PAS_DW
18
## the following two parameters indicate the source upload/download bandwidth
## download is useless at the source, but it exists :)
#init.bwi.srcup 128000
#init.bwi.srcdw 640000
## Chunk distribution protocol initializer
init.ii AlternateInitializer

init.ii.protocol int
init.ii.bandwidth bwp
init.ii.chunks CHUNKS
init.ii.chunk_size CHUNK_SIZE
init.ii.push_retry PUSHRETRY
init.ii.pull_retry PULLRETRY
init.ii.switchtime SWITCHTIME
init.ii.debug DEBUG
init.ii.push_window PUSH_WIN
init.ii.pull_window PULL_WIN
## 0 - no knowledge on neighbors buffer states
## 1 - total knowledge on neighbors buffer state
## 2 - hybrid knowledge on neighbors buffer state
init.ii.neighborsknow 2
init.ii.degree DEGREE
## Initializers order
include.init rndlink bwi ii
#- - - - - - C O N T R O L S - - - - - -#
## Control that produces chunks at the source
control.00 SourceObserver
control.00.protocol int
control.00.step NEW_CHUNK_DELAY
## Control collects statistics on the operation performed by
## peers in the chunk distribution process
control.04 OperationObserver
control.04.protocol int
control.04.step OBSERVER_STEP/5
control.04.size SIZE
control.04.chunks CHUNKS
## Write results at the end of each experiment

control.04.FINAL
control.04.debug DEBUG
19
## Control collects statistics on the time in
## which peers receives chunks
control.08 ChunksObserver
control.08.protocol int
control.08.step OBSERVER_STEP
control.08.size SIZE
control.08.chunks CHUNKS
control.08.degree DEGREE
## Write results at the end of each experiment
control.08.FINAL
control.08.debug DEBUG
3. Simulation experiments
In this paper, we consider the piece selection policy implemented in [2], which
provide a neighbor selection strategy depend on pushmaxID value. We run the
simulation for three scenarios: one pull then one push, one pull then two push and
two pull then one push; on three different networks: first has 1000 nodes, contact
list size is 16 and number of chunks is 500; second has 5000 nodes, contact list
size is 24 and number of chunks is 500; third has 10000 nodes, contact list size is
32 and number of chunks is 500.
The performance was computed with three main attributes: completion time,
maximum delay and successful delivery rate then draw graph follow the
cumulative distribution function (CDF) using gnuplot[5] tool.
20
a. Completion time
Figure : Overall completion time of 1000 – 500 – 16 network
For the first network with small number of nodes, we can see the performance of
one pull-two push and two pull-one push scenarios is nearly the same. Compare to

results from the original one pull-one push, the completion time is less stable when
the minimum completion time is 77 cycles but the maximum is 85 cycles. Besides,
the scenario one pull-one push still has little better completion time.
Figure : Overall completion time of 5000 – 500 – 24 network
21
The second network has some different performance compare to the first one. The
one pull-two push has smallest minimum completion time but the first scenario is
still the most stable one.
Figure : Overall completion time of 10000 – 500 – 32 network
The performance for the third network also has not much difference. Therefore,
for the completion time, the original scenario one pull – one push has got the best
effect.
b. Maximum delay
Same as the completion time, in the first network, performance of chunk delivery
delay of first scenario one pull – one push is better than the others; this indicated
that for small network, first scenario is still the best choice. For the second
network with 5000 nodes, the maximum delay is increased a little bit but still
shows the clear different between the two scenarios we consider with the original
one.
22
Figure : Chunk delivery delay of 1000 – 500 – 16 network
In the last one, 10000 nodes network, there is a clear difference that the distance
between three scenarios is narrowing. Perhaps for the bigger network, the
maximum delay is stable for every scenario.
Figure : Chunk delivery delay of 5000 – 500 – 24 network
23
Figure : Chunk delivery delay of 10000 – 500 – 32 network
c. Successful delivery rate
For the 1000 nodes and 5000 nodes network, the simulation results shown that the
scenario two pull – one push is much worse than the others, while the one pull –

one push and one pull – two push is nearly the same performance.
24
Figure : Successful delivery ratio of 1000 – 500 – 16 network
Figure : Successful delivery ratio of 5000 – 500 – 24 network
However, for the biggest network with 10000 nodes, the original scenario one pull
– one push present the worse performance than others while successful delivery
ratio is fluctuated around 24% to 39%, smaller than the remain strategies.
25
Figure : Successful delivery ratio of 10000 – 500 – 32 network
V. CONCLUSION AND FUTURE APPROACH
This paper has given the idea of interleaving pull and push protocols in interactive
environment on network. Follow the research of [1] and [2] we have two strategies for
select pieces and neighbor to execute a pull or a push.
The first one in [1] is randomly take a neighborhood then pull the lowest sequence
numbered chunk or push the highest sequence numbered chunks that node has,
exchange the information with the chosen neighbor. This scenario has weak point that
random will cause waste in bandwidths and cycle while the node cannot find the
suitable neighbor to do the action.
The second one in [2] using another parameter called pushmaxID to determine the
neighbor with greater aptitude to have or need the pieces that a node chose to push or
pull by the same piece selection policy like [1].
Nevertheless, there is a question raised that the scenario of switching between one
pull and one push in protocol of these research, is it the best? In this paper, we
examine two more scenarios that one pull – two push and two pull – one push then
compare the performance to the original one. After experience on three different
networks, we conclude that using one pull then one push in cycle time can do the
better performance.