The SIJ Transactions on Computer Networks & Communication Engineering (CNCE), Vol. 3, No. 2, February 2015
Proposing a BitTorrent-Like Protocol for
Efficient Interactive Multimedia
Streaming Applications
Ananda Görck Streit* & Carlo Kleber da Silva Rodrigues**
*Student, FATECS, University Center of Brasília – UniCEUB, Brasília, DF, BRAZIL. E-Mail: ananda{at}streit{dot}com{dot}br
**Department of Electrical and Electronics, University of the Armed Forces - ESPE, Sangolqui, Ecuador, University Center of Brasília UniCEUB, Brasília, DF, BRAZIL. E-Mail: carlokleber{at}gmail{dot}com
Abstract—Multimedia on-demand streaming applications is a trend over the Internet. However, a potential
problem arises when it comes to ensure a low-cost service delivery and a high-quality content distribution
among users. For this reason, this paper introduces a BitTorrent-like protocol named as Adaptive Window
Interactive Streaming (AWIS) to run under interactive multimedia streaming. It has two variants: AdaptiveDefinite Window Interactive Streaming (ADWIS) and Adaptive-Stretching Window Interactive Streaming
(ASWIS). These variants are mainly based on the adaption of the original piece-selection policy of the
BitTorrent protocol. The validation of the proposals is carried out by means of simulations and competitive
analysis. The final results indicate significant optimizations compared to other state-of-art protocols. For
instance, the new variants have shown a throughput optimization of up to 65.0% in scenarios where the users
are very interactive without compromising the user streaming experience.
Keywords—BitTorrent; Interactivity; Multimedia; Piece Selection; Streaming; Video-on-Demand.
Abbreviations—Adaptive Window Interactive Streaming (AWIS); Hidden Markov Model (HMM); Peer-toPeer (P2P).
I.
M
INTRODUCTION
ULTIMEDIA on-demand streaming applications
have rapidly increased traffic flow over the Internet
[Aurelius et al., 22]. This has yielded an
unprecedented demand for high-quality content distribution
among users supported by different network technologies.
The deployment of P2P systems has proven to be a real
effective solution for such a new emerging scenario. These
systems compel users to share their own resources, thus
significantly reducing the overall bandwidth requirements
encountered in the traditional client/server architectures
[Huang et al., 9; D'Acunto et al., 30].
BitTorrent [Cohen, 2], a widely used P2P protocol, is
recognized by its reputation of fast file replication. Its
operation is based on two core policies: peer selection policy
and piece selection policy. These policies encompass a very
clever cooperative incentive mechanism among users, and
still provide a fast and balanced object replication in the
network [Huang et al., 9; D’Acunto et al., 19; Xia &
Muppala, 20]. Nonetheless, the use of this protocol for ondemand streaming is not adequate [Legout et al., 6]. This is
due to the fact that real-time constraints need to be considered
to ensure a satisfactory reproduction experience. So, recent
ISSN: 2321-2403
works [Shah & Pâris, 12; Savolainen et al., 15; Hoffmann et
al., 24; Streit & Rodrigues, 29; Romero et al., 32], pursuing
to adapt the BitTorrent protocol for multimedia streaming,
have mainly focused on addressing these time requirements,
while still maintaining the well-known replication efficiency
provided by the protocol.
Although numerous works to date have competitively
compared different BitTorrent-like piece selection policies,
most of them often present their analyses on static (i.e., no
interactivity) streaming scenarios [Vlavianos et al., 7; Shah &
Pâris, 12; Savolainen et al., 15; Borghol et al., 21]. The works
of Hoffmann et al., [24] and Streit & Rodrigues [29] are
within the few examples that go further and investigate
different piece selection policies for interactive scenarios,
where users have more liberty and are allowed to execute
interactive actions during the file playback. Therefore, it is
true that there is still space for considerations and further
improvements concerning piece-selection policies to be used
in interactive scenarios.
Considering the above, this paper introduces a
BitTorrent-like protocol named as Adaptive Window
Interactive Streaming (AWIS) to run under interactive
multimedia streaming. It has two variants: Adaptive-Definite
Window Interactive Streaming (ADWIS) and Adaptive-
© 2015 | Published by The Standard International Journals (The SIJ)
28
The SIJ Transactions on Computer Networks & Communication Engineering (CNCE), Vol. 3, No. 2, February 2015
Stretching Window Interactive Streaming (ASWIS). These
variants are based on the adaption of the original pieceselection policy of the BitTorrent protocol. The validation of
these novel variants is carried out by means of simulations
and competitive analysis with two other protocols from the
literature. The final results indicate significant optimizations.
For instance, the new variants have shown a throughput
optimization of up to 65.00% in scenarios where the users are
very interactive without compromising the user streaming
experience.
The rest of this paper is structured as follows. Section 2
explains the main concepts to fully understand the BitTorrent
paradigm and its extensions to multimedia streaming. In
Section 3, several important works that influenced the new
protocols are briefly discussed. In Section 4, the new
BitTorrent-like protocol is introduced. The results and
corresponding analysis lie in Section 5. Finally, conclusions
and possible future work directions are found in Section 6.
II.
BASIS OF A BITTORRENT SYSTEM
This section explains the main concepts to fully understand
the BitTorrent paradigm and its extensions to multimedia
streaming. To this end, in what follows, it is described the
logical sequence of events that takes place, and all of the
details then involved, when a user comes for the first time to
download a file from a BitTorrent system.
To participate in the file sharing process (i.e., swarm), a
user needs to choose a static file with an extension .torrent
from an ordinary web server. This file corresponds to the real
media file the user wants to download. It keeps metadata
related to the content of interest and also the IP address of the
tracker, which is a centralized entity responsible for
coordinating the swarm peers.
The tracker facilitates the communication among all the
participants of the replication process. The existence of this
entity is what normally classifies BitTorrent as a centralized
P2P protocol, although it may be used in a decentralized
fashion with the addition of different mechanisms provided
by some modern clients (e.g., uTorrent, Azureus, BitComet)
[Zhang et al., 23].
A newcomer user requests a list of random peers
participating in the swarm to the tracker and starts inviting
the peers from the list to establish connections with him. It is
at this time that the user makes the other participants aware of
his existence inside the swarm. Every time an invitation is
accepted, the user adds the peer to his neighbor set. This set
contains the swarm peers the user knows about. For ease of
explanation, a remote peer is considered herein to be a peer
inside the neighbor set of a local peer.
The number of remote peers may vary. By default, the
protocol defines a minimum of 20 and a maximum of 80
peers. Only 40 connection invitations may be though sent by
the user, opening space for him to accept 40 more invitations
sent by other peers. In the end, the whole swarm can be
viewed as a big system containing several interconnected
ISSN: 2321-2403
mini-systems representing the neighbor set of each peer
[Rodrigues, 34].
When the user is settled inside the swarm and connected
with different peers, he may start exchanging content with its
neighbors using the techniques determined by the
BitTorrent’s policies. The peer selection policy uses the
choke algorithm as a strategy to select the peers inside the
neighbor set. This algorithm, also called tit-for-that, focuses
on promoting reciprocation between connected peers. The
idea is to incentive them to cooperate and share their own
resources by providing them higher download rates according
to how high their upload rates are.
A local peer only unchokes peers which belong to its
neighbor set and are interested in the parts of the file it has. It
may happen that a remote peer is also choked. This means it
is interested in the user but it was not elected to receive
resources. By default, all the peers run this evaluation at
regular intervals, typically of 10 seconds, and select four
interested neighbor peers to share resources with. The choke
algorithm also sets optimistic intervals to promote the
discovery of better neighboring peers. In this case, the
selection occurs at random for solely one interested peer and,
by default, at every 30 seconds.
How the parts of a file are chosen for download is what
is named the piece-selection policy. BitTorrent specifies that
a file is divided into pieces of typically 256.0 kB and,
subsequently, each piece is split into blocks of 16.0kB in size.
Each peer knows what pieces all the other peers belonging to
its peer set have. Thus, there are several ways a peer can
choose which pieces it may ask for download. Note that the
selection occurs at the piece level, while the transmission unit
corresponds to the blocks, where typically five-block requests
are pipelined at once in order the avoid latency between the
exchange of pieces.
The main strategy specified by BitTorrent for the
selection of pieces is called rarest first. The idea is to select
the less replicated pieces in the neighborhood of the local
peer. The local peer must first be unchoked by a remote peer
and, only then, may choose the rarest piece available on that
remote peer, even if this piece is not the globally rarest one
[Rodrigues, 34]. Nevertheless, this strategy is essential and
highly influences the success of the piece-selection strategy
of BitTorrent, avoiding cases where the swarm does not
contain all the pieces available among its participants [Legout
et al., 6].
To end this subsection, the concepts of seed and leecher
are explained. A seed is a peer already possessing the entire
file and, therefore, does not need to make any download
requests to its neighbors. The presence of at least one seed is
important when starting a new swarm. On the other hand, the
leecher is a peer that still has not finished the download of the
file. A new peer starts as a leecher and normally ends up
being a seed.
© 2015 | Published by The Standard International Journals (The SIJ)
29
The SIJ Transactions on Computer Networks & Communication Engineering (CNCE), Vol. 3, No. 2, February 2015
III.
RELATED WORK
This section briefly explains some of the main BitTorrent-like
piece-selection protocols designed when adapting the
BitTorrent protocol for multimedia streaming applications.
Despite the fact that some of these policies are not designed
for interactive scenarios, they represent some of the state-ofart algorithms belonging to this area of study.
The policies are divided in three categories: (1) window;
(2) priority; and (3) probability. The application of the
window category is really evident in numerous works from
the literature, to mention a few: Shah & Pâris [12],
Savolainen et al., [15], Borghol et al., [21], Hoffmann et al.,
[24], Streit & Rodrigues [29], and Rodrigues [35]. These
works are mostly characterized by a sliding window
comprising pieces that should be downloaded with higher
priority since they are usually close (in time) to be played by
the user. As the download progresses, the window
dynamically slides through the media file, encompassing new
pieces which were not yet downloaded by the user.
For example, Shah & Pâris [12] present a fixed window
size containing high-priority pieces. The rarest-first policy is
used for selecting pieces inside the window, which slides
through the media file until it reaches the next not recovered
piece. This proposal is designed for static scenarios. As an
example of interactive scenarios using the window category,
the work of Hoffmann et al., [24] presents two window sets:
playback window and prevision window. Both of them have a
fixed size of pieces inside its limits. Besides, these windows
are chosen alternately and, once one of them is elected, the
rarest-first strategy is applied. The playback window follows
the playback point, sliding if its first piece is recovered or if
the user executes an interactive action. However, the
prevision window innovates when considers a user prediction
behavior model based on hierarchical HMM (Hidden Markov
Model) [de Vielmond et al., 10].
The priority category features pieces divided into
different sets. Each set determines a specific priority to more
efficiently decide the next piece to request and which piece
selection strategy to use. For example, Mol et al., [14] define
three sets of priorities to the pieces close to be played. The
pieces of these sets (namely high priority, mid priority and
low priority) are selected for download following the highest
priorities. At first, the pieces of the high-priority set have to
be received, following the in-order piece selection strategy in
case the user has already set play, or the rarest first otherwise.
The in-order strategy differs from the rarest first strategy and,
as implicit in its name, it refers to a sequential retrieval of
pieces. After that, it is time to select the pieces of the midpriority set using the rarest-first piece selection strategy. Only
then, the low priority pieces may be selected, also following
the rarest-first piece selection strategy. Both sizes of the high
and mid priorities are fixed and related to two different and
fixed parameters. The size of the low priority set is not fixed,
since it begins in the subsequent piece of the end of the mid
set and ends in the last piece of the file.
ISSN: 2321-2403
The probability category is characterized by the use of a
probability distribution for the piece selection. For example,
Charls et al., [16] designs a piece-selection protocol with the
Zipf probability distribution. In the probability distribution
expression, it is utilized a parameter, identified by 𝜃, which
corresponds to the size of the set. If θ is a fixed parameter,
then the set is also fixed. The use of probabilities for the
selection of pieces and sets are also mentioned, for instance,
in the works of Vlavianos et al., [7], Carlsson & Eager [11]
and Hoffmann et al., [24].
Finally, relatively recent works [Ma et al., 28; D'Acunto
30] have proven the differences achieved in the overall
system performance when distinct piece and peer selection
strategies are composed and tested in conjunction. Not only
the piece selection policy needs to be adapted for on-demand
streaming multimedia applications, but also the original peer
selection policy of BitTorrent can drastically change the
system dynamics of these applications. If the reader is
interested, it is possible to check the studies of Rocha &
Rodrigues [31], Rodrigues [34] and Rodrigues [35], where
some insights about different BitTorrent-like peer selection
policies that may completely change how the reciprocation
and the potential piece exchange between peers may be
affected.
IV.
ADAPTIVE WINDOW INTERACTIVE
STREAMING
This section introduces the novel protocol: BitTorrent-like
protocol named as Adaptive Window Interactive Streaming
(AWIS), for interactive multimedia streaming. As already
mentioned, it has two variants: Adaptive-Definite Window
Interactive Streaming (ADWIS) and Adaptive-Stretching
Window Interactive Streaming (ASWIS).
The AWIS protocol utilizes two windows to delimit two
different priority sets: the high and the low priority sets,
respectively. The playback window covers the high-priority
set and, as the name implies, follows the playback point. It
has an adaptive size rather than a fixed quantity of pieces
inside its limits during the playback. Therefore, it updates its
size according to Equations 1 and 2, defined in the following.
(1)
𝑤𝑚𝑖𝑛 = 𝑚𝑎𝑥 𝑘𝑚𝑖𝑛 𝑑 − 𝑟 − 𝜃 , 0 + 𝑣𝑚𝑖𝑛
(2)
𝑤𝑚𝑎𝑥 = max 𝑘𝑚𝑎𝑥 𝑑 − 𝑟 − 𝜃 , 0 + 𝑣𝑚𝑖𝑛
where: 𝑑 is the last contiguous recovered piece; 𝑟 is the
playback position (i.e., the piece that is currently being
played back); 𝜃 is the threshold that places a lower bound on
the number of contiguous pieces required before 𝑤𝑚𝑖𝑛 and
𝑤𝑚𝑎𝑥 can grow; 𝑘𝑚𝑖𝑛 and 𝑘𝑚𝑎𝑥 are the scaling coefficients;
and 𝑣𝑚𝑖𝑛 is the pre-defined minimum size for 𝑤𝑚𝑖𝑛 and
𝑤𝑚𝑎𝑥 .
The prevision window has a fixed size. It follows a user
behavior model and it is updated every time the user makes
an interactive action. This update is relative to the point
predicted by the user behavior model. The goal is to supply
the user with pieces he might request in the future, avoiding
© 2015 | Published by The Standard International Journals (The SIJ)
30
The SIJ Transactions on Computer Networks & Communication Engineering (CNCE), Vol. 3, No. 2, February 2015
interruptions in case he jumps. Both low and high priority
sets follow the rarest-first strategy for the selection of pieces.
Figure 2 is a general guideline for understanding the
operation of the AWIS protocol. Procedure 1 describes how
the window selection happens. As mentioned, this selection
depends on a probability that can be influenced by different
indicators, for example: the number of interruptions suffered
by the user, the download velocity achieved inside the
reproduction window, and the number of jump requests.
The probability of selecting the playback window is set
to one only when the user suffers an interruption, that is,
when the next piece to be played is not recovered in time by
him. As described in Step 3, the playback is paused and the
pieces of the reproduction window have priority to be
downloaded. At this moment, the reproduction window does
not slide, even if its first piece is recovered. Only when the
user downloads all the pieces inside it, the playback returns,
and pieces from the prevision window can be then selected
for download again.
This work subdivides the AWIS protocol in order to
emphasize a property referred here as stretching. Stretching
means the expansion of the size of a window. It occurs to
maintain the same amount of not recovered pieces inside the
window in case a piece is recovered and the window does not
slide.
This above property is clearly observed in the playback
window of one of the AWIS's variants, named as AdaptiveStretching Window Interactive Streaming (ASWIS). ASWIS
determines that 𝑘𝑚𝑎𝑥 is always bigger than 𝑘𝑚𝑖𝑛 and,
therefore, that 𝑤𝑚𝑎𝑥 is always bigger than 𝑤𝑚𝑖𝑛 . The other
variant is named as Adaptive-Definite Window Interactive
Streaming (ADWIS) and, in contrast, does not exhibit the
stretching property. Thus, the playback window keeps the
coefficients 𝑘𝑚𝑖𝑛 and 𝑘𝑚𝑎𝑥 with equal values. This way, the
limits 𝑤𝑚𝑖𝑛 and 𝑤𝑚𝑎𝑥 end up sustaining the same value. Note
that 𝑘𝑚𝑖𝑛 must not be greater than 𝑘𝑚𝑎𝑥 .
Step 1: Startup delay:
a. Starting position is chosen.
Initialization
b. Playback point and playback window are placed in the chosen the position
c. Local peer requests all the pieces inside the playback window using rarest first strategy. The window
does not slide. To ensure a low delay, the playback window assumes its minimum size.
Step 2: Interactive Actions
Play or Jump (forward or backwards):
Repeat
a. Playback point is updated to the position chosen and playback window is placed over the first not
recovered piece starting from this point.
b. User behavior model verifies the playback position and returns prevision point. Prevision window is
placed in this point.
Step 3: Interruption, when piece is not downloaded in time to be played.
a. Playback is paused.
After playback
started
b. Local peer requests all the pieces not yet downloaded (inside the playback window) using rarest first
strategy. The window does not slide. To ensure a low delay, the playback window assumes its
minimum size.
c. Playback resumes.
Until local peer
stops playback
Step 4: Piece from playback window downloaded
a. If local peer is not interrupted or if local peer is interrupted and received the last not recovered piece
from playback window, then playback window slides and updates its size, if necessary.
Step 5: Piece from prevision window downloaded:
a. Prevision window slides and updates its size, if necessary.
Procedure 1: Window selection, it happens every time a local peer downloads a piece or executes a jump.
a. Define in which window set the next piece for download will be. This selection is based on probabilities. The window with
higher probability for selection is the one with higher priority.
b. If local peer is initializing or interrupted, the playback window set is selected with probability equal to1.
Procedure 2: Piece Selection, happens every time a local peer is unchoked by a remote peer.
a. The local peer verifies the pieces available at the remote peer.
b. If neighbor has at least a piece the local peer does not have inside the window elected for selection, local peer selects the rarest
one.
c. Local peer request remote peer the selected piece.
Figure 2: Overall Operation of AWIS
Figure 3 graphically illustrates the stretching property
and highlights the main differences between the playback
windows of both of the variants. In Figure 3(a) (for the
ADWIS proposal), each line represents a different size. The
window has bigger sizes only when it surpasses the threshold
ISSN: 2321-2403
𝜃 of consecutive recovered pieces from the playback position.
That means that the user has achieved a good download
performance. The decreasing lines represent the behavior of
the playback window when more pieces are recovered inside
it. In this situation, as pieces are received by the user, the
© 2015 | Published by The Standard International Journals (The SIJ)
31
The SIJ Transactions on Computer Networks & Communication Engineering (CNCE), Vol. 3, No. 2, February 2015
Number of not recovered
pieces
number of not recovered pieces decreases and the number of
recovered pieces increases in a compensatory way. The
distance between these lines refers to how scalable the
coefficients 𝑘𝑚𝑖𝑛 and 𝑘𝑚𝑎𝑥 are. Moreover, the cross markers
represents all the possible playback window sizes, always
with 𝑤𝑚𝑖𝑛 = 𝑤𝑚𝑎𝑥 .
On the other hand, the big black dots in Figure 3(b)(for
the ASWIS proposal) represent the different values for the
limit 𝑤𝑚𝑎𝑥 achieved, when adapting its value under the
Equation 2. Until the playback window covers the same
amount of pieces represented by a dot, its size can stretch
between the cross markers line, in function of the number of
downloaded pieces inside the window. The better the user’s
download rate is, the greater the stretching interval is.
Besides, as the stretching interval gets larger, users can select
for download different pieces that are not necessarily close in
time to the playback position. The cross markers represents
the situations in which 𝑤𝑚𝑖𝑛 = 𝑤𝑚𝑎𝑥 . The decreasing lines of
this graph represent the behavior of the playback window
when it has already reached 𝑤𝑚𝑎𝑥 , and so more pieces are
recovered inside it.
(a) ADWIS: Playback Window
9
7
5
3
1
-1
0
2
4
6
8
Number of not recovered
pieces
Number of recovered pieces
(b) ASWIS: Playback Window
8
6
4
2
0
0
5
10
Number of recovered pieces
Figure 3: Playback Windows from ADWIS and ASWIS
For instance, the small change between the AWIS's
variants may generate different outcomes and benefits to the
user. The non-stretchable window from ADWIS is
characterized to remain with a constant size for a longer time
as it only considers changing its size when the variables 𝑤𝑚𝑖𝑛
and 𝑤𝑚𝑎𝑥 are both updated. This is due to variations in the
system dynamics and/or in the user's download capacity.
Therefore, the ability to stretch is used by ASWIS as a tool to
enhance the piece diversity in the swarm.
ISSN: 2321-2403
V.
PERFORMANCE EVALUATION
5.1. Simulation Scenario and Workloads
To define fair and realistic simulation scenarios, it is
important to analyze real streaming multimedia workloads, as
already done by several works in the literature [Almeida et
al., 1; Costa et al., 3; Guo et al., 4; Rocha et al., 5; García et
al., 13; Cha et al., 18; Zhang et al., 23; Varvello et al., 26;
Chen et al., 33]. One of the real world aspects considered in
the simulations to follow is the user's interactive behavior
during the file playback.
Rocha et al., [5], for example, mention that users of real
media services typically do not access the media sequentially,
but often tend to execute interactive actions. Their research
distinguishes real workloads in three different categories:
high, medium and low interactivities, respectively. They
observe that the workloads of the first category normally
have streaming sessions with at least three interactive
requests and average request duration under 20.0% of the
media file duration. The medium interactivity workloads
present typically less than three interactive requests, with
average request duration under 20.0% of the media duration.
And the low interactivity workloads usually present less than
two interactive actions per streaming session, with average
request duration of at least 20.0% of the media file duration.
Another important characterization is the swarm size.
For example, Zhang et al., [23] investigates a large amount of
data measured from five of the most popular torrent
discovery sites (Mininova, Pirate Bay, Torrent Reactor,
BTmonster, and Torrent Portal). They find out that contents’
popularity normally follow a long-tail distribution. Their data
has shown that about 82.0% of the torrents have no more than
10 peers and only about 1.0% of the torrents have more than
100 peers.
Moreover, the study of Hoßfeld et al., [25] suggests that
there is a clear relationship between the file size and the
swarm size. The larger the content offered, the larger the
average and maximum number of peers sharing this content
in a swarm are. For characterizing the content size, Wang et
al., [27] measures and analyzes real BitTorrent swarm
systems. They conclude that, for video contents, 90.0% are
larger than 100.0 MB, 5.0% are larger than 10.0 GB, and the
maximum video reaches nearly 20.0 GB. On the other hand,
for non-video contents, only 30.0% are larger than 100.0 MB,
over 50.0% are less than 20.0 MB, whereas those small
contents are very few in the existing video file swarms.
The simulation scenario herein considered admits that
each reproduction begins with a play interaction and
continues up to the end of the media or to a stop interaction.
During the streaming sessions users can perform intermediate
actions: Play, Stop, Pause, Jump Forwards (JF) and Jump
Backwards (JB). It is not considered actions like Fast
Forwarding and Fast Rewinding, once it is very rare that
users execute them [Costa et al., 3].
The workloads used in the simulations are synthetic and
created separately according to the interactive level. They are
generated using a user interactive model based on the work of
© 2015 | Published by The Standard International Journals (The SIJ)
32
The SIJ Transactions on Computer Networks & Communication Engineering (CNCE), Vol. 3, No. 2, February 2015
Rodrigues [8]. This model has five different states, each of
them corresponding to one of the interactive actions
mentioned above. The duration of each state is defined by
exponential distributions of mean 𝑑𝑖 , 𝑖 = 0, … ,4, and the
transitions between these states occur with probabilities 𝑝𝑖 ,
𝑖 = 0, … ,4.
This work also considers an HMM model [de Vielmond
et al., 10] in order to categorize the user in different
interactive levels: High Interactivity (HI), Medium
Interactivity (MI) and Low Interactivity (LI). This
categorization depends on how many requests the user
makes. Based on the above findings of past works, Table 1
presents the main parameters involved in each of the aspects
considered: content, interactivity, and the BitTorrent swarm
itself. The choice of each parameter value is conditioned to a
general media streaming scenario.
Table 1: Scenario Characterization Parameters for a General Media
Streaming Scenario
Aspect
Symbol
Definition
Value
Content size,
20.0 MB
𝑂𝑠
measured in bytes
Piece size,
256.0 KB
𝑝𝑠
measured in bytes
Content
Block size,
16.0 KB
𝑏𝑠
measured in bytes
Reproduction rate,
𝑅𝑟𝑒𝑝
measured in bits per
240.0Kbps
second
𝐼𝑝
Interactive profile
HI
MI
LI
Mean exponentional
time in state Play, in 1.20 1.70 2.20
𝑑0
seconds
Mean exponentional
time in state Stop,
0.00 0.00 0.00
𝑑1
in seconds
Mean exponentional
time in state Pause, 1.00 1.00 1.00
𝑑2
in seconds
Mean exponentional
time in state JB, in
0.75 0.75 0.75
𝑑3
seconds
Mean exponentional
time in state JF, in
0.75 0.75 0.75
𝑑4
Interactivity
seconds
Transition
probability from
0.35 0.60 0.85
𝑝0
Play to Play
Transition
probability from
0.05 0.04 0.02
𝑝1
Play to Stop
Transition
probability from
0.20 0.12 0.04
𝑝2
Play to Pause
Transition
probability from
0.20 0.12 0.04
𝑝3
Play to JB
Transition
probability from
0.20 0.12 0.04
𝑝4
Play to JF
ISSN: 2321-2403
𝑛
𝑚
BitTorrent
swarm
𝑅𝑑𝑜𝑤𝑛
𝑅𝑢𝑝
Number of seeders
in the swarm
Number of leechers
in the swarm
Download rate
(leechers or
seeders), measured
in bits per second
Upload rate
(leechers or
seeders), measured
in bits per second
1
7
240.0 Kbps
240.0 Kbps
5.2. Simulation Setup and Performance Metrics
Three different policies are designed and simulated on top of
the Tangram-II modeling environment [de Souza e Silva et
al., 17]. One of them is the novel proposal AWIS introduced
here, distinctly emphasizing both variants ADWIS and
ASWIS. The other two policies are Shah & Paris [12] and
BIP-S [Hoffmann et al., 24], chosen in order to provide a
more complete and competitive analysis of the new proposed
variants.
The results and analysis discussed herein are focused on
the piece selection policy. The performance metrics used,
further discussed in this section, also drive the analysis solely
to this policy. However, the system dynamics highly depend
on the relation and on the performance achieved by both
policies (i.e., piece and peer policies). If both policies are not
modeled, the results obtained would not be accurate and
would not correspond to the ones obtained in a real
BitTorrent application. Therefore, the original BitTorrent
peer selection policy is also included in all the proposed
models.
Additionally, the system to be evaluated in the
simulations is considered to be in steady state. This means
that even when peers join and leave the system, the number
of active peers, represented by the sum of the parameters 𝑚
and 𝑛, stays constant. Thus, the total number of peers
emulated in a simulation run is different from the total
number of simultaneous active peers.Finally, the simulation
results have confidence intervals of 95.0%, which are within
5.0% around the average of the metric values presented.
The numerical values in Table 2 are mostly gleaned from
past literature works [Shah & Pâris, 12; Hoffmann et al., 24]
as well as from extensive experiments carried out during the
elaboration of this text (not presented herein due to the sake
of objectivity). For determining the number of
pieces𝑣𝑚𝑖𝑛 ,𝑤𝑝𝑙𝑎𝑦 and 𝑤𝑝𝑟𝑒𝑣 have, Shah & Pâris [12] finds
that the optimal window size is 8.0% of the file size. Note
that 𝑤𝑝𝑙𝑎𝑦 and 𝑤𝑝𝑟𝑒𝑣 refer to the size of the reproduction and
prevision window, respectively. The variables 𝑘𝑚𝑖𝑛 , 𝑘𝑚𝑎𝑥
and 𝜃also refer to a specific number of pieces and their values
are chosen based on the work of Borghol et al., [21]. At last,
the performance metrics used in the simulations are defined
in Table 3.
© 2015 | Published by The Standard International Journals (The SIJ)
33
The SIJ Transactions on Computer Networks & Communication Engineering (CNCE), Vol. 3, No. 2, February 2015
Table 2: Parameter Values of each Piece Selection Policies
AWIS (Variant ADWIS)
𝑤𝑝𝑟𝑒𝑣
𝑣𝑚𝑖𝑛
7
5
Metric
Efficiency
Retrieving
Coefficient
Mean Number
of
Interruptions
Mean Time to
Return
Number of
Peers Served
𝑘𝑚𝑖𝑛
1
AWIS (Variant ASWIS)
𝑘𝑚𝑎𝑥
𝜃
1
3
𝑤𝑝𝑟𝑒𝑣
𝑣𝑚𝑖𝑛
7
5
Table 3: Performance Metrics
Notation
Definition
Evaluates the download efficiency
achieved by the peers in comparison
to a situation where the file retrieving
ERC
process occurs under an exclusive
data-delivery channel, when the peers
do not suffer from playback
interruptions.
Average number of missing data
pieces occurred in a simulation run,
NI
considering all the peers that
participated in the swarm.
Average delay time suffered by all the
TR
peers in a simulation run after an
interruption. Measured in minutes.
Mainly used to see whether an
PS
expressive number of peers have been
served during the whole simulation.
5.3. Results and Competitive Analysis
5.3.1. Competitiveness between ADWIS and ASWIS
In this subsection, the focus lies on the analysis of the
variants ADWIS and ASWIS. Four different cases are
considered: 𝑝(0.80), 𝑝(0.90), 𝑝(1.00), and no prevision
window. The higher 𝑝 is, the higher the chance of selecting
the playback window becomes. The Case 𝑝(1.00) differs
𝑘𝑚𝑖𝑛
𝑘𝑚𝑎𝑥
1
𝜃
2
SHAHPARIS
𝑤𝑝𝑙𝑎𝑦
3
7
BIP-S
LI
MI
HI
𝑤𝑝𝑙𝑎𝑦
7
7
7
𝑤𝑝𝑟𝑒𝑣
12
3
2
from the case with no prevision window since it still allows
the selection of the prevision window in some specific
situations; for example, when the playback window reaches
the end of the file and has already recovered all the pieces
inside it.
Figures 4 and 5 plot the average values obtained for ERC
and NI with distinct probabilities for selecting the playback
window instead of the prevision window. On one hand, it is
clear that the performances of both variants are quite similar
for ERC. On the other hand, it is observed a clear distinction
between ADWIS and ASWIS for the NI. Observe that there
is an inverse relation between ERC and NI. The Case
𝑝(0.80) frequently presents the worst performance for the
metric NI, immediately followed by the Case 𝑝(0.90).
Besides, it is observed that Case 𝑝(1.00) and that with no
prevision window perform similarly. Altogether, these
observations suggest that the preview window may be
unnecessary because introduces system complexity with no
corresponding gain.
Finally, note that NI is usually higher for less interactive
users, and it gets lower as more interactive the user becomes.
This can be justified by the frequency in which some pieces
are watched more than once in a same user session. For
example, a high interactive user tends to watch some parts of
the file more than once because he has a higher probability of
executing JB than a low-interactive user.
0.90
0.90
0.93
0.92
0.88
0.90
0.92
0.91
0.89
0.91
0.92
0.88
0.89
0.92
0.90
0.89
1.00
0.87
0.90
0.87
0.84
ERC
1.50
0.91
0.85
0.86
0.87
2.00
ADWIS
ASWIS
ADWIS
ASWIS
ADWIS
ASWIS
0.50
p(0.80)
p(0.90)
p(1.00)
No Prev
0.00
1.32
1.08
0.86
0.95
p(0.80)
1.28
1.00
0.80
0.75
1.85
1.42
1.13
1.40
1.40
1.57
1.63
1.17
1.11
NI
2.10
2.38
1.85
1.97
2.36
2.80
1.79
2.15
1.96
1.61
Figure 4: ERC for Distinct Probabilities
p(0.90)
p(1.00)
0.70
No Prev
0.00
ADWIS
ASWIS
ADWIS
ASWIS
ADWIS
ASWIS
Figure 5: NI for Distinct Probabilities
ISSN: 2321-2403
© 2015 | Published by The Standard International Journals (The SIJ)
34
ISSN: 2321-2403
MI
(a)
0.88
0.89
LI
0.25
0.39
0.34
0.69
0.92
0.91
ERC
0.50
HI
1.51
0.75
0.95
0.73
1.00
1.77
1.11
1.40
2.49
1.61
2.36
0.58
NI
2.00
1.03
3.00
0.00
LI
MI
(b)
HI
Shah-Paris
BIP-S
ADWIS No
Prev
ASWIS No
Prev
LI
MI
HI
(b)
0.43
0.58
22.65
13.10
HI
33
45
38
LI
MI
65
84
84
67
80
75
100
80
60
40
20
0
(a)
84
81
3.41
0.94
1.35
25.00
20.00
15.00
10.00
5.00
0.00
17.55
4.25
0.43
0.44
15.12
Figure 6 (a): ERC for Distinct Policies; (b): NI for Distinct Policies
40
This subsection has the prior goal to understand if the
variants ADWIS and ASWIS from the novel proposal AWIS
are competitive comparing to two state-of-art piece selection
policies: Shah-Paris and BIP-S. Taking into account the
results observed in the last subsection, it is herein decided to
consider for evaluation only the condition with no prevision
window for both variants ADSWS and ASWIS.
Comparing the values obtained for ERC in Figure 6(a), it
is clear that the variants ADWIS and ASWIS outperform the
two other literature protocols, no matter the interactivity level
is. For instance, they have shown an improvement of about
50.0% compared to BIP-S, and of about 65.0% compared to
Shah-Paris in scenarios where the users are very interactive.
BIP-S performs better than Shah-Paris because it provides a
second window for the selection of pieces, consequently
enhancing the system throughput. However, since the
playback window of BIP-S does not adapt or enlarge its size,
its performance does not overcome the one provided by
AWIS.
As for NI, referred in Figure 6 (b), Shah-Paris achieves
the best results. However as the interactive profile gets
higher, the difference between Shah-Paris and the variants
ADWIS and ASWIS gets smaller. In fact, the variants rapidly
decrease their NI. A partial conclusion is that protocols that
make use of a playback adaptive window can recover a more
diverse set of pieces without compromising the user
experience. Note that ADWIS present better results than
ASWIS. This particularly happens because ADWIS does not
stretch its playback window as done by ASWIS. It only
enlarges or shrinks in accordance with the user's download
performance.
Figure 7(a) depicts the average time to return (TI). It may
be seen that, even though Shah-Paris presents the less average
number of interruptions, it still has the greater average time to
return from an interruption. This is already expected since
Shah-Paris does not encourage piece diversity in the system
in comparison to the other proposals. BIP-S has a better
performance than Shah-Paris. This is basically due to the
employment of a second recovery set. The variants have a
good performance because of their adaptive nature, enabling
the window to change its size whenever it is advantageous.
1.00
0.00
TR
5.3.2. Overall Competitive Analysis
1.50
PS
Considering the above, both ADWIS and ASWIS
variants present better results in Case 𝑝(1.00) and that with
no prevision window. There is not a significant difference
between both cases for both variants, indicating that the
condition with no prevision window should be pointed out as
the most adequate alternative for ADWIS and ASWIS, since
it clearly shows one of the best performances without
increasing the system complexity for the selection of pieces.
Besides, in case of choosing one of these variants, the
ADWIS should be identified as the most interesting choice,
once it usually shows a better performance compared to
ASWIS for the condition with no prevision; besides, it
preserves a good throughput level in the system according to
the ERC metric.
0.40
0.77
0.87
0.84
The SIJ Transactions on Computer Networks & Communication Engineering (CNCE), Vol. 3, No. 2, February 2015
ShahParis
BIP-S
ADWIS
No Prev
ASWIS
No Prev
Figure 7 (a): TR for Distinct Policies; (b): PS for Distinct Policies
Finally, the results observed for the metric PS agree with
the previous statements presented in this subsection. The
protocols which promote piece diversity and enhance the
bartering ability of the peers tend to have a higher throughput
and a higher ERC. Thus, more users are able to participate in
the swarm during the same amount of time. Nevertheless, the
variant ADWIS without prevision window can be pointed out
as the most adequate alternative among the others analyzed
herein, since it is the one that best maintains a good
equilibrium between user experience and system throughput.
VI.
CONCLUSIONS AND FUTURE WORK
This work presented a novel BitTorrent-like protocol for
interactive multimedia streaming: the Adaptive Window
Interactive Streaming (AWIS). An adaptive playback
window, which follows the playback point, as well as a
prevision window confining parts of the file expected to be
watched soon by the user, determined by a behavior model,
are its main design concepts. The target is to promote a good
trade-off between playback continuity and data diversity.
© 2015 | Published by The Standard International Journals (The SIJ)
35
The SIJ Transactions on Computer Networks & Communication Engineering (CNCE), Vol. 3, No. 2, February 2015
Additionally, it has two variants named as Adaptive-Definite
Window Interactive Streaming (ADWIS) and AdaptiveStretching Window Interactive Streaming (ASWIS). The
ASWIS variant differentiates from the ADWIS since the
former promotes a stretching playback window which may
enlarge its size to optimize system piece diversity.
Two important conclusions may be highlighted among
those obtained in this work. First, both variants of the AWIS
proposal showed to be very competitive compared to some of
the
literature
state-of-art
piece-selection
policies,
outperforming them in most of the experiments carried out
herein. For example, they have shown a throughput
optimization of up to 65.0% in scenarios where the users are
very interactive without compromising the user streaming
experience. This indicates that employing an adaptive
playback window is really important, especially in high
interactive scenarios. Second, the prevision window has
turned out to be an unnecessary complement to the novel
proposal, provided that it enhances the system complexity
with no corresponding gain.
Finally, future work may include further analysis in more
distinct simulation scenarios to better understand its
properties and operation, including systems with much larger
files and with a higher number of users with heterogeneous
download and upload capacities.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
J.M. Almeida, J. Krueger, D.L. Eager & M.K. Vernon (2001),
“Analysis of Educational Media Server Workloads”,
Proceedings of the 11th international workshop on Network
and Operating Systems Support for Digital Audio and Video,
Pp. 21–30.
B. Cohen (2003), “Incentives Build Robustness in BitTorrent”,
Workshop on Economics of Peer-to-Peer Systems, Vol. 6, Pp.
68–72.
C.P. Costa, I.S. Cunha, A. Borges, C.V. Ramos, M.M. Rocha,
J.M Almeida & B. Ribeiro-Neto (2004), “Analyzing Client
Interactivity in Streaming Media”, Proceedings of the 13th
International Conference on World Wide Web, Pp. 534–543.
L. Guo, S. Chen, Z. Xiao, E. Tan, X. Ding & X. Zhang (2005),
“Measurements, Analysis, and Modeling of BitTorrent-Like
Systems”, Proceedings of the 5th ACM SIGCOMM Conference
on Internet Measurement, Pp. 4.
M. Rocha, M. Maia, Í. Cunha, J. Almeida & S. Campos (2005),
“Scalable Media Streaming to InteractiveUsers”, Proceedings
of the 13th Annual ACM International Conference on
Multimedia, Pp. 966–975.
A. Legout, G. Urvoy-Keller & P. Michiardi (2006), “Rarest
First and Choke Algorithms are Enough”, 6th ACM SIGCOM
Conference on Internet Measurement, Pp. 203–216.
A. Vlavianos, M. Iliofotou & M. Faloutsos (2006), “BiToS:
Enhancing BitTorrent for Supporting Streaming Applications”,
9th IEEE Global Internet Symposium, Pp. 1–6.
C.K.S. Rodrigues (2006) “Mecanismos de Compartilhamento
de Recursos para Aplicações de MídiaContínuana Internet”,
UFRJ COPPE/PESC, Rio de Janeiro, Brazil.
C. Huang, J. Li & K. Ross (2007), “Can Internet Video-onDemand be Profitable”, ACM SIGCOMM Computer
Communication Review, Vol. 37, No. 4, Pp. 133–144.
C.C.L.B. de Vielmond, R.M.M. Leão & E. de Souza e Silva
(2007),
“Um
Modelo
HMM
Hierárquico
para
ISSN: 2321-2403
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
UsuáriosInterativosacessandoum
Servidor
Multimedia”,
Simpósio Brasileiro de Redes de Com- putadores, Vol. 1,
Portuguese.
N. Carlsson & D. Eager (2007), “Peer-Assisted On-Demand
Streaming of Stored Media using Bittorrent-Like Protocols”,
NETWORKING 2007. Ad Hoc and Sensor Networks, Wireless
Networks, Next Generation Internet, Pp. 570–581.
P. Shah & J.-F. Pâris (2007), “Peer-to-Peer Multimedia
Streaming using BitTorrent”, IEEE International Performance,
Computing, and Communications Conference – IPCCC, Pp.
340–347.
R. García, X.G. Pañeda, V. García, D. Melendi & M. Vilas
(2007), “Statistical Characterization of a Real Video on
Demand Service: User Behaviour and Streaming-Media
Workload Analysis”, Simulation Modelling Practice and
Theory, Vol. 15, No. 6, Pp. 672–689.
J.J.D. Mol, J.A. Pouwelse, M. Meulpolder, D.H.J. Epema &
H.J. Sips (2008), “Give-to-Get: Free-Riding-Resilient VideoOn-Demand in P2P Systems”, Electronic Imaging 2008, Pp.
681804.
P. Savolainen, N. Raatikainen & S. Tarkome (2008),
“Windowing BitTorrent for Video-on-Demand: Not all is Lost
with Tit-for-Tat”, IEEE GLOBECOM, Pp. 1–6.
A. Charls, T. Sharma & P.K. Singh (2009), “Media Streaming
in P2P Networks based on BitTorrent”, International
Conference on Computer Engineering and Applications
(IPSCIT), Vol. 2, Pp. 158–162.
E. de Souza e Silva, D. Figueiredo & R. Leão (2009) “The
Tangram-II Integrated Modelling Environment for Computer
Systems and Networks”, ACM SIGMETRICS Performance
Evaluation Review, Vol. 36, No. 4, Pp. 45–65.
M. Cha, H. Kwak, P. Rodriguez, Y.Y. Ahn & S. Moon (2009),
“Analyzing the Video Popularity Characteristics of Large-Scale
User Generated Content Systems”, IEEE/ACM Transactions on
Networking, Vol. 17, No. 5, Pp. 1357–1370.
L. D’Acunto, J. Andrade & H. Sips (2010), “Peer Selection
Strategies for Improved QoS in Heterogeneous BitTorrent-Like
VoD Systems”, IEEE International Symposium on Multimedia,
Pp. 89–96.
R.L. Xia & J.K. Muppala (2010), “A Survey of BitTorrent
Performance”, IEEE Communications Surveys & Tutorials,
Vol. 12, No. 2, Pp. 140–158.
Y. Borghol, S. Ardon, N. Carlsson & A. Mahanti (2010),
“Toward Efficient On-Demand Streaming with Bittorrent”,
IFIP Networking, Pp. 53–66.
A. Aurelius, C. Lagerstedt & M. Kihl (2011), “Streaming
Media over the Internet: Flow based Analysis in Live Access
Networks”, IEEE International Symposium on Broadband
Multimedia Systems and Broadcasting (BMSB), Pp. 1–6.
C. Zhang, P. Dhungel, D. Wu & K.W. Ross (2011),
“Unraveling the Bittorrent Ecosystem”, IEEE Transactions on
Parallel and Distributed Systems, Vol. 22, No. 7, Pp. 1164–
1177.
L.J. Hoffmann, C.K.S. Rodrigues & R.M.M. Leão (2011),
“BitTorrent-Like Protocols for Interactive Access to VoD
Systems”, European Journal of Scientific Research, Vol. 58,
No. 4, Pp. 550–569.
T. Hoßfeld, F. Lehrieder, D. Hock, S. Oechsner, Z. Despotovic,
W. Kellerer & M. Michel (2011), “Characterization of
BitTorrent Swarms and their Distribution in the Internet”,
Computer Networks, Vol. 55, No. 5, Pp. 1197–1215.
M. Varvello, M. Steiner & K. Laevens (2012), “Understanding
BitTorrent: A Reality Check from the ISP’s Perspective”,
Computer Networks, Vol. 56, No. 3, Pp.1054–1065.
© 2015 | Published by The Standard International Journals (The SIJ)
36
The SIJ Transactions on Computer Networks & Communication Engineering (CNCE), Vol. 3, No. 2, February 2015
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
H. Wang, J. Liu & K. Xu (2012), “Understand Traffic Locality
of Peer-to-Peer Video File Swarming”, Computer
Communications, Vol. 35, No. 15, Pp. 1930–1937.
Z. Ma, K. Xu & Y. Zhong (2012), “Exploring the Policy
Selection of P2P VoD System: A Simulation based Research”,
Proceedings of the 2012 IEEE 20th International Workshop on
Quality of Service, Pp. 23.
A.G. Streit & C.K.S. Rodrigues (2013), “On the Design of
Protocols for Efficient Multimedia Streaming over Internet”,
ESPE - Ciencia y Tecnología, Vol. 4, No. 1, Pp. 25–39.
L. D'Acunto, N. Chiluka, T. Vinkó & H. Sips (2013),
“BitTorrent-Like P2P Approaches for VoD: A Comparative
Study”, Computer Networks, Vol. 57, No. 5, Pp. 1253–1276.
M.V.M. Rocha & C.K.S. Rodrigues (2013), “On Client’s
Interactive Behaviour to Design Peer Selection Policies for
BitTorrent-Like Protocols”, International Journal of Computer
Networks & Communications (IJCNC), Vol. 5, No. 5, Pp. 141–
159.
P. Romero, F. Aomoza & P. Rodrígues-Bocca (2013),
“Optimum Piece Selection Strategies for a Peer-to-Peer Video
Streaming Platform”, Computers & Operations Research, Vol.
40, No. 5, Pp. 1289–1299.
Y. Chen, B. Zhang, Y. Liu & W. Zhu (2013), “Measurement
and Modeling of Video Watching Time in a Large-Scale
Internet Video-on-Demand System”, IEEE Transactions on
Multimedia, Vol. 15, No. 8, Pp. 2087–2098.
C.K.S. Rodrigues (2014), “Analyzing Peer Selection Policies
for BitTorrent Multimedia On-Demand Systems in Internet”,
International
Journal
of
Computer
Networks
&
Communications (IJCNC), Vol. 6, No. 1, Pp. 203–221.
C.K.S. Rodrigues (2014), “On the Optimization of BitTorrentLike Protocols for Interactive On-Demand Streaming
Systems”, International Journal of Computer Networks &
Communications, Vol. 6, No. 5.
ISSN: 2321-2403
Ananda Görck Streit is currently a B.Sc.
Computer Science student from the
University Center of Brasília (UniCEUB),
Brazil. Already in the end of her graduation
program, she intends to start a M.Sc. program
and continue her research in the Computer
Network and Multimedia Communications
field. During her graduation, she has
published three different papers and
participated in a congress, apart from coordinating and being for
almost three semesters actively engaged in a research group from
her university that conducted studies on the Artificial Intelligence
area. Recently, she has finished the participation in a scholarship
program promoted by the Brazilian government to study during two
semesters in the RWTH Aachen University, Germany.
Carlo Kleber da S. Rodrigues received the
B.Sc. degree in Electrical Engineering from
the Federal University of Paraiba in 1993, the
M.Sc. degree in Systems and Computation
from the Military Institute of Engineering
(IME) in 2000, and the D.Sc. degree in
System Engineering and Computation from
the Federal University of Rio de Janeiro
(UFRJ) in 2006. Currently he is Military
Assessor of the Brazilian Army in Ecuador, Professor at the Armed
Forces University (ESPE) in Ecuador, and Professor at the
University Center (UniCEUB) in Brazil. His research interests
include the areas of computer networks, performance evaluation,
and multimedia streaming.
© 2015 | Published by The Standard International Journals (The SIJ)
37