Introduction to the classic ABR algorithm: FESTIVE (CoNEXT '12) paper reading notes

foreword

FESTIVE (Fair, Efficient, and Stable adapTIVE) is one of the most classic ABR algorithms in DASH video-on-demand , and it is also a representative of rate-based ABR algorithms. FESTIVE predicts throughput based on the harmonic mean (HM) of the past 20 video blocks, and then determines the bit rate and request time of video blocks through a series of additional mechanisms. This note is based on the translation, sorting out and summary of the original paper.

FESTIVE论文：Improving fairness, efficiency, and stability in HTTP-based adaptive video streaming with FESTIVE - CoNEXT '12

Summary of the paper:

• FESTIVE continues from the previous measurement work (the following two papers), and is optimized for the scenario where multiple players share bottleneck links
  • What happens when HTTP adaptive streaming players compete for bandwidth? - NOSSDAV '12
  • Confused, timid, and unstable: picking a video streaming rate is hard - IMC '12
• Proposed three indicators: fairness, efficiency (bit rate), stability (bit rate switching), but did not consider Caton
• Not limited to the ABR algorithm (bit rate selection), but also includes subsequent bit rate adjustment and video block request control, which is a bit like BOLA (INFOCOM '16)

Note: The words in "【】" are personal thoughts; this note only focuses on the background and design of FESTIVE, omitting other parts such as experimental evaluation.

Introduction

When multiple players share the bottleneck link, three goals need to be met:

• Fairness: Multiple competing players sharing a bottleneck link should be able to converge to a fair allocation of network resources
• Efficiency: A set of players must select the highest feasible bitrate set to maximize user experience [Video Quality]
• Stability: Players should avoid unnecessary bitrate switching, as this will adversely affect user experience [Quality Switching]

Measurements and findings in this article:

• Three components implement: (1) schedule specific video "chunks" to download, (2) choose a bitrate for each chunk, (3) estimate bandwidth
• Root cause of the problem: Interaction between inaccurate throughput estimation and bitrate selection at the application layer
  • Periodic block scheduling combined with stateless rate selection used by today's players can lead to bad feedback loops with bandwidth estimation and lead to unnecessary rate switches and unfairness in rate selection

Solution: FESTIVE, trade-off between fairness, efficiency and stability

1. Random Block Scheduling: Avoiding Synchronization Drifts When Sampling Network State
2. Stateful bit rate selection: can compensate for skewed interactions between bit rate and estimated bandwidth
3. Delayed Update Approach: Tradeoffs for Stability and Efficiency
4. Bandwidth estimator: use the harmonic mean of download speeds of recent blocks to be robust to outliers

Implementation: implement FESTIVE using Open Source Media Framework (OSMF)

Evaluate:

• Environment: real & emulate simulation, change overall bandwidth and number of users
• Comparison Method: Commercial Players
  • SmoothStreaming[12]、Netflix[8]、Adobe OSMF[2]和Akamai HD[3]
• Effect: FESTIVE improves fairness by 40%, stability by 50%, and efficiency by at least 10%; FESTIVE is robust to the number of players sharing bottlenecks, increases in bandwidth variability, and available bitrate sets

contribute:

• The design space of adaptive video algorithms is systematically explored with the goals of fairness, stability, and efficiency
• Identify the major factors in bitrate selection and chunk scheduling employed by today's state-of-the-art players that lead to undesirable feedback loops and instability
• Robust mechanisms are devised for block scheduling, bandwidth estimation, and bitrate selection that inform the design of a suite of adaptive algorithms that trade off stability, fairness, and efficiency
• Identify a specific design from this family of algorithms as a reasonable point in this trade-off space and show that it outperforms state-of-the-art players in most scenarios considered

Background & Motivation

Three indicators: total $N$ players share the bottleneck bandwidth as$W$ , where player$x$ inttThe code rate selected at time$t$$b_{x,t}$

• Inefficiency: $\frac{|{\sum }_x{b}_{x,t}-W|}{W}$, close to 0 means that each player can choose the highest possible bit rate
• Unfairness: $1-\sqrt{JainFair}$，$JainFair$ indicates the Jain fairness index [43] of each player, the lower the value, the $fairer$$it$$is$
  • [43] A quantitative measure of fairness and discrimination for resource allocation in shared computer system
• 不稳定性：$\frac{{\sum }_{d=0}^{k-1}|b_{x,t-d}-b_{x,t-d-1}|\cdot w(d)}{{\sum }_{d=0}^{k-1}{b}_{x,t-d}\cdot w(d)}$, indicating that the nearest $k=The\; weighted\; sum\; of\; all\; code\; rate\; switches\; observed\; within\; 20$ seconds is divided by the weighted sum of code rates during this period, using the weight function$w(d)=k-d$ adds a linear penalty for the most recent bitrate switch

*Similar to the performance evaluation index of TCP, but the scenarios of HAS and TCP are very different, so the approach scheme of TCP cannot be copied directly

Performance of Commercial Players: Unfair, Inefficient, Unstable

FESTIVE design

An adaptive streaming player consists of three components:

1. Schedule (Schedule) the download timing of the next block
2. Choose an appropriate code rate for the next block
3. Estimated network bandwidth

FESTIVE design: only focus on steady-state (*start-up behavior is consistent with other players)

• Estimated network bandwidth : based on the harmonic mean (HM) of the past 20 blocks
  • No bit rate switching is performed within the first 20 blocks of the video stream, and only the lowest bit rate may be selected
• Stateful code rate selection : instead of directly selecting the code rate according to the estimated throughput, it is limited when choosing a higher code rate (in order to improve fairness)
  • You can only switch to the next adjacent high/low bit rate level each time, and use a lower up-switching rate at a higher bit rate (the rate decreases linearly with the bit rate, to avoid rapid switching to high bit rates that cause unfair)
  • If you need to increase the code rate, then in kkIncrement kk$after\; k$ blocks$k$ levels of reference code rate; but if the code rate needs to be reduced, it can be switched immediately (with$p=0.85\times$ predicted bandwidth for comparison to avoid VBR video block size fluctuations)
• Delayed update : Treat the previous code rate selection as a reference value, and exit the actual code rate switch based on the measurement of efficiency/fairness and stability
  • Calculate the current ( $b_{cur}$) and the reference bit rate calculated in the previous step ( $b_{ref}$) to an efficient or stable allocation
  • 整体得分：$scor{e}_{efficiency}(b)+a\times scor{e}_{stability}\left(b\right)$ , choose the code rate with lower score (where$a=12$）
    • efficiency cost：$scor{e}_{efficiency}\left(b\right)=|\frac{b}{min(w,b_{ref})}-1|$
      • $b$ is the target code rate,$w$ is the prediction bandwidth, when$b=b_{ref}$When the value of the formula is minimum (0)
    • stability cost：$scor{e}_{stability}(b)=\{\begin{array}{ll}{2}^n+1& \text{if }b=b_{ref}\\ 2^n& \text{if }b=b_{cur}\end{array}$
      • $b$ is the target code rate,$n$ is the nearest$k=The\; number\; of\; code\; rate\; switching\; times\; within\; 20$ seconds
      • The exponential function is used because $scor{e}_{stability}(b_{ref})-scor{e}_{stability}\left(b_{cur}\right)$ with$n$ monotonically increasing
• Random video block scheduling : No longer based on a fixed target buffer, the second is to randomly select the target buffer size from the range of (target buffer-Δ, target buffer+Δ], where Δ is the duration of the video block [However, if the target buffer is much larger than the video Block time, which is almost useless under strong network]
  • The past method: immediate scheduling (continuously requesting video blocks) or periodic scheduling (similar to the implementation of dash.js, ie ON-OFF)