QoS Policing vs Shaping Explained: Drop It or Delay It?
Policing and shaping both enforce a speed limit on network traffic, and both measure that limit with the same token bucket. The whole difference is what happens to the traffic that breaks the limit: a policer throws it away or marks it down, a shaper makes it wait in a queue. That one choice decides whether you get drops, delay, or a smooth stream.
The short answer
Policing drops or downgrades traffic that exceeds a rate limit. Shaping delays it. Both tools enforce the same contract — for example, no more than 200 megabits per second, with a small burst allowed above that — and both check every packet against the same measuring device, a token bucket. If a packet fits the contract, both let it straight through. The difference is entirely in the failure case. A policer (the measuring device plus an immediate verdict) discards the excess packet, or stamps it as lower priority so it is the first to be dropped later. A shaper puts the excess packet in a waiting room — a buffer queue — and lets it out later, once the rate allows. Drop it, or delay it: every design choice in this article follows from that sentence.
Picture a venue door with a strict entry rate. The policer is the bouncer: if the entry tokens have run out, you are turned away on the spot — no queue forms, nobody inside is slowed down, but you personally have to go away and come back. The shaper is the same door with a waiting room added: when the tokens run out you sit down inside, and staff call you forward at the steady allowed rate. Nobody is turned away until the waiting room itself is full — but everyone who sat down arrived late, and the later you were called, the later you got in. Networks make exactly this trade, millions of times a second, and call the first version policing and the second shaping.
The token bucket, in plain English
Forget formulas for a moment. Imagine a bucket that a tap fills with tokens at a steady rate — the CIR. The bucket has a fixed size, called the burst size. A packet that wants to pass must take tokens out of the bucket equal to its own size in bytes. If there are enough tokens, the packet conforms and leaves, and the bucket is that much emptier. If there are not, the packet is over the limit at that instant. Tokens keep dripping in whenever the bucket is not full, and any drip that arrives at a full bucket is simply lost — you cannot save up an hour of silence and then send an hour of traffic in one second.
Two consequences explain almost everything people find confusing about QoS rates. First, bursts are allowed, on purpose. If the link has been quiet, the bucket sits full, so the next packet stream can spend the whole saved bucket at wire speed before the steady drip becomes the limit. The average rate over time still cannot exceed the CIR — but instant by instant, traffic is bursty, and the bucket size is exactly how much burst you have chosen to forgive. Second, a bucket smaller than one packet can never work. A packet needs its full size in tokens at once, so the burst size must be at least as large as the biggest packet you expect — a rule the standards state directly, as the fact-check box below notes. A tiny burst size is the most common reason a correctly-typed rate still drops ordinary traffic.
Refinements add a second bucket or rate. A single-rate three-colour marker (RFC 2697) uses the CIR with a committed and an excess burst, painting packets green, yellow or red. A two-rate three-colour marker (RFC 2698) adds a peak rate above the CIR, so yellow means between the two rates and red means above the peak. Strip the names away and it is still buckets, drips, and three verdicts.
One burst, two fates: a worked example
Make it concrete. A device enforces 10 megabits per second. Thirty packets of 1,500 bytes arrive in one instant burst — 45,000 bytes in total, which is 360,000 bits. The token bucket starts full and holds 20,000 bytes of tokens. The first packets spend tokens as they pass; by the time 20,000 bytes have gone through, the bucket is empty and the drip only replaces tokens at 10 megabits per second — 1,250,000 bytes per second, or 1,250 bytes per millisecond. The remaining 25,000 bytes of the burst are over the limit, right now.
The policer version: those excess packets are dropped (or painted yellow/red and re-marked). The burst is over in the instant it arrived. The senders learn about the drops the TCP way — missing acknowledgements, retransmissions, smaller sending windows — and try again spread over time. The shaper version: the excess 25,000 bytes wait in the buffer. The shaper releases traffic at 10 megabits per second, so the whole 45,000-byte burst takes 36 milliseconds to leave, and the last excess byte waits roughly 20 milliseconds in the queue. Nothing was dropped — but nothing in the second half of that burst was on time, either. Same bucket, same limit, opposite costs: loss versus delay.
Side by side
| Question | Policing | Shaping |
|---|---|---|
| What happens to excess traffic? | Dropped, or re-marked to a lower priority | Buffered and sent later, at the configured rate |
| Which direction? | Inbound or outbound | Outbound only — you can only delay packets you still hold |
| Added delay? | Essentially none for the traffic that passes | Yes — queuing delay that grows with the burst |
| Memory needed? | Almost none — no queue is kept | A buffer sized to the bursts you want to absorb |
| What the output looks like | Still bursty, with gaps where drops happened | Smoothed to a steady stream at the set rate |
| How TCP reacts | Drops trigger retransmission and window cuts — a saw-tooth | Usually no loss signal, but delay rises; a full queue drops anyway |
| Typical home | Provider edge enforcing what a customer bought; protecting a priority queue from itself | Your edge, sending into a slower service you bought over a faster physical link |
When to police, when to shape
Shape when the limit is yours to respect and the traffic hates loss. The textbook case is the sub-rate link: your router has a 1-gigabit physical connection, but the service you bought is 200 megabits per second. Anything you blast out above 200 will meet the provider policer at the far end and be dropped at random, mid-burst. Shape your outbound side to 200 instead, and you choose what waits, in which queue, in which order — the provider policer then sees a stream that already conforms and has nothing to do. You have moved the decision from their bouncer to your waiting room.
Police when you are protecting something, or enforcing a contract at the door. A provider policing a customer connection inbound is not being rude; there is no waiting room it could offer that would make an over-rate customer stream arrive slower — delay can only be added by whoever still holds the packet, which on ingress is the sender. Policing is also how a priority queue is kept honest: voice traffic gets strict priority, but a policer caps how much of it there can be, so a broken or malicious priority flow cannot starve everything else by claiming the fast lane forever.
Delay-sensitive traffic flips the preference. For a file transfer, a 20-millisecond wait is nothing and a drop is a retransmission — shape it. For live voice, a very late packet is nearly as useless as a lost one. So real designs mix both by class: shape the whole outbound pipe to the bought rate, queue classes inside it, and police the classes — above all the priority class — so none can abuse the arrangement.
Four mistakes this article prevents
1. Policing your own sub-rate WAN link on the way out. You are dropping packets the provider would have accepted if only they had arrived a few milliseconds apart. Shape outbound to the bought rate and let your queues, not random drops, decide the order. 2. Trying to shape inbound. By the time a packet reaches you, the congested link upstream has already done whatever damage it was going to do. Inbound, your honest options are policing and marking — shaping belongs on the far side, before the bottleneck. 3. Setting a burst size smaller than a real packet. A packet needs tokens equal to its full size at once. A bucket that can never hold that many tokens drops every large packet no matter how quiet the link has been — check the burst size before blaming the rate. 4. Shaping with an enormous queue and calling it lossless. A giant buffer converts every overload into standing delay — the bufferbloat failure — and still drops at the tail once it fills. A queue is a shock absorber, not a warehouse; size it for the bursts you actually expect.
Try it yourself
Run the worked example above, free, in your browser: open the QoS token-bucket policer and shaper simulator, set a 10 Mbps rate, and switch the same burst between policer and shaper modes to watch the excess packets get dropped in one and queued in the other. Then try a burst size smaller than a 1,500-byte packet and watch even a quiet link start dropping — mistake 3, live.
- Policing and shaping enforce the same rate with the same token-bucket measurement. A policer reacts to excess traffic immediately, by dropping it or re-marking it to a lower priority. A shaper reacts by holding excess traffic in a buffer and releasing it at the configured rate.
- A token bucket fills with tokens at the committed rate (CIR) and holds at most a set burst size. A packet can proceed as conforming only if the bucket holds enough tokens to cover its size — which is why a short burst can pass even though its instant rate is far above the CIR.
- Shaping is outbound only, because you can only delay packets you still hold. Policing works inbound or outbound, because a drop-or-mark decision can be made the moment a packet arrives. The classic pairing is to shape your own outbound traffic to the rate you bought, so the provider policer at the other end has nothing to drop.
- For TCP, policing drops trigger retransmissions and window cuts, so throughput saw-tooths. Shaping avoids those drops but buys delay instead — and if the shaping queue is huge or fills completely, you get bufferbloat first and tail drops anyway.