Probe and Adapt: Rate Adaptation for HTTP VideoStreaming At Scale

Zhi Li, Xiaoqing Zhu, Josh Gahm, Rong Pan, Hao Hu, Ali C. Begen, Dave OranCisco Systems, San Jose, CA USA

{zhil2, xiaoqzhu, jgahm, ropan, hahu2, abegen, oran}@cisco.com

Abstract—Today, the technology for video streaming overthe Internet is converging towards a paradigm named HTTP-based adaptive streaming (HAS), which brings two new features.First, by using HTTP/TCP, it leverages network-friendly TCPto achieve both firewall/NAT traversal and bandwidth sharing.Second, by pre-encoding and storing the video in a number ofdiscrete rate levels, it introduces video bitrate adaptivity in ascalable way so that the video encoding is excluded from theclosed-loop adaptation. A conventional wisdom is that the TCPthroughput observed by an HAS client indicates the availablenetwork bandwidth, and thus can be used as a reliable referencefor video bitrate selection.

We argue that this is no longer true when HAS becomesa substantial fraction of the total traffic. We show that whenmultiple HAS clients compete at a network bottleneck, thepresence of competing clients and the discrete nature of thevideo bitrates together result in difficulty for a client to correctlyperceive its fair-share bandwidth. Through analysis and test bedexperiments, we demonstrate that this fundamental limitationleads to, for example, video bitrate oscillation that negativelyimpacts the video viewing experience. We therefore argue thatit is necessary to design at the application layer using a “probe-and-adapt” principle for HAS video bitrate adaptation, whichis akin to, but also independent of the transport-layer TCPcongestion control. We present PANDA – a client-side rateadaptation algorithm for HAS – as practical embodiment ofthis principle. Our test bed results show that compared toconventional algorithms, PANDA is able to reduce the instabilityof video bitrate selection by over 75% without increasing therisk of buffer underrun.

I. INTRODUCTION

Over the past few years, we have witnessed a major tech-nology convergence for Internet video streaming towards anew paradigm named HTTP-based adaptive streaming (HAS).Since its inception in 2007 by Move Networks [1], HAS hasbeen quickly adopted by major vendors and service providers.Today, HAS is employed for over-the-top video delivery bymany major media content providers. A recent report by Cisco[7] predicts that video will constitute more than 90% of thetotal Internet traffic by 2014. Therefore, HAS may become apredominant form of Internet traffic in just a few years.

In contrast to conventional RTP/UDP-based video stream-ing, HAS uses HTTP/TCP – the protocol stack traditionallyused for Web traffic. In HAS, a video stream is choppedinto short segments of a few seconds each. Each segment ispre-encoded and stored at a server in a number of versions,each with a distinct video bitrate, resolution and/or quality.After obtaining a manifest file with necessary information, aclient downloads the segments sequentially using plain HTTP

Fetched Bitrate Aggregated over 36 Streams

200 300 400 500 600 700 800 900 1000 1100 120060

80

100

120

Time (Sec)

Fet

ched

(M

bps)

Fetched Bitrate of Individual Streams (Zoom In)

400 420 440 460 480 500 520 540 560 580 6000

2

4

6

Time (Sec)

Fet

ched

(M

bps)

Fig. 1. Oscillation of video bitrate when 36 Microsoft Smooth clientscompete at a 100-Mbps link. For more detailed experimental setup, refer to§VI-B.

GETs, estimates the network conditions, and selects the videobitrate of the next segment on-the-fly. A conventional wisdomis that since the bandwidth sharing of HAS is dictated byTCP, the problem of video bitrate selection can be resolvedstraightforwardly. A simple rule of thumb is to approximatelymatch the video bitrate to the observed TCP throughput.

A. Emerging Issues

A major trend in HAS use cases is its large-scale de-ployment in managed networks by service providers, whichtypically leads to aggregating multiple HAS streams in theaggregation/core network. For example, an important scenariois that within a single household or a neighborhood, severalHAS flows belonging to one DOCSIS1 bonding group competefor bandwidth. In the unmanaged wide-area Internet, as HASis growing to become a substantial fraction of the total traffic,it will also become more and more common to have multipleHAS streams compete for available bandwidth at any networkbottlenecks.

While a simple rate adaptation algorithm might work fairlywell for the case where a single HAS stream operates aloneor shares bandwidth with non-HAS traffic, recent studies[13], [3] have reported undesirable behaviors when multipleHAS streams compete for bandwidth at a bottleneck link. Forexample, while studies have suggested that significant videoquality variation over time is undesirable for a viewer’s qualityof experience [18], in [13] the authors reported unstable video

1Data over cable service interface specification.

arX

iv:1

305.

0510

v2 [

cs.N

I] 7

Jul

201

3

bitrate selection and unfair bandwidth sharing among threeMicrosoft Smooth clients sharing a 3-Mbps link. In our owntest bed experiments (see Figure 1), we observed significantand regular video bitrate oscillation when multiple MicrosoftSmooth clients share a bottleneck link. We also found thatoscillation behavior persists under a wide range of parametersettings, including the number of players, link bandwidth, starttime of clients, heterogeneous RTTs, random early detection(RED) queueing parameters, the use of weight fair queueing(WFQ), the presence of moderate web-like cross traffic, etc.

Our study shows that these HAS rate oscillation and insta-bility behaviors are not incidental – they are simply symptomsof a much more fundamental limitation of the conventionalHAS rate adaptation algorithms, in which the TCP down-loading throughput observed by a client is directly equatedto its fair share of the network bandwidth. This fundamentalproblem would also impact a HAS client’s ability to avoidbuffer underrun when the bandwidth suddenly drops. In brief,the problem derives from the discrete nature of HAS videobitrates. This makes it impossible to always match the videobitrate to the network bandwidth, resulting in undersubscrip-tion of the network bandwidth. Undersubscription is typicallycoupled with clients’ on-off downloading patterns. The off-intervals then become a source of ambiguity for a client tocorrectly perceive its fair share of the network bandwidth,thus preventing the client from making accurate rate adaptationdecisions2.B. Overview of Solution

To overcome this fundamental limitation, we envision asolution based on a “probe-and-adapt” principle. In this ap-proach, the TCP downloading throughput is taken as aninput only when it is an accurate indicator of the fair-sharebandwidth. This usually happens when the network is over-subscribed (or congested) and the off-intervals are absent. Inthe presence of off-intervals, the algorithm constantly probes3

the network bandwidth by incrementing its sending rate, andprepares to back off once it experiences congestion. Thisnew mechanism shares the same spirit with TCP’s congestioncontrol, but it operates independently at the application layerand at a per-segment rather than a per-RTT time scale. Wepresent PANDA (Probe AND Adapt) – a client-side rateadaptation algorithm – as a specific implementation of thisprinciple.

Probing constitutes fine-tuning the requested network datarate, with continuous variation over a range. By nature, theavailable video bitrates in HAS can only be discrete. A mainchallenge in our design is to create a continuous decision spaceout of the discrete video bitrate. To this end, we propose tofine-tune the intervals between consecutive segment downloadrequests such that the average data rate sent over the network

2In [3], Akhshabi et al. have reached similar conclusions. But they identifythe off-intervals instead of the TCP throughput-based measurement as theroot cause. Their sequel work [4] attempts to tackle the problem from a verydifferent angle using traffic shaping.

3By probing, we mean small trial increment of data rate, instead of sendingauxiliary piggybacking traffic.

Time  

Rate  

(a) PANDA

Time  

Rate  

Steady  State  (Buffer  Full)  Buffer  Growing  

(b) Conventional Bimodal

Fig. 2. Illustration of PANDA’s fine-granular request intervals vs. aconventional algorithm’s bimodal request intervals.

Notation Explanationw Probing additive increase bitrateκ Probing convergence rateα Smoothing convergence rateβ Client buffer convergence rate∆ Quantization marginε Multiplicative safety marginτ Video segment duration (in video time)B Client buffer duration (in video time)

Bmin; Bmax Minimum/maximum client buffer durationT Actual inter-request timeT Target inter-request timeT Segment download durationx Actual average data ratex Target average data rate (or bandwidth share)y Smoothed version of xx TCP throughput measured, x := r·τ

TR Set of video bitrates R := {R1, ..., RL}r Video bitrate available from RS(·) Rate smoothing functionQ(·) Video bitrate quantization function

TABLE INOTATIONS USED IN THIS PAPER

is a continuous variable (see Figure 2 for an illustrative com-parison with the conventional scheme). Consequently, insteadof directly tuning the video bitrate, we probe the bandwidthbased on the average data rate, which in turn determines theselected video bitrate and the fine-granularity inter-requesttime.

There are various benefits associated with the probe-and-adapt approach. First, it avoids the pitfall of inaccurate band-width estimation. Having a robust bandwidth measurementto begin with gives the subsequent operations improved dis-criminative power (for example, strong smoothing of thebandwidth measurement is no longer required, leading tobetter responsiveness). Second, with constant probing viaincrementing the rate, the network bandwidth can be moreefficiently utilized. Third, it ensures that the bandwidth sharingconverges towards fair share (i.e., the same or adjacent videobitrate) among competing clients. Lastly, an innate feature ofthe probe-and-adapt approach is asymmetry of rate shifting –PANDA is equipped with conservative rate level upshift butmore responsive downshift. Responsive downshift facilitatesfast recovery from sudden bandwidth drops, and thus caneffectively mitigate the danger of playout stalls caused bybuffer underrun.

