Video Streaming Over QUIC: A Comprehensive Study

The QUIC transport protocol represents a significant evolution in web transport technologies, offering improved performance and reduced latency compared to traditional protocols like TCP. Given the growing number of QUIC implementations, understanding their performance, particularly in video streaming contexts, is essential. This paper presents a comprehensive analysis of various QUIC implementations, focusing on their transport-layer congestion control (CC) performance and its impact on HTTP Adaptive Streaming (HAS) in single-server, multi-client environments. Through extensive trace-driven experiments, we explore how different QUIC CCs impact adaptive bitrate (ABR) algorithms in two video streaming scenarios: video-on-demand (VoD) and low-latency live streaming (LLL). Our study aims to shed light on the impact of QUIC CC implementations, queuing strategies, and cooperative versus competitive dynamics of QUIC streams on user QoE under diverse network conditions. Our results demonstrate that identical CC algorithms across different QUIC implementations can lead to significant performance variations, directly impacting the QoE of video streaming sessions. These findings offer valuable insights into the effectiveness of various QUIC implementations and their implications for optimizing QoE, underscoring the need for intelligent cross-layer designs that integrate QUIC CC and ABR schemes to enhance overall streaming performance.

💡 Research Summary

The paper presents a thorough experimental investigation of how different QUIC transport‑layer implementations affect HTTP Adaptive Streaming (HAS) performance and end‑user Quality of Experience (QoE). Recognizing that video traffic will dominate mobile data by 2024, the authors focus on the interplay between QUIC congestion‑control (CC) algorithms and adaptive bitrate (ABR) selection in both video‑on‑demand (VoD) and low‑latency live (LLL) scenarios.

Seven widely used QUIC server implementations are examined: AIOQUIC, MVFST, LSQUIC, PICOQUIC, QUINN, TQUIC, and XQUIC. Each implementation supports a distinct set of CC algorithms (Cubic, Reno, BBR variants, Copa, etc.) and differs in internal design choices such as thread model, asynchronous APIs, and multi‑path support. The authors extend the Vegvisir framework to create a single‑server, multi‑client (SS‑MC) testbed with five parallel clients sharing a traffic shaper that emulates three real‑world network traces (5G Netflix, LTE Belgium, and a cascade trace).

The streaming workload consists of a 4K video (3840×2160) encoded across a 0.5–40 Mbps ladder. For VoD, 4‑second segments and a 60‑second playback buffer are used; for LLL, 2‑second segments and a 6‑second buffer emulate low‑latency constraints. Each experiment runs for about 100 seconds, providing enough data to capture throughput dynamics, rebuffering events, start‑up delay, and perceptual quality (VMAF). The authors evaluate six trace/ABR configurations (same trace/same ABR, same trace/different ABR, different trace/same ABR) to isolate the effect of CC from ABR behavior.

Key findings:

1. Implementation‑level variance – Even when the same CC algorithm (e.g., Cubic) is used, different QUIC stacks exhibit up to 15 % variation in average goodput and markedly different rebuffering frequencies. The divergence stems from differences in initial congestion windows, RTT estimation, packet‑retransmission logic, and scheduler granularity.

2. CC‑ABR interaction – BBR‑family algorithms quickly adapt to bandwidth fluctuations, delivering higher average bitrates but can cause latency spikes in LLL due to aggressive ProbeRTT phases. Cubic, being more conservative, reduces rebuffering but suffers throughput loss under sudden loss bursts. The choice of ABR (buffer‑based vs. throughput‑based) further amplifies these effects.

3. Active Queue Management (AQM) and ECN – Replacing the default PFIFO queue with RED or CoDel shows that BBR‑based implementations benefit from ECN marks, improving bandwidth utilization by >10 %. Cubic, however, reacts poorly to ECN, inflating its congestion window and increasing loss, which degrades QoE.

4. Coexistence with TCP – When TCP flows share the same bottleneck, the QUIC implementation determines the TCP share: from 20 % to 45 % of the link capacity. TQUIC’s multipath support (MP‑QUIC) enables it to retain a larger portion of the bandwidth compared to single‑path stacks.

5. Multi‑client support – Implementations lacking proper multi‑client handling (LSQUIC, XQUIC) experience severe buffer depletion and frequent stalls when five clients compete, whereas multi‑threaded or asynchronous stacks (MVFST, QUINN) maintain smoother playback.

From these results the authors derive practical recommendations: for stable high‑bandwidth, low‑latency environments (e.g., 5G), MVFST with BBR2 yields the best QoE; for edge servers that must serve many concurrent clients, TQUIC’s multipath capabilities are advantageous. They also argue that QUIC standardization should incorporate performance profiles or benchmark suites to reduce implementation‑level disparities.

Limitations include the modest client count (five), focus on a single 4K video, and omission of multi‑audio/subtitle streams. Future work should scale to thousands of clients, test newer QUIC versions (e.g., QUIC‑v2, Multipath QUIC), and explore reinforcement‑learning‑based ABR algorithms.

Overall, the paper convincingly demonstrates that QUIC’s promise for video delivery is highly contingent on the concrete implementation details, and that cross‑layer optimization between transport‑layer CC and application‑layer ABR is essential for maximizing user QoE.