BE-MVPS — Bandwidth-Efficient Incremental MVPS
Cell-Partitioned Coherence with Bandwidth-vs-CPU Pareto Trade-off

1. Introduction

The Multi-Vantage Path Synchrony framework models a distributed observability surface as a triple per vantage \(v\):

The aggregate state is the Mahalanobis distance:

where \(\mu(t)\) is the empirical centroid of \(\{x_v(t)\}\). The reference implementation recomputes \(\mu(t)\), \(C_2\) (JSD proxy), and \(D^2\) over the full \(N\)-sized population at every tick. The cost per tick is

For \(N = 10^4\) vantages with \(d = 6\) axes and 1-second ticks, that is 480 KB/s/observer. The CPU is tractable; the network is not. FMVPS exploits the fact that BAU information content per vantage is by construction near zero.

3. Information redundancy of dense MVPS

4. Cell-partitioned coherence

5. Edge delta gating

6. Lazy Mahalanobis via Sherman-Morrison-Woodbury

7. CRDT coherence merge

8. Cell-aware Byzantine detection

9. C₄ perturbation lower bound

10. The FMVPS algorithm

FMVPS-update(X(t)):

  1. for each vantage v in parallel:
       if ||x_v(t) - x_v^last||_2 > epsilon:
         transmit (v, x_v(t)) to its cell coordinator
         x_v^last := x_v(t)

  2. for each cell c in parallel:
       if cell c received at least one push:
         mu_c := alpha * mu_c + (1 - alpha) * mean(pushed values)

  3. at the broker (only if any cell pushed):
       delta_mu := (1/k) sum_c (mu_c - mu_c^prev)
       D^2 := D^2 + 2 * (mu^prev - mu_0)^T Sigma_0^{-1} delta_mu
                  + delta_mu^T Sigma_0^{-1} delta_mu
       mu^prev := mu^prev + delta_mu

  4. cell-minimax (Byzantine detector):
       worst_c := argmin_c D^2_minimax(c)
       if (D^2 - D^2_minimax(worst_c)) / D^2 > theta_byz
          and D^2 > chi^2_{d,0.95}:
         emit Byzantine alarm on cell worst_c

  5. C_4 perturbation (every perturbation_period ticks):
       run perturbation on one random vantage
       update C_4 estimator (EWMA)

  6. emit:
       Phi_K(D^2) in {BAU, WATCH, ALARM}
       C_4 status
       any cell-Byzantine alarms

11. Numerical results

Wall-clock benchmark over 6 scenarios, N=1000 vantages, T=200 ticks:

Bandwidth and memory footprint:

Scaling N from 100 to 10 000

Other benchmark figures

12. Operational architecture

Layer 0 (Edge agent, per vantage):
  - Evaluates gating, stores x_v^last, emits push on threshold cross
  - Cost: O(d) per tick, O(d) memory
  - Deployable in switch ASIC via P4_16

Layer 1 (Cell coordinator, one per cell):
  - Aggregates gated pushes via CRDT merge
  - Cost: O(d) per push, O(d) memory
  - Containerised at PoP scale

Layer 2 (Broker, one per surface):
  - Maintains mu, D^2, runs cell-minimax
  - Cost: O(k·d + d²) per tick
  - One broker handles ~10^6 vantages at 1-tick/s precision

Layer 3 (Forensic engine, on-demand):
  - Full geometric median, R_cross, drift transfer function
  - Triggered only on phase escalation
  - Amortised cost < 1% of broker

13. Coherence-BFD — sub-tick detection (new)

The FMVPS framework operates on the tick scale (60 s default), which is appropriate for path coherence but unsuitable for sub-second failover. This section introduces five execution variants inspired by BFD (RFC 5880) and reports real wall-clock benchmark results — not estimates.

13.1 Five variants benchmarked