C. Paper Organization

In the rest of the paper, after formalizing the problem (§II),we first introduce a method to characterize the conventionalrate adaptation algorithms (§III), based on which we analyzethe root cause of its problems (§IV). We then introduce ourprobe-and-adapt approach (§V) to directly address the rootcause, and present the PANDA rate adaptation algorithm asa concrete implementation of this idea. We provide compre-hensive performance evaluations (§VI). We conclude the paperwith final remarks and discussion of future work (§VIII).

II. PROBLEM MODEL

In this section, we formalize the problem by first describinga representative HAS server-client interaction process. Wethen outline a four-step model for an HAS rate adaptationalgorithm. This will allow us to compare the proposed PANDAalgorithm with its conventional counterpart. Table I lists themain notations used in this paper.

A. Process of HAS Server-Client Interaction

Consider that a video stream is chopped into segments of τseconds each. Each segment has been pre-encoded at L videobitrates, all stored at a server. Denote by R := {R1, ..., RL}the set of available video bitrates, with 0 < R` < Rm for` < m.

For each client, the streaming process is divided into se-quential segment downloading steps n = 1, 2, .... The processwe consider here generalizes the process used by conventionalHAS clients by further incorporating variable durations be-tween consecutive segment requests. Refer to Figure 3. Atthe beginning of each download step n, a rate adaptationalgorithm:• Selects the video bitrate of the next segment to be

downloaded, r[n] ∈ R;• Specifies how much time to give for the current down-

load, until the next download request (i.e., the inter-request time), T [n].

The client then initiates an HTTP GET request to the serverfor the segment of sequence number n and video bitrater[n], and the downloading starts immediately. Let T [n] bethe download duration – the time required to complete thedownload. Assuming that no pipelining of downloading isinvolved, the next download step starts after time

T [n] = max(T [n], T [n]), (1)

where T [n] is the actual inter-request time. That is, if thedownload duration T [n] is shorter than the target delay T [n],the client waits time T [n]− T [n] (i.e., the off-interval) beforestarting the next downloading step (Scenario A); otherwise,the client starts the next download step immediately after thecurrent download is completed (Scenario B).

Typically, a rate adaptation algorithm also measures its TCPthroughput x during the segment downloading, via:

x[n] :=r[n] · τT [n]

.

Time  

Rate  

T[n]T[n] T[n+1]

T[n+1]

τ ⋅ r[n]τ ⋅ r[n+1] τ ⋅ r[n+ 2]

CScenario  A   Scenario  B  

Fig. 3. The HAS segment downloading process.

The downloaded segments are stored in the client buffer.After playout starts, the buffer is consumed by the videoplayer at a natural rate of one video second per real second onaverage. Let B[n] be the buffer duration (measured in videotime) at the end of step n. Then the buffer dynamics can becharacterized by:

B[n] = max (0, B[n− 1] + τ − T [n]) . (2)

B. Four-Step Model

We present a four-step model for an HAS rate adaptationalgorithm, generic enough to encompass both the conventionalalgorithms (e.g., [15], [19], [20], [17], [16]) and the proposedPANDA algorithm. In this model, a rate adaptation algorithmproceeds in the following four steps.• Estimating. The algorithm starts by estimating the net-

work bandwidth x[n] that can legitimately be used.• Smoothing. x[n] is then noise-filtered to yield the

smoothed version y[n], with the aim of removing outliers.• Quantizing. The continuous y[n] is then mapped to the

discrete video bitrate r[n] ∈ R, possibly with the help ofside information such as client buffer size, etc.

• Scheduling. The algorithm selects the target interval untilthe next download request, T [n].

III. CONVENTIONAL APPROACH

Using the four-step model above, in this section we intro-duce a scheme to characterize a conventional rate adaptationalgorithm, which will serve as a benchmark.

To the best of our knowledge, almost all of today’s commer-cial HAS players4 implement the measuring and schedulingparts of the rate adaptation algorithm in a similar way, thoughthey may differ in their implementation of the smoothingand quantizing parts of the algorithm. Our claim is basedon a number of experimental studies of commercial HASplayers [2], [10], [13]. The scheme described in Algorithm1 characterizes their essential ideas.

First, the algorithm equates the currently available band-width share x[n] to the past TCP throughput x[n−1] observedduring the on-interval T [n− 1]. As the bandwidth is inferredreactively based on the previous downloads, we refer to thisas reactive bandwidth estimation.

The algorithm then obtains a filtered version y[n] using asmoothing function S(·) that takes as input the measurementhistory {x[m] : m ≤ n}, as described in (4). Various filteringmethods are possible, such as sliding-window moving average,

4In this paper, the terms “HAS player” and “HAS client” are usedinterchangeably.

0 1 2 3 4 5 6 7 80

1

2

Rat

e

(a) Perfectly Subscribed, Round-Robin0 1 2 3 4 5 6 7 8

0

1

2

Rat

e

(d) Oversubscribed

0 1 2 3 4 5 6 7 80

1

2

Rat

e

(b) Perfectly Subscribed, Partially Overlapped0 1 2 3 4 5 6 7 8

0

1

2

Rat

e

(e) Undersubscribed

0 1 2 3 4 5 6 7 80

1

2

Rat

e

(c) Perfectly Subscribed, Fully Overlapped0 1 2 3 4 5 6 7 8

0

1

2

Rat

e

(f) Single-Client

Fig. 4. Illustration of various bandwidth sharing scenarios. In (a), (b) and (c), the link is perfectly subscribed. In (d), the bandwidth sharing starts withround-robin mode but then link becomes oversubscribed. In (e), the bandwidth sharing starts with fully overlapped mode when the link is oversubscribed.Starting from the second round, the link becomes undersubscribed. In (f), a single client is downloading, and the downloading on-off pattern exactly matchesthat of the blue segments in (a).

Algorithm 1 ConventionalAt the beginning of each downloading step n:

1) Estimate the bandwidth share x[n] by equating it to themeasured TCP throughput:

x[n] = x[n− 1]. (3)

2) Smooth out x[n] to produce filtered version y[n] by

y[n] = S({x[m] : m ≤ n}). (4)

3) Quantize y[n] to the discrete video bitrate r[n] ∈ R by

r[n] = Q (y[n]; ...) . (5)

4) Schedule the next download request depending on thebuffer fullness:

T [n] =

