Poor Video Streaming Performance Explained (and Fixed)

TL;DR

This paper identifies the root cause of poor video streaming performance as small, sequential segment downloads disrupting TCP and router interactions, and proposes an adaptive download size algorithm to improve throughput.

Contribution

It analytically models video flow throughput, develops an adaptive download size algorithm, and implements a DASH player that significantly improves fairness and throughput in streaming.

Findings

Sprint achieves above 90% of fair-share throughput.

State-of-the-art methods vary widely in throughput, often below 50%.

Industry players also underperform in fair bandwidth sharing.

Abstract

HTTP-based video streaming is a key application on the Internet today, comprising the majority of Internet traffic today. Yet customers remain dissatisfied with video quality, resulting in lost revenue for content providers. Recent studies have blamed this on the adaptive bitrate selection (ABR) algorithm used by client players, claiming it interacts poorly with TCP when the video buffer is full, which causes it to underestimate available network bandwidth. We show that the root cause of the problem lies in the data plane, and that even a perfect control plane (ABR) algorithm is not enough to guarantee video flows their fair share of network bandwidth. Namely, it is the sequential download of (small) video segments that is at fault, as they disrupt the normal interaction between TCP congestion control and router queue occupancy. We analytically derive the throughput of a video flow as a function of download size and network conditions, and use this to develop an adaptive algorithm for selecting the download size. Combined with pipelining, our approach achieves near-optimal throughput and fast bitrate adaptation, regardless of the control plane algorithm. We implement our approach as a DASH video player called Sprint, and evaluate it against state-of-the-art proposals from the literature as well as deployed players from Netflix, Youtube, Hulu, and Amazon. Sprint consistently achieves above 90% of its fair-share throughput, while the previous state-of-the-art exhibits high variability (e.g., from 31% to close to fair share depending on the network conditions). Industry players often achieve below 50% of their fair share.

Tables

Table 1. TABLE I: Median unfairness measure (lower is better) and standard deviation across 5 experiments as different types of flows compete with each other.

Queue Size	256		512
	Unfairness	Std. Dev.	Unfairness	Std. Dev
Bulk vs Bulk	0.03	0.18	0.05	0.07
DASH vs DASH	0.04	0.01	0.10	0.04
DASH vs Sprint	0.12	0.04	0.49	0.05
DASH vs Bulk	0.15	0.02	0.45	0.02
Sprint vs Sprint	0.06	0.03	0.05	0.05
Sprint vs Bulk	0.03	0.02	0.03	0.04

Table 2. TABLE II: Network fair share used by video services run over a mobile network while competing against a file download. The measurement period lasts 10 minutes. Hulu could not sustain playback while using a tethered connection.

	Youtube	Netflix	Hulu	Amazon
App	49%	27%	18%	11%
Tether	47%	48%	N/A	30%

Equations

$$E=S/(r\times BD{P}_f)$$

$$E=\frac{S}{r\times BD{P}_f}=\frac{S}{(r_1+r_2+r_3)BD{P}_f}$$

$$1-ϵ\le \frac{r_3}{r_1+r_2+r_3}=\frac{r_{3}BD{P}_f}{(r_1+r_2+r_3)BD{P}_f}$$

$$1-ϵ<\frac{S}{(r_1+r_2+r_3)BD{P}_f}=E$$

Full text

\IEEEsettopmargin

t.875in \IEEEsettextheight.875in.875in

Poor Video Streaming Performance Explained (and Fixed)

Matvey Arye∗, Siddhartha Sen*†*, Michael J. Freedman∗

∗Princeton University, *†*Microsoft Research

I Introduction

Video is the main source of Internet traffic, comprising a whopping 78% of total North American traffic [5]. Yet poor video quality remains a source of dissatisfaction for customers and lost revenue for content providers: estimates place 58.4% of views as impacted by low resolution in 2014 [6].

Video streaming over HTTP is the dominant form of video consumption: it is easy to deploy and allows content providers to reuse existing infrastructure for content distribution. Netflix, Youtube, and Amazon Video all use this form of streaming, and alone account for more than 50% of all peak downstream North American Internet traffic [26]. There are several standards for HTTP-based video streaming, including proprietary ones from Apple, Microsoft, and Adobe, and the open-source Dynamic Adaptive Streaming over HTTP (DASH) standard. All use the same underlying technique. Movies are divided into segments of a given duration (e.g., 4 seconds of video), and each segment is encoded at multiple pre-set bitrates: higher bitrates result in larger, higher-quality segments. These segments are served as static content from regular web servers and caches. The video player on the client determines when to download the next segment and at what bitrate.

We can divide a video player’s functionality into a control plane and a data plane. The control plane chooses when to download the next segment and uses adaptive bitrate selection (ABR) to choose the segment’s bitrate; it maintains the downloaded segments in a buffer. The data plane downloads each segment via an HTTP request. Typically, the ABR algorithm selects a bitrate based on current buffer levels combined with bandwidth estimates based on timing data from the previous downloads. As long as the video buffer is below the target level, segments are downloaded sequentially (one at a time). When the buffer fills, downloads are paused until the buffer drains below a certain watermark. The ABR algorithm walks a tightrope: if a selected bitrate is too high, the download may not keep up with video playback, resulting in interruptions; if the bitrate is too low, video quality and user satisfaction suffer. Ultimately, the goal is to pick a bitrate that matches the available network bandwidth.