• V0 FMVPS-baseline — T_tick = 60 s, M = 1, push-gated (current default)
• V1 BFD-heartbeat-fast — T_tick = 50 ms, M = 3, push + continuous heartbeat
• V2 BFD-demand — T_tick = 1 s, M = 1, broker poll on suspicion (D² > 0.7·threshold)
• V3 BFD-echo — T_tick = 50 ms, M = 1, echo packet every other tick
• V4 BFD-hybrid — T_tick = 50 ms, M = 3, push + echo + demand

13.2 Measured detection latency (50 trials per variant, N=1000)

13.3 Variant selection guidance

Reproducibility: python scripts/benchmark_coherence_bfd.py. All trials deterministic under fixed seed. Numbers above are measured, not estimated.

The full protocol specification (TLVs, state machine, IANA considerations, security analysis) is in the standalone companion draft: draft-melegassi-coherence-bfd-00.

14. Packet sizing, MTU, and OS network tuning

A protocol that doesn't fit in an MTU, or that ignores how the host kernel handles 2 million packets per second, fails operationally regardless of how elegant its math is. This section answers three questions auditors ask immediately: does it fragment? does it saturate the broker's NIC? does it require kernel bypass?

14.1 Packet size budget (computed byte-by-byte, IPv4)

All Coherence-BFD packets are computed below from their formal binary layout (see §15.1 of draft-melegassi-coherence-bfd-00). All fit comfortably in standard Ethernet MTU 1500.

Implementations MUST set IP DF=1. Path-MTU black-hole drops (RFC 4821) would otherwise manifest as silent vantage timeouts, which the M-multiplier interprets as ALARM transitions — turning a routing problem into a false coherence alarm.

Note on the IPPM bundle envelope: The original draft-melegassi-ippm-mvps-bundle-00 carries full path snapshots; for paths of N ≥ 30 hops with rich ICMP + TTL + timestamp metadata, typical snapshots exceed 1500 octets. Bundles are exchanged out-of-band over TCP or chunked control channels — they are not carried over Coherence-BFD. This will be tightened in a future bundle revision (-01).

14.2 PPS regimes and OS tuning thresholds

Broker inbound packets per second:

\[ \mathrm{PPS} \;=\; \frac{N}{T_{\mathrm{tick}}} \]

The Linux network stack has four well-known performance regimes. Failure to tune for the target regime causes IRQ storm, RX queue overflow, and silent drops — pathologies that this protocol amplifies because the M-multiplier confuses them with anomaly.

14.3 Operational examples (real deployments)

14.4 Minimum recommended Linux settings (Regime B/C)

# NIC ring buffers
ethtool -G <iface> rx 4096 tx 4096

# RX coalescing (Regime B adaptive; Regime C manual)
ethtool -C <iface> adaptive-rx on  rx-usecs 50 rx-frames 64  # B
ethtool -C <iface> adaptive-rx off rx-usecs 10 rx-frames 16  # C

# RSS hash on UDP src port (spread vantages across queues)
ethtool -N <iface> rx-flow-hash udp4 sdfn

# Kernel UDP path
sysctl -w net.core.rmem_max=268435456
sysctl -w net.core.netdev_max_backlog=300000
sysctl -w net.core.netdev_budget=600

# Regime C: pin IRQs manually
systemctl stop irqbalance && systemctl mask irqbalance
echo <core_mask> > /proc/irq/<irq_n>/smp_affinity

# Replace pfifo_fast with fq_codel (lower egress latency)
tc qdisc replace dev <iface> root fq_codel

# Broker socket (Regime C): enable busy polling
# setsockopt(sk, SOL_SOCKET, SO_BUSY_POLL, &usec=50, sizeof usec);

# NUMA + isolation for the broker (Regime C/D)
# kernel cmdline: isolcpus=2-7 nohz_full=2-7 rcu_nocbs=2-7
taskset -c 2 ./mvps_broker

Full prescriptive text and IPv6/Jumbo variants in draft-melegassi-coherence-bfd-00 §15.

14.5 Honest limits — when the framework alone is insufficient

