MSc Research · The Thesis
Media Streaming over QUIC
A Quality of Experience Perspective
MSc in Computer & Communications Engineering · Lebanese International University · June 2026
- QUIC
- QoE
- HTTP/3
- HTTP/2
- MPEG-DASH
- Rebuffering
- Transport Protocols
- Adaptive Bitrate
My research evaluates how the QUIC transport protocol affects multimedia streaming Quality of Experience (QoE) compared to traditional TCP-based systems. It examines QUIC's answers to TCP's core limitations — head-of-line blocking, startup delay, and inefficient loss recovery — and compares QUIC/HTTP-3 against TCP/HTTP-2 streaming under controlled network conditions including packet loss, latency variation, and bandwidth instability, measuring bitrate stability, rebuffering, startup delay, and playback continuity.
Objectives
Four Questions
01
Expose TCP's limits
Analyze the limitations of TCP/TLS transport for media streaming — multi-stage connection establishment, transport-level head-of-line blocking, throughput instability.
02
Evaluate QUIC's design
Evaluate QUIC's design for streaming — UDP-based operation, stream multiplexing, reduced handshake latency, connection migration.
03
Build a QoE framework
Build a comparative QoE evaluation framework prioritizing user-perceived metrics over raw network efficiency.
04
Quantify under degradation
Quantify protocol behavior under realistic degraded network conditions.
The Platform
MoQUICS
I built MoQUICS — Media Streaming over QUIC — a purpose-built experimental streaming platform, so every measurement runs on infrastructure I control end to end.
Server
A physical Linux machine running Caddy 2.11 with native HTTP/3 and TLS 1.3 via a local CA (mkcert). I chose physical hardware over virtualization to eliminate artificial jitter.
Content
Nine videos transcoded to MPEG-DASH with FFmpeg at three ABR quality levels — 480p @ 800 kbps, 720p @ 2500 kbps, 1080p @ 5000 kbps.
Frontend
A single-page React 18 + strict TypeScript app bundled with Vite 5, embedding a dash.js v5 player, with custom hooks for player control, live QoE accumulation, and browser/protocol detection.
Network conditioning
Linux tc/netem injecting three conditions — Clean, Moderate (50 ms delay / 1% loss), Poor (150 ms delay / 3% loss) — switchable from the web UI via a custom daemon.
Isolation
Fully offline over a direct cable link; even the fonts are self-hosted, so no Internet variability contaminates the measurements.
Measurement
The QoE Engine
The engine measures ten metrics per session and derives a MOS-style 0–5 score using a penalty-based approximation of ITU-T P.1203. Every session exports an 18-column CSV row.
- 01Startup delay
- 02Rebuffer count
- 03Total rebuffer duration
- 04Rebuffer ratio
- 05Watch time
- 06Initial bitrate
- 07Time-weighted average bitrate
- 08Maximum bitrate
- 09Bitrate switches
- 10Connection-setup time
Methodology
One Variable
I used a paired experimental design: for each network condition and video, one session over QUIC/HTTP-3 (Chrome) and one over TCP/HTTP-2 (Firefox) with identical conditions — isolating the transport protocol as the only variable. I verified protocol usage per session via DevTools and tc qdisc.
Results
The Numbers
| Condition | Protocol | Startup (ms) | Rebuffers | Rebuffer time (s) | Avg bitrate (Mbps) | QoE score |
|---|---|---|---|---|---|---|
| Clean | HTTP/3 (QUIC) | 520 | 0 | 0.0 | 4.91 | 4.7 |
| Clean | HTTP/2 (TCP) | 860 | 1 | 0.8 | 4.65 | 4.2 |
| Moderate (50ms/1%) | HTTP/3 (QUIC) | 910 | 1 | 1.2 | 4.45 | 4.1 |
| Moderate (50ms/1%) | HTTP/2 (TCP) | 1420 | 3 | 4.8 | 3.82 | 3.2 |
| Poor (150ms/3%) | HTTP/3 (QUIC) | 1680 | 3 | 5.4 | 3.68 | 3.1 |
| Poor (150ms/3%) | HTTP/2 (TCP) | 2480 | 7 | 13.4 | 3.05 | 2.1 |
Gold rows: QUIC/HTTP-3 · higher QoE score is better
Key Findings
What It Means
01
On a clean network the protocols converge — head-of-line blocking never appears, so QUIC's advantage is marginal.
02
As loss and latency rise, QUIC's lead grows sharply: at 1080p under moderate degradation, TCP suffered heavy rebuffering while QUIC played uninterrupted.
03
Under poor conditions TCP became effectively unwatchable at high resolutions; QUIC sustained smooth playback at ABR-selected quality — confirming QUIC's strength is QoE stability in unstable, latency-sensitive environments, not raw throughput.
Conclusion
The Verdict
QUIC/HTTP-3 delivers materially better QoE than TCP/HTTP-2 for adaptive-bitrate and live streaming — lower startup delay, fewer rebuffering events, greater stability — with its advantage concentrated in lossy, unstable, and mobile-like network conditions where user experience matters most.
Future directions
- Large-scale CDN deployment studies
- QUIC in wireless & mobile networks
- AI-driven ABR / QoE optimization
- Ultra-low latency use cases (cloud gaming, live sports, VR)
- Comparison with WebRTC and Media over QUIC (MoQ)
- Reducing QUIC's CPU overhead