{0, B[n− 1] < Bmax,

τ, otherwise.(6)

exponential weighted moving average (EWMA) or harmonicmean [13].

The next step maps the continuous y[n] to a discrete videobitrate r[n] ∈ R using a quantization function Q(·). In general,Q(·) can also incorporate side information, including the pastfetched bitrates {r[m] : m < n} and the buffer history {B[m] :m < n}.

Lastly, the algorithm determines the target inter-request timeT [n]. In (6), T [n] is a mechanical function of the bufferduration B[n − 1]. If B[n − 1] is less than a pre-definedmaximum buffer Bmax, T [n] is set to 0, and by (1), the nextsegment downloading starts right after the current downloadis finished; otherwise, the inter-request time is set to the videosegment duration τ , to stop the buffer from further growing.This creates two distinct modes of segment downloading –the buffer growing mode and the steady-state mode, as shownin Figure 2(b). We refer to this as the bimodal downloadscheduling.

IV. ANALYSIS OF THE CONVENTIONAL APPROACH

In this section, we take a deep dive into the conventionalrate adaptation algorithms and study their limitations.

A. Bandwidth Cliff Effect

As we have seen in the previous section, conventionalrate adaptation algorithms use reactive bandwidth estimation(3) that equates the estimated bandwidth share to the TCPthroughput observed during the on-intervals. In the presenceof competing HAS clients, however, the TCP throughput doesnot always faithfully represent the fair-share bandwidth. In thissection, we present an intuitive analysis of this phenomenon,by extending the one first presented in [3].5 A rigorous analysisof this phenomenon is presented in Appendix A.

First, we illustrate with simple examples. Figure 4 (a) - (e)show the various scenarios of how a link can be shared by twoHAS clients in steady-state mode. We consider three differentscenarios: perfect link subscription, link oversubscription andlink undersubscription. We assume ideal TCP behavior, i.e.,perfectly equal sharing of the available bandwidth when thetransfers overlap.

Perfect Subscription: In perfect link subscription, the totalamount of traffic requested by the two clients perfectly fills thelink. (a), (b) and (c) illustrate three different modes of band-width sharing, depending on the starting time of downloadsrelative to each other. Essentially, under perfect subscription,there are unlimited number of bandwidth sharing modes.

Oversubscription: In (d), the two clients start with round-robin mode and perfect subscription. Starting from the secondround of downloading, the bandwidth is reduced and the linkbecomes oversubscribed, i.e., each client requests segmentslarger than its current fair-share portion of the bandwidth.This will result in unfinished downloads at the end of eachdownloading round. Then, the unfinished segment will startoverlapping with segments of the next round. This repeats and

5A main difference of our analysis compared to [3] is that we rigorouslyprove the convergence properties presented in the bandwidth cliff effect.

the downloading will become more and more overlapped, untilall the clients enter the fully overlapped mode.

Undersubscription: In (e), initially the bandwidth sharingis in fully overlapped mode, and the link is oversubscribed.Starting from the second round, the bandwidth increases andthe link becomes undersubscribed. Then the clients start fillingup each other’s off-intervals, until a transmission gap emerges.The bandwidth sharing will eventually converge to a modewhich is determined by the download start times.

In any case, the measured TCP throughput faithfully rep-resents the fair-share bandwidth only when the bandwidthsharing is in the fully overlapped mode; in all other cases theTCP throughput overestimates the fair-share bandwidth. Thus,most of the time, the bandwidth estimate is accurate whenthe link is oversubscribed. Bandwidth overestimation occurswhen the link is undersubscribed or perfectly subscribed. Ingeneral, when the number of competing clients is n, thebandwidth overestimation ranges from one to n times the fair-share bandwidth.

Although the preceding simple examples assume idealizedTCP behavior which abstracts away the complexity of TCPcongestion control dynamics, it is easy to verify that similarbehavior occurs with real TCP connections. To see this,we conducted a simple test bed experiment as follows. Weimplemented a “thin client” to mimic an HAS client in thesteady-state mode. Each thin client repeatedly downloads asegment every 2 seconds. We run 100 instances of the thinclient sharing a bottleneck link of 100 Mbps, each with astarting time randomly selected from a uniform distributionbetween 0 and 2 seconds. Figure 5 plots the measured averageTCP throughput as a function of the link subscription rate.We observe that when the link subscription is below 100%,the measured throughput is about 3x the fair-share bandwidthof ~1 Mbps. When the link subscription is above 100%, themeasured throughput successfully predicts the fair-share band-width quite accurately. We refer to this sudden transition fromoverestimation to fairly accurate estimation of the bandwidthshare at 100% subscription as the bandwidth cliff effect.

We summarize our findings as follows:• Link oversubscription converges to fully overlapped

bandwidth sharing and accurate bandwidth estimation.• Link undersubscription converges to a bandwidth sharing

pattern determined by the download start times andbandwidth overestimation.

• In perfect link subscription, there exist unlimited band-width sharing modes, leading to bandwidth overestima-tion.

B. Video Bitrate Oscillation

With an understanding of the bandwidth cliff effect, weare now in a good position to explain the bitrate oscillationobserved in Figure 1.

Figure 6 illustrates this process. When the client bufferreaches the maximum level Bmax, by (6), off-intervals startto emerge. The link becomes undersubscribed, leading tobandwidth overestimation (a). This triggers the upshift of

90 95 100 105 110 1151

1.5

2

2.5

3

3.5

TC

P T

hrou

ghpu

t (M

bps)

Link Subscription (%)

Fig. 5. Bandwidth cliff effect: measured TCP throughput vs. link subscriptionrate for 100 thin clients sharing a 100-Mbps link. Each thin client repeatedlydownloads a segment every τ = 2 seconds.

!Time (Sec)

Bitrate (M

bps)

Link Subscription (%

)

TCP Throughput

Link Subscription

Requested Video Bitrate

(a)

(b)

(c)

(d)

500 550 600 650

130

120

110

100

90

80

12

10

8

6

4

2

0 450

Fig. 6. Illustration of vicious cycle of video bitrate oscillation. This plot isobtained with 36 Smooth clients sharing a 100-Mbps link. For experimentalsetup, refer to §VI-B.

requested video bitrate (b). As the available bandwidth cannotkeep up with the video bitrate, the buffer falls below Bmax. By(6), the client falls back to the buffer growing mode and theoff-intervals disappear, in which case the link again becomesoversubscribed and the measured throughput starts to convergeto the fair-share bandwidth (c). Lastly, due to the quantizationeffect, the requested video bitrate falls below the fair-sharebandwidth (d), and the client buffer starts growing again,completing one oscillation cycle.

C. Fundamental Limitation

The bandwidth overestimation phenomenon reveals a moregeneral and fundamental limitation of the class of conven-tional reactive bandwidth estimation approaches discussed sofar. As video bitrates are chosen solely based on measuredTCP throughput from past segment downloads during theon-intervals, such decisions completely ignore the networkconditions during the off-intervals. This leads to an ambiguityof client knowledge of available network bandwidth during theoff-intervals, which, in turn, hampers the adaptation process.

To illustrate this point, consider two alternative scenarios asdepicted in Figures 4 (f) and (a). In (f), the client downloadingthe blue (darker-shaded) video segments occupies the linkalone; in (a), it shares the same link with a competing clientdownloading the green (lighter-shaded) video segments. Notethat the on/off-intervals for all the blue (darker-shaded) videosegments follow exactly the same pattern in both scenar-ios. Consequently, the client observes exactly the same TCP

throughput measurement over time. If the client would obtaina complete picture of the network, it would know to upshiftits video bitrate in (f) but retain its current bitrate in (a).In practice, however, an individual client cannot distinguishbetween these two scenarios, hence, is bound to the samebehavior in both.

Note that as long as the off-intervals persist, such ambiguityin client knowledge is inherent to the bandwidth measure-ment step in a network with competing streams. It cannotbe resolved or remedied by improved filtering, quantization,or scheduling steps performed later in the client adaptationalgorithm. Moreover, the bandwidth cliff effect, as discussedin Section IV-A, suggests that the bandwidth overestimationproblem does not improve with more clients, and that it canintroduce large errors even with slight link undersubscription.

Instead, the client needs to take a more proactive approachin adapting the video bitrate — whenever it is known thatthe client knowledge is impaired, it must avoid using suchknowledge in bandwidth estimation. A way to distinguish thecase when the knowledge is impaired from when it is not, is toprobe the network subscription by small increment of its datasending rate. We describe one algorithm that follows such analternative approach in the next section.

V. PROBE-AND-ADAPT APPROACH

In this section, we introduce our proposed probe-and-adaptapproach to directly address the root cause of the conventionalalgorithms’ problems. We begin the discussion by layingout the design goals that a rate adaptation algorithm aimsto achieve. We then describe the PANDA algorithm as anembodiment of the probe-and-adapt approach, and provide itsfunctional verification using experimental traces.

A. Design Goals

Designing an HAS rate adaptation algorithm involves trade-offs among a number of competing goals. It is not legitimateto optimize one goal (e.g., stability) without considering itstradeoff factors. From an end-user’s perspective, an HAS rateadaptation algorithm should be designed to meet these criteria:• Avoiding buffer underrun. Once the playout starts, buffer

underrun (i.e., complete depletion of buffer) leads to aplayout stall. Empirical study [8] has shown that bufferunderrun may have the most severe impact on a user’sviewing experience. To avoid it, some minimal bufferlevel must be maintained at all times6, and the adap-tation algorithm must be highly responsive to networkbandwidth drops.

• High quality smoothness. In the simplest setting withoutconsidering visual perceptual models, high video qualitysmoothness translates into avoiding both frequent and

6Note that, however, the buffer level must also have an upper bound, for afew different reasons. In live streaming, the end-to-end latency from the real-time event to the event being displayed on user’s screen must be reasonablyshort. In video-on-demand, the maximum buffered video must be limited toavoid wasted network usage in case of an early termination of playback andto limit memory usage.

Algorithm 2 PANDAAt the beginning of each downloading step n:

1) Estimate the bandwidth share x[n] by

x[n]− x[n− 1]

T [n− 1]= κ ·(w−max(0, x[n−1]− x[n−1])),

(7)2) Smooth out x[n] to produce filtered version y[n] by

y[n] = S({x[m] : m ≤ n}). (8)

3) Quantize y[n] to the discrete video bitrate r[n] ∈ R by

r[n] = Q (y[n]; ...) . (9)

4) Schedule the next download request via

T [n] =r[n] · τy[n]

+ β · (B[n− 1]−Bmin) (10)

significant video bitrate shifts among available videobitrate levels [13], [18].

• High average quality. High average video quality dictatesthat a client should fetch high-bitrate segments as much aspossible. Given a fixed network bandwidth, this translatesinto high network utilization.

• Fairness. In the simplest setting, fairness translatesinto equal network bandwidth sharing among competingclients.

Note that this list above is non-exhaustive. Other criteria,such as low playout startup latency, are also important factorsimpacting user’s viewing experience.

B. PANDA Algorithm

In this section, we discuss the PANDA algorithm. Comparedto the reactive bandwidth estimation used by a conventionalrate adaptation algorithm, PANDA uses a more proactiveprobing mechanism. By probing, PANDA determines a targetaverage data rate x. This average data rate is subsequentlyused to determine the video bitrate r to be fetched, and theinterval T until the next segment download request.

The PANDA algorithm is described in Algorithm 2, anda block diagram interpretation of the algorithm is shown inFigure 7. Compared to the conventional algorithm in Algo-rithm 1, we only make modifications in the estimating andscheduling steps – we replace (3) with (7) for estimating thebandwidth share, and (6) with (10) for scheduling the nextdownload request. We now focus on elaborating each of thesetwo modifications.

In the estimating step, (7) is designed to directly addressthe root cause that leads to the video bitrate oscillation phe-nomenon. Based on the insights obtained from §IV-A, whenthe link becomes undersubscribed, the direct TCP throughputestimate x becomes inaccurate in predicting the fair-sharebandwidth, and thus should be avoided. Instead, the clientcontinuously increments the target average data rate x by κ ·wper unit time as a probe of the available capacity. Here κ is theprobing convergence rate and w is the additive increase rate.

xNetwork Dynamics Estimation

D

Smoothing Quantizing Scheduling Network Dynamics

