Concepts
Buffer-based adaptive bitrate (ABR)
Intuition
Think of someone filling a water tank while the house consumes water all the time: trying to guess the flow of the pipe over the next few hours is risky, but looking at how much water is still left in the tank is easy and tells you exactly what matters. If the tank is nearly empty, you spend little and try to refill it; if it is quite full, you can afford to spend more. In internet video, the "water" is the stretch of video already downloaded and stored for playback, and "spending more" is choosing a higher-quality (and heavier) version of the video.
How it works
Each video is stored at several rates, from a minimum (Rmin) to a maximum (Rmax), and the client chooses the rate of each fixed-duration chunk it downloads; the buffer is measured in seconds of video and drains at one second per second, so requesting a rate above capacity empties it until playback stops (rebuffer). The usual approach estimates future capacity from the past, which is fragile when throughput varies widely: in the trace analyzed by the paper it oscillates between about 17 Mb/s and 500 kb/s, and an adjustment factor that avoided every rebuffer would have to be so conservative (at most 0.03 on that trace) that it would yield only about 3% of the rate a correct estimate would allow. The alternative is to choose the rate as a function of the buffer level, through a map that goes from Rmin (empty buffer) to Rmax (full buffer). Under idealized assumptions (infinitesimal chunks, any rate available, constant encoding rate, infinite videos), any continuous map that is strictly increasing in the middle range and pinned at the ends avoids unnecessary rebuffers (as long as the capacity C(t) does not fall below Rmin, the buffer grows again before it empties); and, if Rmin < C(t) < Rmax the whole time, the average rate tracks the average of the capacity C(t). In practice, with finite chunks, the map is shifted to create a reservoir: while the buffer is inside it, Rmin is always requested, so the buffer can recover; above it comes the cushion region, in which the rate rises with the buffer, and then a region in which Rmax is requested (in BBA-0: 90 s reservoir, 126 s cushion, 240 s buffer). Since real videos have variable bitrate, BBA-1 computes the reservoir from the size of the upcoming chunks; and since at startup the empty buffer says little about the network, BBA-2 uses a simple estimate (the throughput of the last chunk) only in that phase, going back to deciding by the buffer alone afterward.
In practice
In A/B tests at Netflix with more than half a million users per group, the buffer-based algorithms reduced the rebuffer rate relative to the default algorithm of the time, which was based on capacity estimation (for example, 20 to 28% fewer at peak hour with BBA-1), and BBA-2, which handles the startup phase, kept the video rate practically indistinguishable from that of the default algorithm. The lesson the paper draws is that capacity estimation is unnecessary in the steady state, but useful at the beginning of the session. So, when designing a player or a video delivery service, it makes sense to start from a simple control based on buffer level, with a reservoir, and only add complexity where it is justified, such as at startup.
Use it in a design
Practice the cases that rely on this concept in the System Design school.