Prior work has shown that video flows are unable to achieve their fair share of available bandwidth when competing against other flows [20, 3, 15, 16]. This is a common scenario: shared downlinks are characteristic of both residential Internet connections [27, 9] and mobile networks [19]. In 2014, households had an average of 1.5 devices streaming video concurrently during prime-time [6]. This number is up 28% since 2012, and other flows complete for bandwidth as well.

In a recent study, Huang et al [16] attributed the problem to two things: (i) when the video buffer is full, the pauses between segment downloads cause TCP to time out and reset the congestion window (cwnd), and (ii) lower cwnd values cause the ABR algorithm to underestimate the available bandwidth, leading it to select lower bitrates (smaller segments) that further stymie the growth of cwnd, creating a negative feedback loop. Not surprisingly, the proposed solutions have included alternative ABR algorithms—e.g., Huang et al’s algorithm [17] avoids filling the video buffer—and techniques that ensure a minimum download size to allow cwnd to grow [16].

In common network conditions, however, the proposed solutions are insufficient, given the manner in which network buffer sizes effect video streaming performance. We develop a conceptual and analytical model of how the iterative nature of HTTP-based video streaming interacts with TCP and network buffering, and use it to devise a comprehensive solution.

We first review some TCP basics and establish a connection between a flow’s cwnd and the bandwidth-delay product (BDP) (§II-B). Since competing flows increase the perceived roundtrip time by filling router queues with their packets, they increase BDP. This combined with the sequential nature of video segment downloads—which repeatedly drains the router queues of a flow’s packets—is what leads to suboptimal throughput (§III). In particular, this is a data plane problem that occurs even when the video buffer is not full, so it affects all control-plane algorithms, including those of Huang et al [16, 17]. By addressing the problem, we can improve the performance of all control planes simultaneously.

Armed with this insight, we devise a data plane solution based on ensuring a minimum download size of video data (§IV). Unlike prior solutions that take this approach, we use our knowledge of the root cause to analytically derive the minimum download size required, as a function of current network conditions, in order to achieve a $1-\epsilon$ fraction of the video flow’s fair-share throughput.

We describe two implementations of our solution: one uses expanded range requests and runs inside a regular web page (Sprint-x); the other uses pipelined requests and runs as a browser extension (Sprint). Both solutions are very simple on the surface, but right-sizing the downloads is critical to their efficiency, which in turn relies on a correct understanding of the problem. In particular, we show in §IV-B1 that simply turning on pipelining is not good enough. Our evaluation (§V) shows that our solutions achieve large gains in throughput across a variety of control plane algorithms.

In effect, Sprint allows the control plane to focus on high-level objectives such as quality of experience (QoE), while trusting the data plane to execute its decisions efficiently. Our evaluation additionally shows gains in QoE metrics such as video bitrate, video stalls, and subsequent rebuffering.

To summarize, we make the following contributions:

• •

We show that sequential downloads are a first-class problem for video streaming performance, because they disrupt the normal interaction between TCP congestion control and router queue occupancy.

• •

We develop a model to explain video flow throughput as a function of download size and network conditions. We use this to define an algorithm that adaptively determines the download size needed to achieve fair-share bandwidth given estimates of current network throughput and RTT.

• •

We implement our data plane solution, Sprint, as a DASH video player and evaluate it in emulated and real environments against state-of-the-art proposals and commercial players. We demonstrate Sprint’s universality by applying it to several control-plane algorithms.

II Background

We first summarize prior efforts to explain the underperformance of video flows. Then, we describe an analytical framework for diagnosing problems in the data plane.

II-A Related work

Finding the performance of existing video players lacking, previous work largely proposed new ABR (control plane) solutions to improve performance and QoE. These solutions are complementary to our data-plane changes. Broadly speaking, these works considered three scenarios:

(i) When there are no competing network flows, previous work found that video players often fail to optimize quality of experience (QoE) metrics such as average video bitrate, rebuffering time, and frequency of bitrate changes [2, 22, 8, 25]. Many ABR algorithms have been proposed to optimize QoE metrics. For brevity, we note only two recent algorithms that use a control-theoretic approach to optimize QoE [28, 29]. These ABR algorithms were not designed (or evaluated) for cases when video flows compete for bandwidth, and thus do not address the problems caused by client-side pauses.

(ii) When multiple video players compete for bandwidth, client-side pauses that occur when the video buffers become full can become synchronized [20, 3, 15, 21]. Such synchronization can make it hard for the video players to accurately sense available bandwidth and trap one player in a lower-bandwidth setting, leading to unfairness. FESTIVE [20] and PANDA [21] address these problems by injecting randomness into pause scheduling to de-synchronize video flows, and propose new methods of pause-aware bandwidth estimation.

(iii) When a video player competes against a bulk flow, client-side pauses can lead to TCP congestion window timeouts and other effects that favor the bulk flows [16]. Huang et al. [17] proposed an ABR algorithm that will not fill the buffer and incur client-side pauses unless the player is already downloading segments at the highest bitrate available. This minimizes the number of such pauses that can occur.

Yet video players can fail to achieve their network fair-share even when using the perfect ABR algorithm (§III), i.e., one that picks a bitrate to exactly match the correct fair-share and eliminates all client-side pauses. Thus, changing the control plane while using an unmodified data plane is insufficient. Our work is a data-plane solution that changes different operational parameters than previous ABR solutions. In particular, we change the size of data transferred per request or per pipeline “train” (if using pipelining), and show that this achieves network fair-share with any control plane.

