A connection that stays fast under load — and gaming that just works behind CGNAT

Subscribers don't experience your speed test; they experience the video call that stutters when someone starts a download, and the console that says “Strict NAT” and won't party-chat. BNGSOFT tackles both in the data plane: a per-subscriber responsiveness-under-load score — latency measured while the link is busy, the honest “feels-fast” number — with a feedback loop that actively suppresses bufferbloat; and Open NAT — PCP/NAT-PMP so CGNAT subscribers get the inbound ports gaming and P2P need, every one logged to your collector for clean attribution. No probes. No per-subscriber config.

Working latency

not idle ping

latency measured while the link is actually busy — what users feel

Feedback loop

self-suppressing bufferbloat

bad working-latency nudges the AQM to mark harder, within bounds

Open NAT

PCP / NAT-PMP

CGNAT subs request inbound ports — gaming & P2P just work

Fully logged

allocate = release

every PCP port → your IPFIX collector, attribution intact

Idle ping is a number for marketing slides. Working latency — how snappy the line stays when it's carrying real traffic — is the number a subscriber actually lives with.

1 · Responsiveness under load — the honest “feels fast” metric measuring

A line can show 10 ms idle and 300 ms the moment it gets busy — that's bufferbloat, and it's why a connection “feels slow” even when the speed test looks great. BNGSOFT measures the number that matters: per-subscriber latency under load.

Measured passively, from the data plane

The BNG's per-subscriber AQM already tracks queuing delay. We sample it only when the subscriber is loaded (their traffic is hitting the shaper) and compare it to their idle baseline — the inflation is the bufferbloat, with no probes and no client app.

One number that means “snappy”

A 0–100 responsiveness score (and an RPM-style figure) per subscriber, plus a fleet view — report “X% of subscribers stay responsive under load,” a claim that actually correlates with how the network feels.

A loop that fixes it, not just reports it

When a subscriber's working latency drifts into the bad band, the score feeds back into the L4S/dual-queue AQM controller to mark more aggressively for that flow — bounded by the controller's own limits so it tightens latency without destabilizing throughput.

Latency a subscriber actually feels (illustrative)

Idle ping looks great on every line. Working latency — under load — is where bufferbloat hides, and where the feedback loop acts.

Measure latency under load → score it → bias the AQM (bounded) → bufferbloat falls. Off by default until the numbers earn trust.

Why this beats a dashboard of idle pings. It catches the exact failure subscribers complain about — “it's fine until someone in the house starts a big download” — and the same signal that detects it also drives the AQM that cures it. Off by default; turn the feedback on when the measurements earn your trust.

2 · Open NAT — gaming and P2P that work behind CGNAT live, default-on

CGNAT is the #1 source of “Strict NAT” on consoles, broken party chat, dead P2P, and self-hosting that won't. BNGSOFT Open NAT implements PCP (RFC 6887) and NAT-PMP (RFC 6886) on the CGNAT itself: the subscriber's router asks for an inbound mapping, the CGNAT grants it, and the inbound path opens.

# the CPE asks the CGNAT for an inbound mapping; the CGNAT answers with the public port console → CPE → PCP / NAT-PMP → BNGSOFT CGNAT ← public_ip : port granted (within the subscriber's own port block) # result: "Open NAT" — party chat, matchmaking, P2P, self-host all work

Allocated inside the subscriber's own block

The pinned inbound port comes from the subscriber's existing CGNAT port block (or a new block, logged) — never a stray out-of-range port. Deterministic CGNAT and clean attribution stay intact.

Quota'd and bounded

A per-subscriber mapping quota stops any one user exhausting the public-port pool; mappings carry a lifetime and are reclaimed on expiry or disconnect.

Every port logged — for real

Each mapping create and release is exported to your IPFIX collector and syslog through the same pipeline as normal CGNAT, so lawful-intercept / abuse attribution covers PCP ports too.

The CPE requests an inbound port via PCP/NAT-PMP; the CGNAT grants one from the subscriber's own block and logs the create/release to the operator's collector.

Pinned inside the subscriber's own CGNAT port block — never a stray port

PCP pins a specific port (e.g. 1100) from the subscriber's existing block — so attribution and deterministic CGNAT stay intact, no out-of-range allocation.

The compliance bit, done right. Open NAT does not get its own port-accounting. It rides the existing CGNAT allocate/release logging, adding explicit PCP_MAP_CREATE/PCP_MAP_DELETE records — with an allocate == release invariant so a missing release is a detectable bug, not a silent untracked port. “Who held public port X at time T?” resolves for PCP-mapped ports exactly as it does for ordinary CGNAT.

Part of the BNGSOFT subscriber-intelligence suite

Flow Intelligence

Measure

Passive per-flow loss + access/transit RTT in XDP — no probes.

Autonomous QoE + Responsiveness

Decide & feel

Each sub's own normal; anomaly + working-latency that drives the AQM.

CGNAT + Open NAT

Scale & unblock

Memory that tracks real sessions; PCP/NAT-PMP for gamers.

The honest state of play

Open NAT (PCP/NAT-PMP) is shipping — implemented on the CGNAT with within-block allocation and full allocate/release logging, and enabled by default (one config flag disables it per node). Responsiveness-under-load is measured today; the AQM feedback loop is bounded and ships off-by-default so you can watch the numbers before you let it act.

What we'd tell you straight: these are newly shipped capabilities, validated on our test platform and rolling toward production behind config flags — not decade-old features. We'd rather show you them running on a node with live traffic than quote a number we haven't earned.

Want to see it? We'll walk you through working latency on real subscribers and an Open-NAT mapping opening end-to-end — with the matching allocate/release record landing in your collector.

Sources & honest framing: This is an engineering brief, not a benchmark report, and no performance, throughput, latency, or session figures are claimed. Responsiveness-under-load derives a per-subscriber “working latency” from the existing per-subscriber AQM queuing-delay measurement, sampled under load (gated by the subscriber's shaper activity) against an idle baseline, surfaced as a 0–100 score / RPM figure and a fleet aggregate; the optional AQM feedback biases the L4S/dual-queue PI controller within its existing clamps and ships off by default. Open NAT implements PCP (RFC 6887: MAP/PEER) and NAT-PMP (RFC 6886) on the CGNAT, allocating the pinned inbound port from the subscriber's own port block via the existing bitmap allocator, with a per-subscriber mapping quota and lifetime, and exporting create/release events through the existing IPFIX/syslog pipeline (with an allocate==release accounting invariant); IPv6-PCP is planned. These are newly shipped capabilities under active validation. Related per-topic briefs — Flow Intelligence, Autonomous QoE, CGNAT Arena Engine, L4S/AQM — are available alongside this guide.