STREAMCOMPLETE: an Architecture for
Mesh-based Peer-to-Peer Live Video
Streaming
指導教授：許子衡 教授
學生：王志嘉
Introduction (i)


P2P media streaming is a promising approach to
broadcasting non-interactive live media from one
source to a large number of receivers
Designing a live P2P streaming system, however,
faces many challenges:
1)
2)
2
high churn rate: peers may join or leave the system at any
time.
unlike dedicated servers, peers are limited in their uplink
bandwidth.
2016/7/13
Introduction (ii)
3)

STREAMCOMPLETE provides two important
novel distributed algorithms:
1)
2)
3
the heterogeneity of client capacities
the Fast Top procedure that improves the general
performance of the overlay intervening on the
network topology.
the Loop Check procedure that checks the presence
of bounded loops in the mesh graph.
2016/7/13
Introduction (iii)

4
The paper result demonstrates the ability of peers
of joining the system in only few seconds. All the
algorithms of network control and optimization
generate almost zero additional traffic, when
compared with data traffic
2016/7/13
Related Works (i)

The P2P streaming architectures are essentially
divided into two types:
1)
2)
5
dissemination-tree-based ones which organize the peers in
a classic tree structure, in which every peer receives the
stream from its unique parent and forward the same signal
to all its children
gossip-based ones that organize the peers in a mesh graph,
with a quite casual number of parent- and childrelationships.
2016/7/13
Related Works (ii)


6
One of the main differences between tree- and gossipbased approaches is the presence of a loop avoidance
or loop detection procedure: only tree-based systems
avoid building loops, while in the gossip case the
problem of loops in the overlay network is
completely ignored
Table I reports a synoptic view on the analyzed
academic systems.
2016/7/13
Table I
7
2016/7/13
Architecture (i)


8
The internal architecture of a STREAMCOMPLETE
peer consists of three logical layers: first, the Network
Access Objects one (NAO) exchanges control data
(using TCP)
The middle layer consists of Controller and Domain
Objects (DO), which implement all the logic of
STREAMCOMPLETE.
2016/7/13
Architecture (ii)

9
The upper layer is the View one and implements both
presentation logic and video stream control logic,
using RTP on UDP.
2016/7/13
N.A.O. Layer


It implements the logical network adapter of the peer.
On receiving a packet from another peer, the system
starts a new thread that executes the following steps:
1)
2)
10
performs the mapping between the received packet and
Java data structures and creates the appropriate objects.
analyzes the properties of these objects and invokes the
appropriate procedure of the upper application logic.
2016/7/13
D.O. & Controller Layer
11

In D.O. there are all the abstractions of the overlay
network, that is the Node and the VideoSource (a
video source peer) Java classes.

The package Controller contains all the upper
application logic and all the abstractions of the
application level control messages.
2016/7/13
View Layer


12
It realizes incoming and outgoing video streaming.
All classes are based on the Java Media Framework
(JMF) that enables audio, video and other time-based
media to be added to applications and applets built
with Java technology.
2016/7/13
Overlay Network Management (i)
13

STREAMCOMPLETE is a constant attention to the
balance of the workload across the overlay network.

The key parameter used by STREAMCOMPLETE is
the state of health, which is calculated by every node
and is disseminated within each communication.
2016/7/13
Overlay Network Management (ii)

The exact formula used is as follows (let H be
the health function):
incoming bandwidth
nominal bandwidth
valuefrom the video
number of hop
outgoing bandwidth
14
2016/7/13
source
number of suppliers
Overlay Network Management—Join (i)


Joining the system, the peers must start the other
procedures (membership and scheduling) in order to
increase their connections immediately.
There are two major steps in this procedure:
1)
15
the new node X sends the request to one or more peers on
receiving the request, a peer calculates its own available
outgoing bandwidth
2016/7/13
Overlay Network Management—Join (ii)
2)
16
it will turn itself into one of the suppliers of X. This
particular forwarding ensures that the request does not
trace the overlay network too quickly back to the center,
namely to the video-source
2016/7/13
Overlay Network Management--Membership (i)


Each peer has a partial knowledge of the network
and maintains a local view: with the membership
procedure, the peer can extend and update its own
knowledge of the other peers.
There are two major steps in this procedure:
1)
17
The peer that starts the procedure sends a
LocalViewReqMex message to all the other known peers
2016/7/13
Overlay Network Management--Membership (ii)
2)
18
the peer that receives a LocalViewReqMex message
updates its local view, checking the timestamps, and
finally replies with a LocalViewResMex message in
which there are only information unknown by the other
peer.
2016/7/13
Overlay Network Management—Scheduling (i)

