All right, Daniel's following up on our in-flight Wi-Fi and Starlink episodes with a question about what happens after the signal arrives — when the pipe is too small for everyone and somebody has to decide who gets what. He wants to dig into traffic shaping, and he's asking about it from both ends: what ISPs do to us, and what we can do to our own networks if we're motivated enough to crack open an OpenWrt router. He's talking about mechanisms for prioritizing clients, protocols, even specific websites — not just letting everyone on the network grab whatever they want, but actually writing rules for how the internal pipe gets allocated. So where do we even start with this?
We start by clearing up the thing almost everyone gets wrong. Traffic shaping is not throttling. Throttling is reactive — you've used too much data, or you're on a congested tower, so the ISP clamps your speed down to a crawl. Shaping is proactive. You're deciding, ahead of time, which traffic gets priority when there's contention. It's the difference between a bouncer who throws you out after you've had too many and a maître d' who decides where you sit when you walk in.
So throttling is punishment, shaping is table assignment.
That's the one. And QoS — Quality of Service — that's the whole restaurant. It's the umbrella term for all the techniques that manage how network resources get divided up. Traffic shaping is one tool under that umbrella. You've also got policing, which just drops packets that exceed a rate limit, and prioritization, which tags packets and lets the router sort them into fast and slow lanes. Shaping is the one that actually smooths traffic out — it buffers and delays rather than dropping.
Daniel mentioned OpenWrt specifically, which tells me he's looked at this more than casually. Most people see "QoS" in their router settings and click past it.
And they're usually right to, because the QoS presets on consumer routers are often terrible. But we'll get to that. Let's start with the mechanism that makes shaping work, because once you understand this one idea, everything else clicks into place. It's called the token bucket.
Which sounds like something you'd find at a carnival.
It's actually beautifully simple. Imagine a bucket that fills up with tokens at a steady rate — say, one token every millisecond. Each token represents permission to send a certain amount of data. When a packet arrives, the router checks the bucket. If there's a token, the packet goes out immediately and the token is consumed. If the bucket is empty, the packet waits until a new token arrives. The bucket has a maximum size — when it's full, new tokens just spill over and are lost.
So the fill rate sets your average speed, and the bucket size sets how much you can burst.
If your bucket holds a thousand tokens and fills at one per millisecond, you can send a thousand packets in a burst — that's your peak — but over time you can't exceed the fill rate. It's a way of saying "you can have short sprints, but your marathon pace is fixed."
And this is what's actually running inside a router?
In some form, yes. The Linux kernel's traffic control system — tc — implements token bucket filters directly. When you configure QoS on an OpenWrt router, underneath it's setting up token buckets or similar rate-limiting mechanisms. The algorithm itself dates back to the early days of packet-switched networking. It's not new, it's just that the implementations have gotten better and the configuration tools have gotten less terrifying.
I want to sit with the burst thing for a second, because that's where the user experience lives. If I'm loading a webpage, I want that initial burst — all the images and scripts arriving fast — and then I'm reading for thirty seconds. The token bucket lets that happen without letting me saturate the connection the whole time.
Right. And the alternative — a strict rate limiter with no bucket — would make every page load feel sluggish, even if the average throughput was the same. That's why shaping feels different from throttling. Throttling just says "you get five megabits per second, period." Shaping says "you get five megabits per second on average, but I'll let you have twenty for the first half-second."
So that's the mechanism. Now, what are ISPs actually doing with it?
This is where it gets less friendly. ISPs use something called Deep Packet Inspection — DPI — to look inside the packets and figure out what protocol they belong to. Is this BitTorrent? Is this Netflix? Is this a VoIP call? Once they've identified the traffic, they apply shaping rules. And they've been doing this for a long time. Ars Technica documented this extensively — ISPs would detect BitTorrent traffic and deliberately slow it down, even if the network wasn't congested.
And they'd claim it was about network management.
Sure, and sometimes it was. BitTorrent can be extremely chatty — hundreds of connections to peers all over the world, saturating upload links. On a shared cable segment, one heavy torrent user could degrade service for everyone else on the node. But the problem is, once you've built the DPI infrastructure to identify protocols, the temptation to use it for other purposes is enormous. Why not slow down a competitor's video service? Why not charge Netflix for "premium" delivery that bypasses the shaping rules?
Which brings us to net neutrality, sitting in the corner taking notes.
It's the entire tension. Traffic shaping is a legitimate engineering tool. Every network engineer needs it. But the same mechanisms that reduce latency for VoIP calls can also be used to give the ISP's own streaming service an unfair advantage. The mechanism is neutral. The policy is not.
Let's bring this into a specific constrained environment, because Daniel's original question came out of the in-flight discussion. What's happening at thirty-five thousand feet?
In-flight Wi-Fi is shaping on hard mode. You've got a satellite link — maybe Starlink, maybe geostationary — with limited total capacity shared across every passenger on the plane. But you've also got cockpit data that cannot be delayed. ACARS messages, weather radar updates, maintenance telemetry — that stuff has to go through immediately, every time. So the system implements strict priority queues. Cockpit traffic goes into the highest-priority queue, period. Below that, you might have premium passenger traffic — people who paid for the "business" tier — then standard passenger browsing, then background stuff like app updates.
And somewhere below that, the guy trying to download a four-gigabyte game update while everyone else is trying to send an email.
Who is, I should note, the reason we have traffic shaping in the first place. Every network engineer has a story about the one user who ruined it for everyone. But yes — that traffic gets the lowest priority, and if the link is saturated, it might not move at all until the plane lands.
So the token bucket is doing the shaping, but there's also a priority system layered on top. How do those interact?
You can think of it as multiple token buckets, one per priority level. The high-priority bucket gets its tokens first. If there's anything left, the next bucket gets serviced. And so on down. In practice, this is often implemented with something called Hierarchical Token Bucket — HTB — which lets you build a tree of classes, each with its own rate and priority, and the scheduler walks the tree deciding who gets to send next.
A tree of token buckets. That's either beautiful or deeply alarming, depending on your disposition.
Both. It's elegant in concept and a nightmare to configure by hand. Which is why most people don't. But that's the ISP side. Daniel also asked about what consumers can do on their own networks, and this is where it gets genuinely interesting.
Because now the power dynamic flips. Instead of the ISP shaping your traffic for their purposes, you're shaping your own traffic for yours.
Right. And the most common entry point is the QoS settings on a consumer router. You've probably seen these — presets for "gaming," "streaming," "VoIP," and so on. What they're doing under the hood is classifying traffic by port number or by a simple DPI engine and assigning it to priority queues. Gaming traffic — which is mostly UDP on known port ranges — goes to the high-priority queue. Streaming video goes to medium. Bulk downloads go to low.
And how well does that actually work?
It's... mixed. The problem is bufferbloat.
Which is the phenomenon where routers hold onto packets too long, thinking they're being helpful, and end up adding massive latency.
Your router has buffers — memory where packets wait before being transmitted. When the link is congested, those buffers fill up. A naive router will just keep accepting packets and queuing them, and suddenly your gaming latency goes from twenty milliseconds to two hundred milliseconds because your game packets are sitting behind a queue of Netflix data. The QoS presets help by putting the game packets in a separate queue, but if that queue's buffer is still too large, you've only moved the problem.
So you need something smarter than just priority queues.
This is where OpenWrt's SQM comes in — Smart Queue Management. And it's the thing I'd recommend to anyone who's actually serious about fixing their home network latency. SQM combines shaping with active queue management. The specific algorithm most people use is called fq_codel — Fair Queuing with Controlled Delay.
Break that down.
Fair queuing means every flow gets its own queue. A flow is roughly one conversation between two applications — your Zoom call is one flow, your wife's Netflix stream is another, the kid's game is a third. Each flow gets a separate queue, and the scheduler services them in a round-robin, so no single flow can monopolize the link. Controlled delay means the algorithm is constantly measuring how long packets spend in each queue, and if the delay exceeds a target — typically five milliseconds — it starts dropping packets from that queue.
Dropping packets sounds bad.
It sounds bad, but it's actually the fix. TCP — the protocol that carries most internet traffic — interprets packet loss as a congestion signal and reduces its sending rate. By dropping packets early, before the buffer fills up, fq_codel tells the sender "slow down" while the latency is still low. The alternative is letting the buffer fill completely, at which point every packet experiences huge delay and TCP eventually reacts anyway, but much later and much more painfully.
So you're breaking a few eggs to keep the kitchen clean.
And the results are dramatic. On a typical home connection — say a hundred megabit cable link — bufferbloat can add hundreds of milliseconds of latency under load. With SQM configured properly, that drops to single digits. Your Zoom call stays clear, your game stays responsive, and the download still finishes. Everyone wins.
What does configuring it actually involve?
On OpenWrt, you install the SQM package, go to the SQM QoS page in the web interface, set your download and upload speeds to about ninety percent of what your connection actually delivers — you leave a little headroom — and select fq_codel as the queuing discipline. That's it for the basic setup. The system handles the rest. It shapes the traffic so you never quite hit the link's actual limit, which prevents the ISP's modem from building up its own buffers, and fq_codel manages the queues inside your router.
Ninety percent — why not the full speed?
Because you want your router to be the bottleneck, not the ISP's equipment. If you shape to exactly your line rate, the ISP's modem might still buffer packets before your shaper gets a chance to manage them. By shaping slightly below the line rate, you ensure your router is always in control of the queue. It's one of those counterintuitive things — slightly reducing your maximum throughput gives you dramatically better latency.
That's the kind of detail that separates "I clicked the gaming preset" from actually solving the problem.
And it's why I said most consumer router QoS is terrible. The presets don't address bufferbloat at all. They just sort packets into priority buckets and call it a day. If the buffers are still huge, your high-priority game packets are still waiting behind a wall of low-priority data that the router accepted and hasn't sent yet.
Daniel mentioned prioritizing specific clients and protocols. How deep can you go on a consumer setup?
Pretty deep, if you're willing to learn the syntax. You can set per-device bandwidth limits — say, the smart TV gets capped at ten megabits so it can't saturate the link with 4K streams. You can write protocol-based rules — prioritize SSH traffic for remote work, or deprioritize torrent traffic by port range. You can even do hostname matching in some configurations, so traffic to your work VPN endpoint always gets priority.
And at that point you're basically running a miniature ISP in your house.
You are, and this is where the two worlds collide. Your ISP is shaping your traffic for their network efficiency. You're shaping your traffic for your experience. And those goals can conflict. If your ISP is already de-prioritizing video traffic, and you're also trying to prioritize it on your end, the two shaping systems can interact in weird ways. You might be giving your Netflix traffic the highest priority internally, but the ISP is putting it in the slow lane on their side.
So you're fighting a battle you can't see.
And can't really win. The ISP controls the last mile. You control your internal network. There's a boundary where your control ends and theirs begins, and that boundary is usually the modem. Everything you do with SQM is about managing what happens inside your house. Once the packets leave, they're in someone else's queue.
This connects to something we touched on in an earlier episode — the first-tenant advantage. When a network owner also sells services, they have every incentive to prioritize their own traffic.
And it's not even always malicious. If you're a cable ISP and you also sell a VoIP phone service, it makes engineering sense to put your own VoIP traffic in the high-priority queue — you control the endpoints, you can guarantee the quality. But when you start doing that for your streaming video service while competitors' traffic gets best-effort delivery, you've crossed into territory that net neutrality rules were designed to prevent.
The thing that strikes me is how much of this is invisible to the user. You experience it as "Netflix is slow tonight" or "my game is laggy," but you have no way to know whether it's your router, your ISP's shaping, congestion at the peering point, or the server you're connecting to.
There are tools — the DSLReports speed test includes a bufferbloat measurement, and there's the Flent tool for more detailed testing. But for most people, it's a black box. They pay for a speed tier and they get whatever they get.
Let's talk about the fairness dimension for a moment. In a household of four people, all working from home, all on video calls — is shaping actually fair, or is it just organized scarcity?
That's the philosophical question at the heart of it. A pure free-for-all — everyone gets whatever they can grab — sounds fair until you realize that one person's large download can ruin three other people's calls. Shaping with something like fq_codel is arguably more fair because it gives each flow an equal shot at the link. Your video call and my download each get a queue, and the scheduler alternates between them. The download takes longer, but the call stays clear.
So it's not about who's more important, it's about preventing any one flow from dominating.
Right. And that's a different philosophy from priority-based shaping, which says "this type of traffic is inherently more important than that type." Fq_codel doesn't care what the traffic is — it just ensures that every flow gets a turn and no queue gets too long. It's remarkably egalitarian for a piece of router software.
Which approach does Daniel's question point toward? He mentioned prioritizing clients and protocols, which sounds more like the priority-queue model.
It does, and there are legitimate reasons to go that route. If you're a software developer working from home, you might want to guarantee that SSH traffic to your build server always gets through, even if someone else is streaming 4K video. That's a reasonable thing to want. The question is whether you want to be in the business of making those judgments for every device and protocol on your network.
Most people don't. They want it to just work.
And that's the promise of SQM with fq_codel — you set it up once, you tell it your line speed, and it handles the rest. No per-device rules, no protocol classification, no manual priority assignments. It's not perfect for every scenario, but it solves the biggest problem — bufferbloat — without requiring you to become a network engineer.
You mentioned earlier that the token bucket algorithm has been around since the early days. What's actually new here?
The active queue management part. Token buckets are old. Priority queuing is old. What fq_codel brought was the insight that you could combine fair queuing with a clever delay-based dropping algorithm and get something that works well across a huge range of conditions without needing to be tuned. The "codel" part — controlled delay — was the breakthrough. Kathleen Nichols and Van Jacobson published the paper in twenty twelve, and it took a few years for it to make its way into Linux and then into OpenWrt, but now it's the default in a lot of places.
Van Jacobson — that's the same person who wrote the congestion control algorithms that saved the internet from collapse in the late eighties.
The very same. He's been thinking about this problem for decades. The fact that he's still working on it tells you how hard it is.
Where does this leave the consumer who isn't going to install OpenWrt? Are there off-the-shelf routers that do this well?
Some. Eero has a feature they call SQM — they actually use that term — which implements fq_codel under the hood. IQrouter is a niche product built specifically around bufferbloat mitigation. Even some gaming routers from Asus and Netgear have gotten better about this, though their marketing tends to focus on flashy features rather than the unglamorous work of queue management. The situation is improving, slowly.
On the ISP side? Are they using these techniques too, or are they still on older methods?
It depends on the ISP and the technology. DOCSIS — the cable modem standard — has had a bufferbloat problem for years because cable modems tend to have large buffers. The newer DOCSIS standards include AQM features, but deployment is uneven. Fiber ISPs generally have less bufferbloat because the links are symmetric and the equipment tends to have smaller buffers. But ISP-level shaping is still mostly about DPI and priority queues, not about fair queuing for individual subscriber flows.
Because they're managing aggregates, not individual flows.
Right. An ISP doesn't care about your specific Zoom call. They care about the total bandwidth consumed by video conferencing across ten thousand subscribers. The granularity is different. That's why consumer-side shaping and ISP-side shaping are complementary but not redundant. They operate at different scales with different goals.
Hilbert, you've been quiet back there. You've got a story about this, don't you?
Hilbert: I ran a small ISP in the late nineties. Well, I say ISP. It was a T1 line and about forty customers in an office park.
You ran an ISP.
Hilbert: We called it one. I did the network admin work because I was the only one who'd read the manual. We had a Linux box doing routing and I set up traffic shaping with the tc command. Token bucket filters, all typed by hand.
You understood what you were doing?
Hilbert: Not even slightly. I had a printout from the Linux Advanced Routing and Traffic Control HOWTO. I copied the examples and changed the numbers until it seemed to work.
What were you trying to accomplish?
Hilbert: The CEO of one of our client companies complained that his email was slow. So I wrote a rule that prioritized SMTP traffic above everything else. Port twenty-five got the fast lane. Everything else got what was left.
Everything else including...
Hilbert: Web browsing. File transfers. DNS lookups, which in retrospect was a problem.
Because if DNS is slow, everything feels slow even if the actual data transfer is fast.
Hilbert: Took me three days to figure that out. But that wasn't the real disaster. The real disaster was when the same CEO tried to do a video call. This would have been around nineteen ninety-nine — video over IP was barely a thing, but he had some expensive H.323 setup. And my shaping rules had no idea what H.323 was. It wasn't port twenty-five, so it went into the default bucket, which I'd set to about the speed of a fax machine.
How many angry calls?
Hilbert: He called every day for a week. I kept telling him I'd fixed it. I had not fixed it. What I eventually did was find his machine's IP address and give it a dedicated high-priority class with no rate limit. So for about two months, one guy in the office park had perfect internet and everyone else got crumbs.
The CEO solution.
Hilbert: Then his assistant started complaining that her connection was slow. Same office, different IP. I hadn't thought to ask if anyone else in that office needed bandwidth.
You created a two-tier system entirely by accident.
Hilbert: The thing is, if I'd had something like SQM back then — fq_codel, fair queuing — I wouldn't have needed to do any of that. The T1 would have just worked for everyone, more or less. Instead I spent weeks playing whack-a-mole with individual IP addresses because I didn't understand the difference between shaping and fairness.
Did you ever go back and learn the theory properly?
Hilbert: Years later, when I was setting up a network for a warehouse management system. Different job. But by then the tools were better and I didn't have to type the tc commands myself. I still have the printout somewhere. It's got coffee stains on the token bucket diagram.
I'm not sure there's a better summary of the whole topic than that. A room full of network engineers in the nineties, all copying commands they didn't understand from a HOWTO, trying to keep CEOs from yelling at them.
The tools have gotten better, but the fundamental problem hasn't changed. You've got a shared resource, and you need to decide who gets what when there's contention. The only difference now is that we have algorithms that do it fairly without requiring you to know every IP address on your network.
Hilbert: The CEO eventually left that office park. I like to think it wasn't because of the internet.
I wouldn't bet on it.
Here's the open question I keep coming back to. As Starlink and other LEO satellite services grow — and as 5G fixed wireless becomes more common — we're going to have more connections that are shared and constrained in ways that fiber isn't. The shaping problem gets more acute, not less. And the question is whether ISPs will give consumers better tools to manage their own traffic, or whether they'll use the complexity as an excuse to take more control.
The track record suggests the latter.
But the counterpressure is real. The knowledge is out there. Anyone who's motivated enough can take control of their own internal pipe, and the results are good. The barrier is that most people don't know it's possible, and the setup isn't quite plug-and-play yet.
The misconception I want to nail down is the one we started with — that traffic shaping and throttling are the same thing. They're not. Throttling is a blunt instrument that punishes you after the fact. Shaping is a set of decisions about who gets priority before the congestion happens. One is reactive, the other is architectural.
The second misconception is that your router's "gaming" QoS preset solves the problem. It doesn't, unless it's also addressing bufferbloat. Without active queue management, you're just rearranging deck chairs on a ship that's still taking on water.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop, who apparently spent the late nineties running an office park ISP on vibes and a printout.
If you want to dig deeper into SQM or share your own traffic shaping horror stories, email the show at show at my weird prompts dot com. We'll be back soon.
