# Probe and Adapt: Rate Adaptation for HTTP Video Streaming At Scale

arXiv: https://arxiv.org/abs/1305.0510 · HTML: https://mlsanity.com/paper/1305.0510/

## Key facts

- Cited by 9 papers in the map (data through 14 Oct 2026).
- First posted on arXiv 1 May 2013.

## Built on by (most cited first, 9 of 9)

- [NetLLM: Adapting Large Language Models for Networking](https://mlsanity.com/paper/2402.02338/) (2024)
- [Deep Neural Network-based Enhancement for Image and Video Streaming Systems: A Survey and Future Directions](https://mlsanity.com/paper/2106.03727/) (2021)
- [A Brief Survey on Adaptive Video Streaming Quality Assessment](https://mlsanity.com/paper/2202.12987/) (2022)
- [ANT: Learning Accurate Network Throughput for Better Adaptive Video Streaming](https://mlsanity.com/paper/2104.12507/) (2021)
- [Reinforcement Learning -based Adaptation and Scheduling Methods for Multi-source DASH](https://mlsanity.com/paper/2308.11621/) (2023)
- [MU-MIMO Grouping For Real-time Applications](https://mlsanity.com/paper/2106.15262/) (2021)
- [Grounding Large Language Models as Generalizable Policies in Network Control](https://mlsanity.com/paper/2512.11839/) (2025)
- [NSMA: Neuro-Symbolic Manifold Alignment for Generalizable Adaptive Bitrate Streaming under Texture Shift](https://mlsanity.com/paper/2607.18845/) (2026)
- [ReForge: Keeping ABR Algorithms Never Finished with Verified Large Language Model Edits](https://mlsanity.com/paper/2608.15138/) (2026)

## Abstract (arXiv)

Today, the technology for video streaming over the Internet is converging towards a paradigm named HTTP-based adaptive streaming (HAS). HAS comes with two unique flavors. First, by riding on top of HTTP/TCP, it leverages the network-friendly TCP to achieve firewall/NATS traversal and bandwidth sharing. Second, by pre-encoding and storing the video in a number of discrete bitrate levels, it introduces video bitrate adaptivity in a scalable way that the video encoding is excluded from the closed-loop adaptation. A conventional wisdom is that the TCP throughput observed by a HAS client indicates the available network bandwidth, thus can be used as a reliable reference for the video bitrate selection. We argue that this no longer holds true when HAS becomes a substantial fraction of the Internet traffic. We show that when multiple HAS clients compete at a network bottleneck, the presence of competing clients and the discrete nature of the video bitrates would together create confusion for a client to correctly perceive its fair-share bandwidth. Through analysis and real experiments, we demonstrate that this fundamental limitation would lead to, for example, video rate oscillation that negatively impacts the video watching experiences. We therefore argue that it is necessary to implement at the application layer a "probe-and-adapt" mechanism for HAS video rate adaptation, which is akin but orthogonal to the transport-layer network rate adaptation achieved by TCP. We present PANDA -- a client-side rate adaptation algorithm for HAS -- as an embodiment of this idea. Our testbed results show that compared to conventional algorithms, PANDA is able to reduce the instability of video rate by 60%, at a given risk of buffer underrun.