D

xy r

T

B

Fig. 7. Block diagram for PANDA (Algorithm 2). Module D represents delay of one adaptation step.

The algorithm keeps on monitoring the TCP throughput x, andcompares it against the target average data rate x. If x > x,x would not be informative, since in this case the link maystill be undersubscribed and x may overestimate the fair-sharebandwidth. Thus, its impact is suppressed by the max(0, ·)function. But if x < x, then TCP throughput cannot keep upwith the target average data rate indicates that congestion hasoccurred. This is when the target data rate x should back off.The reduction imposed on x is made proportional to x − x.Intuitively, the lower the measured TCP throughput x, themore reduction that needs to be imposed on x. This designmakes our rate adaptation algorithm very agile to bandwidthchanges.

PANDA’s probing mechanism shares similarities withTCP’s congestion control [11], and has an additive-increase-multiplicative-decrease (AIMD) interpretation: κ · w is theadditive increase term, and −κ·max(0, x[n−1]−x[n−1]) canbe interpreted as the multiplicative decrease term. The maindifference is that in TCP, congestion is indicated by packetlosses (TCP Reno) or increased round-trip time (delay-basedTCP), whereas in (7), congestion is indicated by the reductionof measured TCP throughput. This AIMD property ensuresthat PANDA is able to efficiently utilize the network band-width, and in the presence of multiple clients, the bandwidthfor each client eventually converges to fair-share status7.

In the scheduling step, (10) aims to determine the targetinter-request time T [n]. By right, T [n] should be selected suchthat the smoothed target average data rate y[n] is equal tor[n]·τT [n]

. But additionally, the selection of T [n] should also drivethe buffer B[n] towards a minimum reference level Bmin > 0,so the second term is added to the right hand side of (10),where β > 0 controls the convergence rate.

One distinctive feature of the PANDA algorithm is itshybrid closed-loop/open-loop design. Refer to Figure 7. Inthis system, (7) forms a closed loop by itself that determinesthe target average data rate x. (10) forms a closed loop byitself that determines the target inter-request time T . Overall,the estimating, smoothing, quantizing and scheduling stepstogether form an open loop. The main motivation behindthis design is to reduce the bitrate shifts associated withquantization. Since quantization is excluded from the closedloop of x, it allows x to settle in a steady state. Since r[n] isa deterministic function of x[n], it can also settle in a steadystate.

In Appendix B, we present an equilibrium and stability anal-ysis of PANDA. We summarize the main results as follows.Our equilibrium analysis shows that at steady state, the system

7Assuming the underlying TCP is fair (e.g., equal RTTs).

variables settle at

xo = xo + w (11)= yo

ro = Q(xo; ...)

Bo =

(1− ro

yo

)· τβ

+Bmin, (12)

where the subscript o denotes value of variables at equilibrium.Our stability analysis shows that for the system to convergetowards the steady state, it is necessary to have:

κ <2

τ(13)

w ≤ ∆, (14)

where ∆ is a parameter associated with the quantizer Q(·),referred to as the quantization margin, i.e., the selected discreterate r must satisfy

r[n] ≤ y[n]−∆. (15)

C. Functional Verification

We verify the behavior of PANDA using experimentaltraces. For detailed experiment setup (including the selectionof function S(·) and Q(·)), refer to §VI-B.

First, we evaluate how a single PANDA client adjusts itsvideo bitrate as the the available bandwidth varies over time.In Figure 8, we plot the TCP throughput x, the target averagedata rate x, the fetched video bitrate r and the client bufferB for a duration of 500 seconds, where the bandwidth dropsfrom 5 to 2 Mbps at 200 seconds, and rises back to 5 Mbps at300 seconds. Initially, the target average data rate x ramps upgradually over time; the fetched video bitrate r also ramps upcorrespondingly. After the initial ramp-up stage, x settles in asteady state. It can be observed that at steady state, the differ-ence between x and x is about 0.3 Mbps, equal to w, whichis consistent with (11). Similarly, the buffer B also settles ina steady state, and after plugging in all the parameters, onecan verify that the steady state of buffer (12) also holds. At200 seconds, when the bandwidth suddenly drops, the fetchedvideo bitrate quickly drops to the desirable level. With thisquick response, the buffer hardly drops. This property makesPANDA favorable for live streaming applications. When thebandwidth rises back to 5 Mbps at 300 seconds, the fetchedvideo bitrate gradually ramps up to the original level.

Note that, in practical implementation, we can further adda startup logic to improve PANDA’s ramp-up speed at thestream startup stage, akin to the slow-start mode of TCP. Theidea is simple: since it is necessary to add off-intervals onlywhen the buffer duration B[n] exceeds the minimum reference

0 100 200 300 400 5000

2

4

6

8B

itrat

e (M

bps)

TCP ThroughputTarget Avg. Data RateFetched Video Bitrate

0 100 200 300 400 5000

10

20

30

40

50

Time (Sec)

Buf

fer

(Sec

)

Fig. 8. A PANDA client adapts its video bitrate under a bandwidth-varyinglink. The bandwidth is initially at 5 Mbps, drops to 2 Mbps at 200 secondsand rises back to 5 Mbps at 300 seconds.

0 20 40 600

1

2

3

4

Time (Sec)

Bitr

ate

(Mbp

s)

Startup OffStartup On

0 20 40 600

10

20

30

40

Time (Sec)

Buf

fer

(Sec

)

Startup OffStartup On

Fig. 9. Comparison of the startup behavior of a PANDA player with andwithout the startup logic. The bandwidth is 5 Mbps.

level Bmin, we can use the conventional algorithm at startupor after playout stall, until B[n] ≥ Bmin; after that, we switchto the main Algorithm 2. Without the presence of the off-intervals, the conventional algorithm works fast enough andreasonably well. Figure 9 shows the startup behavior of aPANDA player with 5 Mbps link bandwidth, with and withoutthe startup logic. As can be seen, the startup logic allows thevideo bitrate to ramp up efficiently, albeit at the expense ofsomewhat dampened buffer growth.

The more intriguing question is whether PANDA couldeffectively stop the bitrate oscillation observed in the Smoothplayers. We conduct an experiment with the same setup as theexperiment shown in Figure 1, except that the PANDA playerand the Smooth player use slightly different video bitrate levels(due to different packaging methods). The resulting fetchedbitrates in aggregate and for each client are shown in Figure10. From the plot of the aggregate fetched bitrate, except forthe initial fluctuation, the aggregate bitrate closely tracks theavailable bandwidth of 100 Mbps. Zooming in to the individualstreams’ fetched bitrates, the fetched bitrates are confinedwithin two adjacent bitrate levels and the number of shifts ismuch smaller than the Smooth client’s case. This affirms thatPANDA is able to achieve better stability than the Smooth’srate adaptation algorithm. In §VI, we perform a comprehensiveperformance evaluation on each adaptation algorithm.

To help the reader develop a better intuition on why PANDAperforms better than a conventional algorithm, in Figure 11we plot the trace of the measured TCP throughput and thetarget average data rate for the same experiment as in Figure10. Note that the fair-share bandwidth for each client isabout 2.8 Mbps. From the plot, the TCP throughput not onlygrossly overestimates the fair-share bandwidth, it also has alarge variation. If used directly, this degree of noisiness givesthe subsequent operations a very hard job to extract useful

Fetched Bitrate Aggregated over 36 Streams

200 300 400 500 600 700 800 900 1000 1100 120060

80

100

120

Time (Sec)

Fet

ched

(M

bps)

Fetched Bitrate of Individual Streams (Zoom In)

400 420 440 460 480 500 520 540 560 580 6000

2

4

6

Time (Sec)

Fet

ched

(M

bps)

Fig. 10. 36 PANDA clients compete at a 100-Mbps link in steady state.

Measured TCP Throughput x

200 300 400 500 600 700 800 900 1000 1100 12000

5

10

Time (Sec)

Thr

ough

put(

Mbp

s)Target Average Data Rate x

200 300 400 500 600 700 800 900 1000 1100 12000

5

10

Time (Sec)

Tar

get (

Mbp

s)

Fig. 11. The traces of the TCP throughput and the target average data rateof 36 PANDA clients compete at a 100-Mbps link in steady state. The tracesof the first five clients are plotted.

information. For example, one may apply strong filteringto smooth out the bandwidth measurement, but this wouldseriously affect the responsiveness of the client. When thenetwork bandwidth suddenly drops, the client would not beable to respond quickly enough to reduce its video bitrate,leading to catastrophic buffer underrun. Moreover, the bias isboth large and difficult to predict, making any correction tothe mean problematic. In comparison, although also biased, thetarget average data rate estimated by the probing mechanismis much less noisy than the TCP throughput. One can easilycorrect the bias (via (15) and quantization) and select the rightvideo bitrate without sacrificing responsiveness.

In Figure 12, we verify the stability criteria (13) and (14)of PANDA. With τ = 2, the system is stable if κ < 1. Thisis demonstrated by Figure 12 (a), where we show the tracesof the target average rate x for two κ values 0.9 and 1.1. InFigure 12 (b), we show that when ∆ = 0, the buffer cannotconverge towards the reference level of 30 seconds.

VI. PERFORMANCE EVALUATION

In this section, we conduct a set of test bed experimentsto evaluate the performance of PANDA against other rateadaptation algorithms.

0 50 100 150 2000

1

