Bufferbloat, and the lab

Someone in the office starts a big upload, a backup to the cloud say, and suddenly video calls stutter, web pages crawl and SSH sessions lag, for everyone. The link isn't broken, and it isn't really "full": a single upload is using all of it, and everything else is stuck in a queue behind it. That queue is the problem, and it has a name: bufferbloat.

Every link that's slower than the network feeding it needs a buffer. A broadband modem receives packets from your router at a gigabit and sends them out at, say, 5 Mbit/s, so packets wait in its buffer. Modems are typically built with large, simple first-in-first-out buffers, often big enough to hold a second or more of traffic. A bulk transfer keeps that buffer full, and every other packet, your ping, your VoIP call, your keystroke, waits behind it.

You can't change the modem's buffer. What you can do is make your router send a little slower than the line, so the queue builds up in the router instead, and then manage that queue well. That's what CAKE (Common Applications Kept Enhanced) does: a shaper, a fair queue per flow and per host, and active queue management (AQM) that keeps every queue short, in one Linux queueing discipline with very few settings.

The lab, and why it's a VM

The office router, gw, sits between the office LAN (two PCs) and a "modem" with a 5 Mbit/s upload and a 20 Mbit/s download, each with a deep buffer, as many real ones have. Beyond the modem is a server to measure against with ping and iperf3.

Unlike the other Debian lessons, the router here is a real Debian 13 virtual machine, not a container. Containers share the host's kernel, and Docker Desktop's kernel is built without CAKE (and without fq_codel). Debian's own kernel has both, so the lab runs Debian's official cloud image under QEMU, the same way the VyOS lessons run VyOS. Everything you type on gw is plain Debian 13.