Operating an ABR algorithm on top of an unmodified data plane is complicated by the fact that the ABR decision affects network throughput: smaller bitrates (segment sizes) and/or longer pauses cause throughput to drop. This interaction leads to a negative feedback loop when lowering video bitrate [20, 16] and contributes to the difficulty in bandwidth estimation (a problem noted in [16, 21, 20]). Our data plane solution breaks this interaction by guaranteeing fair-share of network throughput independent of the ABR algorithm.

Previous work has proposed less-thorough versions of our solution based on empirical observation, e.g., Huang et al. [16] advocate downloading larger (fixed-sized) chunks of video data. Yet as we show, the correct size depends on network conditions, and no single size is appropriate for all scenarios. Another study [23] noted that HTTP2, which uses persistent connections and pipelining, improves video performance. While simple pipelining may lead to some benefit, it doesn’t guarantee network fair-share. In contrast, we derive the number of requests to pipeline together analytically as a function of network conditions so as to guarantee network fair-share.

MSPlayer [4] proposes dynamic chunk sizes to synchronize downloads across parallel video streams, not to increase throughput. Other work improves video streaming performance by modifying on-path network elements, e.g., [15, 14]. We focus on client-side solutions as those are easier to deploy.

II-B TCP Throughput Basics

To understand what goes wrong in the data plane of video flows, we need to review some TCP basics. Recall that TCP limits the number of unacknowledged bytes sent on the network to the congestion window (cwnd). Since an acknowledgment takes a roundtrip time (RTT) to arrive, this limits the flow’s throughput to $cwnd/\text{RTT}$. Equivalently, to support a throughput of $T$, cwnd must exceed $T\times\text{RTT}$ bytes, the familiar bandwidth-delay product (BDP). When multiple flows share a bottleneck link, the cwnd of each flow has to exceed the fair-BDP—the fair share of the link bandwidth multiplied by RTT. (For simplicity, we use BDP and fair-BDP interchangeably.) It is critical to note that RTT is a dynamic quantity because it includes queuing delays in the network. Consequently, BDP is also dynamic: it rises and falls as network queues fill and drain (see Figure 1). These fluctuations can be large: a 3Mbps link with a 256KB queue (representative of U.S. home connections, see §V-B) can take 683ms to drain in the worst case. If RTT without queuing is 100ms, BDP could grow by 583%.

TCP flows do not always rely on cwnd exceeding BDP in order to get their fair share of throughput. Instead, in-network queues absorb the peaks and troughs of TCP’s famous cwnd sawtooth pattern. Figure 1 shows the interaction between cwnd and in-network queueing. When cwnd exceeds BDP, the sender is transmitting more bytes than the bottleneck link can drain, so network queues start growing. Eventually, the queues fill to capacity, packets are dropped, and TCP’s congestion avoidance cuts cwnd in half. Now, cwnd might be less than BDP, but the full bottleneck queue can supply data, so no throughput is lost. If the queue is sized appropriately, it will finish draining just as cwnd again exceeds BDP. This analysis of the interaction between congestion control and in-network queuing applies to all AIMD variants of TCP congestion control including Cubic, Reno, and Tahoe.

The following observations, while not new, are critical to understanding the problems with today’s video flows.

Observation 1**.**

BDP is a dynamic quantity that rises and falls as network queues fill and drain.

Observation 2**.**

To fully utilize network bandwidth, either cwnd $>$ BDP or network queues must not be empty. We call a violation of this the inadequate window syndrome.

As we will see, video flows tend to exhibit the inadequate window syndrome, leading to poor throughput.

III Explaining Poor Video Performance

We can now (re-)explain video flow performance and recharacterize prior conclusions. There are three scenarios of interest for a video flow: (i) no competing flows, (ii) competing against a bulk flow with pauses between requests, and (iii) competing against a bulk flow without pauses. (Our evaluation also considers non-bulk flows.)

Prior work has focused on the first two scenarios. Huang et al. [16] showed that video flows underestimate their fair share of bandwidth when competing against bulk flows, causing the video player to choose a lower bitrate than necessary. They attributed this to the periodic pauses that occur when the video buffer is full: the player alternates between downloading video segments to fill the buffer, and pausing while the buffer drains due to video playback. During a pause, cwnd times out and collapses to its initial value (e.g., 10 packets, the Linux default). Since the bulk flow keeps filling the network queues, the video flow experiences high packet loss upon resuming download, causing cwnd to get “repeatedly beaten down.” They did not observe this effect when there was no competing flow.

Our analytical model explains these effects. Moreover, we discover the problem occurs even when there are no pauses in downloading (scenario (iii) below). This occurs while the video buffer is filling and in general when the fair share of bandwidth is below the chosen video bitrate. According to Akamai [1], this is common for high quality video: only 18% of network flows in the U.S. have an average speed above the 15Mbps bitrate characteristic of 4K video.

We find that in this scenario the video flow also fails to achieve its fair share of network throughput even when using the solutions proposed in previous work.

We now (re-)explain the three scenarios:

(i) No competing flows. Without any competing flows, there is no queueing delay in the network, so BDP remains lower than cwnd. This satisfies Observation 2. Even if a pause occurs and cwnd drops to its initial value, this is still often higher than BDP. For example, in Huang et al.’s [16] experiment setup, the BDP of a 5Mbps link with no queueing is 100 kbits, while the initial cwnd is 117 kbits. This explains why they observed good performance when there were no competing flows.