2

3

4

5

Time (Sec)

Tar

get (

Mbp

s)

κ=0.9κ=1.1

(a) κ

0 100 200 3000

10

20

30

Time (Sec)

Buf

fer(

Sec

)

∆=w∆=0

(b) ∆

Fig. 12. Experimental verification of PANDA’s stability criteria. In (a), onePANDA client streams over a link of 5 Mbps. In (b), 10 PANDA clientscompete over a 10 Mbps link.

A. Evaluation Metrics

In §V-A, we discussed four criteria that are most importantfor a user’s watching experience – i) ability to avoid bufferunderruns, ii) quality smoothness, iii) average quality, and iv)fairness. In this paper, we use buffer undershoot as the metricfor Criterion i), described as follows.• Buffer undershoot: We measure how much the buffer

goes down after a bandwidth drop as a indicator of analgorithm’s ability to avoid buffer underruns. The less thebuffer undershoot, the less likely the buffer will underrun.Let Bo be a reference buffer level (30 seconds for allplayers in this paper), and Bi,t the buffer level for playeri at time t. The buffer undershoot for player i at time tis defined as max(0,Bo−Bi,t)

Bo. The buffer undershoot for

player i within a time interval T (right after a bandwidthdrop), is defined as the 90th-percentile value of thedistribution of buffer undershoot samples collected duringT .

We inherit the metrics defined in [13] – instability, inefficiencyand unfairness, as the metrics for Criteria ii), iii) and iv), re-spectively. We only make a slight modification to the definitionof inefficiency. Let ri,t be the video bitrate fetched by playeri at time t.• Instability: The instability for player i at time t is∑k−1

d=0 |ri,t−d−ri,t−d−1|·w(d)∑k−1d=0 ri,t−d·w(d)

, where w(d) = k − d is aweight function that puts more weight on more recentsamples. k is selected as 20 seconds.

• Inefficiency: Let C be the available bandwidth. [13]

defines inefficiency as |∑

i ri,t−C|C for player i at time t.

But sometimes the sum of fetched bitrate∑i ri,t can be

greater than C. To avoid unnecessary penalty in this case,

we revise the inefficiency metric tomax(0,C−

∑i ri,t)

C forplayer i at time t.

• Unfairness: Let JainFairt be the Jain fairness indexcalculated on the rates ri,t at time t over all players. Theunfairness at t is defined as

√1− JainFairt.

B. Experimental Setup

HAS Player Configuration: The benchmark players that weuse to compare against PANDA are:• Microsoft Smooth player [5], a commercially available

proprietary player. The Smooth players are of version

1.0.837.34 using Silverlight runtime version 4.0.50826.To our best knowledge, the Smooth player as well as theApple HLS and the Adobe HDS players all use the sameTCP throughput measurement mechanism, so we pickedthe Smooth player as a representative.

• FESTIVE player, which we implemented based on thedetails specified in [13]. The FESTIVE algorithm is thefirst known client-side rate adaptation algorithm designedto specifically address the multi-client scenario.

• A player implementing the conventional algorithm (Al-gorithm 1), which differs from PANDA only in theestimating and scheduling steps.

For fairness, we ensure that PANDA and the conventionalplayer use the same smoothing and quantizing functions. Forsmoothing, we implemented a EWMA smoother of the form:y[n]−y[n−1]T [n−1] = −α · (y[n− 1]− x[n]), where α > 0 is the

convergence rate of y[n] towards x[n]. For quantization, weimplemented a dead-zone quantizer r[n] = Q(y[n], r[n− 1]),defined as follows: Let the upshift threshold be defined asrup := maxr∈R r subject to r ≤ y[n] − ∆up, and thedownshift threshold as rdown := maxr∈R r subject tor ≤ y[n]−∆down, where ∆up and ∆down are the upshift anddownshift safety margin respectively, with ∆up ≥ ∆down ≥ 0.The dead-zone quantizer updates r[n] as

r[n] =

rup, r[n− 1] < rup,

r[n− 1], rup ≤ r[n− 1] ≤ rdown,rdown, otherwise.

(16)

The “dead zone” [rup, rdown] created by setting ∆up > ∆down

mitigates frequent bitrate hopping between two adjacent levels,thus stabilizing the video quality (i.e. hysteresis control). Forthe conventional player, set ∆up = ε·y and ∆down = 0, where0 ≤ ε < 1 is the multiplicative safety margin. For PANDA,due to (14) and (15), set ∆up = w + ε · y and ∆down = w 8.

Table II lists the default parameters used by each player, aswell as their varying values. For fairness, all players attemptto maintain a steady-state buffer of 30 seconds. For PANDA,Bmin is selected to be 26 seconds such that the resultingsteady-state buffer is 30 seconds (by (12)).

Server Configuration: The HTTP server runs Apache onRed Hat 6.2 (kernel version 2.6.32-220). The Smooth playerinteracts with an Microsoft IIS server by default, but we alsoperform experiments of Smooth player interacting with anApache server on Ubuntu 10.04 (kernel version 2.6.32.21).

Network Configuration: As service provider deploymentover a managed network is our primary case of interest,our experiments are configured to highly match the imporantscenario where a number of HAS flows compete for bandwidthwithin a DOCSIS bonding group. The test bed is configuredas in Figure 13. The queueing policy used at the aggregationrouter-home router bottleneck link is the following. For a linkbandwidth of 10 Mbps or below, we use random early de-tection (RED) with (min_thr,max_thr, p) = (30, 90, 0.25);

8Note that this will not give PANDA any unfair advantage.

Algorithm Parameter Default ValuesPANDA κ 0.14 0.04,0.07,0.14,0.28,0.42,0.56

w 0.3α 0.2 0.05,0.1,0.2,0.3,0.4,0.5β 0.2ε 0.15 0.5,0.4,0.3,0.2,0.1,0Bmin 26

Conventional α 0.2 0.01,0.04,0.07,0.1,0.15,0.2ε 0.15Bmax 30

FESTIVE Window 20 20,15,10,6,3,1targetbuf 30

TABLE IIPARAMETERS USED IN EXPERIMENTS

Local

HTTP

Server

Aggregation

Router

Local

100 or 10 Mbps

20 ms

…

.

HA

S

Clie

nt

HA

S

Cli

en

t

L

o

c

a

l

L

o

c

a

l

Home

Router

Fig. 13. The network topology configured in the test bed. Local indicatesthat the bitrate is effectively unbounded and the link delay is 0 ms.

if the link bandwidth is 100 Mbps, we use RED with(min_thr,max_thr, p) = (300, 900, 1). The video content ischopped into segments of τ = 2 seconds, pre-encoded withL = 10 bitrates: 459, 693, 937, 1270, 1745, 2536, 3758, 5379,7861 and 11321 Kbps. For the Smooth player, the data ratesafter packaging are slightly different.

C. Performance Tradeoffs

It would not be legitimate to discuss a single metric withoutminding its impact on other metrics. In this section, weexamine the performance tradeoffs among the four metricsof interest. We designed an experimental process under whichwe can measure all four metrics in a single run. For each run,five players (of the same type) compete at a bottleneck link.The link bandwidth stays at 10 Mbps from 0 seconds to 400seconds, drops to 2.5 Mbps at 400 seconds and stays thereuntil 500 seconds. We record the instability, inefficiency andunfairness averaged over 0 to 400 seconds over all players, andthe buffer undershoot over 400 to 500 seconds averaged overall players. Figure 14 shows the tradeoff between stability andeach of the other criteria – buffer undershoot, inefficiency andunfairness – for each of the types of player. Each data pointis obtained via averaging over 10 runs, and each data pointrepresents a different value for one of the parameters of thecorresponding algorithm, as indicated in the Values column ofTable II.

For the PANDA player, the three parameters that affectinstability the most are: the probing convergence rate κ, thesmoothing convergence rate α and the safety margin ε. Figure14 (a) shows that as we vary these parameters, the tradeoffcurves mostly stay flat (except for at extreme values of theseparameters), implying that the PANDA player maintains goodresponsiveness as the stability is improved. A few factors

contribute to this advantage of PANDA: First, as the bandwidthestimation by probing is quite accurate, one does not needto apply strong smoothing. Second, since after a bandwidthdrop, the video bitrate reduction is made proportional to theTCP throughput reduction, PANDA is very agile to bandwidthdrops. On the other hand, for both the FESTIVE and theconventional players, the buffer undershoot significantly in-creases as the scheme becomes more stable. Overall, PANDAhas the best tradeoff between stability and responsiveness tobandwidth drop, outperforming the second best conventionalplayer by more than 75% reduction in instability at the samebuffer undershoot level. It is worth noting that the conventionalplayer uses exactly the same smoothing and quantizationsteps as PANDA, which implies that the gain achieved byPANDA is purely due to the improvement in the estimating andscheduling steps. FESTIVE has the largest buffer undershoot.We believe this is because the design of FESTIVE has mainlyconcentrated on stability, efficiency and fairness, but ignoredresponsiveness to bandwidth drops. As we do not have accessto the Smooth player’s buffer, we do not have its bufferundershoot measure in Figure 14 (a).

Figure 14 (b) shows that PANDA has the lowest inefficiencyover all as we vary its instability. The probing mechanismensures that the bandwidth is most efficiently utilized. As theinstability increases, the inefficiency also increases moderately.This makes sense intuitively, as when the bitrate fluctuates,the average fetched bitrate also decreases. The efficiencyof the conventional algorithm underperforms PANDA, butoutperforms FESTIVE. Lastly, the Smooth player has thehighest inefficiency.

