Keep Gaming, Calls and Web Snappy — Even When the Line is Full
in 40 seconds on a live node
across ~950 live subscribers
zero subscriber harm
or per-subscriber licences
Speed and latency are not the same thing. A 200 Mbps download can feel completely broken — choppy Zoom calls, rubber-banding games, slow page loads — while the throughput looks perfect. The cause is head-of-line blocking: the subscriber's own bulk download fills the shaper queue, and every interactive packet gets stuck behind it. IFP classifies those thin, latency-sensitive flows and gives them a protected lane. The bulk download still gets its bandwidth. The interactive flows stop waiting behind it.
1 · The problem L4S does not fully solve — and why IFP fills the gap
L4S / dual-queue AQM is the right tool for controlling queue depth: it watches how long packets wait, marks or drops the bulk flows building the queue, and keeps average queuing latency near a target. On a healthy network, it stays idle. Under sustained congestion, it cuts average queuing latency demonstrably.
There are two distinct sub-problems that IFP addresses, each with a specific mechanism:
Interactive packets stuck behind bulk backlog
A 50 Mbps download saturates the subscriber's token bucket. The Zoom audio packet, the game input, the DNS lookup all arrive at the same shaper queue and wait behind the download burst. Throughput looks fine. The subscriber notices every millisecond of it in their game and their call.
IFP fix: classify the thin/interactive flows and exempt them from the policer's virtual-queue delay and the AQM's mark/drop decisions. They pass without joining the bulk backlog.
Saturated upload collapses download speed
On asymmetric residential links (fast download / slow upload), a saturated upload queue starves the upstream TCP ACKs. Without those ACKs, the sender's congestion window stalls — download throughput collapses and download latency inflates, even when the download line itself has headroom. Classic bufferbloat on the upload path.
IFP fix: fast-path pure TCP ACKs on the upload direction. ACKs carry no payload; they are the mechanism by which the download works. Protecting them recovers download performance and responsiveness simultaneously.
2 · How the protected lane works — plainly
XDP is run-to-completion: it cannot hold a packet, reorder flows, or maintain a per-flow scheduler. What it can do is make a differential decision at the two existing chokepoints where interactive packets would otherwise be harmed:
The flow path — with and without IFP
A packet arrives, is classified, and takes one of two lanes. The bulk lane sees the full policer and AQM. The interactive lane bypasses the policer's induced queue delay and the AQM's mark/drop decisions — it is never delayed or penalised on account of bulk traffic it did not cause.
1 · Policer (check_rate_limit): a classified interactive packet does not accrue the subscriber's virtual-queue induced delay and is not rate-limited by the shared bulk bucket. It gets a small, bounded priority allowance instead.
2 · AQM decision (aqm_p3_decide / ecn_set_ce): a classified interactive packet is exempt from CE-marking and classic early-drop. It was not the cause of the queue, and marking or dropping a game packet / VoIP frame / DNS query is precisely the wrong action.
Abuse prevention: the protected lane is gated on a combination of signals (small packet size AND/OR pure-ACK AND/OR known-interactive port) plus a per-subscriber priority token allowance (default 10% of shaped rate). A bulk download cannot masquerade: its packets are large and carry payload — they fail the gates. If any flow tries to saturate the priority allowance, it spills back to the normal policer.
3 · What IFP classifies as interactive — the five gates
Upstream TCP acknowledgements
Packets with TCP ACK flag, no SYN, and size ≤64 bytes — the pure acknowledgement stream. On asymmetric links, these ACKs are what make downloads work. When they are starved, download throughput collapses.
Applies primarily to the upload direction. This is the ACK-prioritization fix — well-understood bufferbloat remedy, works continuously.
TCP connection setups
Packets with the TCP SYN flag. Every page load, every app connection, every game session starts with a SYN. Handshake latency is directly felt as page load time and lobby-join delay.
Tiny packets, never carry bulk — zero false-positive risk.
Name resolution traffic
Packets on port 53 (source or destination). DNS sits on the critical path of every user action — before the first byte of any page, app, or game can be fetched. DNS delay adds directly to perceived page-load time.
Small queries and responses; never bulk traffic.
VoIP, RTP, gaming, control
Packets ≤256 bytes (tunable). VoIP/RTP audio frames (~160–200 B), online gaming UDP (~40–120 B), and real-time control packets are structurally small — this threshold captures them without requiring per-app port lists.
The bounded priority allowance contains any false positives from small bulk segments.
Operator/CPE-marked priority
Optional, off by default. Honors DSCP EF (46) or CS6/CS7 markings set by the CPE or upstream devices. Many access networks bleach DSCP — enable only where CPE marking is trusted.
Operator can also supply a small priority port list (e.g. specific game/VoIP ports) checked per packet.
Sparse-flow detection (Phase 3)
Any flow sending below the line's drain rate never builds a queue — it is by definition sparse and interactive. Phase 3 uses per-flow state (reusing existing flow-map infrastructure) to detect sparse flows and protect them even if they don't match Tier 1 gates.
Available on native/split programs with headroom; full-mono stays Tier 1. Ships after Phase 2.
4 · Validated in production REAL DATA
IFP has been observed on a live production access node — real residential traffic, i40e NIC, native XDP mode. The measurement below is from a 40-second monitoring window during normal operation. No synthetic load, no lab setup.
40-second measurement window — live residential traffic
- ~1.15 million of those were pure TCP ACKs — the upstream ACK stream that, when starved, collapses download performance on asymmetric links. That is the dominant protected class on a residential access node, exactly as expected.
- Remaining ~80,000 classified by other Tier 1 gates: SYN, DNS, small-packet interactive (VoIP/gaming/control).
- ~30,000 protected interactive packets per second across the node — continuously, not just during peaks.
- Measured in observe mode: classification and counting only, no enforcement yet. Zero behaviour change from subscriber perspective.
Zero subscriber harm — all indicators flat
- Queuing latency: ~0.6 ms — flat through the measurement window. Classification overhead did not disturb the datapath.
- CPU utilization: ~2% — the classification branch adds negligible cost. Scratch fields are already hot; no new parsing.
- Subscriber count: unchanged. No sessions disrupted, no rate changes, no unexpected drops.
- Classification is stateless per-packet — reads existing scratch fields only, no new BPF map lookups in Tier 1. Verifier budget impact: a few dozen instructions.
- This is observe mode. When enforcement is enabled, the same classification drives the protected-lane decisions with no additional parsing cost.
What was measured: IFP classified and would protect 1.23 million interactive packets in 40 seconds (~30,000/sec), of which ~1.15 million were pure TCP ACKs. Classification runs continuously and correctly identifies the interactive flow population at scale.
What was not measured (and why that is fine): in observe mode, the drop-protection counters (packets saved from drop or mark) stay at zero on a healthy, uncongested line — because there is nothing being dropped to protect against. This is exactly correct. IFP's drop-protection is "armed insurance": it engages automatically when a subscriber's line saturates at peak. The ACK-prioritization and interactive classification work continuously regardless of congestion state.
The three-part value proposition: (1) continuous — interactive flows are always classified and always get the protected lane, even on an uncongested line, preventing head-of-line blocking before it starts; (2) ACK-prioritization always on — recovering asymmetric-link download performance continuously; (3) drop-exemption insurance — automatically fires when a line saturates, with conservative gates that do nothing when not needed and protect the interactive flows that need it when it matters.
5 · How IFP complements L4S/AQM — the full low-latency stack
L4S/AQM controls queue depth. IFP controls who waits in that queue.
L4S / Dual-Queue AQM
Watches how long packets wait in aggregate. When the queue builds, marks ECN-capable flows loss-free and applies early-drop to legacy flows to signal senders to ease off. Keeps average queuing latency near a configured target (e.g. 5 ms). Adaptive controller self-tunes per-site. Validated at scale: <1 ms avg queuing through 2-hour peak on three independent production nodes.
Interactive Flow Protection (IFP)
Classifies each packet as bulk or interactive at line rate. Interactive packets (ACKs, SYN, DNS, small-packet, gaming/VoIP) are given a protected lane: they bypass the policer's induced delay and are exempt from AQM mark/drop decisions. They never wait behind a bulk download. ACK prioritization specifically recovers download performance on asymmetric residential links.
Plain framing: L4S keeps the queue short. IFP keeps the most visible traffic out of that queue entirely. A subscriber doing a 4K stream download and a video call simultaneously: L4S holds the shaper latency below 5 ms; IFP ensures the Zoom audio packets are never delayed by the stream's burst. Both run inline in XDP, both are per-subscriber, both are zero new hardware.
The latency stack — where each mechanism applies
Each mechanism targets a different source of subscriber-felt delay. Together they cover the complete picture from aggregate queue depth down to individual flow fairness.
6 · What it means for your subscribers — and your business
"Gaming and video calls stay smooth even when the household is saturating the line"
This is the sentence that converts a subscriber from a support ticket into a loyal customer. The family's Netflix binge and Windows update do not have to stop — and the gamer's packets do not have to wait behind them. IFP makes that sentence technically true and demonstrably measurable. It is the foundation for a credible premium "low-latency / gaming / pro" tier: protection that is continuous, per-subscriber, and auditable by the NOC.
Runs on your existing XDP BNG fleet. No new hardware, no per-subscriber licence cost. That makes the incremental cost per subscriber effectively zero — and positions it either as a silent retention improvement across all plans, or as a monetizable feature tier for subscribers who care most about real-time performance.
The applications subscribers care about most are structurally intolerant of queuing delay. Here is exactly where IFP's protection lands:
Game inputs and state packets
- Game packets are small (40–120 B UDP) — they hit the small-packet gate and the DNS/connection-setup gates directly
- Without IFP: a game patch or co-player's download in the same household creates a burst in the shaper queue; the game packet waits behind it; the player sees lag spikes, rubber-banding, lost inputs
- With IFP: the game packets take the protected lane; they pass without joining the bulk queue; the lag spikes that everyone on the household's line was causing for each other become smooth play
- Enables a credible "low-latency / gamer" premium tier
VoIP and RTP audio/video frames
- VoIP/RTP audio frames are ~160–200 B — exactly the small-packet gate. Video keyframes are larger but audio is the perceptual bottleneck
- Without IFP: a 4K stream or large upload in the household creates intermittent queue depth; audio frames wait; the call is choppy, people talk over each other, "you're frozen"
- With IFP: audio frames are always in the protected lane; the call stays clear even while the household line is saturated by other traffic
- Critical for work-from-home and business subscribers
Asymmetric link download recovery
- The mechanism is specific, well-understood, and universally applicable to residential ADSL/VDSL/DOCSIS/fixed-wireless (fast download / slow upload) lines
- Without IFP: an upload (video call sending, large file upload, cloud backup) fills the slow upload queue; upstream TCP ACKs for the download queue behind those upload packets; download throughput stalls; both download and upload latency inflate simultaneously
- With IFP: pure ACKs (≤64 B, no payload) are fast-pathed; they can never be delayed by upload bulk traffic; download performance is recovered; the upload continues unaffected
Page loads and connection setups
- DNS queries and TCP SYN packets are the first packets in any user action — they are classifiable at zero cost and protected
- Without IFP: a background download or streaming burst creates queue depth; a DNS query waits behind it; the next page load feels slow even though the speed test says the line is full
- With IFP: DNS and SYN take the protected lane; pages snap open instantly even on a busy line; the "snappiness" that subscribers use to judge service quality is preserved at peak
- This is the gut-feel "is my internet good?" test subscribers run constantly
7 · Zero-risk rollout — observe first, enforce when ready
IFP follows the same phased, observe-first rollout discipline as L4S. Each phase is independently verifiable on real traffic before the next step.
Classify and count — zero behaviour change
- Ships with ifp_mode=observe: classification and counting only
- See the real interactive-packet population on your live nodes: how many pure ACKs, DNS, SYN, small packets per second at peak
- Exactly how the production measurement (1.23 M / 40 s) was obtained — observe mode on a real node, zero risk
- Default OFF — opt-in per node, nothing changes until you enable it
Protected lane active — the subscriber-felt win
- Flip ifp_mode=enforce per node with one operator command
- ACK-prioritization, SYN/DNS/small exemption from policer delay and AQM mark/drop
- Instant on/off — reversible. Roll out node-by-node at your own pace
- Drop-protection counters now fire during peak congestion, confirming protection events
- Tunable via
bngxdpctl ifp set <key> <val>, same as AQM
Rate-aware sparse-flow protection + SLA view
- Tier 2 (native/split programs): per-flow pps detection protects interactive flows that don't match Tier 1 gates — generalises to unknown real-time apps
- Per-subscriber protection stats in
bngxdpctl sub show <ip>andbngxdpctl metrics - NOC view: fleet-wide "interactive flows protected" rollup — proof of engagement during peak
- Foundation for active latency measurement and subscriber-level latency SLA reporting
8 · Operator configuration — simple, safe defaults
Configuration knobs — all have sensible defaults, all are runtime-tunable
All IFP settings live in a separate, non-pinned ifp_config_map — the existing pinned struct layout is never disturbed. Runtime-tunable via bngxdpctl ifp set. Stored as xdp.* JSON, same pattern as aqm_*.
| Key | Default | What it does |
|---|---|---|
xdp.ifp_enabled |
false | Master switch. Default OFF — opt-in per node. |
xdp.ifp_mode |
"observe" | observe = classify and count only (zero behaviour change) · enforce = protected lane active |
xdp.ifp_protect_ack |
true | Fast-path pure TCP ACKs on the upload direction. The asymmetric-link ACK-starvation fix. |
xdp.ifp_protect_syn |
true | Protect TCP connection setup (SYN) packets. Direct page-load and session-join latency. |
xdp.ifp_protect_dns |
true | Protect DNS traffic (port 53 src/dst). Name resolution on the critical path of every user action. |
xdp.ifp_protect_small |
true | Protect small packets (≤ifp_small_bytes). Proxy for VoIP/RTP/gaming/control traffic. |
xdp.ifp_protect_dscp |
false | Honor DSCP EF / CS6–CS7 markings. Off by default — many access nets bleach DSCP. |
xdp.ifp_ack_max_bytes |
64 B | Maximum packet size to qualify as pure-ACK. 40–52 B is the real range; 64 B allows header options. |
xdp.ifp_small_bytes |
256 B | Packet-size threshold for the small-packet interactive gate. Tunable; bounded allowance contains false positives. |
xdp.ifp_priority_allowance_pct |
10% | Bounded per-subscriber priority token allowance. Caps the protected lane share — bulk cannot ride it to bypass shaping. |
xdp.ifp_priority_ports |
empty | Optional operator-supplied interactive port list (e.g. specific game/VoIP ports). Max 16 entries. |
· bng_qos_monolithic_native (native/airmax, most headroom): Tier 1 + Tier 2
· bng_download_qos + bng_upload_qos (split tail-call): Tier 1 + Tier 2
· bng_monolithic (full CGNAT+FW+QoS): Tier 1 only (
IFP_TIER2 0 — mirrors L4S AQM_P3 strategy on budget-tight programs)
The classification function is an
__always_inline leaf reading only existing scratch fields — no packet dereference, no new BPF stack arguments, no var_off masking. Budget impact is minimal across all program variants.9 · Cost effectiveness — same CapEx, new capability
| Approach | Hardware | Per-subscriber licence | Adds latency / hop? | Interactive-flow protection | ACK prioritization |
|---|---|---|---|---|---|
| Dedicated QoE / DPI appliance | New appliance per site | Typically yes | Yes — extra box in path | Varies; often per-app policy | Rarely included |
| BNGSOFT IFP | None — existing XDP BNG | None | No — same datapath | Built in · all subscribers | Built in · always on |
What it costs to add per-subscriber interactive flow protection
The comparison that matters for a large operator. (Lower is better.)
The bottom line
Speed is the pipe. Latency is how the pipe feels. L4S/AQM keeps the queue short. Interactive Flow Protection makes sure the gamer's packets, the Zoom audio, and the DNS lookup never wait behind the download that built that queue in the first place. Together they answer the question every residential subscriber asks every peak hour: "why does my internet lag when someone downloads?"
Production-validated on a live access node: 1.23 million interactive packets — 1.15 million pure TCP ACKs — classified and protected in a 40-second window (~30,000/sec). Queuing latency flat at ~0.6 ms, CPU at ~2%, zero subscriber impact. The classification runs continuously, the ACK-prioritization is always active, and the drop-protection insurance engages automatically when it is needed and does nothing when it is not.
Zero new hardware · zero per-subscriber licence · software-only on your existing XDP BNG fleet
Recommendation: enable OBSERVE mode on your first node today — see your real interactive-flow population and ACK volumes on real subscribers at zero risk — then roll out to enforce node-by-node with one command. It runs on the fleet you already operate, alongside the L4S/AQM capability it completes.