A BNG has to hold each subscriber to the speed they pay for. There are two ways to do it, policing and shaping, and the choice has a direct effect on latency, on TCP throughput, and on whether your network is the one that introduces bufferbloat. The two are often used as if interchangeable. They are not.
Policing: meter and drop
A policer meters the rate with a token bucket. Tokens arrive at the committed rate; each packet spends tokens equal to its size; a packet that arrives with no tokens left is dropped (or remarked) immediately. There is no queue. A burst is allowed up to the bucket depth, and anything past it is discarded on the spot.
The strengths follow from there being no queue. A policer adds no latency of its own, it needs almost no memory per subscriber, and its state is tiny enough that any CPU core can charge it without coordination. The weakness is that it enforces the rate with loss: a bursty TCP flow sees drops and backs off, so a single flow can underperform its headline rate on a pure policer, especially with a small burst allowance.
Shaping: queue and release
A shaper holds packets in a queue and releases them at the target rate. Bursts are smoothed into a steady stream rather than dropped, so TCP sees a clean pipe and a single flow fills the rate more readily.
The cost is latency and the risk of bufferbloat. A queue, by definition, holds packets, and a queue sized too deep holds them for a long time: the classic bufferbloat symptom is a download that pushes interactive latency from milliseconds into seconds because every small packet waits behind a wall of buffered bulk traffic. A shaper is only as good as its queue management; a deep, dumb FIFO shaper is worse for a gamer than a policer.
| Policing | Shaping | |
|---|---|---|
| Mechanism | Meter, drop over-rate | Queue, release at rate |
| Latency added | None | The queue's depth |
| Bufferbloat risk | None (no queue) | High if the queue is deep and unmanaged |
| TCP single-flow throughput | Can dip on bursts | Smooth |
| Per-subscriber cost | Tiny (a token bucket) | A queue and a scheduler slot |
Where Netavo sits
Netavo enforces each subscriber's rate with a per-session policer, in both directions. The buckets are a committed rate and burst (CIR and CBS), with an optional peak rate and burst (PIR and PBS, the RFC 2698 two-rate model) and an optional packets-per-second limit. A subscriber's policer is a single atomically-updated timestamp, so any worker core can enforce it without a lock, which is what lets the policer run at line rate across all cores.
The deliberate consequence is that Netavo's rate enforcement adds no latency. For interactive traffic, gaming, voice, video calls, that is exactly what you want: the network does not become the source of delay. The burst allowance (CBS) is the dial that trades a little rate-enforcement strictness for better behaviour on bursty TCP; sizing it to around 100 ms of the subscriber's rate is a sound default, and Netavo defaults to that.
A downstream shaper, built on per-subscriber departure timestamps and a per-worker timing wheel so it keeps the same lock-free, any-worker property, is designed as the next step for the cases that genuinely want smoothing and active queue management rather than policing. It is on the roadmap rather than in the shipping product, so if your service model depends on shaped delivery with AQM today, plan around the policer and talk to us about the timeline.
The queue you cannot fix from the BNG
One trap is worth naming because it sends operators chasing the wrong box. A BNG shapes or polices the traffic passing through it. It cannot remove delay that has already built up in a queue upstream of it, and the worst offender is often the subscriber's own CPE on the upload path. If a home router buffers a large upload in its own queue, the latency is added before the packets ever reach your BNG, and nothing you do on the BNG downstream path will undo it. Diagnosing "my connection lags when I upload" means looking at the CPE's upstream queue, not only at the BNG's enforcement.
Measuring it honestly
The number that matters for QoS is not throughput, it is latency under load: the interactive delay while the link is saturated in the other direction. Measure it with a working-latency test (a flent-style run, or a simple ping during a saturating transfer) rather than a plain speed test, which hides the queue. A policer should show near-idle latency under load because it never queues; a shaper should be judged on how well its queue management holds latency down while keeping the rate full.
Policing and shaping are tools with different jobs, not better and worse versions of the same thing. Policing protects latency and scales trivially; shaping protects single-flow throughput at the cost of a queue you must manage. Choose by what your subscribers feel, and measure latency under load, not just speed.
Try it under load
The free evaluation build runs the production per-session policer with committed and peak buckets. Put a subscriber behind it, saturate the link, and watch interactive latency hold while the rate is enforced. Start at netavobng.com/evaluation; the shaping and traffic-class design is in the manual, and the performance method is on the performance page.