Lastly, Figure 14 (c) shows that in terms of fairness,FESTIVE achieves the best performance. This may be due tothe randomized scheduling strategy of FESTIVE. PANDA andthe conventional players have similar fairness; both of themoutperform the Smooth player.

D. Increasing Number of Players

In this section, we focus on the question of how the numberof players affects instability, inefficiency and unfairness atsteady state. Two scenarios are of interest: i) we increasethe number of players while fixing the link bandwidth at 10Mbps, and ii) we increase the number of players while varyingthe bandwidth such that the bandwidth/player ratio is fixedat 1 Mbps/player. Figure 15 and Figure 16 report results forthese two cases, respectively. Each data point is obtained byaveraging over 10 runs.

Refer to Figure 15 (a). In the single-player case, all fourschemes are able to maintain their fetched video bitrate at aconstant level, resulting in zero instability. As the number ofplayers increases, the instability of the conventional player andthe Smooth player both increase quickly in a highly consistentway. We speculate that they have very similar underlyingstructure. The FESTIVE player is able to maintain its stabilityat a lower level, due to the strong smoothing effect (smoothingwindow at 20 samples by default), but the instability stillgrows with the number of players, likely due to the bandwidth

0 0.02 0.04 0.06 0.080

0.2

0.4

0.6

0.8

1

Instability

Und

ersh

oot

PANDA (Vary α)PANDA (Vary k)PANDA (Vary ε)FESTIVE (Vary Win)Conventional (Vary α)

(a)

0 0.02 0.04 0.06 0.080

0.05

0.1

0.15

0.2

Instability

Inef

ficie

ncy

PANDA (Vary α)PANDA (Vary k)PANDA (Vary ε)FESTIVE (Vary Win)Conventional (Vary α)Smooth

(b)

0 0.01 0.02 0.03 0.04 0.05 0.06 0.070

0.05

0.1

0.15

0.2

0.25

Instability

Unf

airn

ess

PANDA (Vary α)PANDA (Vary k)PANDA (Vary ε)FESTIVE (Vary Win)Conventional (Vary α)Smooth

(c)Fig. 14. The impact of varying instability on buffer undershoot, inefficiency and unfairness for PANDA and other benchmark players.

overestimation effect. The PANDA player exhibits a ratherdifferent behavior: at two players it has the highest instability,then the instability starts to drop as the number of playersincreases. Investigating into the experimental traces revealsthat this is related to the specific bitrate levels selected. Moreimportantly, via probing, the PANDA player is immune to thesymptoms of the bandwidth overestimation, thus it is ableto maintain its stability as the number of clients increases.The case of varying bandwidth in Figure 16 (a) exhibitsbehavior fairly consistent with Figure 15 (a), with PANDAand FESTIVE exhibiting much less instability compared tothe Smooth and the conventional players.

Figure 15 (b) and Figure 16 (b) for the inefficiency metricboth show that PANDA consistently has the best performanceas the number of players grow. The conventional player andFESTIVE have similar performance, both outperforming theSmooth player by a great margin. We speculate that theSmooth player has some large bitrate safety margin by design,with the purpose of giving cross traffic more breathing room.

Lastly, let us look at fairness. Refer to Figure 15 (a). Wehave found that when the overall bandwidth is fixed, theunfairness measure has high dependence on the specific bitratelevels chosen, especially when the number of players is small.For example, at two players, when the fair-share bandwidthis 5 Mbps, the two PANDA players end up in steady statewith 5.3 Mbps and 3.7 Mbps, resulting in a high unfairnessscore. At three players, when the fair-share bandwidth is 3.3Mbps, the three PANDA players each end up with 3.7, 3.7and 2.5 Mbps for a long period of time, resulting in a lowerunfairness score. FESTIVE exhibits lowest unfairness overall,which is consistent with the results obtained in Figure 14 (c).In the varying-bandwidth case in Figure 16 (c), The unfairnessranking is fairly consistent as the number of players grow:FESTIVE, PANDA, the conventional, and Smooth.

E. Competing Mixed Players

One important question to ask is how PANDA will behavein the presence of different type of players? If it behaves tooconservatively and cannot grab enough bandwidth, then thedeployment of PANDA will not be successful. To answer thisquestion, we take the four types of players of interest and havethem compete on a 10-Mbps link. For the Smooth player, wetest it with both a Microsoft IIS server running on Windows7, and an Apache HTTP server running on Ubuntu 10.04. A

single trace of the fetched bitrates for 500 seconds is shownin Figure 17. The plot shows that the Smooth player’s abilityto grab the bandwidth highly depends on the server it streamsfrom. Using the IIS server, which runs on Windows 7 with anaggressive TCP, it is able to fetch video bitrates over 3 Mbps.With the Apache HTTP server, which uses Ubuntu 10.04’sconservative TCP, the fetched bitrates are about 1 Mbps. Theconventional, PANDA and FESTIVE players all run on thesame TCP (Red Hat 6), so their differences are due to theiradaptation algorithms. Due to bandwidth overestimation, theconventional player aggressively fetches high bitrates, but thefetched bitrates fluctuate. Both PANDA and FESTIVE are ableto maintain a stable fetched bitrate at about the fair-share levelof 2 Mbps.

F. Summary of Performance Results

• The PANDA player has the best stability-responsivenesstradeoff, outperforming the second best conventionalplayer by 75% reduction in instability. PANDA also hasthe best bandwidth utilization.

• The FESTIVE player has been tuned to yield high sta-bility, high efficiency and good fairness. However, it un-derperforms other players in responsiveness to bandwidthdrops.

• The conventional player yields good efficiency, but lacksin stability, responsiveness to bandwidth drops and fair-ness.

• The Smooth player underperforms in efficiency, stabilityand fairness. When competing against other players,its ability to grab bandwidth is a consequence of theaggressiveness of the underlying TCP stack.

VII. RELATED WORK

AIMD Principle: The design of the probing mechanism inPANDA shares similarity with Jacobson’s AIMD principle forTCP congestion control [11]. Kelly’s framework on networkrate control [14] provides a theoretical justification for theAIMD principle, and proves its stability in the general networksetup.

HAS Measurement Studies: Various research efforts havefocused on understanding the behavior of several commer-cially deployed HAS systems. One such example is [2],where the authors characterize and evaluate HTTP streamingplayers such as Microsoft Smooth Streaming, Netflix, and

0 5 10 150

0.01

0.02

0.03

0.04

0.05

Num. Clients

Inst

abili

ty

PANDAFESTIVEConventionalSmooth

(a)

0 5 10 150

0.05

0.1

0.15

0.2

0.25

0.3

0.35

Num. Clients

Inef

ficie

ncy

PANDAFESTIVEConventionalSmooth

(b)

0 5 10 150

0.05

0.1

0.15

0.2

0.25

Num. Clients

Unf

airn

ess

PANDAFESTIVEConventionalSmooth

(c)Fig. 15. Instability, inefficiency and unfairness as the number of clients increases. The link bandwidth is fixed at 10 Mbps.

0 2 4 6 8 100

0.01

0.02

0.03

0.04

0.05

Num. Clients

Inst

abili

ty

PANDAFESTIVEConventionalSmooth

(a)

0 2 4 6 8 100

0.05

0.1

0.15

0.2

0.25

0.3

0.35

Num. Clients

Inef

ficie

ncy

PANDAFESTIVEConventionalSmooth

(b)

0 2 4 6 8 100

0.05

0.1

0.15

0.2

Num. Clients

Unf

airn

ess

PANDAFESTIVEConventionalSmooth

(c)Fig. 16. Instability, inefficiency and unfairness as the number of clients increases. The link bandwidth increases with the number of players, with thebandwidth-player ratio fixed at 1 Mbps/player.

Adobe OSMF via experiments in controlled settings. The firstmeasurement study to consider HAS streaming in the multi-client scenarios is [3]. The authors identify the root cause ofthe player’s rate oscillation problem as the existence of on-offpatterns in HAS traffic. In [10], the authors measure behaviorof commercial video streaming services, i.e., Hulu, Netflix,and Vudu, when competing with other long-lived TCP flows.The results revealed that inaccurate estimations can trigger afeedback loop leading to undesirably low-quality video.

Existing HAS Designs: To improve the performance ofadaptive HTTP streaming, several rate adaptation algorithms[15], [19], [20], [17], [16] have been proposed, which, ingeneral, fit into the four-step model discussed in Section II-B.In [12], a sophisticated Markov Decision Process (MDP) isemployed to compute a set of optimal client strategies in orderto maximize viewing quality. The MDP requires the knowl-edge of network conditions and video content statistics, whichmay not be readily available. Control-theoretical approaches,including use of a PID controller, are also considered byseveral works [6], [19], [20]. A PID controller with appropriateparameter choice can improve streaming performance. Server-side mechanisms are also advocated by some works [9], [4].Two designs have been considered to address the multi-clientissues: in [4], a rate-shaping approach aiming to eliminate theoff-intervals, and in [13], a client rate adaptation algorithmdesign implementing a combination of randomization, statefulrate selection and harmonic mean based averaging.

VIII. CONCLUSIONS

This paper identifies an emerging issue for HTTP adaptivestreaming, which is expected to become the predominant form

