How Package-Fair Oversubscription works
When a backhaul saturates (storm damage, a fibre cut, growth outpacing your build), PFO shrinks every customer's speed by the same percentage of what they pay for, so the network degrades gracefully instead of melting down. Most customers never notice.
What happens when demand exceeds capacity
Every ISP oversubscribes. That's the business model, and it works because customers don't all peak at once. But some days they do: a backhaul loses capacity in weather, a redundant path is down for maintenance, or a tower simply grows faster than the build schedule. Demand now exceeds capacity, and something decides who gets through.
By default, that something is a FIFO queue on the bottleneck link, and FIFO has two ugly properties. First, it rewards whoever sends the most: a handful of customers running sustained downloads fill the queue and take most of the link, so the customer paying for 100 Mbps to work from home loses to the customer torrenting on a 25 Mbps plan. Second, the standing queue itself is bufferbloat. Latency climbs into the hundreds of milliseconds, and the traffic that dies first is exactly the traffic people call about (video calls, gaming, VoIP). The calls are about latency, though — most customers never notice raw throughput dropping.
Watch the same event handled both ways. Five customers behind one backhaul; a storm takes the link from 300 to 160 Mbps:
Five customers behind one backhaul, looping through a storm. When capacity drops from 300M to 160M, FIFO lets whoever queues hardest win regardless of plan while latency climbs; PFO scales every plan to the same fraction so demand fits, and latency stays flat. When the link recovers, everyone scales straight back up.
Plan-rate shaping misses mid-network bottlenecks
Here's the part that surprises even experienced operators. Suppose you're running a QoE appliance that shapes every customer to their plan rate with fq_codel — the right tool, working as designed. Now a mid-network backhaul drops to 160 Mbps while the customers behind it still sum to 230. The shaper keeps delivering 230 Mbps of correctly-shaped traffic into a 160 Mbps pipe.
The queue doesn't disappear, it just moves. It re-forms inside the backhaul radio itself, a dumb FIFO buffer where no AQM is running, and every bufferbloat symptom comes right back. Meanwhile the shaping dashboard shows green across the board, because from where it sits, every customer is shaped correctly. Some QoE tools do manage access-point airtime, but a degraded PtP span or a saturated ring segment between the shaper and the AP is invisible to them.
PFO combines the shaping with live knowledge of what every link in the path can carry.
What PFO knows
Swift Fox already measures the live capacity of every backhaul (modulation data plus automated TCP tests — the same inputs that drive MPLS auto-balancing), and it knows your topology: exactly which customer accounts sit behind every link, even as routing changes, even in complex layouts with MPLS and ECMP. Capacity and membership are tracked, per bottleneck, continuously.
What PFO does
When demand behind a link exceeds its measured capacity, PFO rescales every affected customer's fq_codel shaping rate to the same percentage of their plan — enough that total demand fits back inside the link. The queue stays in the shaper where AQM keeps latency flat, tiers stay ordered (the 100 Mbps customer always gets 4× the 25 Mbps customer), and when capacity returns, everyone scales right back up. No tickets, no manual intervention.
"Fair" here means equal fractions of what each customer pays for, rather than equal speeds (equal speeds would shortchange the higher tiers). It's also why the phone doesn't ring: a customer briefly getting two-thirds of their plan with flat latency rarely notices, but a customer getting 400 ms of bufferbloat always does.
What this means in dollars
Squeezing more out of the backhauls you already have
Planned upgrades. The usual trigger for an emergency backhaul upgrade isn't average utilization, it's the week of peak-hour meltdowns and support calls. PFO removes the meltdown, which turns an emergency upgrade into one you can schedule for next quarter. Operators can often ride out months of growth on a link that would otherwise have forced an immediate build.
Storm days. The storm still happens, but the support spike doesn't, and most customers never know there was a problem.
Included in every tier. PFO is part of the platform, not a separate subscription — it runs on the MikroTik edge you already own, or the Pathbox appliance.
See PFO absorb a saturated backhaul, live
Book a 20-minute demo and bring your most oversubscribed link. We'll show you exactly what PFO would do with it, and you'll be talking to the person who built it.
Book a 20-minute demoPrefer email? [email protected]
Next deep dive: how auto MPLS traffic balancing works →