(ii) Competing against a bulk flow with pauses between requests. Competing flows induce a queueing delay, and thus raise BDP during a pause in the video flow. As we observed earlier, this increase can be dramatic. When the video flow resumes downloading, its initial cwnd of 10 packets falls below the current BDP; meanwhile, the preceding pause has drained all video packets from the bottleneck queue. Together, these conditions violate Observation 2 and thus exhibit the inadequate window syndrome, resulting in suboptimal throughput. This explanation is the same as Huang et al.’s [16].

(iii) Competing against a bulk flow without pauses between requests. Even without pauses, the video player still periodically drains the network queues of all video packets. This is because it downloads the video segments sequentially using HTTP requests. Figure 2 illustrates the difference between this sequential flow and a bulk flow. The video player waits to receive the last packet of the previous request (shown in red) before issuing the next request. The act of receiving this packet drains the network queues of all video packets, as the video server has no more data to send until it receives the next request. If cwnd is below BDP at this time—e.g., right after it halves during congestion avoidance, as shown in Figure 1—then the flow will exhibit the inadequate window syndrome and achieve suboptimal throughput.

By focusing on control-plane issues and QoE metrics, prior work may have overlooked the third scenario; also, some experiments used queue sizes that were too small, e.g., 15KB in Huang et al.. A small bottleneck queue may not allow BDP to increase enough to cause the inadequate window syndrome. The majority of U.S. homes have downlink queues greater than 128KB (§V-B), however, and bufferbloat [13] remains a problem.

Prior work has found a negative feedback loop when video flows achieve less than their fair share of throughput [16, 20]: lower throughput causes the ABR algorithm to switch to a lower bitrate; lower bitrate segments are smaller so less data is downloaded and cwnd grows less; lower cwnd values lead to lower throughput. Although previously observed for the second scenario above, we find that it also holds for the third.

III-A Empirical validation

Using tcp_probe traces of actual network transfers, we can validate our explanations of video performance. Figure 3 traces a video flow in each of the above scenarios.

Without competing flows (Figure 3(a)), the video flows encounters no problems because cwnd remains above BDP. The situation is starkly different when competing against a bulk flow with pauses (Figure 3(c)). Here cwnd times out repeatedly due to the pauses and never reaches fair-BDP. The resulting inadequate window syndrome leads to poor throughput.

Figure 3(b) shows the scenario that has been overlooked, where there is a competing flow but no pauses in downloading. We still see the inadequate window syndrome: cwnd falls below fair-BDP at the same time the router queues are emptied of all video packets. This happens at the boundary of video segment downloads: the end of the previous download drains the router queues of all video data (in-flight packets drops to zero), while the queueing delay induced by the competing flow prevents fair-BDP from falling as much as it did without a competing flow. Together, these factors make it likely that, at the start of a next segment download, cwnd is below fair-BDP. This is exactly what happens at seconds 5, 11, 40, 48 and 53. Thus even without pauses, the sequential nature of video downloads can lead to suboptimal throughput. Our evaluation shows that this degradation can be severe in practice, especially for industry video players (Figure 12).

Finally, we validate our claim that the negative feedback loop previously observed applies even without pauses. Figure 4 shows the throughput of sequential downloads as segment size (bitrate) decreases. Clearly, as the ABR algorithm selects lower bitrates, performance will continue to spiral downwards.

III-B Towards a solution

Previous work proposed ABR algorithms that address the second scenario by eliminating pauses between requests. For example, Huang et al.’s algorithm [17] chooses the bitrate based on the current buffer level, and thus avoids filling it unless the available bandwidth supports the maximum bitrate.

However, eliminating pauses is not sufficient: the problem of sequential downloads exists even without pauses, and therefore cannot be resolved by changes in the control plane ABR algorithm. Instead, we must change the way segments are downloaded in the data plane.

Our data-plane solution, Sprint, insulates ABR algorithms from feedback interactions with the network layer. This allows ABR algorithms to focus on QoE metrics instead of the negative feedback loop problems above. Even standard ABR algorithms that had previously shown poor network throughput performance are able to achieve their fair-share of throughput when running on top of our data plane.

IV Fixing Video Performance

Armed with the above analysis, we introduce a new data plane that avoids the interruptions caused by sequential downloads. We achieve this by increasing the amount of data that is downloaded as a continuous stream, which we call a chunk. A chunk that spans multiple video segments allows cwnd to grow and avoids draining the network queues between segments, satisfying Observation 2. In order to use chunks effectively, we need to determine the minimum chunk size needed to achieve fair-share throughput (§IV-A), while still allowing the control plane to adapt the bitrate to available bandwidth (§IV-B).

IV-A Adaptive chunk sizing

To determine the appropriate size for a video chunk, we first quantify the relationship between chunk size and network throughput. We then estimate the minimum chunk size needed to achieve a $1-\epsilon$ fraction of the fair-share throughput.

We define the efficiency of a chunk transfer as the ratio between the achieved and fair-share throughput. We estimate achieved throughput by estimating the number of round-trips used to transfer the chunk during the three phases of TCP:

