Flow Intelligence · per-flow loss · access/transit RTT · elephant scavenging · per-sub QoE · auto-remediation

1 · The problem L4S and IFP don't solve

Modern AQM and Interactive Flow Protection are real wins — but they answer the wrong half of the question. A subscriber rings support: "the internet is slow." You ping their line and the latency is fine. What's actually happening is that a few bulk / elephant flows — a cloud backup, an OS update, one fat download — have filled the subscriber's queue and are starving the interactive traffic that makes the connection feel fast: the game, the video call, the page load.

And nobody on the NOC can answer the simplest question — is this subscriber actually having a good experience right now, and if not, why not? — because the BNG never measures real per-flow loss or latency. It shapes blind.

2 · The idea — a closed loop in the fast path

Flow Intelligence is a control loop that lives inside the XDP data plane: measure → scavenge → score → remediate. It runs inline alongside CGNAT, QoS and security in the same eBPF program — not a separate shaping box, not a hairpin to an external appliance, not a kernel scheduler.

3 · The four pillars

4 · What it helps

5 · How it works — under the hood

The marketing story above is the whole of it; the rest of this brief is for the network engineer who wants to know exactly how each pillar is implemented in the data plane and the daemon.

5 · Measurement — passive per-flow loss

A per-flow LRU hash, keyed on the subscriber four-tuple, tracks the highest end-sequence seen for the flow. Every download TCP segment is classified against that high-water mark into one of four buckets:

The reorder window (default ~3000 bytes ≈ 2×MSS) is what separates genuine out-of-order delivery — which is counted separately and not treated as loss — from a true retransmit, the loss proxy. That is why a wireless or reordered path does not inflate the measured loss. Counters land in a per-CPU QoE map (tcp_retransmits, tcp_dl_segments, tcp_ooo_packets), and the loss figure is simply retransmits ÷ segments.

Path RTT & jitter NEW are timed the same passive way. The upload side stamps the instant a flow’s SYN leaves into the per-flow map; the matching SYN-ACK on the way back yields one handshake RTT (now − syn_time), folded into a per-subscriber ring that gives average RTT and jitter. And it doesn’t stop at the handshake: a sampled, throttled TCP-timestamp (TSval/TSecr) match NEW refreshes the RTT continuously through the life of a long flow, so the figure tracks the path in real time. This all runs in the native QoS-only data plane as well as full-CGNAT, so even a QoS-only box can tell support whether a subscriber’s latency lives on the access line or out in the transit.

Access vs Transit — the split itself NEW is the elegant part. The continuous match above already times the full path (the subscriber’s timestamp, echoed back by the server). To isolate the access leg, the download direction records the server’s own timestamp into the same flow entry; when the subscriber’s next segment echoes that value back, the elapsed time is the BNG↔CPE round trip in isolation — the access line and the home Wi-Fi, nothing else. Two passive measurements, one flow entry, no extra map walk: the result is transit RTT (the internet/server leg) and access RTT (the customer’s own line) as two distinct per-subscriber numbers. Because the access figure also includes the subscriber device’s own response time, it reads as an honest upper bound on last-mile responsiveness under load — exactly the signal that exposes Wi-Fi and last-mile bufferbloat — and a plausibility cap keeps a stray sample from skewing the average.

6 · Scavenging — elephants, contention-gated

An elephant is a flow that has pushed past a cumulative-byte threshold (default 3 MB) and, optionally, clears a windowed-rate gate: a per-second window measures the flow's rate and only flows above a configurable kbps qualify — so a big-but-slow flow (a long, gentle download) is left alone.

Demotion is contention-gated. The data plane computes the subscriber's download virtual-queue sojourn:

Scavenging only acts when that sojourn exceeds a target (default 5000 µs, the AQM target). When the subscriber is contended, an eligible elephant packet is demoted with a configurable probability (default 50%):

Per-flow fairness (optional) scales that demotion probability by how many multiples of the rate threshold the flow's windowed rate represents — 2×, 4×, 8× map to progressively higher probability, computed division-free. The dominant bulk flow therefore yields hardest, while a borderline flow that is only just over the line is spared. That is the CAKE-like behaviour, expressed as a probability shift inside the XDP program.

7 · Score & auto-remediation

The per-subscriber QoE 0–100 is derived from the measured loss: low loss maps to a high score, rising loss pulls it down. On top of that sits the auto-remediation controller — a daemon control loop, not a data-plane component.

The controller samples the box every few seconds and measures the loss in the most recent window — the retransmits and segments that appeared since the last sample, not a lifetime average — so it reacts to a real spike the moment it builds, and relaxes again as soon as it clears. It pairs that with the new bulk-flow activity in the same window, so it only acts when fresh elephant traffic is genuinely present. Hysteresis requires several consecutive bad windows to step up, and more good ones to step down; a cooldown sits between changes; a maximum probability bounds the top. It runs in one of two modes: observe logs the decision it would make and never touches the data plane, while enforce applies it. Escalation is always layered on the operator baseline — never below it — and reverts on reload or restart. Critically it acts per subscriber, not box-wide NEW: the controller writes a small per-sub demote-boost that the scavenger reads, so a struggling subscriber’s bulk flows yield harder while every healthy subscriber on the same box is left completely untouched — surgical, not a blanket policy.

8 · Operating it — bngxdpctl

Everything is driven from bngxdpctl; there is no per-subscriber configuration to maintain. A single subscriber's experience is one glance away:

9 · Safety, deployment & limits