0 100 200 300 400 500 600 7000

1

2

3

4

Time (Sec)

Fet

ched

(M

bps)

Smooth (IIS)ConventionalPANDAFESTIVESmooth (Apache)

Fig. 17. PANDA, Smooth (w/ IIS), Smooth (w/ Apache), FESTIVE and theconventional players compete at a bottleneck link of 10 Mbps.

of the Internet traffic, and lays out a solution direction that caneffectively address this issue. Our main contributions in thispaper can be summarized as follows:

• We have identified the bandwidth cliff effect as the rootcause of the bitrate oscillation phenomenon and revealedthe fundamental limitation of the conventional reactivemeasurement based rate adaptation algorithms.

• We have envisioned a general probe-and-adapt principleto directly address the root cause of the problems, anddesigned and implemented PANDA, a client-based rateadaptation algorithm, as an embodiment of this principle.

• We have proposed a generic four-step model for an HASrate adaptation algorithm, based on which we have fairlycompared the proposed approach with the conventionalapproach.

The probe-and-adapt approach and our PANDA realizationthereof achieve significant improvements in stability of HASsystems at no cost in responsiveness. Given this framework,we plan to explore further improvements in our future work.

REFERENCES

[1] History of Move Networks. Available online:http://www.movenetworks.com/history.html.

[2] S. Akhshabi, S. Narayanaswamy, Ali C. Begen, and C. Dovrolis. Anexperimental evaluation of rate-adaptive video players over HTTP.Signal Processing: Image Communication, 27:271–287, 2012.

[3] Saamer Akhshabi, Lakshmi Anantakrishnan, Constantine Dovrolis, andAli C. Begen. What happens when HTTP adaptive streaming playerscompete for bandwidth. In Proc. ACM Workshop on Network andOperating System Support for Digital Audio and Video (NOSSDAV’12),Toronto, Ontario, Canada, 2012.

[4] Saamer Akhshabi, Lakshmi Anantakrishnan, Constantine Dovrolis, andAli C. Begen. Server-based traffic shaping for stabilizing oscillatingadaptive streaming players. In to appear in NOSSDAV13, 2013.

[5] Alex Zambelli. IIS Smooth Streaming Technical Overview.http://tinyurl.com/smoothstreaming.

[6] Luca De Cicco, Saverio Mascolo, and Vittorio Palmisano. Feedbackcontrol for adaptive live video streaming. In Proc. ACM MultimediaSystems Conference (MMSys’11), pages 145–156, San Jose, CA, USA,February 2011.

[7] Cisco White Paper. Cisco visual networking index - forecast andmethodology, 2011-2016. http://tinyurl.com/ciscovni2011to2016.

[8] F. Dobrian, V. Sekar, A. Awan, I. Stoica, D. Joseph, A. Ganjam, J. Zhan,and H. Zhang. Understanding the impact of video quality on userengagement. In Proceedings of the ACM SIGCOMM 2011 conference,SIGCOMM ’11, pages 362–373, New York, NY, USA, 2011. ACM.

[9] Remi Houdaille and Stephane Gouache. Shaping http adaptive streamsfor a better user experience. In Proceedings of the 3rd MultimediaSystems Conference, pages 1–9, 2012.

[10] Te-Yuan Huang, Nikhil Handigol, Brandon Heller, Nick McKeown, andRamesh Johari. Confused, timid, and unstable: Picking a video streamingrate is hard. In Proceedings of the 2012 ACM conference on Internetmeasurement conference, 2012.

[11] V. Jacobson. Congestion avoidance and control. In Symposium proceed-ings on Communications architectures and protocols, SIGCOMM ’88,pages 314–329, New York, NY, USA, 1988. ACM.

[12] Dmitri Jarnikov and Tanir Ozcelebi. Client Intelligence for AdaptiveStreaming Solutions. EURASIP Journal on Signal Processing: ImageCommunication, Special Issue on Advances in IPTV Technologies,26(7):378–389, August 2011.

[13] Junchen Jiang, Vyas Sekar, and Hui Zhang. Improving fairness,efficiency, and stability in http-based adaptive video streaming withfestive. In Proceedings of the 8th international conference on Emergingnetworking experiments and technologies (CoNEXT), 2012.

[14] F. P. Kelly, A. K. Maulloo, and D. K. H. Tan. Rate control forcommunication networks: Shadow prices, proportional fairness andstability. The Journal of the Operational Research Society, 49(3):237–252, 1998.

[15] Chenghao Liu, Imed Bouazizi, and Moncef Gabbouj. Rate Adaptationfor Adaptiv HTTP streaming. In Proc. ACM Multimedia SystemsConference (MMSys’11), pages 169–174, San Jose, CA, USA, February2011.

[16] Chenghao Liu, Imed Bouazizi, Miska M. Hannuksela, and MoncefGabbouj. Rate adaptation for dynamic adaptive streaming over HTTP incontent distribution network. Signal Processing: Image Communication,27(4):288–311, April 2012.

[17] Konstantin Miller, Emanuele Quacchio, Gianluca Gennari, and AdamWolisz. Adaptation algorithm for adaptive streaming over http. InProceedings of 2012 IEEE 19th International Packet Video Workshop,pages 173–178, 2012.

[18] R.K.P. Mok, E.W.W. Chan, X. Luo, and R.K.C. Chang. Inferring theQoE of HTTP video streaming from user-viewing activities. In Proc.SIGCOMM W-MUST, 2011.

[19] Guibin Tian and Yong Liu. Towards agile and smooth video adap-tation in dynamic http streaming. In Proceedings of the 8th interna-tional conference on Emerging networking experiments and technologies(CoNEXT), pages 109–120, 2012.

[20] Chao Zhou, Xinggong Zhang, Longshe Huo, and Zongming Guo. Acontrol-theoretic approach to rate adaptation for dynamic http streaming.In Proceedings of Visual Communications and Image Processing (VCIP),pages 1–6, 2012.

APPENDIX ABANDWIDTH CLIFF EFFECT: THEORETICAL ANALYSIS

A. Problem Formulation

Consider that K clients share a bottleneck link of capacityC. The streaming process of each client consists of discretedownloading steps n = 1, 2, ..., where during each step onevideo segment is downloaded.

Fixed requested video bitrate. As we are interested in howthe measured TCP throughput causes HAS clients to shift theirvideo bitrates requested, we analyze the stage of the dynamicswhere the rate shift has not occurred yet. Thus, in our model,we assume that each HAS client does not change its requestedvideo bitrate over the time interval of analysis. For k = 1, ...K,each k-th client requests a video segment of fixed size rk · τat each downloading step, where rk ∈ R is the video bitrateselected.

Segment requesting time and downloading duration. Denoteby Rk(t) the instantaneous data downloading rate of the k-thclient at time t (note that Rk and rk are different). Denote bytk[n] the time that the k-th client requests its n-th segment(which, for simplicity, is also assumed to be the time thatthe downloading starts). For each client, assume that therequesting time of the first segment tk[1] is given. For n ≥ 1,the requesting time of the next segment is determined by:

tk[n+ 1] = tk[n] + max(τ, Tk[n]), (17)

where Tk[n] is the actual duration of the k-th client download-ing its n-th segment. This is a reasonable assumption where thebuffer level of a HAS client has reached the maximum level.The actual duration of downloading, Tk[n], can be related tork by ˆ tk[n]+Tk[n]

t=tk[n]

Rk(t) · dt = rk · τ. (18)

The TCP throughput measured by the k-th client for down-loading the n-th segment, is defined as xk[n] := rk·τ

Tk[n]. In a

conventional HAS algorithm, the TCP throughput is used asan estimator of a client’s fair-share bandwidth, which, ideally,is equal to C

K .

Idealized TCP behavior. We assume that the network obeysa simplified bandwidth sharing model, where we do notconsider the effects such as TCP slow-start restart and het-erogenous RTTs.9 At any moment t ≥ 0 when there areA(t) ≥ 1 active TCP flows sharing the bottleneck link, eachactive flow will receive a fair-share data rate of Rk(t) = C

A(t)instantaneously, and the total traffic rate in the link is C; atany moment when there is no active TCP flows, or A(t) = 0,the total traffic rate in the link is 0. For this case, we have thefollowing definition:

Definition 1. A gap is an interval within which the total trafficrate of all clients is 0.

9It is trivial to extend the analysis to the case of heterogenous RTTs.

Client initial state. We assume that each client may havesome arbitrary initial state, including:

• Time of requesting the first segment tk[1], k = 1, ...,K,as forementioned.

• Initial data downloading rate, i.e., it may be that Rk(t) >0 for t < tk[1], k = 1, ...,K, where the rate may be due torequesting a segment earlier than the first segment beingconsidered. In practice, this may correspond to the caseswhere the clients have already started downloading butmay be in a different state, before the first segment beingconsidered (e.g., link is oversubscribed before it becomesundersubscribed).

B. Link Undersubscription

The link is undersubscribed by the K HAS clients if thesum of the requested video bitrates is less than the linkcapacity, i.e.,

∑Kk=1 rk < C. We would like to show that

even the slightest undersubscription of the link would leadto convergence into a state where each client has a TCPthroughput greater than its fair-share bandwidth C

K .To begin with, we prove a set of lemmas. We first show

that any two adjacent requesting times tk[n] and tk[n+ 1] arespaced by exactly τ if there exists a gap between them.