The three steps of the procedure:
1)
2)
19
a peer X starts the scheduling procedure and, in this first
step, orders all its known peers that are not just suppliers or
children, by decreasing state of health; afterward, it sends
to them a StartMex message;
on receiving a StartMex message of the scheduling
procedure, a peer checks its available output bandwidth
and, if it is not too low, accepts the request.
2016/7/13
Overlay Network Management—Scheduling (ii)
3)
20
note that the number of new suppliers that the peer X can
accept is limited, so, if it receives a positive response, it
must check the current available input bandwidth.
2016/7/13
Overlay Network Management—Departure (i)



21
The overlay network must automatically reorganize
its own topology in case of departure of the peers.
The departure in STREAMCOMPLETE combines a
reduced control traffic overhead with a two-step
algorithm.
First, the peer sends a DepartureMex message to all
the nodes of its local view.
2016/7/13
Overlay Network Management—Departure (ii)

22
On receiving a DepartureMex message, a peer delete
the original sender from its own local view and then it
forwards the message with a decreased TTL to all
known peers.
2016/7/13
Overlay Optimizations

23
The Fast-Top and Loop-Check procedures represent
the main innovations introduced by
STREAMCOMPLETE in order to improve the local
and the general performance of the overlay network.
2016/7/13
Fast-Top Procedure (i)


This is a six-step procedure designed to improve the
general performance of the overlay network.
Below the details of FastTop started by peer X (see
Figure 1):
1)
24
The first step consists in the searching of the lowest health
state supplier: if the value is lower then a particular
threshold, the peer X can start the procedure sending the
request messages
2016/7/13
Fast-Top Procedure (ii)
2)
3)
4)
25
On receiving a request message, peer Y checks its current
health state to verify the real gap with its child So, peer Y
replies with a positive or negative ack message;
In case of positive ack, the peer Y itself must stop all the
video streams received from its own suppliers.
In case of negative ack message, the peer X only updates
its own local view and stops the procedure; otherwise, the
positive ack message contains the list of Y’s suppliers.
2016/7/13
Fast-Top Procedure (iii)
5)
6)
26
On receiving a positive ack message from the new
suppliers, peer X can accept the new video streams;
At same time, it must start a new video stream to peer Y
which becomes, now, a child.
2016/7/13
Fig.1
27
2016/7/13
Loop-Check Procedure


28
In a real time scenario and in particular in case of a
high cardinality, checking the presence of loops in a
generic graph is a too expensive operation.
The value of this bound is generally the size of the
local view: a peer sends a loop-check message to its
children and, if it receives the same message from a
supplier, this means that there is a loop in the overlay
network.
2016/7/13
Experimental Evaluation (i)




29
This paper fixed a set of session parameters, in
particular：
Video bit rate：30kbps to 100kbps
churn rate： In particular, ever x minutes there is a
range [w,t] of time in which peers can disconnect and
re-connect themselves with probability p
max local-view cardinality: STREAMCOMPLETE
limits the maximum local-view cardinality in a range
from 10 to 100 peers.
2016/7/13
Experimental Evaluation (ii)


30
STREAMCOMPLETE was tested into five realist
scenarios, described in Table II.
The state of health calculus is as follow (let H be the
health function)
2016/7/13
Table II
31
2016/7/13
Experimental Evaluation-Join Procedure


32
Figure 2 demonstrates the ability of peers of joining
the system and receiving the video stream in only few
seconds.
The average size of control packet is about 180 bytes,
which is irrelevant in terms of total traffic.
2016/7/13
Fig.2
33
2016/7/13
Experimental Evaluation-Fast Top

34
Figure 3 shows the performance of Fast Top. In the
different scenarios we registered times that range
from 18 to 46 seconds, including disconnections and
the re-activations of all the involved video streaming
2016/7/13
Fig.3
35
2016/7/13
Experimental Evaluation-Loop Check

36
We tested the average number of hops in the
exchange of LoopCheckMex. The results shown in
Figure 4 demonstrate that STREAMCOMPLETE, on
average, respect the small worlds property
2016/7/13
Fig.4
37
2016/7/13
Conclusion (i)


38
The importance of multimedia streaming increases
continually as well as connectivity and bandwidth
availability.
STREAMCOMPLETE has been conceived and
developed after a careful analysis of current
achievements and it merges the best practices of treeand mesh- based approaches
2016/7/13
Conclusion (ii)

39
STREAMCOMPLETE builds and manages a mesh
overlay network with a continuous local optimization
aimed at improving the general performance
2016/7/13