MVPS Detection-Latency Reconciliation: A Unified Onset-Phase Lemma for Multi-Vantage Coherence Profiles
draft-melegassi-ippm-mvps-latency-reconciliation-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Leonardo Melegassi Costa | ||
| Last updated | 2026-05-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-melegassi-ippm-mvps-latency-reconciliation-00
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/