nf_conntrack Table-Pressure & Implicit-Drop Slippage Playbook

Why this matters

In low-latency execution, teams usually track exchange throttles, app latency, and packet loss.

But many stacks still carry an invisible network-layer tax: stateful conntrack pressure on paths that should be deterministic.

When nf_conntrack gets stressed (or fills), new-flow packets can be dropped before normal packet handling, producing:

• transient ACK/fill visibility gaps,
• cancel/replace confirmation skew,
• false residual-risk estimates,
• bursty catch-up child-order behavior,
• tail implementation-shortfall inflation.

This often gets misdiagnosed as "random venue instability" while the root cause is local path state pressure.

Failure mechanism (kernel path -> execution)

1. Stateful tracking is enabled on strategy/gateway traffic.
2. Flow count and/or hash-chain pressure rises (nf_conntrack_count approaches nf_conntrack_max).
3. New-flow packets are dropped or delayed under pressure episodes.
4. App-side order-state timeline becomes causally distorted (late/clustered acks, stale pending state).
5. Router overreacts with urgency bursts and queue-priority-destructive retries.

Result: p95/p99 slippage rises even when median latency looks mostly fine.

Slippage decomposition with conntrack term

For parent order (i):

[ IS_i = C_{impact} + C_{timing} + C_{routing} + C_{ct} ]

Where:

[ C_{ct} = C_{drop-gap} + C_{state-skew} + C_{burst-recovery} ]

• (C_{drop-gap}): missing/delayed transport events from table-pressure drops
• (C_{state-skew}): incorrect pending/filled/canceled state freshness
• (C_{burst-recovery}): clustered catch-up dispatch after visibility recovery

Operational metrics (new)

1) CTR — Conntrack Utilization Ratio

[ CTR = \frac{\texttt{nf_conntrack_count}}{\texttt{nf_conntrack_max}} ] Primary stress gauge.

2) HCP95 — Hash-Chain Pressure p95

p95 lookup-chain length proxy (or equivalent per-host lookup cost telemetry).

3) NFD — New-Flow Drop Rate

Rate of packets/flows dropped during high-CTR windows (kernel log + firewall counters).

4) OSD — Order-State Drift

Difference between internal order-state age and reconstructed ground-truth progression age.

5) CDT — Conntrack Distortion Tax

Incremental IS during high-CTR/NFD windows vs matched low-pressure windows.

What to log in production

Kernel/netfilter layer

• net.netfilter.nf_conntrack_count
• net.netfilter.nf_conntrack_max
• net.netfilter.nf_conntrack_buckets
• kernel log events related to conntrack table pressure/drops
• per-host conntrack slab/memory pressure context

Transport/order-state layer

• ack/cancel/fill inter-arrival gap quantiles
• pending-state dwell time distribution
• state-transition burst metrics (events per short window)

Execution outcomes

• passive fill ratio in low vs high CTR regimes
• cancel/replace frequency around pressure episodes
• short-horizon markout conditioned on pressure state
• tail IS uplift (CDT)

Identification strategy (causal, not anecdotal)

1. Match windows by spread, realized vol, participation, and time-of-day.
2. Split windows into low vs high CTR/NFD regimes.
3. Estimate incremental tail IS with host fixed effects.
4. Validate via canary controls:
   • conntrack bypass for trusted deterministic paths (where policy allows), or
   • increased conntrack capacity + timeout hygiene.
5. Confirm that CDT drops while market covariates remain matched.

If yes, the uplift is infra-causal (conntrack-path), not merely market-regime noise.

Regime state machine

CT_HEALTHY

• low CTR, no pressure logs
• normal execution controls

CT_TIGHTENING

• rising CTR/HCP95, early state-skew signals
• pre-emptive pacing and retry restraint

CT_PRESSURED

• sustained high CTR and/or observable new-flow drops
• strict burst damping, conservative urgency

CT_SAFE_CONTAIN

• repeated pressure episodes with slippage-tail breach
• route to clean path class, cap aggression, prioritize control stability

Use hysteresis + minimum dwell times to avoid flapping.

Control ladder

1. Scope conntrack intentionally
   • avoid tracking traffic classes that do not require stateful firewall semantics (subject to security policy)
2. Right-size buckets/max together
   • increasing nf_conntrack_max without healthy hash geometry can move pressure, not remove it
3. Timeout hygiene by protocol profile
   • reduce stale-entry residency for your actual traffic mix
4. Isolate noisy traffic domains
   • prevent unrelated connection churn from consuming execution-path headroom
5. Model pressure features directly
   • include CTR/NFD/OSD signals in slippage mean + tail heads
6. Fail-safe execution behavior
   • when CT_PRESSURED, enforce anti-burst guards and tighten retry budgets

Failure drills (must run)

1. Table-pressure replay drill
   • synthetic flow surge to verify detection + state transitions
2. Bypass canary drill
   • policy-compliant conntrack bypass test on a small host pool
3. Capacity-step drill
   • controlled bucket/max adjustments and CDT response measurement
4. Rollback drill
   • deterministic revert path for netfilter parameter changes

Common mistakes

• Treating conntrack as "just security plumbing" with no latency-tail impact
• Watching only median latency while state-skew tails explode
• Raising nf_conntrack_max alone without hash/timeout discipline
• Blaming venue microstructure before host-path pressure attribution

Bottom line

Conntrack pressure can silently distort order-state time and create avoidable slippage tails.

If execution infrastructure is stateful by default, conntrack health must be a first-class feature in both observability and slippage control.

References

• Linux kernel documentation: Netfilter conntrack sysctls (nf_conntrack_count, nf_conntrack_max, nf_conntrack_buckets, defaults and semantics)
  • https://docs.kernel.org/networking/nf_conntrack-sysctl.html
• Cloudflare engineering write-up: conntrack behavior under table fill and packet-path placement context
  • https://blog.cloudflare.com/conntrack-tales-one-thousand-and-one-flows/
• conntrack-tools user manual (operational state tracking context)
  • https://conntrack-tools.netfilter.org/manual.html