See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/339694640
DQ-DASH: A Queuing Theory Approach to Distributed Adaptive
Video Streaming
Article in ACM Transactions on Multimedia Computing, Communications and Applications · March 2020
DOI: 10.1145/3371040
CITATIONS
READS
18
340
4 authors:
Abdelhak Bentaleb
Praveen Yadav
Concordia University Montreal
National University of Singapore
62 PUBLICATIONS 1,198 CITATIONS
11 PUBLICATIONS 133 CITATIONS
SEE PROFILE
SEE PROFILE
Wei Tsang Ooi
Roger Zimmermann
National University of Singapore
National University of Singapore
173 PUBLICATIONS 1,884 CITATIONS
461 PUBLICATIONS 7,486 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Networked Virtual Environments View project
Map Matching View project
All content following this page was uploaded by Praveen Yadav on 03 May 2021.
The user has requested enhancement of the downloaded file.
SEE PROFILE
DQ-DASH: A Queuing Theory Approach to Distributed
Adaptive Video Streaming
ABDELHAK BENTALEB, PRAVEEN KUMAR YADAV, WEI TSANG OOI, and
ROGER ZIMMERMANN, School of Computing, National University of Singapore, Singapore
The significant popularity of HTTP adaptive video streaming (HAS), such as Dynamic Adaptive Streaming
over HTTP (DASH), over the Internet has led to a stark increase in user expectations in terms of video quality and delivery robustness. This situation creates new challenges for content providers who must satisfy
the Quality-of-Experience (QoE) requirements and demands of their customers over a best-effort network
infrastructure. Unlike traditional single server DASH, we developed a Distributed Queuing theory bitrate
adaptation algorithm for DASH (DQ-DASH) that leverages the availability of multiple servers by downloading segments in parallel. DQ-DASH uses a M x /D/1/K queuing theory based bitrate selection in conjunction
with the request scheduler to download subsequent segments of the same quality through parallel requests
to reduce quality fluctuations. DQ-DASH facilitates the aggregation of bandwidth from different servers and
increases fault-tolerance and robustness through path diversity. The resulting resilience prevents clients from
suffering QoE degradations when some of the servers become congested. DQ-DASH also helps to fully utilize
the aggregate bandwidth from the servers and download the imminently required segment from the server
with the highest throughput. We have also analyzed the effect of buffer capacity and segment duration for
multi-source video streaming.
CCS Concepts: • Information systems → Multimedia streaming;
Additional Key Words and Phrases: Multiple server, multi-source, queuing theory, DASH, QoE, fairness, ABR
ACM Reference format:
Abdelhak Bentaleb, Praveen Kumar Yadav, Wei Tsang Ooi, and Roger Zimmermann. 2020. DQ-DASH: A
Queuing Theory Approach to Distributed Adaptive Video Streaming. ACM Trans. Multimedia Comput. Commun. Appl. 16, 1, Article 4 (March 2020), 24 pages.
https://doi.org/10.1145/3371040
1 INTRODUCTION
HTTP Adaptive Streaming (HAS) delivery systems are used widely for video delivery, and their
continuing adoption will lead to their dominance in total Internet traffic in the near future [51].
A. Bentaleb and P. K. Yadav contributed equally to the paper.
This research is supported by Singapore Ministry of Education Academic Research Fund Tier 2 under MOE’s official grant
number MOE2018-T2-1-103 and in part of NExT++ research, supported by the National Research Foundation, Prime Minister’s Office, Singapore under its IRC@SG Funding Initiative. We gratefully acknowledge the support of NVIDIA Corporation with the donation of a Titan Xp GPU used for this research.
Authors’ addresses: A. Bentaleb, P. K. Yadav, W. T. Ooi, and R. Zimmermann, School of Computing, National University
of Singapore, 21 Lower Kent Ridge Rd, Singapore, 119077, Singapore; emails: {bentaleb, praveen, ooiwt, rogerz}@comp.
nus.edu.sg.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee
provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and
the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored.
Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires
prior specific permission and/or a fee. Request permissions from permissions@acm.org.
© 2020 Association for Computing Machinery.
1551-6857/2020/03-ART4 $15.00
https://doi.org/10.1145/3371040
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
4
4:2
A. Bentaleb et al.
Current trends [12] estimate that video traffic will grow by 31% from the year 2016 to 2021 and
reach 82% of overall Internet traffic by 2021. This increase in video network traffic calls for a novel
video delivery solution to satisfy the requirement of users. With Dynamic Adaptive Streaming
over HTTP (DASH), a client typically leverages one server at a time and only redirects to another
server via domain name system (DNS) redirect if a network bottleneck develops. The available
media representation levels (bitrates and resolutions) at the servers are discrete. The clients that
share an overloaded server or a bottleneck link limit themselves to a lower representation level
to avoid playback stalls. Conversely, the clients on less loaded servers can achieve a much higher
video quality, causing unfairness in the Quality-of-Experience (QoE).
In this work, we take a different approach and propose DQ-DASH, a Queuing theory based bitrate adaptation solution for Distributed DASH where multiple clients share more than one server
in parallel. The sharing of servers results in achieving an approximately fair QoE across clients. A
bottleneck link or an overloaded server does not create a localized impact on clients. The entire
DQ-DASH functionality is implemented in a distributed manner in the client-side application layer
following the existing DASH architecture. DQ-DASH does not require any modification of kernel
or network functionality, including transport layer. Our extensive experimental results show that
DQ-DASH can significantly improve performance in all considered scenarios, with the findings
summarized as follows:
— DQ-DASH is in full compliance with DASH ISO/IEC standards [25]. It does not need any
customized video codecs or server-side application programming interface (API). All the
servers are stateless HTTP storage servers.
— DQ-DASH archives up to 33% higher QoE with less than 1% variation amongst the clients
compared to a sequential download from a single server.
— DQ-DASH is robust against server bottlenecks and variable network conditions. Our solution does not over-exploit the available bandwidth, and it requires only one extra segment
download to check the status of a server in the case of a bottleneck.
— We discuss the relationship between segment duration, number of servers, and the maximum buffer capacity, and their effect on the total performance. Based on this relationship,
DQ-DASH uses the 30s, 60s, and 120s maximum buffer capacities for segment duration 1s,
2s, and 4s, respectively (see Section 7.3.1).
— DQ-DASH performance is compared to the sequential single-server DASH solution and
content delivery network (CDN) based load balancing rules including: Round Robin, Least
Connected, Session Persistence, and Weighted (see Section 7.1.3). DQ-DASH significantly
outperforms both solutions in the considered experimental scenarios.
— DQ-DASH performs well in real-world settings using a distributed DASH dataset [34].
— DQ-DASH supports a large-scale deployment. We have shown scalability of the proposed
solution using National Cybersecurity R&D Laboratories (NCL) testbed [47] with 100 clients
sharing four servers in parallel under different network configurations.
This article addresses the challenges of single-server DASH and CDN-based load balancing
rules, and it makes the following contributions:
(a) Overview and formalization of DQ-DASH. We design a M x /D/1/K queuing theory
bitrate adaptation algorithm (an extension of our prior work [58]) to select the bitrate
based on throughput from the different servers, current buffer occupancy, and total buffer
capacity. Thus, the developed method DQ-DASH aims to improve QoE, video quality stability, and quality fairness by not only considering the bitrate adaptation decisions but
further leveraging multiple servers (Sections 4 and 5).
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
DQ-DASH: A Queuing Theory Approach to Distributed Adaptive Video Streaming
4:3
(b) Design and practical implementation. We provide a practical implementation of DQDASH in the open source dash.js reference player [14], and we highlight the implementation challenges (Section 6).
(c) Results and Analysis. We evaluate and analyze the efficiency of our solution using a full
system implementation with realistic network trace-driven and real-world testbed experiments that consider a set of throughput variability datasets, different segment durations,
QoE metrics, multiple DASH clients, and servers. We compared DQ-DASH with CDNbased load balancing rules available on a NGINX server [50]. The findings in all considered scenarios show that DQ-DASH significantly outperforms a single DASH server and
CDN-based load-balancer rules (Section 7).
Outline. The rest of the article is organized as follows. Section 2 describes the background on
DASH, the challenges of single-server DASH, and the motivations for DQ-DASH. We discuss some
of the state-of-the-art video segment scheduling techniques for video streaming in Section 3. Section 4 provides an overview of DQ-DASH and its model formulation. How DQ-DASH selects suitable bitrate levels for multi-server adaptive streaming is described in Section 5. Section 6 highlights
the different implementation challenges and their proposed solution. The experimental methodology, evaluation, and result analysis are highlighted in Section 7. Section 8 offers a discussion of
some observations and open issues. Finally, Section 9 concludes the article.
2 BACKGROUND, MOTIVATIONS, AND CHALLENGES
2.1 Background on DASH
A DASH system consists of two main entities: an HTTP server and a DASH client. The server
stores videos that are divided into small fixed duration segments (2–15 seconds) and each segment is encoded at various representation levels (bitrates and resolutions). A Media Presentation
Description (MPD) file describes the video, which includes metadata about segment durations,
codec, and representation levels for different tracks (audio and subtitles). The client first fetches
the MPD file and then issues HTTP requests for the segments sequentially based on its Adaptive
Bitrate (ABR) controller decisions. The server responds by sending the requested segments through
HTTP.
DASH adapts dynamically to the network conditions thanks to its ABR schemes that are based
on heuristics [32] such as throughput measurements, playback buffer occupancy, or a combination of both. Furthermore, it uses HTTP, which enables content providers to leverage existing
CDN infrastructure and simplifies the traversal through network middleboxes. Finally, it is highly
scalable as DASH clients can request and fetch video segments independently, maintaining their
local playback state in a decentralized way using stateless HTTP servers.
2.2
Motivations and Challenges
In this section, we provide the motivations and challenges of using single versus multi-source1
DASH streaming. In a DASH delivery system, every DASH client strives to improve its QoE by
making the best bitrate decision that can accommodate the underlying network conditions without
introducing stalls. The bitrate decision is performed using an ABR logic (see Figure 1), which
relies on available representation levels, throughput estimation, buffer occupancy measurement,
and buffer capacity. Selecting the right decision in an existing network infrastructure with single
source DASH, however, is an arduous task on two key fronts:
1 In
this article, we use a source and a server, and buffer and queue, interchangeably.
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
4:4
A. Bentaleb et al.
(i) Lack of bandwidth: The ever-growing user demands for higher video quality [51] have
lead to an explosive consumption of bandwidth. In single source DASH, achieving a high
QoE over existing bandwidth-limited networks is very challenging because of frequent
congestion caused by DASH clients’ competition. This competition introduces stalls and
frequent quality switch that significantly impact the user QoE. The high traffic load for
a video content is often shared between CDNs based on some redirection policy (CDNbased load balancing rules). In such a system, the DASH client uses only one server at a
time and gets connected to a new server if a bottleneck is detected, based on the policy
decided by the content provider. The clients connected to a more loaded server gets a
lower QoE, which leads to unfairness. DQ-DASH enables sharing of multiple servers in
parallel between clients for fair sharing of resources, video quality, and QoE.
(ii) Server-side bottlenecks: In single server DASH solutions [32], typically only one server
is considered for sequential segment delivery determined by a given base URL (i.e., the
next segments can be downloaded only if the current one is fully downloaded). This one
segment at time mechanism represents a weak spot in the presence of a bottleneck on
the server-side. The problem is aggravated if the minimum bitrate for the available representations is higher than the throughput of the bottleneck link. Therefore, the server
bottleneck results in increasing stalls, video instability, frequent changes in selection of
representation level, and unfairness [4, 44]. Some CDN and Peer-to-Peer (P2P) based prior
research [41, 44, 56] tries to identify the bottleneck using a simple network metrics (e.g.,
latency, download time, throughput), and then select the appropriate server or servers
for P2P. However, their solutions are: (i) not adaptable to existing chunked-based DASH
delivery systems or (ii) need modifications on the network-side, or (iii) are not scalable
where each client needs to report its state to the centralized network controller. Conversely, DQ-DASH deals with bottlenecks efficiently. First, it determines the bottleneck
server employing the same strategy as Netflix [1] (i.e., a server is considered a bottleneck
if it cannot support the minimum stated bitrate listed in the MPD file), and then it stops
requesting future segments from that corresponding server. In this situation, the client
monitors the status of the bottleneck server periodically for any changes (i.e., it may become a healthy server again) via probe-based passive or active measurements.
The above-mentioned factors negatively affect the viewer QoE for single source DASH even in
the presence of CDN-based redirection policies. However, DQ-DASH provides a fair and higher
QoE amongst the clients by selecting the appropriate representation level, leveraging the expanded bandwidth from multiple servers with heterogeneous capacities. Our proposed multisource scheme is a purely client-driven solution where the modifications are restricted to the client.
Thus, the network and server sides remain unchanged.
3 RELATED WORK
In this section, we classified how a client requests and downloads the segments from the video
server(s) into two main classes, namely: sequential or parallel.
3.1 Sequential Downloads
The scheduler requests the video segments sequentially one after the other, where the next segment cannot be downloaded until the requested one is fully received. The sequential schemes [6]
can fall into two main categories: isolated ABR and centralized ABR.
An isolated ABR solution uses its ABR controller to select the bitrate individually. This solution
type can be divided into three classes based on the heuristic of the ABR controller: rate-based,
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
DQ-DASH: A Queuing Theory Approach to Distributed Adaptive Video Streaming
4:5
buffer-based, and mixed. Akhshabi et al. [2] experimentally evaluated three commercial players
(MSS, Netflix, and OSMF) and their ABR schemes in terms of how they react to dynamic network conditions, what their achievable bitrate is, and how they deal with multiple players competing for the available bandwidth in a shared network. Li et al. and Sun et al. both designed
throughput-based ABR methods [36, 54], where the former provides a probe mechanism to estimate the throughput when multiple clients compete at a bottleneck link, while the latter is based
on a data-driven approach to predict the available bandwidth accurately to deliver a high-quality
video. Huang et al. and Spiteri et al. proposed buffer-based ABR schemes [24, 52], where they considered a buffer reservoir underflow and overflow and Lyapunov theory, respectively. In the same
context, QUEuing Theory-based Rate Adaptation (QUETRA) [58] has been developed as a queuing
theory based ABR that considers the estimated throughput, the current buffer occupancy, and the
buffer capacity. Finally, the mixed schemes combine both rate-based and buffer-based techniques
during the ABR process [3, 26, 29, 42, 59, 62].
A centralized ABR solution uses various assisting information (e.g., bitrate recommendation,
congestion level) to help the client in its ABR decisions. The assistant information is given by a
centralized entity like a proxy, a software defined networking (SDN) controller, and the like, or a
network element such as with a server and network-assisted DASH (SAND) architecture [55]. A
number of ABR schemes follow this centralized design philosophy [4, 5, 20, 27, 39, 48, 63, 64].
Multi-view videos are another variant of DASH applications where the user has the flexibility
of choosing views from different camera angles. Yu et al. [61] and Zhang et al. [66] have proposed
rate adaptations for this application, where the ABR decision also utilizes user interactions as an
input parameter.
In contrast to existing methods, we modify the DASH client to download the segments from
different servers. Similar to previously existing solutions, the client makes the ABR decision using throughput, available bitrate for different representation levels, buffer occupancy, and total
buffer capacity. While modifying the client, we ensure that it still follows the DASH ISO/IEC [25]
standards. We do not introduce any new tags for the MPD file, and the different DASH clients
independently perform the entire rate adaptation process and schedule the segment downloads
from multiple servers in a distributed manner.
3.2 Parallel Downloads
With a parallel approach, a scheduler requests and downloads multiple segments in parallel from
different video servers at the same time. Many interesting studies have attempted to improve video
delivery through downloading of parallel segments. However, most of them require kernel or network functionality modifications including both at the application and transport layers [31]. Han
et al. [21] developed a multi-path DASH (MP-DASH) by leveraging multiple network interfaces
employed in the client (e.g., WiFi and cellular) and the multi-path transmission control protocol
(MPTCP) to download from different access networks. Wang et al. [57] also proposed an MPTCPenabled dynamic multi-path streaming for live services. Corbillon et al. proposed a cross-layer
approach to simplify the interactions between the application and transport layers, and thus allowing the streaming application to use MPTCP [13]. Evensen et al. [16] proposed an aggregate
throughput algorithm benefiting from the multiple heterogeneous network interfaces for traditional video streaming.
In another work, Evensen et al. extended DAVVI [28] to support multi-source adaptive video
streaming [17]. Kaspar et al. [30] used the HTTP range retrieval mechanism to divide each segment into sub-streams of a fixed size, and then download different sub-streams from multiple links
in a multi-homing network. Kuschnig et al. [33] designed a solution that supports multi-HTTP
and TCP connections for video streaming. The algorithm proposed by Zhou et al. [67] is able to
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
4:6
A. Bentaleb et al.
download pieces of video (a set of segments) simultaneously without a scheduler from multiple
servers considering the playback deadline of each piece. A scalable video coding together with
multiple video servers is proposed in Ref. [49]. In contrast to the HTTP range retrieval mechanism, Liu et al. proposed a robust solution that used the independent HTTP sessions technique to
request and download multiple segments from different servers [37, 38].
Queyreix et al. [9] proposed Multiple-Source Streaming over HTTP (termed MS-Stream) as an
evolution of HAS-based streaming for DASH, that leverages multiple customized servers to improve the end-user QoE. Although MS-Stream shows good performance in delivering high-quality
videos, the proposed solution has some limitations: (i) it uses Multiple Description Coding (MDC)
for encoding video, which is not part of the DASH standard now; (ii) the implementation needs
a specific API at the servers, which is not in accordance with the DASH standard; (iii) it incurs a
time overhead to combine the content before playing; which might not be acceptable for standard
QoS and QoE; (iv) the existing DASH storage servers and CDN architectures on the Internet would
require modifications that might be significant; and (v) not all the content downloaded is played
resulting in significant overhead, and, hence, the aggregate throughput from multiple servers is not
fully utilized. In another work by Nguyen et al. [46], the authors proposed distributed video streaming from multiple sources. Unlike DASH, the method uses only one video representation level and
sources depend on control packets from the clients for on-the-fly segmentation of the video.
P2P video streaming is another type of multi-source streaming where a client also acts as a
video source for other clients once the content is available on it. PPLive [22], Joost [45], and Coolstreaming [65] are a few such P2P applications. Unlike DASH, P2P can be both pull-based (where a
peer requests content from other peers) and push-based (where a peer pushes the content to other
peers once it is available). P2P systems are more focused on the use of many peers rather than on
adapting the video quality to the changing network conditions. In addition to the availability of
bandwidth, their performance mainly depends on the availability of segments [40] and diversity
of segments [68] at the peers.
In the proposed work, we use a queuing theory model to determine the bitrate of the representation level to download for the DASH client using the throughput from different servers, the total
buffer capacity, and the current buffer occupancy. We further develop a scheduler that requests the
imminent segment from the available server with the highest throughput and avoids the download from a bottleneck server. To the best of our knowledge, our solution is the first to use queuing
theory to select a suitable bitrate level from multiple servers in parallel.
4 SYSTEM MODEL
We now present how we use multiple servers in parallel for DASH video streaming. The method
leverages a queuing theory (i.e., M x /D/1/K queue) based ABR scheme and a scheduler to select
the best possible representation level while maintaining optimum buffer occupancy level (avoiding
buffer overflow and underflow) subjected to download throughput from different servers, available
representation levels, current buffer occupancy, and total buffer capacity for maximizing the QoE.
Unlike a single server DASH [53], our scheme benefits from multiple DASH servers that are available in the network infrastructure (e.g., CDNs network) to request consecutive video segments
simultaneously.
The essential goal of our scheme is to maximize the user satisfaction (QoE) while playing video
at the highest possible quality, avoiding stalls, frequent changes in the representation level, and
long startup delays. As shown in Figure 2, our system consists of three major entities including
DASH clients, servers, and content providers. Our solution does not need any modifications in the
DASH server or the network. Furthermore, all modifications are performed in the DASH player;
thus, no changes are required to the kernel. The client represents the video player that supports
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
DQ-DASH: A Queuing Theory Approach to Distributed Adaptive Video Streaming
Fig. 1. DQ-DASH detailed architecture.
4:7
Fig. 2. An overview of DQ-DASH.
a DASH system such as the reference player dash.js [14]. Each DASH client is characterized by
device capabilities (e.g., display resolution, memory, and CPU) and may request various video
content types (e.g., animation, movie, news) using various ABR schemes [32]. Figure 1 shows
our dash.js based player. It comprises four components including (i) the buffer controller that
tracks the contiguous part of the playback buffer occupancy. (ii) The throughput estimator considers the last throughput from the individual server as its predicted future value of the throughput.
(iii) The ABR controller uses a queue-based model (described in Section 5) to decide the representation level for the next segment to be downloaded. Finally, (iv) the scheduler controls, requests,
and downloads the segments from the appropriate server.
The system considers a scenario where a DASH client can leverage multiple servers for downloading parallel segments using the BaseURL property of the MPD file. The BaseURL represents
the address of the servers that have the same copy of the video segments at the same quality
levels [34]. A DASH client makes parallel requests for different segments from all the available
servers to fully leverage the throughput of multiple servers. As shown in Figure 2, if the available throughputs from five different servers are 2 Mbps, 1 Mbps, 1.5 Mbps, 0.5 Mbps, and 1 Mbps,
the DASH client selects a bitrate level that is sustainable given the aggregate 6 Mbps bandwidth.
If the aggregate bandwidth is too low or high, the client selects the bitrate corresponding to the
lowest or highest representation level, respectively. To achieve this, a DASH client should have a
proper ABR algorithm to select the appropriate bitrate and a request scheduler to request the right
segment from the appropriate server, as shown in Figure 1. The scheduler is also responsible for
avoiding the download of the same segment multiple times and thus save bandwidth as well as to
avoid performance degradations due to bottleneck servers.
We aim to allow each DASH client to request segments from multiple DASH servers simultaneously, which may be geographically distributed. Recall that our DASH clients leverage the link
diversity in the existing network infrastructure to provide a robust video streaming solution.
List of key symbols and notations is highlighted in Table 1. Formally, we consider a system model
that comprises of a set of DASH clients C = {c 1 , . . . , c N } and servers S = {s 1 , . . . , s M }. We assume
a full mesh network, i.e., full-mesh topology (e.g., open shortest path first (OSPF) mesh network)
where every client c j ∈ C with j = [1 . . . N ] has connectivity to each si ∈ S and i = [1 . . . M], and
thus a DASH client uses diverse multiple links to fetch successive segments simultaneously from
existing servers. Due to congestion and network variability, at any time, the link toward the server
si may become slow, and the server will be considered a bottleneck. In this situation, if the bottleneck server is downloading the immediately required segment for playback, the client suffers
from stalls because the client cannot skip the segment for playback. To avoid this issue, the client
stops fetching future segments from the bottleneck servers and considers the M − H remaining
servers, where H is the total number of bottleneck servers. Each DASH client keeps track of the
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
4:8
A. Bentaleb et al.
Table 1. List of Key Symbols and Notations
Notation
Definition
Notation
Definition
T
t
C
S
N
M
ρ
τ
λ
μ
Total video duration
Segment download step
Set of DASH clients
Set of DASH servers
Total number of clients
Total number of servers
Queue server utilization
Segment duration
Arrival rate
Queue service rate
w
R
K
O K, r ,w
BS K, r ,w
Bt
H
Z
seд
η
Segment download throughput
Set of bitrates for different representation levels
Maximum buffer/queue capacity
Expected average buffer occupancy
Expected buffer slack
Buffer occupancy at time t
Total number of bottleneck servers
Total number of segments at each representation level
A segment
Total number of representation levels
Fig. 3. The DQ-DASH client is modeled as M x /D/1/K queue, where the buffer occupancy is measured in
seconds.
statuses of bottleneck servers by requesting previous segments with the lowest bitrate level; thus,
it will use bottleneck servers again when they can provide service and satisfy client requirements.
We note that the total number of redundant segment downloads when there exist server bottlenecks depends on two factors, namely the number of bottleneck servers and the number of DASH
clients.
Before starting a streaming session (i.e., either live or on-demand) and after an authentication
process, every DASH client first fetches the MPD file and then the video segments in parallel from
the existing DASH servers. The segments of each video are stored in the set of DASH servers S, each
video of T seconds is divided into a Z (= T /τ ) segments, and each segment seдt where t ∈ [1 . . . Z ]
has a fixed duration τ seconds and is encoded into η representation levels. During each step t,
the player c j selects a suitable representation level for the next segments to be downloaded using
the DQ-DASH bitrate adaptation (ABR) scheme. The selected bitrate should adapt properly to the
available throughput w t from all the servers and maintain the buffer Bt occupancy within a safe
region (i.e., between underflow and overflow thresholds).
Having the representation levels, we assume that each client chooses a suitable level to eliminate
buffer underrun and overflow issues, and maximize the QoE.
5
RATE ADAPTION FOR MULTI-SERVER STREAMING USING QUEUING MODEL
A DASH client can be seen as a queuing system where video segments are arriving in a finite capacity queue K, where the queue length (i.e., the buffer occupancy) is measured as the duration of
video available in the queue as shown in Figure 3. We consider the arrivals of segments from different servers as a Markovian batch arrival process having Poisson distributions that are independent
of each other. A Markovian batch arrival is a stochastic point process that generalizes the standard
Poisson process by allowing for batches of arrivals, dependent inter-arrival times, non-exponential
inter-arrival time distributions, and correlated batch sizes [10]. Cao et al. [10] have shown that
packet arrivals in a congested network follow a Poisson distribution. Based on the split and the
addition properties of Poisson distributions, the segment arrivals can be modeled with a Poisson distribution as well. Let the arrival rate of segments from server si be λi . Each segment has a
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
DQ-DASH: A Queuing Theory Approach to Distributed Adaptive Video Streaming
4:9
duration of τ seconds. Every second, a single decoder in the client services a segment at the rate μ =
1/τ segment/second. Let the download throughput from server si be w i bps downloading the segi
segments
ment of quality r i bps. Therefore, segments are arriving at the queue with the rate of r iw×τ
per second and get stored in the queue with a capacity of K seconds. Segments in the same batch are
downloaded at the same quality to limit the number of bitrate switches. Thus, the arrival rate from
i
each other, the total
server si is λi = w
r τ . Since the arrivals from different servers are independent of arrival rate at the queue is the sum of all the arrival rates in the batch, i.e., λ = λi [11]. Thus, the
server queue utilization is ρ = i λi /μ = w/r , where w = i w i . We then compute the expected
average buffer occupancy O K,r,w and the expected buffer slack BS K,r,w = K − O K,r,w using the analytical solution given by Brun et al. [7]. The original analytical solution is proposed for non-batch
arrivals that give an equation for average queue length for a given utilization ρ and queue capacity K based on the state transition matrix generating function. Since this state transition matrix
generating function is the same for the batch Markovian arrival process, as shown by Dudin et al.
[15], we can use the solution for the batch arrival rate without any loss of generality. This is the
extension of QUEuing theory Rate Adaptation (QUETRA) [58], which models the expected average
buffer occupancy for a given buffer capacity using the throughput and available bitrates.
The QUETRA ABR algorithm considers a single server and calculates the expected buffer slack
for the available bitrate levels based on the current download throughput and buffer capacity. It
selects a bitrate for which the expected buffer slack is closest to the current buffer occupancy. We
extended this method to consider the aggregate arrival rate from different servers. Let a given
video be encoded with bitrate values R = {r 1 , r 2 , . . . , r η } for η representation levels, where r j < r k
if j < k. Similar to QUETRA, the algorithm selects the bitrate r i at time t such that the expected
buffer slack BS K,r i ,w is closest to the buffer occupancy at time t, denoted Bt ,
r = arg min |BS K,r i ,w − Bt |,
r i ∈R
(1)
breaking ties by favoring the higher bitrate. The intuition behind QUETRA is as follows. Consider
the ideal case where segment bitrate r equals the throughput w, which gives 100% utilization
(ρ = 1). When r = w, one can show that the expected average buffer occupancy O K,r,w can be
approximated to K/2 [23]. By choosing the bitrate such that the buffer occupancy is as close to the
buffer slack as possible, QUETRA, in the hypothetical case where the bitrate value is continuous,
would converge to the buffer occupancy of K/2, which is the ideal scenario. Unlike the original
QUETRA, expected buffer slack is a function of the estimated throughput from the different servers
other than the current bitrate and the total buffer capacity.
6
IMPLEMENTATION CHALLENGES AND SOLUTIONS
We describe the challenges and their solutions that occur in the simultaneous utilization of multiple
servers for DASH streaming as well as the method for maintaining the performance if there exists
a bottleneck server.
6.1 Challenge #1—Parallel Requests for Multiple Segments
To leverage the available throughput from all the servers, the DASH client must request different
segments from different servers. DQ-DASH averts the duplicate download of a segment to avoid
resource wastage.
6.2 Challenge #2—Accurate Throughput Measurements from Different Servers
While downloading segments in parallel from multiple servers, it is important to ensure that not
more than one segment is downloaded from a server. The download of more than one segment from
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
4:10
A. Bentaleb et al.
ALGORITHM 1: Next segment download strategy in a batch.
Bt : Playback buffer occupancy at time t;
τ : Segment duration;
K: Buffer capacity;
M: Total number of available servers;
Servers {s 1 , s 2 , . . . , s M } ∈ S are sorted in decreasing order based on their last throughput;
Initialize: i = 1;
while i ≤ M do
if Bt + τ ≤ K and si is not downloading then
Download next segment from si with bitrate suggested by QUETRA;
end
i = i + 1;
end
the single server would result in a wrong estimate of the throughput [54] from that server because
multiple segment downloads would be competing against each other for resources at server as
well as in the network path.
6.3 Challenge #3—Buffer Overflow and Underflow Prevention
The download scheduler in a multi-server environment must keep track of current buffer levels
before sending a segment request to avoid exceeding the buffer capacity, e.g., a DASH player with
30 seconds of buffer capacity and with a current buffer occupancy of 24 seconds playing a video
with 4 seconds segment duration and five available servers can send a request to only one server. If
the current buffer occupancy drops below 10 seconds, the download scheduler is expected to send
a segment request to all the servers. At each segment download step t, the download scheduler
in DQ-DASH checks for the last throughput from the servers. In a batch, the download scheduler
requests segments that are needed earlier for playback from servers with higher throughput values
as shown in Algorithm 1.
6.4 Challenge #4—Appropriate Bitrate Selection
While leveraging multiple servers in parallel, the individual throughput of a server can be much
lower than the bitrate they can support collectively. Therefore, it is important to model the system
accurately for appropriate selection of bitrate. If the bitrate selection algorithm fails to identify
the effective overall throughput, it may select a higher or a lower bitrate than the capacity, which
may lead to underflow or overflow. In a batch, the bitrate selection algorithm should be able to
calculate the single bitrate level.
6.5 Challenge #5—Identification of the Bottleneck Server
Since the download scheduler in DQ-DASH does not request the same segment from more than
one server to avoid wastage of resources, a bottleneck server can hamper the QoE by causing
stalls. To avoid this situation, the DASH client should identify the bottleneck server and refrain
from requesting a new segment from it. Due to the changing state of a server and the network
condition on the corresponding path, it is not easy to determine the bottleneck server on the fly.
The download scheduler in the proposed method considers a server as a bottleneck if the download throughput of the last segment is less than the lowest available bitrate. This strategy is similar
to the one used by Netflix [1]. The scheduler requests a redundant segment from a bottleneck
server that is already being downloaded by another server to keep track of the current state of it.
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
DQ-DASH: A Queuing Theory Approach to Distributed Adaptive Video Streaming
Fig. 4. Segment scheduling with(out) bottleneck.
4:11
Fig. 5. Scheduling policy in case of out-of-order
segments arrival. Without segment arrival delay
(left), and with arrival delay (right).
Once the throughput increases beyond the lowest available bitrate, the scheduler continues downloading the next non-redundant segment from it. As described earlier, a segment is requested from
a server only if there is no other segment download in progress. This averts choking an already
overloaded server as well as downloading too many redundant segments and throughput overestimation. The implementation of this strategy gives the additional responsibility of maintaining
the timeline of downloads to the download scheduler. An example of this situation is explained
in Figure 4 where in a case without bottleneck the clients c 1 and c 2 fetch the segments in parallel
and they come without redundancy from servers in the order s 1 , s 2 , s 3 , s 2 , s 1 , s 3 , respectively.
In the presence of a bottleneck (server s 2 ), both clients detect the server bottleneck during the
downloading process and react quickly by re-requesting seд3 from s 1 with fast throughput. This
leads to download of a redundant segment from the bottleneck server to keep track of its status.
6.6
Challenge #6—Scheduling Policy
The different network conditions in the path vary the associated throughput. Although the imminently required segments are downloaded from the server with the highest throughput in a greedy
fashion, they may arrive out of order due to dynamic network conditions and server loads. The
DASH client cannot skip a segment, so the unavailability of the next segment for playback causes
stalls even though subsequent segments are available. For example, in Figure 5, we can see that
seд4 is unavailable, but segments seд5 and seд6 are present in the buffer. When the DASH client
completes the playback of seд3 , it will stall until seд4 arrives as the effective buffer occupancy is
now zero. To avoid such situations, the DASH client can re-request seд4 from another server. The
re-requesting of a segment must not be too frequent as it will cause a high number of redundant
segment requests. On the other hand, a too optimistic approach may lead to a stall. DQ-DASH
aborts the ongoing request and re-requests the missing segment when the contiguous part of the
buffer drops below 8 seconds (buffer underflow threshold). The best re-requesting strategy deserves comprehensive investigation and may need extensive experimental evaluations that can be
done in the future.
7 EXPERIMENTAL EVALUATION
In this section, we present the result from our experimental evaluation of DQ-DASH. We first
describe the methodology of our experiments including the network profiles, the video parameters, comparison schemes, and the experimental setup. We then present the DQ-DASH player
implementation in dash.js v2.6.6. We then show the results and their analysis.
7.1 Methodology
7.1.1 Network Profiles. To extensively test our design, we use five different profiles (see Table 2).
We impose profiles P1 to P5 on five different servers to emulate a heterogeneous workload on
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
4:12
A. Bentaleb et al.
Table 2. Characteristics of Network Profiles
Network Profile
P1
P2
P3
P4
P5
Throughput Values (Mbps)
4, 3.5, 3, 2.5, 3, 3.5
2.5, 3, 3.5, 4, 3.5, 3
5, 0.25
9, 4, 3.5, 3, 3.5, 4, 9, 4
3, 3.5, 4, 9, 4, 3.5, 3, 3.5
Inter-variation Duration (s)
30
30
180
30
30
servers. P1 and P4 follow an up-down-up pattern, whereas P2 and P5 follow a down-up-down
pattern. We adopt these profiles from the DASH Industry Forum (DASH-IF) Guidelines [19] as
shown in Table 2. Here, we also created a scenario where one of the servers becomes bottleneck
corresponding to profile P3. We note that the inter-variation duration is the interval time required
before varying the throughput in each profile over the streaming session time.
7.1.2 Video Parameters. We use the reference video sample Big Buck Bunny (BBB) from the
DASH dataset [35]. It is encoded with the H.264/MPEG-4 codec at nine representation levels with
bitrates R = {4.2, 3.5, 3, 2.5, 2, 1.5, 1, 0.75, 0.35} Mbps that comprise approximatelyT = 600s of total
video duration. These bitrate levels correspond to quality levels that are used by YouTube [60].
We do our experimental tests on 1s, 2s, and 4s segment durations for 30s, 60s, and 120s buffer
capacities. The bitrate values at a representation level differ slightly (around 0.1 to 0.3 Mbps) for
different segment durations in the dataset.
7.1.3 Comparison Schemes. To evaluate the performance of our solution, we compared DQDASH against four CDN-based load balancing rules schemes that are available in the web server
NGINX [50] and explained as follows: (a) Round Robin: The set of requests to the DASH servers
are distributed based on a round robin mechanism. This is the default scheme of NGINX. (b) Least
Connected: The next requests are assigned to the DASH servers with a lower load. Thus, this
scheme tries not to overload a busy server with too many requests. (c) Session Persistence: It
always directs a request from the same client to the same DASH server except when this server is
down. This is done using a hash function to determine which server to select for the next request.
(d) Weighted: Here, weights are used to influence the load balancer to give preference to servers
with higher weights. The default weight for every server is one; so, for example, if there are three
servers and the first one has a weight of 3, while the other two have the default weight, then out
of five new requests, the first server will receive three requests, while the other two servers will
get one request each.
7.1.4 Experimental Setup. We performed a set of realistic trace-driven on-demand (VoD) video
streaming experiments using different real-world network profiles (i.e., throughput variability)
from the DASH-IF Guidelines [19], with various segment durations (i.e., 1s, 2s, and 4s), QoE metrics
(i.e., average bitrate, bitrate switch, startup delay, and stalls), number of DASH clients and DASH
servers. Our setup consists of seven machines running Ubuntu 16.04 LTS for DASH clients, DASH
servers, and logging. One machine is a server station with 30 GB RAM, Core i7 CPU, and two GPUs
GeForce GTX 295. The server station runs five Virtual Box VMs, and each VM represents a DASH
server that hosts the video and runs a simple Apache HTTP server (v2.4). Five machines with
4 GB RAM and Core i7 CPUs act as DASH clients where each of them runs the Google Chrome
browser to host our modified dash.js based player (DQ-DASH player in Figure 1). All machines
were connected via a D-link Gigabit switch, and we also used the tc-NetEm network emulator; in
particular, the Hierarchical Token Bucket (HTB) together with Stochastic Fairness Queuing (SFQ)
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
DQ-DASH: A Queuing Theory Approach to Distributed Adaptive Video Streaming
4:13
Fig. 6. Our dash.js based (DQ-DASH) player. The modifications are highlighted in gray color.
queues to shape the total capacity of the links between DASH clients and servers according to our
network profiles. DQ-DASH considers the aggregate bandwidth of the last measured throughput
from all the servers. We set the maximum playback buffer capacity (K) as 30s, 60s, and 120s for 1s,
2s, and 4s segment durations, respectively. The underflow prevention threshold is set as 8s.
7.1.5 Performance Metrics. To evaluate the performance of our solution, we used the following
QoE metrics. We measure the overall quality using the average bitrate played by a DASH client.
We also count the number of changes in representations and their magnitudes. We evaluated the
playback stall durations and the number of occurrences. We summarize the overall effect of the
performance metrics on QoE by the model proposed by Yin et al. [59].
QoE =
Z
t =1
f (R t ) − λ
Z
−1
| f (R t +1 ) − f (R t )| − αTst all − α s Ts
(2)
t =1
Here, the QoE for the Z segments played by a DASH client is a function of their aggregate bitrate
f (R t ), and the magnitude of the difference in adjacently played segments f (R t +1 ) − f (R t ), startup delay Ts and total playback stalls Tst all . As in Ref. [59], f is the identity function, λ = 1, while
α and α s are set to the maximum bitrate of the video sample.
7.2 Implementation
We implemented the proposed solution on dash.js [14] v2.6.6. To leverage multiple sources,
we modified XMLHttpRequest, BaseURLSelector and how the segments will be scheduled in SchedulerController. Also, we added the DQ-DASH ABR scheme as Rule in the
ABRController. The modifications are shown in Figure 6 and explained at a high level as follows: (a) SchedulerController: Controls and generates multiple requests at a time based on the
bitrate selected by the ABR rule and the next available server given by the BaseURLSelector.
Then, it places the request in the XMLHttpRequest for requesting the segment from the corresponding server. (b) BaseURLSelector: Gets the URLs of the existing servers from the Manifest attribute, sorted by their last throughput to decide the next server for downloading the segment. (c) XMLHttpRequest: Prepares the requests given by the SchedulerController in a proper
xhr format through addHttpRequest and modifyRequestHeader methods. Then, it sends multiple requests to different DASH servers in parallel via HTTP GET (i.e., xhr.send()), and receives the responses of the corresponding segments. (d) ABRController: Implements a set of
bitrate decision rules to select the suitable bitrate for the next parallel segments to be downloaded respecting the buffer occupancy and aggregate throughput given by BufferController
and ThroughputEstimator, respectively. The ABR Rules implements the DQ-DASH bitrate selection scheme and is responsible for performing ABR decisions based on the throughput from
a server. Then, it passes such bitrate decisions to the SchedlerController, and in sorted order
of servers to BaseURLSelector. We use a reservoir of 8s buffer, under which we download the
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
4:14
A. Bentaleb et al.
Fig. 7. Performance comparison of DQ-DASH with different segment durations for 30 seconds buffer
capacity.
segment at lowest bitrate to avoid underflow due to variation in bitrate at a representation level.
Unless there is underflow prevention situation, we make the decision to change the representation
after every (K/2 − 8)/τ downloads. This is because QUETRA tries to maintain buffer occupancy
at K/2, and we have 8 seconds for the reservoir.
7.3 Results and Analysis
In this section, we evaluate the performance of DQ-DASH extensively. Our experiments comprise
a set of trace-driven and real-world test cases. We divide these test cases into five scenarios as
shown below. Our experimental results show that DQ-DASH can significantly improve the viewer
QoE and deliver a high-quality video in all considered scenarios. We note that all graphs with error
bars have 95% confidence interval and 5% margin of error.
7.3.1 Segment Duration Selection. In this scenario, we executed a test with a 2s and 4s segment
duration for 30s buffer capacity. Then, five different clients are requesting video segments from
the 5 servers. The set of servers s 1 to s 5 are experiencing network conditions P1 to P5, respectively.
As shown in Figure 7, the performance of DQ-DASH degrades for 2s and 4s segment duration
compared to the case where we run 1s segment duration for 30s buffer capacity. Moreover, our
results have shown that the reduction in average bitrate by 9.5% and 20.3% on average for five
clients for the same video with 2s and 4s segment duration, respectively. Similarly, the QoE is
reduced by 13.6% and 31.6%, respectively. These percentiles represent the difference in average
results over five clients between the best case (i.e., buffer capacity of 30s with chunk duration of
1s) and the runner-up results (i.e., buffer capacity of 30s with chunk duration of 2s or 4s). Although
changes in representation are highest for video of 1s segment by, i.e., approximately 24 compared
to 17 and 22 for video with 2s and 4s segment duration, respectively. In addition, the video player
faces approximately 16 and 53 seconds of stalls on average for five clients for 2s and 4s segment
duration, respectively.
To investigate further, we run the same experiment with a 60s buffer capacity for video with
2s segment duration and 120s buffer capacity for video with 4s segment duration, which we are
not showing due to the space limitation. We observed that the performance of all methods is
similar to the performance for the 1s segment duration and 30s buffer capacity. The degradation in
performance for 4s segment duration and 30s buffer is due to the segment/buffer ratio, the number
of available servers, and segment duration. A client requests segments from all the available servers
in parallel when it has enough capacity in the buffer but does not leverage all servers if the buffer is
about to get full to avoid buffer overflow. For example, if the current buffer occupancy is 18 seconds
out of a total capacity of 30s, the client requests only from three servers (requesting a total of
12 seconds segments) for avoiding a buffer overflow. The remaining capacity of two servers is
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
DQ-DASH: A Queuing Theory Approach to Distributed Adaptive Video Streaming
4:15
Fig. 8. The average bitrate for clients when connected to the different server with profiles (P1–P5) and when
all clients share all the servers (DQ-DASH) for different buffer capacity configurations (30, 60, and 120)s.
Fig. 9. Stall duration and number of stalls when clients are connected to the different server with profiles
(P1–P5) and when all clients share all the servers (DQ-DASH) for different buffer capacity configurations
(30, 60, and 120)s.
shared equally amongst other clients due to TCP fairness. Since all clients have this limitation of
buffer capacity, most of the time they are not leveraging all the servers. This results in the unequal
sharing of a server amongst clients. For 1s segment duration, the repetition of this situation occurs
only if the buffer occupancy of all clients is above 25 seconds out of a total capacity of 30s. Here,
all the clients are likely to be playing at the highest available bitrate due to the richness of buffer
occupancy, so their performance does not get degraded. If we increase the buffer capacity to 120s
while requesting the segments of 4s duration, we give enough room to leverage all the servers,
and the performance becomes similar to the situation where clients request a 1s segment.
7.3.2 Scenario 1 (Single Server DASH vs DQ-DASH). In the first test, we analyzed the scenario
where one client requests video segments from a single server for five different network profiles P1
to P5. Then we compared it to the case where five different clients are requesting video segments
from to all the five servers s 1 to s 5 with network profile P1 to P5, respectively. The idea is to
compare the performance of one-to-one client-server for five clients with respect to all clients
using all servers using the proposed DQ-DASH solution.
Figure 8 shows the average bitrate played during the entire session. Clients experience an average bitrate of 2.9 Mbps to 4 Mbps under profile P1 to P5 with different buffer capacities when
one client is requesting video segments to only one server. Performance under profile P4 is better
than all other profiles as it has the highest magnitude of throughput and starts with the highest
value. The client under profile P4 experiences an average bitrate of 3.8, 3.9, and 4 Mbs for the buffer
capacity 30s, 60s, and 120s, respectively. However, with DQ-DASH where all clients are sharing
five servers with these five network profiles, the clients experience average bitrate of 4, 4, and
3.9 Mbps on average for the buffer capacities 30s, 60s, and 120s, respectively. DQ-DASH also performs better with no stalls even though the server with profile P3 has the bottleneck. So, as shown
in Figure 9, the client requesting from the server with P3 alone experiences 10s and 64s stalls for
the 30s and 60s buffer capacity with three and two stalls, respectively, in total.
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
4:16
A. Bentaleb et al.
Fig. 10. The average QoE when each client is connected to the different server having different profiles (P1–
P5) and when all clients share all the servers with different profiles (DQ-DASH) for different buffer capacity
configurations.
Fig. 11. DQ-DASH vs. CDN-based load balancing rules schemes—The average bitrate when all clients share
all the servers with different profiles (P1–P5) for different buffer capacity configurations (30, 60, and 120)s.
The small error bar in Figure 8 shows the high fairness of the DQ-DASH amongst the clients
regarding the played average bitrate. Although the error bar for the number of change in
representation for 30s buffer capacity is comparatively bigger for DQ-DASH, values are lesser
than that with the one-to-one client-server solution. To sum up all the parameters, we calculated
the QoE as discussed in Section 7.1.5. As Figure 10 shows, clients with DQ-DASH experience 2.35
to 2.41 (x 100) QoE. DQ-DASH is 8% to 33% and 4% to 29% better for the 30s and 60s buffer capacity
compared to one-to-one client-server solution with different profiles. Whereas for 120s, the QoE
is comparable to the nearest value for P4 and 17% better than the smallest value for P2.
7.3.3 Scenario 2 (CDN-based Load Balancing Rules vs. DQ-DASH). To check the robustness of
DQ-DASH in real-world network environments, we compare DQ-DASH against CDN-based load
balancing rules schemes that are implemented in the industry (see Section 7.1.3). We run five
servers with five different network profiles (P1 to P5) shared by five concurrent clients. Each profile
is used to throttle the total capacity between a DASH server and the set of clients.
Figure 11 depicts the average bitrate played during the video streaming session. In all buffer
capacity configurations, we can see that DQ-DASH achieves the best and the most stable average bitrate that ranges from 3.9 Mbps to 4 Mbps for all five clients compared to CDN-based load
balancing rules schemes as shown in Figure 12. Also, DQ-DASH ensures fairness in terms of the
average bitrate among all clients with a variation of 0.1 Mbps, 0.15 Mbps, and 0.3 Mbps, for 30s,
60s, and 120s, respectively. Moreover, two important observations are that (i) CDN least connected
scheme achieves the second best result in average bitrate after DQ-DASH, and (ii) the CDN persistent gets the worst results compared with others. This is because the CDN least connected applies
an efficient request strategy that distributes requests of clients across DASH servers according
to their capacities. This strategy sends the requests to the powerful server, which executes requests more quickly and alleviates the adverse effect of the bottleneck server. However, the CDN
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
DQ-DASH: A Queuing Theory Approach to Distributed Adaptive Video Streaming
4:17
Fig. 12. DQ-DASH vs. CDN-based load balancing rules schemes—The average number of changes in representation when all clients share all the servers with different profiles for different buffer capacity configurations (30, 60, and 120)s.
Fig. 13. DQ-DASH vs. CDN-based load balancing rules schemes—The average QoE when all clients share all
the servers with different profiles for different buffer capacities.
Fig. 14. DQ-DASH vs. CDN-based load balancing rules schemes—-Stall duration and number of stalls when
all clients share all the servers with different profiles (P1–P5) for different buffer capacity configurations (30,
60, and 120)s.
persistent creates a fixed association (hash value) between a client and a server, where all the requests from a given hash value always forwarded to the same server. Thus, the client attached to
the bottleneck server will receive a low bitrate, and this affects the average results over all clients.
The DQ-DASH in contrast to CDN-based load balancing rules leverages all existing DASH servers
and downloads segments from all of them in parallel. It successfully detects the bottleneck server
via a smart bottleneck detection strategy (see Section 6.5); thus, it avoids requesting from this server.
Similarly, in all buffer capacity configurations, DQ-DASH achieves the best average QoE (computed using Equation (2)) with zero stalls and its duration, very low average number of changes in
representation, and start-up delay compared to CDN-based load balancing rules schemes as shown
in Figures 12–14. Clients in DQ-DASH experience a high QoE that ranges from 2.35 to 2.41 (x 100)
compared to CDN least connected that ranges from 1.4 to 1.9, CDN persistent that ranges from
0.43 to 0.73, CDN round robin that ranges from 1.05 to 1.14, CDN weighted from 1.11 to 1.56, in
average for all buffer capacity configurations. The average number of changes in representation,
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
4:18
A. Bentaleb et al.
Fig. 15. Distributed DASH dataset (accessed from France, Austria, Italy)—Average bitrate and changes in
representation for 2s and 4s segment duration for five clients starting together and with a gap of 60s.
stalls, and its duration are high in the CDN-based rules except for CDN persistent that obtains zero
stalls. As a result, these schemes experience a low average QoE. It might be of interest to note that
(i) CDN round robin suffers from many stalls with a long duration because this scheme uses the
round robin mechanism to distribute the requests. Thus, during the turn of the bottleneck server,
the segments take long times to be downloaded by the clients, which leads to video stall. (ii) A
configuration with large buffer capacity decreases the number of changes in representation significantly because large buffer capacity gives more room for the ABR scheme to deal with bandwidth
fluctuations.
7.3.4 Scenario 3 (Internet Dataset Test). In this scenario, we further investigate the performance of DQ-DASH by performing a set of experiments over the real-world Internet. We used
the Distributed DASH Dataset [34] that consists of three servers located in different geographical areas (i.e., France, Austria, Italy) to stream a 6 minute video encoded at 17 bitrate levels
R = {0.1, 0.15, 0.2, 0.25, 0.3, 0.4, 0.5, 0.7, 0.9, 1.2, 1.5, 2, 2.5, 3, 4, 5, 6} Mpbs with segment durations
of 2s and 4s. We run five clients in two test scenarios: (i) all of the clients start the video sessions
in parallel, (ii) clients start incrementally after each other with a gap of Δt = 60 seconds. Figure 15
represents the selected average bitrate and the number of changes in representation for 2s and 4s
segment durations running five clients in the two tests. It shows that most of the time, the clients
select the highest bitrate of 6 Mbps by downloading video segments in parallel from 2 or 3 servers.
Also, the number of changes in representation ranges from 5 to 10 in both tests. Two important
observations can be drawn from this scenario. First, when the number of servers increases, the
clients achieve better performance in the real-world Internet, same as in the test scenarios created
by us. The five clients that together leverage the three servers achieve approximately 10% improvement in the selected bitrate and by 25% less in the bitrate changes, compared to clients using
two servers. Second, both tests are mostly achieving similar results due to the enough aggregate
bandwidth in the Internet paths.
7.3.5 Scenario 4 (Fairness of DQ-DASH). To compare the fairness for the DQ-DASH client with
clients accessing a single server, we run two test cases as shown in Figure 16: (a) running two
clients simultaneously, one DQ-DASH client (sharing five servers with profiles P1–P5) and one
single DASH client (connected to the server with profile P4); (b) two single DASH clients sharing
the server with profile P4. We can see that the DQ-DASH client is friendly when it runs with
the client accessing the single server DASH client and it shares the available bandwidth equally
with him (TCP fair share). During the streaming session, the DQ-DASH client plays the video
at the highest and most stable possible available bitrate (3.9–4.2 Mbps) with fewer changes in
representation (five changes as an average for all buffer capacity configurations) and without any
stall. This because DQ-DASH is benefiting from all the existing servers; thus, the buffer occupancy
of DQ-DASH is frequently at the safe region for all buffer capacity configurations (switch to OFF
state; see Figure 16(c) and 16(d)). This gives more fair share bandwidth for single DASH client
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
DQ-DASH: A Queuing Theory Approach to Distributed Adaptive Video Streaming
4:19
Fig. 16. Bitrate fairness comparison of DQ-DASH client with clients accessing single server.
to improve its bitrate selection (3.7–4 Mbps) as depicted in Figure 16(a) compared to clients in
Figure 16(b) (2.7–4 Mbps).
7.3.6 Scenario 5 (Large-scale Deployment of DQ-DASH). To evaluate the scalability of DQDASH, we performed three real-world test case experiments in our NCL testbed [47]. These experiments consist of 100 clients (rendering video over Google Chrome), four DASH servers with
different profiles, and various last-mile total bandwidth of the single bottleneck link. To emulate a real-world network environment, we used a realistic network topology provided by the
NCL testbed (for more details, refer to Ref. [47]), and we compared the performance of DQ-DASH
against the CDN-based load balancing rules schemes (round robin, least connected, persistent connection, and weighted). The configuration of the test cases are defined as follows: (a) 100 clients
sharing a bottleneck network with a total bandwidth of 300 Mbps and four servers {s 1 , . . . , s 4 } with
network profiles (60, 70, 80, and 90) Mbps (Figure 17(a)); (b) 100 clients sharing a bottleneck network with a total bandwidth of 350 Mbps and four servers {s 1 , . . . , s 4 } with network profiles (60,
70, 80, and 140) Mbps (Figure 17(b)); (c) 100 clients sharing a bottleneck network with a total bandwidth of 400 Mbps and four servers {s 1 , . . . , s 4 } with network profiles (60, 70, 80, and 190) Mbps
(Figure 17(c)). In the case of weighted load balancing rules, the four servers {s 1 , . . . , s 4 } are allocated with weights 1, 2, 3, and 4, respectively. For different buffer capacity configurations, the
result shows that all the DQ-DASH clients select the best and stable possible bitrate with high
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
4:20
A. Bentaleb et al.
Fig. 17. DQ-DASH vs. CDN-based load balancing rules schemes—The average bitrate, changes in representation, and QoE of 100 clients with different total bandwidth (300, 350, and 400) Mbps and buffer capacity
configurations (30, 60, and 120)s.
fairness (see the error bars in Figure 17), QoE, and fewer changes in representation. The weighted
load balancing rule has comparable performance with respect to DQ-DASH for 120s buffer capacity in terms of average bitrate because we have allocated a higher weight to the server with
the highest throughput. The changes in representation are also higher for the weighted load balancing rule that causes the reduction in overall QoE. It is also important to note that most of the
clients in round robin and weighted rules for the 60s and 120s buffer capacity suffer from 1–2 stalls
with up to 50 seconds of total stall duration (not shown in the figure due to space limitation). The
small error bar for DQ-DASH indicates higher fairness for a large number of clients as well. The
100 clients start one by one in the gap of 0.5 seconds (total gap of 50 seconds). So the average
bitrate in few cases for DQ-DASH and weighted load balancing rule is slightly higher than the
full capacity of 300 Mbps, 350 Mbps, and 400 Mbps for the three test cases. With increasing buffer
capacity, the number of changes in representation decreases for both CDN-based load balancing
rules as well as DQ-DASH because there is more room to handle bandwidth fluctuation. In general,
the average bitrate for individual CDN-based load balancer increases with the increase in buffer
capacity. But all of them have a lower bitrate than DQ-DASH and the aggregate bandwidth capacity. DQ-DASH tends to utilize the bandwidth fully, but the average bitrate seems to be decreasing
with the increase in the buffer capacity. In Figure 17, we can see that the average bitrate for DQDASH seems higher for 30s buffer capacity, followed by 60s and 120s buffer capacity, unlike for
CDN-based load balancing rules. This is because the bitrate value at the representation level 6 to
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
DQ-DASH: A Queuing Theory Approach to Distributed Adaptive Video Streaming
4:21
8 (average value of 2.5, 3 and 3.5 Mbps, respectively) in the dataset used [35] is slightly higher for
1s segment, followed by 2s segment and 4s segment (around 0.1 to 0.3 Mbps difference on average). As mentioned before, we use video with 1s, 2s, and 4s segments for 30s, 60s, and 120s buffer
capacities, respectively.
8 DISCUSSION
In this section, we discuss some observations and open issues that we plan to analyze in the future.
8.1 Fault Tolerance
In single server DASH delivery system, the critical failure mode is when the client can no longer
communicate with the DASH server due to the server bottleneck, unreliable link, faulty server,
sudden fluctuation in the network condition, and so on. In this situation, CDN-based solutions
might help, but prior works [18, 43] have shown that it introduces a delay (i.e., DNS redirection),
which may harm the player buffer occupancy and affect the end-user QoE negatively. However,
DQ-DASH successfully addresses these two potential concerns of single server DASH and CDNbased solutions. Fortunately, DQ-DASH leverages multiple servers and avoids the affected link or
server thanks to its robust and smart bottleneck detection strategy. If the client is unable to reach
the server, it will automatically ignore downloading the next segments from it and use only the
remaining servers. Moreover, the client periodically keeps track of the status of the down servers
by either trying to connect with it again or downloading the already played segments if the server
is considered as a bottleneck.
8.2 Client-side Bottleneck
This situation happens when multiple clients start competing for the available bandwidth in a
shared network environment (e.g., last mile network). We tested the performance of DQ-DASH
and CDN-based load balancing rules for the case of last-mile bottleneck where there is no traffic
shaping at all five servers, but all five servers and five clients share a common link of 15 Mbps. In
this scenario, all five clients play the video at 3 Mbps on average for both DQ-DASH as well as for
all CDN-based load balancing rules.
8.3 Server-side Bottleneck Detection
In the presence of server bottleneck, the single server DASH client will suffer from stalls and frequent bitrate changes, which results in a poor viewer QoE. In contrast, DQ-DASH uses multiple
servers and is able to efficiently detect the server bottleneck that may affect the viewer QoE based
on a simple heuristic (i.e., DQ-DASH considers a server as a bottleneck if the download throughput
is less than the lowest available bitrate) as shown in Section 7. We believe that further improvement in the server bottleneck estimation and detection will further enhance our results [8]. In the
future work, we plan to investigate this critical point much more by developing new strategies for
detecting the bottleneck considering more network parameters such as latency, jitter, RTT, and so
on, relying on robust mathematical frameworks such as game theory and machine/deep learning.
9
CONCLUSIONS
Single server DASH clients can have unfair QoE when they are connected to different servers or
having different bottleneck links. Some of the prior research efforts try to avoid this situation by
leveraging multiple servers. However, these efforts require additional support from architecture,
like a server-side API. We proposed DQ-DASH, an evolving adaptive streaming solution that enables multiple sources in DASH delivery systems. Our solution is distributed in nature and works
at the application layer without the need for any extra architectural support. It allows the clients to
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
4:22
A. Bentaleb et al.
benefit from the aggregated bandwidth from diverse paths and multiple servers’ resources; thus,
it can play the video fairly amongst all the clients. Using different scenarios of evaluation over
a broad set of realistic network conditions and real-world testbed, we showed that DQ-DASH
achieved up to 33% and 30% higher QoE and fewer changes in quality compared to single source
DASH and CDN-based load balancing rules, respectively. DQ-DASH is scalable and also avoids
over-exploitation of available bandwidth by downloading just one redundant segment data for
10 minutes of video in all the considered experimental test cases.
REFERENCES
[1] Vijay Kumar Adhikari, Yang Guo, Fang Hao, Matteo Varvello, Volker Hilt, Moritz Steiner, and Zhi-Li Zhang. 2012.
Unreeling Netflix: Understanding and improving multi-CDN movie delivery. In IEEE INFOCOM. 1620–1628.
[2] Saamer Akhshabi, Ali C. Begen, and Constantine Dovrolis. 2011. An experimental evaluation of rate adaptation algorithms in adaptive streaming over HTTP. In ACM MMSys. 157–168.
[3] Abdelhak Bentaleb, Ali C. Begen, Saad Harous, and Roger Zimmermann. 2018. Want to play DASH?: A game theoretic
approach for adaptive streaming over HTTP. In ACM MMSys. 13–26.
[4] Abdelhak Bentaleb, Ali C. Begen, and Roger Zimmermann. 2016. SDNDASH: Improving QoE of HTTP adaptive
streaming using software defined networking. In ACM MM. 1296–1305.
[5] Abdelhak Bentaleb, Ali C. Begen, Roger Zimmermann, and Saad Harous. 2017. SDNHAS: An SDN-enabled architecture to optimize QoE in HTTP adaptive streaming. IEEE TMM 19, 10 (2017), 2136–2151.
[6] A. Bentaleb, B. Taani, A. C. Begen, C. Timmerer, and R. Zimmermann. 2019. A survey on bitrate adaptation schemes for
streaming media over HTTP. IEEE COMST 21, 1 (2019), 562–585. DOI:https://doi.org/10.1109/COMST.2018.2862938
[7] Olivier Brun and Jean-Marie Garcia. 2000. Analytical solution of finite capacity M/D/1 queues. Journal of Applied
Probability (2000), 1092–1098.
[8] Joachim Bruneau-Queyreix, Jordi Mongay Batalla, Mathias Lacaud, and Daniel Negru. 2018. PMS: A novel scaleadaptive and quality-adaptive hybrid P2P/multisource solution for live streaming. ACM TOMM 14, 2s, Article 35
(May 2018), 25 pages.
[9] Joachim Bruneau-Queyreix, Mathias Lacaud, and Daniel Negru. 2017. A multiple-source adaptive streaming solution
enhancing consumer’s perceived quality. In IEEE CCNC. 580–581.
[10] Jin Cao, William S. Cleveland, Dong Lin, and Don X. Sun. 2003. Internet traffic tends toward Poisson and independent
as the load increases. In Nonlinear Estimation and Classification. Springer, 83–109.
[11] Jianyu Cao and Weixin Xie. 2018. Joint arrival process of multiple independent batch Markovian arrival processes.
Statistics & Probability Letters 133 (2018), 42–49.
[12] VNI Cisco. 2017. Cisco Visual Networking Index: Forecast and Methodology. 2016–2021.
[13] Xavier Corbillon, Ramon Aparicio-Pardo, Nicolas Kuhn, Géraldine Texier, and Gwendal Simon. 2016. Cross-layer
Scheduler for Video Streaming over MPTCP. In ACM MMSys. 7.
[14] DASH Reference Player. 2017. Retrieved from https://github.com/Dash-Industry-Forum/dash.js.
[15] Alexander N. Dudin, Vladimir M. Vishnevsky, and Julia V. Sinjugina. 2016. Analysis of the BMAP/G/1 queue with
gated service and adaptive vacations duration. Telecommunication Systems 61, 3 (2016), 403–415.
[16] Kristian Evensen, Dominik Kaspar, Carsten Griwodz, Pål Halvorsen, Audun F. Hansen, and Paal Engelstad. 2012.
Using bandwidth aggregation to improve the performance of quality-adaptive streaming. Elsevier IM 27, 4 (2012),
312–328.
[17] Kristian Evensen, Tomas Kupka, Dominik Kaspar, Pål Halvorsen, and Carsten Griwodz. 2010. Quality-adaptive scheduling for live streaming over multiple access networks. In ACM NOSSDAV. 21–26.
[18] Jeroen Famaey, Steven Latré, Ray van Brandenburg, M. Oskar van Deventer, and Filip De Turck. 2013. On the impact
of redirection on HTTP adaptive streaming services in federated CDNs. In Springer IFIP AIMS. 13–24.
[19] DASH Industry Forum. 2014. Guidelines for Implementation: DASH-AVC/264 Test Cases and Vectors. Retrieved from
http://dashif.org/guidelines/.
[20] Aditya Ganjam, Faisal Siddiqui, Jibin Zhan, Xi Liu, Ion Stoica, Junchen Jiang, Vyas Sekar, and Hui Zhang. 2015. C3:
Internet-scale control plane for video quality optimization. In NSDI. 131–144.
[21] Bo Han, Feng Qian, Lusheng Ji, and Vijay Gopalakrishnan. 2016. MP-DASH: Adaptive video streaming over
preference-aware multipath. In ACM CoNEXT. 129–143.
[22] Xiaojun Hei, Chao Liang, Jian Liang, Yong Liu, and Keith Ross. 2006. Insight into PPLive: A measurement study of a
large-scale P2P IPTV system. In WWW Workshop of IPTV Services.
i
i n−i = 2n + 2 + o (1). Mathematics Stack Exchange. Re[23] Professor Vector. 2017. Show that n
i =0 ((−1) /i!)(n − i ) e
3
trieved April 16, 2017 from https://math.stackexchange.com/q/2236578.
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
DQ-DASH: A Queuing Theory Approach to Distributed Adaptive Video Streaming
4:23
[24] Te-Yuan Huang, Ramesh Johari, Nick McKeown, Matthew Trunnell, and Mark Watson. 2015. A buffer-based approach
to rate adaptation: Evidence from a large video streaming service. In ACM SIGCOMM. 187–198.
[25] ISO/IEC 23009-1:2014 Information technology—Dynamic adaptive streaming over HTTP (DASH). 2014. Retrieved
from https://www.iso.org/standard/65274.html.
[26] Junchen Jiang, Vyas Sekar, and Hui Zhang. 2014. Improving fairness, efficiency, and stability in HTTP-based adaptive
video streaming with FESTIVE. IEEE/ACM TON 22, 1 (2014), 326–340.
[27] Junchen Jiang, Shijie Sun, Vyas Sekar, and Hui Zhang. 2017. Pytheas: Enabling data-driven quality of experience
optimization using group-based exploration-exploitation. In NSDI. 3.
[28] Dag Johansen, Håvard Johansen, Tjalve Aarflot, Joseph Hurley, Åge Kvalnes, Cathal Gurrin, Sorin Zav, Bjørn Olstad, Erik Aaberg, Tore Endestad, et al. 2009. DAVVI: A prototype for the next generation multimedia entertainment
platform. In ACM MM. 989–990.
[29] Parikshit Juluri, Venkatesh Tamarapalli, and Deep Medhi. 2015. SARA: Segment aware rate adaptation algorithm for
dynamic adaptive streaming over HTTP. In IEEE ICCW. 1765–1770.
[30] Dominik Kaspar, Kristian Evensen, Paal Engelstad, Audun F. Hansen, Pål Halvorsen, and Carsten Griwodz. 2010.
Enhancing video-on-demand playout over multiple heterogeneous access networks. In IEEE CCNC. 1–5.
[31] Juhoon Kim, Yung-Chih Chen, Ramin Khalili, Don Towsley, and Anja Feldmann. 2014. Multi-source multipath HTTP
(mHTTP): A proposal. In ACM SIGMETRICS. 583–584.
[32] Jonathan Kua, Grenville Armitage, and Philip Branch. 2017. A survey of rate adaptation techniques for dynamic
adaptive streaming over HTTP. IEEE COMST (2017).
[33] Robert Kuschnig, Ingo Kofler, and Hermann Hellwagner. 2010. Improving internet video streaming performance by
parallel TCP-based request-response streams. In IEEE CCNC. 1–5.
[34] Stefan Lederer, Christopher Mueller, Christian Timmerer, Cyril Concolato, Jean Le Feuvre, and Karel Fliegel. 2013.
Distributed DASH dataset. In ACM MMSys. 131–135.
[35] Stefan Lederer, Christopher Müller, and Christian Timmerer. 2012. Dynamic adaptive streaming over HTTP dataset.
In ACM MMSys. 89–94.
[36] Zhi Li, Xiaoqing Zhu, Joshua Gahm, Rong Pan, Hao Hu, Ali C. Begen, and David Oran. 2014. Probe and adapt: Rate
adaptation for HTTP video streaming at scale. IEEE JSAC 32, 4 (2014), 719–733.
[37] Chenghao Liu, Imed Bouazizi, and Moncef Gabbouj. 2011. Rate adaptation for adaptive HTTP streaming. In ACM
MMSys. 169–174.
[38] Chenghao Liu, Imed Bouazizi, Miska M. Hannuksela, and Moncef Gabbouj. 2012. Rate adaptation for dynamic adaptive streaming over HTTP in content distribution network. Elsevier IM 27, 4 (2012), 288–311.
[39] Hongqiang Harry Liu, Ye Wang, Yang Richard Yang, Hao Wang, and Chen Tian. 2012. Optimizing cost and performance for content multihoming. In ACM SIGCOMM. 371–382.
[40] Yong Liu. 2007. On the minimum delay peer-to-peer video streaming: How realtime can it be? In ACM MM. 127–136.
[41] Zhengye Liu, Yanming Shen, Keith W. Ross, Shivendra S. Panwar, and Yao Wang. 2009. LayerP2P: Using layered video
chunks in P2P live streaming. IEEE TMM 11, 7 (2009), 1340–1352.
[42] Hongzi Mao, Ravi Netravali, and Mohammad Alizadeh. 2017. Neural adaptive video streaming with pensieve. In ACM
SIGCOMM. 197–210.
[43] Matthew K. Mukerjee, Ilker Nadi Bozkurt, Devdeep Ray, Bruce M. Maggs, Srinivasan Seshan, and Hui Zhang. 2017.
Redesigning CDN-Broker interactions for improved content delivery. In ACM CoNEXT. 68–80.
[44] Matthew K. Mukerjee, David Naylor, Junchen Jiang, Dongsu Han, Srinivasan Seshan, and Hui Zhang. 2015. Practical,
real-time centralized control for CDN-based live video delivery. In ACM SIGCOMM. 311–324.
[45] Mehdi Nafaa and Nazim Agoulmine. 2009. Analysing joost peer to peer IPTV protocol. In IFIP/IEEE Integrated Network
Management. IEEE, 291–294.
[46] Thinh P. Nguyen and Avideh Zakhor. 2001. Distributed video streaming over Internet. In Multimedia Computing and
Networking, Vol. 4673. International Society for Optics and Photonics, 186–196.
[47] NUS. 2018. National Cybersecurity Laboratories (NCL) Testbed. Retrieved from https://ncl.sg.
[48] Stefano Petrangeli, Jeroen Famaey, Maxim Claeys, Steven Latré, and Filip De Turck. 2016. QoE-driven rate adaptation
heuristic for fair adaptive video streaming. ACM TOMM 12, 2 (2016), 28.
[49] Wei Pu, Zixuan Zou, and Chang Wen Chen. 2011. Dynamic adaptive streaming over HTTP from multiple content
distribution servers. In IEEE GLOBECOM. 1–5.
[50] Will Reese. 2008. Nginx: The high-performance web server and reverse proxy. Linux Journal 2008, 173 (2008), 2.
[51] Sandvine. 2016. Video Quality of Experience: Requirements and Considerations for Meaningful Insight, white paper.
[Online] https://www.sandvine.com/hubfs/downloads/archive/whitepaper-video-quality-of-experience.pdf.
[52] Kevin Spiteri, Rahul Urgaonkar, and Ramesh K. Sitaraman. 2016. BOLA: Near-optimal bitrate adaptation for online
videos. In IEEE INFOCOM. 1–9.
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
4:24
A. Bentaleb et al.
[53] Thomas Stockhammer. 2011. Dynamic adaptive streaming over HTTP–: Standards and design principles. In ACM
MMSys. 133–144.
[54] Yi Sun, Xiaoqi Yin, Junchen Jiang, Vyas Sekar, Fuyuan Lin, Nanshu Wang, Tao Liu, and Bruno Sinopoli. 2016. CS2P:
Improving video bitrate selection and adaptation with data-driven throughput prediction. In ACM SIGCOMM. 272–
285.
[55] E. Thomas, M. O. van Deventer, T. Stockhammer, A. C. Begen, and J. Famaey. 2017. Enhancing MPEG DASH performance via server and network assistance. SMPTE Motion Imaging Journal 126, 1 (2017), 22–27.
[56] Florian Wamser, Steffen Höfner, Michael Seufert, and Phuoc Tran-Gia. 2017. Server and content selection for MPEG
DASH video streaming with client information. In ACM Internet-QoE. 19–24.
[57] Bing Wang, Wei Wei, Zheng Guo, and Don Towsley. 2009. Multipath live streaming via TCP: Scheme, performance
and benefits. ACM TOMM 5, 3 (2009), 25.
[58] Praveen Kumar Yadav, Arash Shafiei, and Wei Tsang Ooi. 2017. QUETRA: A queuing theory approach to DASH rate
adaptation. In ACM MM. 1130–1138.
[59] Xiaoqi Yin, Abhishek Jindal, Vyas Sekar, and Bruno Sinopoli. 2015. A control-theoretic approach for dynamic adaptive
video streaming over HTTP. In ACM SIGCOMM. 325–338.
[60] YouTube. 2018. YouTube Live Encoder Settings, Bitrates, and Resolutions. Retrieved from https://support.google.com/
youtube/answer/2853702.
[61] Li Yu, Tammam Tillo, Jimin Xiao, and Marco Grangetto. 2017. Convolutional neural network for intermediate view
enhancement in multiview streaming. IEEE Transactions on Multimedia 20, 1 (2017), 15–28.
[62] Hui Yuan, Huayong Fu, Ju Liu, Junhui Hou, and Sam Kwong. 2018. Non-cooperative game theory based rate adaptation for dynamic video streaming over HTTP. IEEE TMC 17, 10 (2018), 2334–2348.
[63] Hui Yuan, Huayong Fu, Ju Liu, and Jimin Xiao. 2016. End-to-end distortion-based multiuser bandwidth allocation for
real-time video transmission over LTE network. IEEE Transactions on Broadcasting 63, 2 (2016), 338–349.
[64] Hui Yuan, Xuekai Wei, Fuzheng Yang, Jimin Xiao, and Sam Kwong. 2018. Cooperative bargaining game-based multiuser bandwidth allocation for dynamic adaptive streaming over HTTP. IEEE TMM 20, 1 (2018), 183–197.
[65] Xinyan Zhang, Jiangchuan Liu, Bo Li, and Y.-S. P. Yum. 2005. CoolStreaming/DONet: A data-driven overlay network
for peer-to-peer live media streaming. In IEEE INFOCOM, Vol. 3. 2102–2111.
[66] Xue Zhang, Laura Toni, Pascal Frossard, Yao Zhao, and Chunyu Lin. 2018. Adaptive streaming in interactive multiview
video systems. IEEE Transactions on Circuits and Systems for Video Technology 29, 4 (2018), 1130–1144.
[67] Chao Zhou, Chia-Wen Lin, Xinggong Zhang, and Zongming Guo. 2014. A control-theoretic approach to rate adaption
for DASH over multiple content distribution servers. IEEE TCSVT 24, 4 (2014), 681–694.
[68] Yipeng Zhou, Dah Ming Chiu, and John C. S. Lui. 2007. A simple model for analyzing P2P streaming protocols. In
IEEE ICNP. 226–235.
Received November 2018; revised October 2019; accepted October 2019
ACM Trans. Multimedia Comput. Commun. Appl., Vol. 16, No. 1, Article 4. Publication date: March 2020.
View publication stats