Network Working Group L. Melegassi Internet-Draft Catellix Intended status: Informational 28 May 2026 Expires: 29 November 2026 MVPS Detection-Latency Reconciliation: A Unified Onset-Phase Lemma for Multi-Vantage Coherence Profiles draft-melegassi-ippm-mvps-latency-reconciliation-00 Abstract Several Multi-Vantage Path Snapshot (MVPS) profiles state a detection-latency bound as a function of the detection multiplier M and the control-tick period T_tick. The bandwidth-efficient profile [I-D.melegassi-mvps-incremental-be] states it as M*T_tick; the Coherence-BFD [I-D.melegassi-coherence-bfd] and DDoS-Resilience [I-D.melegassi-mvps-ddos-resilience] profiles state it as (M-1)*T_tick. A reviewer reading two profiles in parallel observes a one-tick disagreement. This document shows the disagreement is not a mathematical error but an unstated difference in the ONSET-PHASE convention, and closes it with a single Unified Detection-Latency Lemma (L_DL): tau_detect(phi) = M*T_tick - phi + tau_RTT, phi in [0, T_tick) whose best case is (M-1)*T_tick + tau_RTT, worst case is M*T_tick + tau_RTT, and expected (uniform-phase) case is (M-1/2)*T_tick + tau_RTT. All three published statements are then correct simultaneously, as different points of one one-parameter family. The lemma is numerically validated to the millisecond against the published benchmark receipt by scripts/validate_detection_latency_lemma.py (PASS, max error 0 ms) and recorded in evidence/detection_latency_lemma_receipt.json. This document introduces no new wire format, requests no IANA action, and changes no MVPS v4.0 theorem; it is a clarifying lemma plus a recommended reporting convention. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 29 November 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The One-Tick Disagreement . . . . . . . . . . . . . . . . 3 1.2. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 4 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 3. Onset-Phase Model . . . . . . . . . . . . . . . . . . . . . . 5 4. The Unified Detection-Latency Lemma (L_DL) . . . . . . . . . 6 5. Reconciliation with the Profiles . . . . . . . . . . . . . . 7 6. Numerical Receipt . . . . . . . . . . . . . . . . . . . . . . 8 7. Recommended Reporting Convention . . . . . . . . . . . . . . 9 8. Relationship to MVPS v4.0 . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Mathematical Core (Normative) . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction 1.1. The One-Tick Disagreement The MVPS profiles share a common detection pipeline: a broker advances a global tick counter at a fixed period T_tick, each tick window yields one coherence observation, and an alarm fires after the M-th consecutive above-threshold observation. The latency from the anomaly onset to the moment a subscriber may act is the detection latency tau_detect. Three profiles state tau_detect differently: o [I-D.melegassi-mvps-incremental-be], Theorem 9: tau_detect >= max( M*T_tick, tau_RTT, tau_C4 ). o [I-D.melegassi-coherence-bfd], Section 12.1: detection latency 100 ms = (M-1)*T_tick = 2*50 ms. o [I-D.melegassi-mvps-ddos-resilience], Theorem D1: tau_detect = (M-1)*T_tick for all R >= R_sat. The first uses M*T_tick; the latter two use (M-1)*T_tick. A reviewer reading them in parallel sees a disagreement of exactly one tick. Each profile is internally consistent, but each assumes a different, unstated convention for WHERE in a tick window the anomaly onset falls. This document makes that convention explicit and binds all three statements to one lemma. 1.2. Scope and Non-Goals This document: o defines the onset-phase model (Section 3), o proves the Unified Detection-Latency Lemma L_DL (Section 4), o maps each profile's statement to a point of the L_DL family (Section 5), o reproduces the benchmark receipt (Section 6), and o recommends a single reporting convention (Section 7). This document does NOT introduce a wire format, does NOT request any IANA action, and does NOT alter any MVPS v4.0 theorem. It is a clarifying lemma and a reporting recommendation. 2. Terminology and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. T_tick: The fixed control-tick period of the broker (T_tick > 0). M: Detection multiplier: the number of consecutive above-threshold observations REQUIRED before an alarm fires (M >= 1). tau_RTT: One-way signalling latency from broker alarm to subscriber action (tau_RTT >= 0). Onset (t_0): The instant at which the coherence surface departs from baseline by an amount that exceeds the alarm threshold in any subsequent tick window. Onset need not coincide with a tick boundary. Onset phase (phi): phi = t_0 - floor(t_0 / T_tick) * T_tick, in [0, T_tick). 3. Onset-Phase Model The broker advances the tick counter at t_k = k*T_tick for k in {0, 1, 2, ...}. Let k_0 = floor(t_0 / T_tick) be the index of the tick window containing the onset, and phi = t_0 - k_0*T_tick the onset phase. Under the standard CLOSED-LEFT, OPEN-RIGHT window convention, a tick window [t_k, t_{k+1}) emits its observation at t_{k+1}; the FIRST CAPTURED TICK (the first window whose observation reflects the onset) therefore has index k_0 + 1. An alarm fires after the M-th consecutive above-threshold observation, i.e. at tick index k_0 + M, at the instant t_alarm = (k_0 + M)*T_tick. The subscriber may act at t_act = t_alarm + tau_RTT, and tau_detect = t_act - t_0. 4. The Unified Detection-Latency Lemma (L_DL) LEMMA L_DL (Unified Detection-Latency). Under the model of Section 3, for any fixed M >= 1, T_tick > 0, and tau_RTT >= 0, the detection latency is a function of the onset phase phi in [0, T_tick): tau_detect(phi) = M*T_tick - phi + tau_RTT. (1) Consequently: (a) BEST CASE (phi -> T_tick^-, onset just before a tick boundary): tau_min = (M - 1)*T_tick + tau_RTT. (2) (b) WORST CASE (phi = 0, onset exactly at a tick boundary): tau_max = M*T_tick + tau_RTT. (3) (c) EXPECTED CASE (phi ~ Uniform[0, T_tick)): tau_E = (M - 1/2)*T_tick + tau_RTT. (4) tau_min, tau_E, tau_max are all linear in M with identical slope T_tick. The spread tau_max - tau_min = T_tick is exactly one tick. PROOF. The alarm fires at t_alarm = (k_0 + M)*T_tick, so t_alarm - t_0 = (k_0 + M)*T_tick - (k_0*T_tick + phi) = M*T_tick - phi. Adding tau_RTT gives (1). Substituting phi -> T_tick^- gives (2); phi = 0 gives (3); integrating uniformly over [0, T_tick) gives (4). Linearity in M is immediate. QED. The full proof and traceability appear in [L-DL-PROOF]. 5. Reconciliation with the Profiles Each profile statement makes one of tau_min, tau_E, tau_max operational. Under L_DL all are correct simultaneously. +=====================================+================+===========+ | Statement (literal) | L_DL quantity | Role | +=====================================+================+===========+ | BE Thm 9: tau_detect >= M*T_tick | tau_max | worst | | | | case | +-------------------------------------+----------------+-----------+ | BFD 12.1: 100 ms = (M-1)*T_tick | tau_min | best case | | | (tau_RTT = 0) | | +-------------------------------------+----------------+-----------+ | DDoS D1: tau_detect = (M-1)*T_tick | tau_min | best case | | | (tau_RTT = 0) | (asymp. R)| +=====================================+================+===========+ COROLLARY 5.1 (BE Theorem 9 reformulated). tau_detect <= M*T_tick + tau_RTT. Equality is attained only at phi = 0; strict inequality holds on a phi-set of measure T_tick. COROLLARY 5.2 (BFD / DDoS Theorem D1 reformulated). tau_detect >= (M - 1)*T_tick + tau_RTT. Published p95 benchmark figures are upper percentiles and therefore approach tau_max, not tau_min. COROLLARY 5.3 (Expected case). E[tau_detect] = (M - 1/2)*T_tick + tau_RTT. This is the time-averaged latency under uniform onset phase, and is the single number that operator-facing documentation SHOULD cite. The "= R_sat" wording in the DDoS profile is asymptotic in attack rate R, not in M; the volume-independence claim is unchanged, since neither tau_min nor tau_max depends on R. 6. Numerical Receipt The lemma is checked against the synthetic benchmark of scripts/benchmark_coherence_bfd.py (N = 1000 vantages, tau_RTT = 5 ms) by scripts/validate_detection_latency_lemma.py. The machine-readable receipt is evidence/detection_latency_lemma_receipt.json (verdict PASS, maximum absolute error 0 ms). Every observed p95 equals tau_max (3) to the millisecond: +========================+=========+===+========+========+========+ | Variant | T_tick | M | tau_min| tau_max| p95 | | | (ms) | | (ms) | (ms) | obs(ms)| +========================+=========+===+========+========+========+ | V0 FMVPS-baseline | 60000 | 1 | 5 | 60005 | 60005 | | V1 BFD-heartbeat-fast | 50 | 3 | 105 | 155 | 155 | | V2 BFD-demand | 1000 | 1 | 5 | 1005 | 1005 | | V3 BFD-echo | 50 | 1 | 5 | 55 | 55 | | V4 BFD-hybrid | 50 | 3 | 105 | 155 | 155 | +========================+=========+===+========+========+========+ All five variants are explained by tau_max to the millisecond. 7. Recommended Reporting Convention To prevent the one-tick disagreement from recurring, MVPS profiles and operator-facing material SHOULD adopt the following convention: o When reporting a benchmark upper percentile (e.g. p95), cite tau_max = M*T_tick + tau_RTT (3). o When reporting a single representative latency, cite the expected value tau_E = (M - 1/2)*T_tick + tau_RTT (4). o When stating a best-case lower bound, cite tau_min = (M - 1)*T_tick + tau_RTT (2), and label it as the best case explicitly. Profiles citing a single formula without naming the case SHOULD be read as tau_max for safety (the worst-case bound). 8. Relationship to MVPS v4.0 L_DL imports only (i) the discrete-time tick-lattice model of standard sampled-data analysis [AstromWittenmark] and (ii) the additive-constant property of one-way signalling latency. It does NOT alter Theorems 1 through 9 of the MVPS v4.0 catalogue [MVPS-V4]; it refines the detection-latency inheritance of the BE, BFD, and DDoS profiles by making the previously implicit onset-phase assumption explicit. It is recorded as an auxiliary lemma in [MVPS-FOUNDATIONS]. 9. Security Considerations This document is a latency-accounting clarification and introduces no new protocol mechanism. It does not change the threat model of any profile. One operational note: when a detection-latency figure is used to dimension a reaction deadline (for example, a DDoS mitigation trigger), operators SHOULD dimension against tau_max (3) rather than tau_min (2), since onset phase is not controllable by the defender and the adversary may, in the worst case, induce onset at a tick boundary (phi = 0). 10. IANA Considerations This document has no IANA actions. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. 11.2. Informative References [MVPS-V4] Melegassi, L., "MVPS Mathematical Existence Proof -- Version 4.0", Catellix technical note, May 2026. [L-DL-PROOF] Melegassi, L., "MVPS Detection Latency -- Unified Lemma (L_DL)", Catellix technical note, May 2026. [MVPS-FOUNDATIONS] Melegassi, L., "MVPS IETF Foundations: Theorem Traceability Table", Catellix technical note, May 2026. [I-D.melegassi-mvps-incremental-be] Melegassi, L., "Bandwidth-Efficient Incremental MVPS", draft-melegassi-mvps-incremental-be-00, May 2026. [I-D.melegassi-coherence-bfd] Melegassi, L., "Coherence-BFD: Sub-Second Coherence Detection Using Bidirectional Forwarding Detection Patterns", draft-melegassi-coherence-bfd-00, May 2026. [I-D.melegassi-mvps-ddos-resilience] Melegassi, L., "Volume-Independent DDoS Detection via Coherence-BFD: The MVPS DDoS Resilience Profile", draft-melegassi-mvps-ddos-resilience-00, May 2026. [AstromWittenmark] Astrom, K. J. and B. Wittenmark, "Computer Controlled Systems: Theory and Design", 3rd ed., Prentice Hall, 1997. Appendix A. Mathematical Core (Normative) LEMMA L_DL. For M >= 1, T_tick > 0, tau_RTT >= 0, and onset phase phi in [0, T_tick): tau_detect(phi) = M*T_tick - phi + tau_RTT, tau_min = (M - 1)*T_tick + tau_RTT (phi -> T_tick^-), tau_max = M*T_tick + tau_RTT (phi = 0), tau_E = (M - 1/2)*T_tick + tau_RTT (phi uniform). Proof: Section 4. Constructive witness: scripts/validate_detection_latency_lemma.py reproduces the per-variant table of Section 6 with maximum absolute error 0 ms (receipt: evidence/detection_latency_lemma_receipt.json). NON-CLAIM. L_DL does not assert a tighter bound than tau_max for an adversary-chosen onset phase; phi = 0 is achievable in principle, so tau_max is the dimensioning quantity for security-sensitive deadlines. Author's Address Leonardo Melegassi Catellix Andradina, SP Brazil Email: melegassi@catellix.com URI: https://catellix.com/