Broadband Gateway · CGNAT · QoS · Protection
"The internet is slow." The line is at full speed. Both statements are true.
AFD is running today across five production gateways — roughly 70,000 subscriber sessions — on both the QoS-only and full-CGNAT datapaths. What that has established:
| Measured | Result |
|---|---|
| Does it engage under real congestion? | Yes. On busy gateways it arbitrates continuously — on the largest, around ten thousand packet decisions per second. |
| Is the behaviour stable? | Yes. Reproducible across repeated measurement windows on the same gateway. |
| Does it stay out of the way when there is no congestion? | Yes. On two gateways whose queues never back up — one carrying over fifty thousand sessions — it recorded zero activity while switched on. |
| Is it the same on every network? | No. Across gateways at one site, configured identically, how firmly it acted varied by a factor of six. Traffic mix decides. |
| Does subscriber latency measurably improve? | Not demonstrated. See below. |
On the last question we will show our working rather than round it up. We ran alternating on/off phases on a gateway carrying about 5,700 subscribers, sampling latency repeatedly in each phase. Average latency fell by roughly a millisecond between the off and on phases — but it fell steadily through the whole test, in every phase, whether AFD was on or off. In one transition, switching AFD off improved latency. That is a traffic trend across the measurement window, not an effect of the feature, and reporting the headline number as a result would have been wrong.
We also see, consistently, that enforcing increases the total number of packets slowed. That is expected — AFD concentrates the slowdown rather than reducing it — but it is a real cost and we would rather you knew about it before enabling it than after.
So: the mechanism is proven to work; the end benefit is not yet proven to be measurable. That is why AFD ships off, with an observe mode that reports what it would do on your traffic. Measure it on your network before you turn it on — and if you find the improvement we have not yet isolated, we would like to see your numbers.
01 The complaint you cannot answer
A customer calls and says the internet is slow. You check the line. It is synced, it is clean, and it is delivering exactly the speed they pay for. Nothing is broken, and that is precisely why the call is so hard.
What happened is that another device in the house began a large transfer — a game update, a cloud backup, a phone uploading a year of photos. That one connection fills the line. Everything else now waits behind it. The delay is not caused by a fault; it is caused by queueing, and queueing is invisible to every tool that reports line speed.
02 Why the usual answer does not work
When a line fills, something has to give. Conventional equipment slows traffic evenly — every connection loses roughly the same proportion, because the equipment has no idea which is which.
That sounds even-handed. It is not. A large transfer loses ten percent and does not care; it simply keeps going. A video call loses ten percent and breaks up, because it had almost nothing spare to give. The same proportional cut is trivial for the connection causing the problem and severe for the connections suffering from it.
03 How it decides
For each connection passing through, AFD maintains a running estimate of how much of that subscriber's own line it is using. When the line becomes congested, connections above their share take more of the reduction; connections below it are left alone.
Two properties matter operationally. First, the comparison is always within one subscriber — a heavy download on one line never affects a neighbour, and there is no shared pool to tune. Second, the decision is made from observed bandwidth alone. Nothing is identified, classified or inspected.
04 Where it sits in the queueing stack
AFD is not a replacement for the queue management already running on our gateways. It is a layer that answers a question the others do not ask.
| Layer | Question it answers | What it cannot see |
|---|---|---|
| Rate control per subscriber | How much may this subscriber send in total? | Nothing about the traffic inside that allowance. |
| AQM queue management | How much must be slowed to keep the queue short? | Which connection should absorb it — it treats the subscriber as one stream. |
| Interactive Flow Protection by traffic type | Is this packet small and time-critical — a call setup, an acknowledgement, a name lookup? | Two large connections competing. Neither is small, so neither is protected. |
| AFD by measured share | Whose packet should absorb the slowdown, given what each connection is actually using? | Anything at all when the line is not congested — it is inactive by design. |
The gap AFD fills is the common one. Interactive Flow Protection already shields the small, obviously time-critical traffic. The case it structurally cannot address is a video stream competing with a download: neither is small, so the existing protection does not apply to either. That is the everyday household situation, and it is what AFD is aimed at.
05 When it acts, and when it will not
AFD is active only while a line is genuinely backed up. This is not a caveat added for safety — it is the design, and it is confirmed by measurement.
| Situation | What happens | |
|---|---|---|
| Busy hour, several devices competing on one line | The intended case. The heavy connection takes the reduction; small connections are left alone. Confirmed in observe mode on live gateways — AFD engages continuously under real busy-hour congestion, and how firmly it acts varies with the traffic on each gateway. | Designed for |
| A gateway that is not congested | Nothing is queueing, so nothing is changed — and this is measured, not asserted. On two gateways whose queues never back up, AFD recorded zero activity while enabled. On an uncongested test line, deliberately saturating the downlink still produced no AFD activity at all and identical latency with it on or off. | No effect |
| Line permanently oversubscribed | It will still redistribute the slowdown, but the honest answer is capacity. AFD improves how a shortage is shared; it does not remove one. | Not the fix |
| A single connection alone on the line | There is no competition to arbitrate. AFD has nothing to do and does nothing. | No effect |
06 How you would evaluate it
Because the outcome is not yet proven, AFD ships the way an unproven feature should: off, with a mode that measures before it acts.
A single command reports engagement and effect, so the question "is this doing anything on my network?" has a numeric answer rather than an opinion. One tuning control sets where a connection's fair share begins; the shipped default is the value our own measurements selected.
Why observe mode matters more than usual here. Congestion is specific to a network — its subscriber mix, its plan sizes, its busy hour. Observe mode tells you which kind of network yours is before you commit to anything.
We can be concrete about why that matters, because it surprised us. Running AFD in observe across three gateways at the same site, carrying roughly 13,000 subscribers between them and configured identically, the balance of its decisions differed by a factor of six from one gateway to the next. On two of the three it behaved as intended, shifting the slowdown with a light touch. On the third it was far more aggressive on the same setting. Nothing was misconfigured — the traffic was simply different.
The same run covered gateways at the other extreme. On two whose queues never back up — including one carrying more than fifty thousand sessions — AFD recorded no activity at all while switched on. It is not idling politely; there is genuinely nothing for it to do, and it does nothing.
That is the argument for measuring rather than assuming. A number taken from someone else's network — including ours — would not have predicted any of those five.
07 What AFD is not
Stated plainly, because these are the four things most likely to be assumed.
| It is not a speed increase | No subscriber's plan goes up and no line gets faster. AFD changes how a full line is shared, nothing more. |
| It is not traffic prioritisation by application | Nothing is identified as gaming, video or anything else. The only input is how much bandwidth a connection is using. |
| It is not a substitute for capacity | On a line that is short of headroom every hour of the day, the fix is headroom. |
| It is not yet a proven latency improvement | Engagement is measured and reproducible. The benefit is not, and we will publish that figure only when we have measured it. |
When a subscriber's line fills, someone has to slow down. Today that decision is made blindly and lands hardest on the traffic least able to absorb it. AFD makes the decision deliberately, using nothing but each connection's measured share of that subscriber's own line — no inspection, no customer equipment, no per-subscriber configuration, on the gateway you already run. It is available now, off by default, with an observe mode built specifically so you can measure its effect on your own network before it changes anything — including whether it helps at all.