Slow start. From the beginning of the transfer to the slow start threshold (SST), the number of bytes transferred doubles every round trip. Given an initial cwnd of 10 packets and the MSS, $10\times MSS$ bytes are transferred in the round trip. Therefore the number of rounds in this phase is: $r_{1}=\lceil\log_{2}(SST/(10\times MSS)\rceil+1$ and via a geometric series the total bytes transferred is: $b_{1}=(10\times MSS)(2^{r_{1}}-1)$. 2. 2.

Additive increase. From the slow start threshold until cwnd reaches fair-BDP (denoted $BDP_{f}$), cwnd increases by one MSS every RTT. Thus, the number of rounds is: $r_{2}=\lfloor(BDP_{f}-SST)/MSS\rfloor+1$ and the total bytes transferred is: $b_{2}=r_{2}\times SST+MSS(r_{2}-1)$. 3. 3.

Transfer at BDP. For the rest of the transfer, the bytes transferred per RTT is equal to fair-BDP. Given chunk size $S$, the number of rounds is: $r_{3}=\lceil(S-(b_{1}+b_{2}))/BDP_{f}\rceil$.

The total number of rounds is $r=r_{1}+r_{2}+r_{3}$, and the average throughput per RTT is $S/r$. Since the fair-share throughput per RTT is simply fair-BDP, efficiency is:

[TABLE]

This analysis shows that smaller chunks transfer at lower efficiency because the fraction of time spent in the first two phases (before cwnd reaches fair-BDP) is higher. On the flipside, keeping chunk size constant, the efficiency of the transfer decreases as fair-BDP increases because it takes longer for the cwnd to reach it ($r_{1}$ and $r_{2}$ increase).

To validate Equation 1, we use it to predict the throughput of real chunk transfers. Figure 5 shows that the prediction is accurate across a wide range of chunk sizes and bottleneck queue sizes. The prediction takes as input the measured average slow-start threshold, chunk size, and bottleneck link bandwidth. Each data point is an average of 10 chunk transfers.

Using Equation 1, we determine the chunk size large enough to ensure an efficiency of $1-\epsilon$, for any $\epsilon$. This ensures the video flow achieves at least $1-\epsilon$ fraction of its fair-share throughput (in our experience, $\epsilon=0.1$ is sufficient). Equation 1 can be rewritten as:

[TABLE]

If we bound $(r_{1}+r_{2})/(r_{1}+r_{2}+r_{3})\leq\epsilon$ we get:

[TABLE]

Since $r_{3}BDP_{f}=S-(b_{1}+b_{2})$, which is less than $S$,

[TABLE]

Thus, if we set $r=(r_{1}+r_{2})/\epsilon$, then the efficiency has to be greater than $1-\epsilon$. Intuitively, we bound the number of round trips during which throughput underperforms ($r_{1}+r_{2}$) to a small fraction ($\epsilon$) of the overall transfer ($r$).

Program 1 shows our algorithm for selecting the chunk size of a video transfer, based on the derivation above. The getChunkSize function takes as input an estimate of the current bandwidth and RTT, as well as the desired $\epsilon$. It sets $r=(r_{1}+r_{2})/\epsilon$ and then uses Equation 1 to determine the chunk size. The program make the following conservative assumptions since it cannot access the internal state of the congestion control protocol: (i) that cwnd drops to its initial value between requests and TCP re-enters slow start, and (ii) that SST is set to $3/4$ of fair-BDP instead of $3/4$ the maximum cwnd as per TCP’s specification.

In our implementation, we use standard techniques to estimate RTT and bandwidth: the RTT is obtained by measuring the latency of a 10-byte XHR request that we send to the video server every second. Bandwidth is estimated by taking an EWMA over the measured throughputs of video segment downloads while downweighting smaller requests.

We note that there is no interaction between Program 1 and the ABR algorithm choosing the bitrate. A chunk may contain multiple segments of varying bitrates. The data plane simply ensures that a chunk size of data is continuously downloaded.

IV-B Two data plane implementations

Program 1 tells us the right chunk size to use, but does not tell us how to download this amount of data. We describe two simple data plane mechanisms for performing the actual downloads. The first, called Sprint, pipelines multiple video segment requests together to comprise a larger (chunk-sized) download. The second, called Sprint-x, issues a single range request that spans enough video data to meet the chunk size. Both players are implemented as modifications of dash.js [7].

We allow the video player to adapt the bitrate in the middle of a chunk, and use the minimum chunk size to ensure the video flow achieves its fair-share throughput. However, whereas Sprint achieves these goals simultaneously, Sprint-x imposes a tradeoff between bitrate adaptation and throughput. On the flipside, Sprint is not readily implementable using standard web browser APIs, and hence must be deployed as a browser extension.

IV-B1 Sprint: Pipelined requests

Our first mechanism uses HTTP pipelining to string multiple video segment requests together. By structuring this pipeline carefully, we can ensure the video server is never waiting for an HTTP request and that the ABR algorithm can change bitrates in a timely manner. 111In some scenarios, e.g., live video streaming, pipelining is difficult because the data is not yet available. We do not consider such scenarios.

We refer to the segment requests belonging to the same chunk as a train; the size of the train is exactly the chunk size from Program 1. Clearly, if we pipeline a train all at once, the ABR algorithm will not be able to change bitrates in the middle of a chunk. This is a problem because the chunk size may be quite large. Instead, we pipeline the requests incrementally, by limiting the number of outstanding requests in the network. As soon as a request completes (reducing the outstanding requests by one), a new segment can be requested. This continues until the entire train has been issued.

In order to set the number of outstanding requests, we observe that we only need enough of them to ensure the video server is not idly waiting in the middle of a chunk. Thus, we set this number to generate a response of at least BDP bytes (but enforce a minimum of 2 to avoid sequential downloads). Although the ABR algorithm cannot change the bitrate of outstanding requests, in practice only a few are needed and they also complete within a few RTTs.

Why not normal HTTP pipelining? One might wonder why a minimum train size is needed if requests are being pipelined, since the video player is continuously downloading data anyway. The answer is that it is needed for when the buffer fills and the player oscillates between downloading data and pausing to drain the buffer. Some ABR algorithms explicitly avoid filling the buffer (e.g., [17]), but many do not. To serve all cases, Sprint enforces the minimum train size each time downloading resumes, even if this causes the buffer to overfill—the latter can easily be accommodated by allocating a small amount of additional space, no larger than the minimum train size. Our evaluation shows this is necessary for good performance (Figure 11). We also show that the maximum buffer size remains bounded in practice (Figure 10), since its growth depends on the gap between video bitrate and available throughput, which the ABR algorithm tackles.

Browsers do not currently provide sufficient APIs to HTML5 video players to implement Sprint. Neither the XMLHttpRequest API nor the new experimental Fetch API [12] expose control over how requests map onto TCP connections. This makes it impossible to form pipeline trains in a controlled manner. Thus, we implement Sprint as a Chrome extension, which uses lower-level socket API. In contrast, Sprint-x can be implemented using standard HTML5 video.

IV-B2 Sprint-x: Expanded range requests

Our second mechanism requests a larger range of data in each HTTP request. In DASH video, it is common for servers to store a video as a single, contiguous file. To fetch individual segments, players use the HTTP Content-Range header to specify a byte range within the file. Sprint-x simply increases this byte range to span at least the chunk size. Note that this approach will not work if video segments are stored as separate files. In addition, requesting variable segment sizes may interact poorly with caching services such as CDNs.

To change the bitrate in the middle of a chunk download, the video player can call the cancel() method on the current HTTP request and issue a new request. Canceling a request closes the underlying TCP connection, and starting a new connection incurs a throughput penalty. Thus, frequent bitrate changes will decrease overall throughput. As shown in our evaluation, this tradeoff disadvantages Sprint-x compared to Sprint.

V Evaluation

We compare the performance of Sprint against leading industry players, and answer the following questions about Sprint’s performance in various scenarios:

• §V-B

When competing against bulk flows across varying bottleneck bandwidths, queue sizes, and number of competing flows;

• §V-B

When competing against other video flows;

• §V-C

With many different control plane algorithms;

• §V-C

When evaluating whether the pipeline train is necessary for good performance;

• §V-D

Compared to today’s video players;

• §V-E

Compared to the expanded-range-request approach of Sprint-x, as opposed to its own pipelining.

We start by establishing a baseline implementation for industry players. Then, we compare the performance of our player to that baseline.

V-A Experimental setup and methodology

Fixed broadband networks. To evaluate video performance on fixed broadband networks, we emulate a range of bottleneck network conditions. We connected (via wired Ethernet) two laptops to a Cisco E1200 home router. We installed DD-WRT on the router and used Linux’s token-bucket filter (tbf) to adjust downstream bandwidth and queue sizes. In all of our experiments, our ISP’s actual downstream bandwidth was greater than that permitted by the token bucket. Unless otherwise specified, the experiments used a bottleneck bandwidth of 3Mbps and a queue size of 256KB (although some experiments go up to 25Mbps and 1536KB, respectively). These are representative values: 3Mbps was chosen from the Netflix ISP Speed Index for the US [24], and 44% of home internet connections have a download queue size of 256KB or greater (see §V-B). The TCP buffers on both laptops were tuned to avoid being limited by TCP flow control in all the network scenarios tested. Flow control is only relevant if the application receiving data cannot keep up with the network or if the TCP buffers are too small for the network. We believe these issues are rare due to the availability of high-performance browsers and TCP buffer auto-tunning.

Mobile networks. We also performed experiments on mobile devices running on the T-Mobile network. No traffic shaping was used for these experiments.

Measuring performance. From an experimental point of there is a very clear decomposition: the data plane is evaluated based on whether it achieves its fair share of network bandwidth while the control plane is evaluated on how closely the video bitrate tracks the network rate. Thus, we report both the network throughput achieved by the video flow and QoE measures such as video bitrates, buffer levels and number of rebuffering events. Though, since we propose a data plane solution that is independent of the control plane, we concentrate on measures of network throughput. The video bitrate has to be slightly lower than network throughput on average in order to have uninterrupted video playback. So any problems in network throughput necessitate inferior video quality downloads.

We measure fairness using two metrics. For experiments where multiple video flows compete again each other, we use the Jain’s fairness index (JFI) [18]. For experiments where a video flow competes against a bulk flow, we use the percent of fair-share throughput achieved by a video flow. We use percent fair-share instead of JFI in the latter scenario because it is easier to interpret (if a flow achieves X% of fair-share throughput, then the video bitrate is at most X% of optimal) and because it isolates the video flows from the competing bulk flows, which we already know achieve their fair share.

We define fair share as the total bandwidth divided by the number of flows. We measure total bandwidth using tshark traces by summing the throughput of all flows. This allows us to measure fair-share in networks we do not control (e.g., in our cellular network experiments), and relies on the fact that bulk flows expand to consume any unused bandwidth.

ABR algorithm. Our evaluation often compares Sprint against the DASH player as a baseline, since DASH performs no worse than the leading industry players. To isolate the effects of our data plane solution, both DASH and Sprint use the same (control plane) ABR algorithm. Thus, they only differ in how they download data: DASH downloads 4-second video segments sequentially, while Sprint (Sprint-x) uses our pipelining (expanded range request) solution with dynamic chunk sizing from Section IV.

We use an ABR algorithm modeled after the best-in-class solution of Huang et al. [17], unless otherwise specified. The algorithm selects the video bitrate based on the level of the video buffer: every time the buffer level increases (decreases) by 10 video-seconds, the bitrate is increased (decreased). To prevent oscillation, the algorithm never switches back to the last bitrate. We chose this algorithm (instead of newer ones e.g., Yin et al. [29]) because Huang’s algorithm was already optimized for environments with competing flows. Using it thus serves to highlight the problems identified (and improvements achieved) by our work.

In all of our experiments, the maximum video bitrate is higher than the fair-share bandwidth. Since the ABR algorithm we use ensures that the video buffer never fills in this case, the weaknesses shown by DASH are not due to the pauses discussed in prior work.

V-B *Sprint utilizes its fair-share of the network across

a wide-range of scenarios.*

Sprint is able to achieve fair-share of network throughput across a wide range of network conditions. In contrast, DASH, which does not benefit from our data plane mechanisms, performs poorly in many realistic scenarios.

Varying bottleneck bandwidth and queue size.

Figure 6 shows the percent of fair-share throughput achieved by Sprint and DASH when they compete with a bulk flow downloaded from the same server. For all values of bottleneck bandwidth and queue size tested, Sprint achieves its fair share of throughput. Our analysis from §III gives us the insight necessary to explain the performance of DASH. DASH’s throughput deteriorates when queue size grows while bandwidth remains constant because competing flows induce longer queuing delays, inflating BDP. Conversely, when bandwidth is increased while queue size is held constant, video throughput improves. In this case, BDP does not actually increase that much because the queueing delay decreases, but the segments are larger because of the higher video bitrate.

Our improvement in achieved throughput translates to a substantial positive effect on QoE. Figure 7 shows that both Sprint and Sprint-x are able to play higher-quality videos than DASH. Figure 8 shows that the amount of rebuffering experienced by our players is lower. A thorough evaluation of QoE depends on the control plane being used, which Sprint tries to be agnostic to; we discuss this further in §V-C.

We use network parameters in our model that are representative of real home networks. To estimate the bottleneck queue size in these networks, we use a method similar to the one used by Sundaresan et al. [27]. We use data from an ongoing study of US home networks run by the FCC and SamKnows [11, 10]. This dataset has an experiment in which the home router pings a server and downloads a file simultaneously. The maximum RTT of the pings is representative of the bottleneck queue size. We multiply this value by the link bandwidth to estimate the queue size, and we use the result to determine the percent of home connections with a certain queue size or greater. Figure 6 annotates these percentages next to the appropriate queue size and bandwidth setting. Since performance degrades with larger queues for players like DASH, the percentages indicate the number of home connections whose performance will be no better than that shown.

Competing against other video flows.

Table I shows what happens when DASH and Sprint video flows compete against other bulk and video flows. We evaluate (un)fairness using the same measure as in Festive [20]: Unfairness = $\sqrt{1-\texttt{JFI}}$, where JFI is Jain’s fairness index [18]. Thus, a lower value implies more fairness. We show the unfairness measure for two competing bulk flows to provide a baseline. It is clear that DASH vs DASH performs only slightly worse than this baseline. However, when DASH competes against a bulk flow, the bulk flow dominates and the video flow is unable to get its fair-share of throughput. DASH is also unable to compete with Sprint flows in much the same way. In contrast, Sprint, performs well when competing with other video or bulk flows.

Varying the number of competing bulk flows.

When a video flow competes with multiple bulk flows, its performance is similar to when it competes with a single bulk flow. For example, when competing against four bulk flows, DASH achieves a median 80% of fair-share throughput across five 30-minute experiments, while Sprint achieves 102%. The results for a single competing bulk flow are 85% and 97%, respectively. Intuitively, adding more bulk flows reduces the video flow’s fair share of bandwidth, causing it to use a lower bitrate and thus segment size. Since both fair-BDP and segment size reduce simultaneously, the net effect is canceled out.

V-C Sprint works well with many different ABR algorithms

Sprint provides a data plane solution that allows many different control plane (ABR) algorithms to achieve good network performance. This allows the control plane to focus on optimizing the QoE without worrying about the network.

In general, ABR algorithms strive to achieve the highest possible video bitrate without causing rebuffering. They are often characterized by their aggressiveness—i.e., how high they make the bitrate. To show that Sprint performs well across a range of aggressiveness settings, we use a simple ABR algorithm that matches the bitrate to a percentage of the measured throughput. Since an aggressiveness of less than 100% will use less than the full fair share, we present the results in terms of expected fair share, which we define as $\min(100\%,\text{aggressiveness})$ times the fair share.

As Figure 11 shows, Sprint achieves its fair share of throughput even when the ABR algorithm is less aggressive. This is a challenging scenario because the video buffer often fills and causes pauses in downloading. Prior work showed that video players underperform in this regime [3, 16] and proposed new ABR algorithms to avoid pauses [20, 17]. In contrast, Sprint uses the pipeline train size to ensure that enough data is transferred between pauses (§IV-B1). Figure 11 shows that when the train size is not enforced, network throughput degrades significantly for aggressiveness settings less than 100%. Many ABR algorithms fall into this category; for example, by default DASH has an aggressiveness of 90%.

The interaction between Sprint and the ABR algorithm is complex. In some cases, Sprint may obviate the need for a control-plane feature (e.g., aggressiveness); or vice versa, e.g., Huang et al’s [17] algorithm avoids filling the buffer, making Sprint’s minimum train size unnecessary.

V-D Sprint outperforms existing players

To demonstrate that even leading industry video-on-demand services fail to achieve their fair share of throughput, we evaluate the performance of Youtube, Netflix, Hulu, and Amazon Video. For each service, we stream videos via a web browser222We use Chrome for Netflix, Youtube, and Amazon Video. We use Firefox for Hulu, the only browser under Linux on which Hulu runs. while simultaneously downloading a large file through the browser. Both the video and file download flows share the bottleneck link created by our home router or mobile connection. The video streams are unmodified and thus incorporate all of the services’ network and CDN optimizations.

Fixed broadband networks.

Figure 12 traces the aggregate throughput of the video and file download flows for Netflix, Amazon, Hulu, and Youtube. The large gap in throughput that develops between the two flows indicates that the video flow is unable to achieve its fair share when competing against bulk flows. At the same time, the dotted line shows that in the absence of competition, these players are able to use their fair share to achieve a higher video bitrate.

We now show that it is the data plane, not the control plane, that is mostly responsible for this gap. The control plane can negatively affect a video flow’s throughput if it stops requesting data or inserts pauses between requests, such as when the video buffer fills. Conversely, if the control plane is continuously requesting data, then the data plane should in principle be able to achieve the full fair share of throughput. We measured the pauses between consecutive requests for all players and found that they were less than 100ms at the 95th percentile for Amazon, Netflix, and Youtube. This suggests that the control plane was not the culprit for these players. Hulu, on the other hand, had significant pauses between requests: 1373ms at the 95th percentile.

To obtain a definitive answer, we conducted a controlled experiment that forced each player to use a fixed video bitrate close to the fair-share throughput, thus bypassing the ABR algorithm. All players except Amazon provide a setting to do this. Figure 9 shows the results. Using the fixed bitrate, the pauses between requests for Hulu were reduced to 128ms at the 95th percentile, and in general the video buffer never filled for any of the players. For all players, the degradation in throughput caused by using the ABR algorithm is only a small part of the total degradation from 100%. This means that the remaining degradation is due to the data plane.

Youtube does not perform as well as the other players when operating without competing flows at (Figure 12d). This is due to a large gap in bitrate encoding levels at this bandwidth setting: the closest bitrates are 727Kbps and 1469Kbps. Youtube’s ABR tends to drop to the lower bitrate in the middle of playback. For the fixed bitrate experiment in Figure 9, we forced the player to use the higher bitrate throughout, but Youtube still used only 75% of its fair-share.

Using the same experimental setup, we evaluate our Sprint and Sprint-x players as well as the DASH player. Figure 10 clearly shows that both Sprint and Sprint-x outperform DASH and achieve close to—slightly more, in the case of Sprint—their fair share of throughput. Similarly, our players achieve a higher median video bitrate. The buffer level graphs show that none of the players experience rebuffering.

Mobile networks.

We tested the mobile performance of the industry players by using each service’s mobile app, and also by running the web browser version of the service on a laptop connected to the Internet via USB tethering. Both experiments were instructive. The app experiment revealed that these services did not implement any (effective) special logic to compensate for the large latencies of mobile networks. At the same time, the tethering experiment made sure that the performance of the video player was not affected by any limitations built into the app (e.g., to save mobile data). The tethering experiment was also necessary because we noticed that the throughput of some of the apps was limited by the TCP send window, perhaps due to limited receive buffers. The tethering experiment ran on a laptop with a TCP stack tuned so as to avoid this limitation.

Table II shows the results when playing a video concurrently with a file download. Both the app and tethering experiments show that the video services are not able to achieve their fair share of throughput over mobile networks.

In contrast, Sprint is able to fully utilize its fair share of mobile bandwidth. We tested the Sprint and DASH players by streaming a video for 10 minutes while performing a file download on a laptop connected by USB tethering. The average percent of fair-share throughput achieved over five experiments was 98% for Sprint and only 80% for DASH.

V-E Sprint-x is not as good as Sprint

Figure 6 shows that while Sprint-x performs better than unmodified DASH, it performs worse than Sprint. This is because Sprint-x has to cancel ongoing requests when switching bitrates (as discussed in §IV-B2). Canceling requests incurs a throughput penalty as illustrated in Figure 13, where the only time when the video flow achieves its fair-share is during minutes 15-20 when no bitrate changes occur.

VI Conclusion

TCP dynamics interact poorly with data transfers that use small, sequential web requests, instead of the bulk transfers for which TCP was designed. To enable video flows to achieve their fair-share throughput, we derive and implement a data-plane mechanism right-sizing requests so that these flows acts more like bulk transfers. Our evaluation shows significant and consistent improvements over state-of-the-art and industry video players, with benefits across all tested ABR algorithms.

Our approach solves the throughput problems with on-demand video streaming but similar problems exist in real-time communication (RTC). RTC is sensitive to increased latency and thus filling up network queues to gain throughput—as we do in our proposed solution—is not an attractive approach in the presence of bufferbloat [13]. In fact there might not be any good end-to-end solutions for mitigating latency when RTC flows compete against bulk flows in a bufferbloated network. Instead, in-network changes to limit queue latency (e.g., fair-queing, AQM) are necessary. Such changes would also be an alternative–if harder to deploy–solution to the video throughput problems discussed in this paper.