Lemma 2. tk[n+ 1] = tk[n] + τ if there exists a gap [t−, t+)with tk[n] ≤ t− and t+ ≤ tk[n+ 1].

Proof: By (17), the only case that tk[n+1] 6= tk[n]+τ iswhen Tk[n] > τ . But this cannot hold, since otherwise therecannot be a gap [t−, t+) with tk[n] ≤ t− and t+ ≤ tk[n+ 1].

The rest of the lemmas in this section make the assumptionof∑Kk=1 rk < C. First, we show that at least one gap must

emerge after some time.

Lemma 3. There exists a gap [t−, t+), where t− >maxk tk[1].

Proof: By (17), within [t, t+τ) for any t, each client candownload at most one segment, or data of size at most rk · τ .Consider within an interval [maxk tk[1],maxk tk[1] + m · τ)for some m ∈ N . The maximum size of the data that canbe downloaded by the K clients is Bres + m ·

∑Kk=1 rkτ ,

where Bres is the total size of the residue data from segmentsrequested prior to maxk tk[1], including those prior to thefirst segments being considered, as discussed in Section A-A,client initial state. By the idealized TCP behavior, at anyinstant, the total traffic rate can be either C or 0. If zerototal traffic rate does not happen, the total downloaded datasize within the interval being considerd is mCτ . Therefore,a sufficient condition for a gap [t−, t+) to occur is to havet− > maxk tk[1] +m ·τ , where mCτ > Bres+m ·

∑Kk=1 rkτ ,

or m =⌈Bres/τ · (C −

∑Kk=1 rk)

⌉.

The next lemma shows that within an interval of duration τimmediately following this gap, each client must request oneand only one segment.

Lemma 4. Within the interval [t+, t+ + τ), each client mustrequest one and only one segment.

Proof: First, we show that each client must request at leastone segment. Invoking Lemma 2 and the fact that [t−, t+) isa gap, the request times immediately preceding and following[t−, t+) must be spaced exactly by τ . This can never hold ifno segment is requested within [t+, t+ + τ).

Second, we show that each client can request at most onesegment within [t+, t++τ). This directly follows applying (17)to any interval of duration τ , similar to the proof of Lemma3.

Since exactly one segment is requested by each client within[t+, t+ + τ), for convenience, let us re-label these segmentsusing a new index n′.

Lemma 5. [t− + τ, t+ + τ) is a gap.

Proof: First, invoking Lemma 2 and the fact that [t−, t+)is a gap, we have tk[n′ − 1] = tk[n′]− τ for k = 1, ...,K. Inother words, the starting time patterns within intervals [t+ −τ, t+) and [t+, t+ + τ) exactly repeat.

Second, consider the data traffic within [t+ − τ, t+) and[t+, t+ + τ). The only difference is that within [t+ − τ, t+),there might be unfinished residue data from the previoussegments whereas within [t+, t+ + τ), there is no suchunfinished residue data due to the gap [t−, t+). By (18),the exact starting times and the idealized TCP behavior, thedownloading completion time can only get delayed with theextra residue data, thus we must have Tk[n′ − 1] ≥ Tk[n′],k = 1, ...,K. Therefore, the data traffic within [t+, t+ + τ)must finish no later than t− + τ , and [t− + τ, t+ + τ) mustalso be a gap.

The following theorem shows that in the case of linkundersubscription, regardless of the client initial states, thebanwidth sharing among the clients will eventually convergeto a periodic pattern.

Theorem 6. If∑Kk=1 rk < C, the data downloading rate

Rk(t) of each client will converge to a periodic pattern withperiod τ , i.e., there exists some t′ ≥ 0 such that for all t ≥ t′,Rk(t+ τ) = Rk(t), k = 1, ...,K.

Proof: The interval [t+, t+ + τ) has no residue datafrom the previous unfinished segments, because of the gap[t−, t+). Using this fact and the idealized TCP behavior, thedata downloading rates Rk(t), k = 1, ...,K for t ∈ [t+, t++τ)is a deterministic function of the starting times tk[n′], k =1, ...,K. The same argument applies to Rk(t), k = 1, ...,Kfor t ∈ [t+ + τ, t+ + 2τ) and tk[n′ + 1], k = 1, ...,K.

By Lemma 2 and Lemma 5, we have tk[n′+1] = tk[n′]+τfor k = 1, ...,K. In other words, other than the offset τ , thestarting time patterns within [t+, t+ +τ) and [t+ +τ, t+ +2τ)are the same. Invoking the deterministic function argument, wecan show Rk(t+τ) = Rk(t), k = 1, ...,K for t ∈ [t+, t++τ).Taking t′ = t+ and repeatly applying the argument above tothe intervals [t+ +mτ, t+ + (m+ 1)τ), m = 2, 3, ... completethe proof.

Note that by the idealized TCP behavior, no client’s TCPthroughput would overestimate its fair-share bandwdith C

Konly if the number of active flows A(t) = K during allthe active time. After the bandwith sharing pattern convergesto periodic, this happens only when the starting times ofall clients are all aligned and their segment data size areequal. The following corollary is an immediate consequenceof Theorem 6:

Corollary 7. If∑Kk=1 rk < C, and tk[n′] 6= tl[n

′] for somek 6= l, then for some clients the TCP throughput will convergeto a value that is greater than its fair-share bandwdith, i.e.,there exists k′ with xk′ [n] > C

K for n ≥ n′. In particular, ifr1 = r2 = ... = rK , then for all k′ = 1, ...,K, xk′ [n] > C

Kfor n ≥ n′.

Note that the start times pattern tk[n′], k = 1, ...,K will dic-tate exactly by how much the TCP throughput overestimatesthe fair-share bandwidth, with the range xk[n]

C/K ∈ [1,K].

C. Link Oversubscription

We next consider the case that the link is oversubscribedby the K HAS clients, i.e.,

∑Kk=1 rk > C. We first show a

sufficient condition under which the TCP throughput wouldcorrectly predict the fair-share bandwidth.

Theorem 8. If rk > CK for all k = 1, ...,K, all clients’ TCP

throughput converges to the fair-share bandwidth, i.e., thereexists n′ > 0 such that xk[n] = C

K , k = 1, ...,K for n ≥ n′.

Proof: We first want to show that there exists n′ > 0 suchthat Tk[n] > τ for all k = 1, ...,K for n ≥ n′. Assume that theopposite is true, i.e., there exists at least a client k′ such that,Tk′ [n] ≤ τ for all n ≥ n′. Since rk′ > C

K , this would hold onlyif within the active intervals of client k′, at least another clientk′′ must be inactive. Denote by [t−k′′ , t

+k′′) the first such inactive

interval. Consider within an interval [t−k′′ , t−k′′+m·τ) for some

m ∈ N . By the idealistic TCP behavior, the total number ofbits that can be downloaded by the K − 1 clients (other thank′) must be ≤ (K − 1)/K · mτC. This contradicts the factthat Tk[n] > τ , for k 6= k′, n ≥ n′. Thus, the assumption isinvalid.

Then, by (17), for n ≥ n′, all clients are active all thetime. By the idealistic TCP behavior, we have xk[n] = C

K ,k = 1, ...,K for n ≥ n′.

By slightly extending the above argument, a sufficientand necessary condition for the correct fair-share bandwidthestimation of all clients can be found.

Theorem 9. If∑Kk=1 rk > C, all clients’ TCP throughput

converges to the fair-share bandwidth, if and only if rk ≥ CK

for all k = 1, ...,K and there exists k′ such that rk′ > CK .

APPENDIX BANALYSIS OF PANDA

We perform an equilibrium and stability analysis ofPANDA. For simplicity, we only analyze the single-client casewhere the system has an equilibrium point.

A. Analysis of x

Assume the measured TCP download throughput x is equalto the link capacity C. Consequently, (7) can be re-written intwo scenarios (refer to Figure 3) as:

x[n]− x[n− 1]

T [n− 1]=

{κ · w, if x < C,

κ · w − κ · (x[n− 1]− C), otherwise.(19)

At equilibrium, setting (19) to zero leads to w = xo − C,hence, xo = C + w > xo = C.

Considering the simplifying assumptions of y = x (nosmoothing) and a quantizer with a margin ∆ such thatr = y − ∆, we need ro = xo − ∆ < C at equilibrium.Therefore, the quantization margin of the quantizer needs tosatisfy

∆ > xo − C = w,

so that the system stays on the multiplicative-decrease side ofthe equation at steady state.

Note that close to equilibrium, the intervals between consec-utive segment downloads match the segment playout durationT [n−1] = τ , therefore, calculation of the estimated bandwidthx follows the simple form of a difference equation:

x[n] = a · x[n− 1] + b.

The two constants are: a = 1− κ · τ and b = κ · (C +w) · τ .The sequence converges if and only if |a| < 1. Hence, weneed: −1 < 1− κ · τ < 1, leading to the stability criterion:

0 < k <2

τ.

B. Analysis of T and B

Assume no smoothing x = y. During transient states, whenT = T > T , update of T pushes the playout buffer size in theright direction: T < r[n]·τ

x[n] leads to a steady growth in buffersize when B < Bmin. At steady state, To = τ = To > To. Itcan be derived from (10) that:

Bo = Bmin +

(1− ro

xo

)· τβ

where Bo is playout buffer at equilibrium.