MVPS / FMVPS / Coherence-BFD observe effects on the coherence surface — they do not configure MTU, IRQ affinity, or queueing disciplines. They tell you something deformed the surface; root-cause attribution requires standard low-level tools (perf, ethtool -S, tracepoint:irq, tcpdump). The contribution is to make those tools fire before the user-visible failure.

15. DDoS resilience — detector, not victim

The most common operational fear is: if a 10 Mpps volumetric DDoS hits the infrastructure I'm monitoring, does MVPS die with it? The answer requires distinguishing two things that are easy to conflate:

Vantages are probes, not middleboxes. They observe the data plane (sampling latency, jitter, loss of user traffic), but the attack packets never reach the broker's NIC if the deployment respects three invariants documented in §12.1 of the Coherence-BFD draft:

1. I1. Vantages + broker on a separate control plane (dedicated NIC / out-of-band).
2. I2. Vantages observe user traffic, do not forward it.
3. I3. Broker NIC sized for telemetry PPS only (independent of attack volume).

15.1 Empirical proof — 10 Mpps DDoS simulation

Question answered with numbers, not narrative:

Measured outcomes:

15.2 Honest failure modes — when MVPS would be at risk

Conclusion of §15. Under correct deployment (out-of-band control plane, Regime-C-tuned broker, k ≥ 7 cells), MVPS does not die under DDoS — it is the fastest path to knowing the DDoS is happening, where it is hitting, and which regions remain healthy. Detection latency in this 10 Mpps scenario was 100 ms vs. typical alert-pipeline detection of 30–120 s.

Reproducibility: python scripts/simulate_ddos_resilience.py. Raw numerical results: SIM_DDOS_RESULTS.txt. Specification reference: §12.1 and §12.2 of draft-melegassi-coherence-bfd-00.

16. Extreme-scale stress test — 10 Mpps to 5 Tbps

The §15 result (100 ms detection of 10 Mpps) is the corporate-scale baseline. Real-world records as of 2025 are 100× to 500× larger:

This section answers the next obvious question: does MVPS hold up at 1 Gpps? At 5 Tbps? Where does it actually break?

16.1 Single-region scaling (10 Mpps → 2 Gpps)

D² peak is constant within 0.3% across two orders of magnitude in attack rate. This is Theorem D1 (Volume-Independence): detection latency is determined by (M−1)·T_tick alone, not by attack volume.

16.2 Tbps-equivalent attacks

16.3 Distributed multi-region attacks — where the limit actually lives

The MISS at 3 regions is fascinating and exposes the dual nature of cell-aware minimax: it is so good at filtering out Byzantine cells that a coordinated attack at exactly the Byzantine bound becomes invisible to the data-plane alarm. The fix is the dual-mode aggregation (§7.2 of the DDoS draft):

16.4 Negative control — deployment defect (I1 violated)

To prove this is an architecture property and not magic, we explicitly violate invariant I1 (broker NIC shared with data plane) under a 1 Gpps attack:

* The few telemetry packets that survive the broker's queue still carry a strong D² signal, so the detection latency on the surviving stream is 100 ms — but the broker process is unable to serve subscribers, so the alarm never reaches its consumers. Deployment defect, not protocol defect.

16.5 Breaking-point summary

Verdict. Across 11 scenarios spanning 5 orders of magnitude in attack rate (10 Mpps → 5 Tbps equivalent), Coherence-BFD detects every correctly-deployed scenario in exactly 100 ms = (M−1)·T_tick, the theoretical lower bound. The framework does NOT scale with attack volume — it scales with the number of geographically distinct simultaneous attack sources, bounded by Byzantine breakdown.

Reproducibility: python scripts/simulate_ddos_extreme.py. Raw results: SIM_DDOS_EXTREME_RESULTS.txt. Formal specification with proofs: draft-melegassi-mvps-ddos-resilience-00 (Theorems D1, D2, D3).

Companion documents

↓ Download full draft (plain ASCII, ~20 pages)