How internet congestion control actually works in the bufferbloat age
summary
Explains why uploads/downloads wreck latency and how TCP’s slow start, congestion avoidance, ACK-clock and loss-driven sawtooth interact with oversized buffers so queues balloon from ~10 ms to >1.6 s in demos; cites extreme cases like 860 seconds buffering. Shows live humans as packets demos and a quiz, explains mitigation: fair queuing plus AQM (fq_codel → CAKE) reduces seconds-long queues to ~5 ms and is mainlined (e.g. CAKE in Linux 4.19), while noting many gateways remain misconfigured.
AI-written summary · about
chapters (12)
- 0:00Start
- 13:27The TCP Initial Window
- 22:08The role of loss and marking
- 25:34Ack Clocking
- 27:58Receive and send windows
- 30:58Problem: Riding the sawtooth
- 31:56Solution: Fair Queuing
- 33:04Problem: Keeping Queues Short
- 35:36Cake v Sonic Fiber @100Mbit
- 37:04Quick Quiz
- 38:44Linux.conf.au wifi cdf plot
- 39:16Questions?
related talks
45mReducing Network Latency: Innovations for a Faster Internet
17mTowards provably performant congestion control
23mACK to the Future: TCP in 2025
16mManaging Congestion Control Heterogeneity on the Internet with Approximate Performance...
24mCopa: Practical Delay-Based Congestion Control for the Internet
53mHow shit works: TCP/IP
17mBridging the Gap between QoE and QoS in Congestion Control: A Large-scale Mobile...
23mThe Short and Happy Lives of TCP and HTTP Requests
