




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/
