Considerations for Interpreting IP Performance Measurement Results
draft-liu-ippm-measurement-interpretation-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 | Libin Liu | ||
| Last updated | 2026-10-24 | ||
| Replaces | draft-liu-ippm-active-loss-considerations | ||
| 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-liu-ippm-measurement-interpretation-00
IPPM L. Liu
Internet-Draft Zhongguancun Laboratory
Intended status: Informational 24 October 2026
Expires: 27 April 2027
Considerations for Interpreting IP Performance Measurement Results
draft-liu-ippm-measurement-interpretation-00
Abstract
IP Performance Measurement (IPPM) metrics characterize properties
such as connectivity, packet loss, delay, delay variation, packet
reordering, packet duplication, and capacity. A result can be
correct for the metric and measurement method used while still being
insufficient to explain the network condition that produced it or to
describe traffic outside the measured scope.
This document provides guidance for interpreting IPPM measurement
results. It considers the metric definition and parameters, the
measured packet or traffic population, the observation scope, and the
measurement method. It also discusses metric-specific considerations
and differences among active, passive, and hybrid measurements.
Operational information can support an interpretation, but this
document keeps it separate from the metric result itself.
This document does not define new metrics or measurement protocols,
and it does not specify a mechanism for determining a unique
operational cause.
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 27 April 2027.
Liu Expires 27 April 2027 [Page 1]
Internet-Draft Measurement Interpretation October 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. General Problem Statement . . . . . . . . . . . . . . . . . . 8
3.1. Metric Result and Operational Explanation . . . . . . . . 8
3.2. Metric Definition and Parameters . . . . . . . . . . . . 8
3.3. Similar Results from Different Operational Conditions . . 8
3.4. Visibility and Observation Scope . . . . . . . . . . . . 9
3.5. End-to-End and Hop-by-Hop Measurement Scope . . . . . . . 9
3.6. Flow-, Path-, Direction-, and Time-dependent Results . . 9
3.7. Sample Population and Representativeness . . . . . . . . 10
3.8. Limits of Cause Attribution . . . . . . . . . . . . . . . 10
4. Operational Conditions Affecting Measurement Results . . . . 10
4.1. Congestion and Queue Behavior . . . . . . . . . . . . . . 10
4.2. Link, Forwarding, and Routing Conditions . . . . . . . . 11
4.3. Endpoint and Measurement-System Behavior . . . . . . . . 11
4.4. Encryption and Limited On-Path Visibility . . . . . . . . 11
4.5. Policy, Filtering, Policing, and Traffic Treatment . . . 12
4.6. Validation-related Discard . . . . . . . . . . . . . . . 12
4.7. Multipath and Load-balancing Effects . . . . . . . . . . 12
4.8. Transient Conditions and State Changes . . . . . . . . . 13
5. General Considerations for Result Interpretation . . . . . . 13
5.1. Start with the Metric Definition and Parameters . . . . . 13
5.2. Identify the Method of Measurement . . . . . . . . . . . 13
5.3. Separate Metric Results from Inferred Causes . . . . . . 14
5.4. Consider Multiple Metrics Together . . . . . . . . . . . 14
5.5. Consider Measurements Across Protocol Layers . . . . . . 14
5.6. Relate Network Measurements to Application Performance . 15
5.7. Consider Direction, Observation Scope, and Measurement
Role . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.8. Consider Flow and Path Selection . . . . . . . . . . . . 15
5.9. Consider Timing and State Changes . . . . . . . . . . . . 16
5.10. Consider the Observed Sample Population . . . . . . . . . 16
Liu Expires 27 April 2027 [Page 2]
Internet-Draft Measurement Interpretation October 2026
5.11. Consider Measurement Representativeness . . . . . . . . . 16
5.12. Treat Correlation as Supporting Evidence, Not Proof . . . 16
5.13. Report Uncertainty . . . . . . . . . . . . . . . . . . . 17
6. Metric-Specific Interpretation Considerations . . . . . . . . 17
6.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 17
6.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. Delay . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.4. Delay Variation . . . . . . . . . . . . . . . . . . . . . 19
6.5. Packet Reordering . . . . . . . . . . . . . . . . . . . . 19
6.6. Packet Duplication . . . . . . . . . . . . . . . . . . . 20
6.7. Capacity-related Metrics . . . . . . . . . . . . . . . . 21
6.8. End-to-End and Hop-by-Hop Interpretation . . . . . . . . 21
6.9. Cross-Metric Interpretation . . . . . . . . . . . . . . . 22
7. Considerations for Active Performance Measurements . . . . . 22
7.1. Active Measurement Stream and Representativeness . . . . 23
7.2. Measurement-induced Effects . . . . . . . . . . . . . . . 23
7.3. One-way Active Measurements . . . . . . . . . . . . . . . 23
7.4. Two-way and Reflected Active Measurements . . . . . . . . 24
7.5. OWAMP, TWAMP, and STAMP . . . . . . . . . . . . . . . . . 24
7.6. Active Measurement over Multipath . . . . . . . . . . . . 25
7.7. Controlled Active Measurements . . . . . . . . . . . . . 25
8. Considerations for Passive Performance Measurements . . . . . 25
8.1. Observation Scope and Stream Selection . . . . . . . . . 26
8.2. Packet Correspondence Across Observation Points . . . . . 26
8.3. Traffic Availability and A Priori Stream Knowledge . . . 27
8.4. Sampling, Aggregation, Export, and Collection Effects . . 27
8.5. Selection Effects and Observed Population . . . . . . . . 27
8.6. Passive Measurement-System State . . . . . . . . . . . . 28
9. Considerations for Hybrid Performance Measurements . . . . . 28
9.1. Identify the Hybrid Construction . . . . . . . . . . . . 28
9.2. Combining Active Measurements with On-Path Hybrid
Techniques . . . . . . . . . . . . . . . . . . . . . . . 29
9.3. Measurement Marking, Augmentation, and Treatment
Equivalence . . . . . . . . . . . . . . . . . . . . . . . 29
9.4. Partial Controllability and Traffic Availability . . . . 30
9.5. Consistency of Measurement State Across Observation
Points . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.6. Coordinated Streams and Hybrid Type II Interpretation . . 30
9.7. Production Traffic Representativeness . . . . . . . . . . 31
9.8. Sampling, Aggregation, and Collection Effects . . . . . . 31
10. Interpretation Context and Supporting Evidence . . . . . . . 31
10.1. Measurement Metadata and Intended Use . . . . . . . . . 31
10.2. Path, Routing, and Forwarding Context . . . . . . . . . 32
10.3. Resource and Traffic-Treatment Context . . . . . . . . . 32
10.4. Measurement-System Context . . . . . . . . . . . . . . . 32
10.5. OAM, Telemetry, and Event Context . . . . . . . . . . . 33
10.6. Operator- and Controller-Provided Context . . . . . . . 33
11. Applying the Interpretation Framework . . . . . . . . . . . . 33
Liu Expires 27 April 2027 [Page 3]
Internet-Draft Measurement Interpretation October 2026
11.1. Define the Intended Use and Required Scope . . . . . . . 34
11.2. Align Scope and Time Before Correlation . . . . . . . . 34
11.3. Compare Like Measurement Results Before Combining
Them . . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.4. Use Complementary Measurements to Reduce Ambiguity . . . 34
11.5. Treat Follow-up Measurements as Tests of a Hypothesis . 35
11.6. Account for Measurement-Method Effects . . . . . . . . . 35
11.7. Interpretation Across Administrative Boundaries . . . . 35
11.8. Report Result, Evidence, Inference, and Uncertainty
Separately . . . . . . . . . . . . . . . . . . . . . . . 36
12. Security Considerations . . . . . . . . . . . . . . . . . . . 36
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
15. Informative References . . . . . . . . . . . . . . . . . . . 37
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction
The IP Performance Measurement (IPPM) framework defines metrics and
measurement methods for characterizing packet delivery and network
performance. Examples include connectivity [RFC2678], one-way and
round-trip delay [RFC7679] [RFC2681], packet loss [RFC7680], delay
variation [RFC3393], packet reordering [RFC4737], packet duplication
[RFC5560], and capacity-related metrics [RFC5136] [RFC9097].
[RFC8911] defines the Performance Metrics Registry, which records
metric definitions, parameters, methods of measurement, outputs, and
related information. This document focuses on packet-transfer and
network-performance metrics in the IPPM context.
The metric, its parameters, and the measurement method define the
scope of a metric result. That result does not identify the
condition that produced it. For example, a delay value does not
separate propagation, transmission, queueing, processing, and
timestamping effects. A packet loss result does not identify whether
or where the packet was discarded, or why the destination did not
receive it within the specified waiting time. Reordering identifies
an ordering property of the measured stream, not the mechanism that
caused it. Capacity results depend on the metric definition, offered
load, packet characteristics, qualification criteria, and network
state.
Liu Expires 27 April 2027 [Page 4]
Internet-Draft Measurement Interpretation October 2026
The distinction matters when operators generalize a measurement
result or use it to support an operational explanation. The metric
result states the measured fact. Statements about congestion,
routing or forwarding changes, filtering, endpoint behavior, or other
causes require additional evidence. A valid result can also be
unrepresentative of traffic outside the measured population, path,
direction, or time interval.
Metric parameters shape the interpretation. [RFC8911] requires the
parameters needed to perform and interpret a measurement to be known,
and notes that runtime parameters can affect the measured property.
Results in the same broad metric family may not support comparison
when their parameters or measurement conditions differ.
The measurement method is a separate consideration. [RFC7799]
classifies measurement methods as Active, Passive, or Hybrid. Active
methods use dedicated measurement traffic. Passive methods observe
existing traffic. Hybrid methods combine active and passive
characteristics. These methods differ in traffic control,
observation scope, representativeness, and measurement-system
effects, so the same metric may require different interpretation
depending on the method that produced it.
This document uses three parts of the measurement context when
interpreting a result:
* the metric definition and parameters, which define the measured
property;
* the measurement method and observation scope, which define how the
measurement forms the measured population; and
* supporting evidence, when an operator uses the result to justify a
broader or causal conclusion.
The general and metric-specific considerations address the first
part. The sections on active, passive, and hybrid measurement
address the second. The discussion of interpretation context and
supporting evidence addresses the third. These parts are
complementary. The document does not assume that every IPPM metric
applies to every measurement-method category.
Liu Expires 27 April 2027 [Page 5]
Internet-Draft Measurement Interpretation October 2026
This document limits its scope to interpretation of measurement
results. The document does not redefine existing metrics, change
their semantics, specify a general troubleshooting procedure, or
define a mechanism for determining a unique operational cause.
[RFC6703] discusses how the intended use of IP performance
measurements affects measurement design and reporting; this document
complements that work by focusing on what conclusions a reported
result can support.
Section 2 defines terminology. Section 3 describes the general
interpretation problem. Section 4 summarizes operational conditions
that can affect measurement results. Section 5 gives common
interpretation considerations, and Section 6 discusses representative
metric families. Section 7, Section 8, and Section 9 cover method-
specific considerations. Section 10 describes supporting context,
and Section 11 discusses how to apply the framework when comparing,
correlating, or generalizing results. Section 12 and Section 13
discuss security and privacy considerations.
2. Terminology
This document uses the terms Active Performance Measurement, Passive
Performance Measurement, and Hybrid Performance Measurement
consistently with [RFC7799]. It also uses Performance Metric and the
distinction between fixed and runtime parameters consistently with
[RFC8911].
The term Operations, Administration, and Maintenance (OAM) follows
[RFC6291]. This document follows the OAM characterization guidelines
in [RFC10014].
Where terms are already defined by existing IPPM documents or
measurement protocols, this document uses those terms consistently
with their existing definitions.
Performance Metric: A quantitative measure of performance targeted
to an IETF-specified protocol or to an application transported
over an IETF-specified protocol, consistent with [RFC8911]. In
this document, the discussion focuses on IPPM metrics that
characterize packet-transfer or network-performance properties.
Method of Measurement: The procedure or set of operations used to
determine a measured value or measurement result. This document
uses the Active, Passive, and Hybrid classifications described in
[RFC7799].
Metric Result: A value, classification, sample, statistic, or other
Liu Expires 27 April 2027 [Page 6]
Internet-Draft Measurement Interpretation October 2026
output produced by applying a defined performance metric and
method of measurement with specified parameters. Examples include
a connectivity result, a packet loss ratio, a one-way delay
sample, a delay variation statistic, a reordered-packet ratio, a
duplication result, or a capacity value.
Metric Parameters: Fixed and runtime parameters that define or
configure a metric and its measurement method. Parameter values
can affect the measured packet or traffic population, the network
property under assessment, and the interpretation of the resulting
value [RFC8911].
Interpretation Context: Information needed to understand what
conclusions a metric result can support. Interpretation context
can include the metric definition, metric parameters, packet or
traffic population, measurement interval, observation scope,
measurement method, path information, and relevant network or
measurement-system state.
Observation Point: A location where a measurement function observes,
counts, timestamps, samples, collects, or otherwise processes
packets or measurement information. An endpoint, network device,
interface, or another measurement function can host an observation
point.
Measurement Flow: A set of packets that share header fields or other
properties relevant to forwarding, load balancing, filtering,
policing, observation, or measurement processing. Different
measurement flows can experience different paths or treatment.
Measurement Representativeness: The extent to which the packets,
traffic, paths, time periods, and observation points in a
measurement represent the traffic or service behavior to which an
analyst applies the result.
Collection Loss: Loss of measurement records, samples, exported
data, or observation information within the measurement or
collection system. Collection loss is distinct from packet loss
in the measured network, although both can create gaps in
available measurement data.
Active Performance Measurement: A measurement method that generates
dedicated measurement traffic for measurement purposes [RFC7799].
Passive Performance Measurement: A measurement method based on
observation of an existing packet stream without modifying that
stream for the purpose of the measurement [RFC7799].
Liu Expires 27 April 2027 [Page 7]
Internet-Draft Measurement Interpretation October 2026
Hybrid Performance Measurement: A measurement method that combines
characteristics of active and passive measurement [RFC7799].
3. General Problem Statement
A performance metric can define the measured property without
explaining why the result occurred. The interpretation problem is
the gap between the result established by the metric and any broader
or causal conclusion drawn from it.
3.1. Metric Result and Operational Explanation
A metric result establishes the quantity defined by the metric for
the measured population and conditions. It does not, by itself,
establish the cause. A loss result does not distinguish congestion
from filtering or forwarding failure. A delay value does not
identify the contribution of propagation, queueing, processing, or a
path change. A reordering result does not identify the mechanism
that changed packet order. Operational explanation remains separate
from the metric result.
3.2. Metric Definition and Parameters
Metric definitions and parameters determine the scope of a result.
Fixed and runtime parameters can specify packet type, packet size,
timing, thresholds, traffic class, observation interval, or other
measurement conditions [RFC8911].
Compare results in the same broad metric family only when the
relevant definitions and parameters are compatible. A network
change, a measurement-configuration change, or both can cause a
difference.
3.3. Similar Results from Different Operational Conditions
Different conditions can produce similar results. Delay can increase
because of queueing, path changes, endpoint processing, or
timestamping effects. Loss can result from congestion, forwarding
problems, filtering, policing, or endpoint behavior. Capacity can
change because of competing traffic, path changes, shaping, physical-
layer conditions, or the measurement setup. A result consistent with
one explanation does not exclude the others.
Liu Expires 27 April 2027 [Page 8]
Internet-Draft Measurement Interpretation October 2026
3.4. Visibility and Observation Scope
Endpoints or observation points, traffic selection, the time
interval, and the measurement method define measurement scope. A
result for one path, traffic class, direction, or interval does not
describe another. Any generalization should remain within the
visibility of the measurement unless additional evidence supports a
broader claim.
3.5. End-to-End and Hop-by-Hop Measurement Scope
End-to-end measurements characterize performance between two
measurement points and can capture the aggregate effect of the path
between them. However, an end-to-end result does not by itself
identify which intermediate node, link, or path segment contributes
to the observed behavior. Hop-by-hop measurements, where the
measurement method provides observations at intermediate points along
the path, can provide finer localization. For example, observations
at successive points can help determine where delay increases or
packet loss appears along a measured path. Such results depend on
the placement and coverage of the observation points and on the
consistency of the measurement method, timestamps, packet
correspondence, and measurement intervals across those points.
The two scopes therefore support different conclusions. An end-to-
end result describes the performance of the measured path as a whole,
while hop-by-hop results can provide evidence about individual
portions of that path. Neither scope should be generalized beyond
the endpoints, intermediate observation points, traffic population,
and interval represented by the measurement.
3.6. Flow-, Path-, Direction-, and Time-dependent Results
Performance can depend on packet fields, traffic class, direction,
path selection, and time. ECMP, link aggregation, tunneling, traffic
engineering, and policy can cause flows between the same endpoints to
experience different conditions. Routing convergence, queue bursts,
policy changes, endpoint load, and measurement-system changes can
produce short-lived differences. Reports should identify the flow,
path, direction, and interval represented by a result when those
factors affect interpretation.
Liu Expires 27 April 2027 [Page 9]
Internet-Draft Measurement Interpretation October 2026
3.7. Sample Population and Representativeness
Many results derive from only part of the relevant packet or
observation population. Delay statistics exclude packets that the
measurement system does not observe and timestamp. Passive systems
may sample traffic. Capacity methods can exclude intervals that fail
qualification criteria. Reordering and duplication measurements
depend on packet identification and observation completeness.
A result can be correct for the observed sample without representing
packets or intervals that the network lost, the measurement system
did not sample, the method excluded, or routing sent elsewhere.
3.8. Limits of Cause Attribution
Additional context can narrow the set of plausible explanations, but
it may not identify a unique cause. Counters can aggregate unrelated
traffic, logs can be incomplete, clocks can differ, and several
events can overlap. Cause attribution should remain an inference
unless the available evidence supports a definitive conclusion.
4. Operational Conditions Affecting Measurement Results
Many operational conditions can affect one or more performance
metrics. Their effects depend on the metric: congestion can increase
delay and delay variation before causing loss; routing changes can
alter delay, reordering, connectivity, or capacity; endpoint and
measurement-system behavior can affect results even when the network
does not change.
This section discusses operational conditions that affect performance
measurements and factors that limit measurement visibility.
4.1. Congestion and Queue Behavior
Congestion and queueing can affect delay, delay variation, packet
loss, and capacity-related results. Queue occupancy can increase
delay and delay variation before a queue begins discarding packets.
Long aggregation intervals can hide short-lived changes caused by
microbursts.
The effect can depend on traffic class, Differentiated Services Code
Point (DSCP), packet size, flow identifiers, queue selection, and
path selection. A result observed for one flow or traffic class may
therefore not represent another.
Liu Expires 27 April 2027 [Page 10]
Internet-Draft Measurement Interpretation October 2026
Increased delay, queue occupancy, and packet loss can support a
congestion hypothesis, but no single metric value proves congestion
without supporting context.
4.2. Link, Forwarding, and Routing Conditions
Link failures, physical errors, forwarding-plane faults, Forwarding
Information Base (FIB) inconsistencies, routing loops, blackholes,
tunnel failures, and routing convergence can affect connectivity,
loss, delay, delay variation, reordering, and capacity-related
results.
A path change can increase or decrease delay without loss.
Convergence can create transient loss or reordering. A forwarding
blackhole can affect connectivity and loss. Interpretation can
benefit from routing events, interface state, forwarding state, and
path information.
4.3. Endpoint and Measurement-System Behavior
Endpoints and the measurement system itself can affect measurement
outcomes. Active receivers or reflectors can reach processing
limits, apply rate limits, use incorrect configuration, or fail to
timestamp or process packets as expected. Passive observation
systems can miss packets or records. Hybrid measurement functions
can apply marking or measurement processing inconsistently.
Such behavior can alter loss, delay, reordering, duplication, or
capacity results without a corresponding change in the network path.
Measurement-system state is therefore part of the interpretation
context.
4.4. Encryption and Limited On-Path Visibility
Encryption can limit the information available to on-path observers
for performance measurement. In particular, transport protocols that
encrypt control information can prevent observers from accessing
packet sequence numbers, acknowledgments, and other fields used to
infer connection performance. For example, QUIC encrypts most
transport control information, limiting the ability of on-path
observers to infer packet loss and retransmission behavior [RFC9065]
[RFC9312].
Liu Expires 27 April 2027 [Page 11]
Internet-Draft Measurement Interpretation October 2026
Encryption does not necessarily prevent network-layer performance
measurements. Depending on the protocol and observation points,
observers can still measure packet counts, packet sizes, timing, and
other visible metadata. However, these observations may not provide
sufficient information to characterize transport or application
performance.
Interpret such measurements according to the information available at
the observation points. Distinguish measured network-layer
properties from transport- or application-level performance estimates
that require additional information.
4.5. Policy, Filtering, Policing, and Traffic Treatment
Access control lists, firewalls, service filters, traffic
conditioning, administrative policy, or policing can discard, delay,
rate limit, or otherwise treat packets differently. Such treatment
can affect connectivity, loss, delay, delay variation, and capacity-
related results.
Effects can depend on source and destination addresses, protocol,
transport ports, DSCP, packet size, direction, interface, customer,
or traffic class. Before generalizing a metric result or attributing
it to a specific condition, use policy configuration, per-class
counters, or other supporting evidence when needed.
4.6. Validation-related Discard
Validation functions can discard packets that are not accepted in the
applicable validation context. Source Address Validation is one
example [RFC2827] [RFC3704] [RFC8704].
Validation-related discard can affect connectivity and packet loss
results and, through selective removal of packets or paths, can
affect the sample population underlying other metrics. However, the
presence of a validation function does not imply that validation
caused a measurement result. Such an attribution requires supporting
evidence such as validation counters, rule state, routing state, and
event timing.
4.7. Multipath and Load-balancing Effects
ECMP, link aggregation, and other multipath mechanisms can cause
different packets or flows to traverse different component paths.
Those paths can differ in propagation delay, queueing, loss,
available capacity, policy, or observation coverage.
Liu Expires 27 April 2027 [Page 12]
Internet-Draft Measurement Interpretation October 2026
Multipath can affect delay distributions, delay variation, loss,
reordering, and capacity results. Aggregate statistics can hide
concentration of a result on one component path. Relevant context
includes the fields and forwarding behavior that influence path
selection.
4.8. Transient Conditions and State Changes
Routing convergence, link failure and restoration, FIB updates,
tunnel reoptimization, policy changes, endpoint restarts, queue
bursts, and measurement configuration changes can produce transient
changes across several metrics.
A short event can appear as a burst of loss, a delay spike,
reordering, a temporary connectivity failure, or a temporary
reduction in measured capacity. Fine-grained timing and event
records can help distinguish transient behavior from persistent
conditions, although temporal correlation alone does not establish
causality.
5. General Considerations for Result Interpretation
The following considerations apply across metric families and
measurement methods.
5.1. Start with the Metric Definition and Parameters
Use the exact metric definition and the fixed and runtime parameters
of the measurement. They define the measured property, the packet or
traffic population, and the conditions under which the measurement
produced the result [RFC8911].
Do not compare or generalize results because they share a label such
as loss, delay, or capacity. Where a Performance Metrics Registry
entry applies, the registry entry and parameter values make the
measurement semantics explicit.
5.2. Identify the Method of Measurement
Record how the measurement produced the result, including whether the
method is Active, Passive, or Hybrid when the [RFC7799]
classification applies. The method determines how the system forms
the measured population, where it observes packets, which variables
it controls, and which measurement-system effects can appear in the
result.
Liu Expires 27 April 2027 [Page 13]
Internet-Draft Measurement Interpretation October 2026
Results for the same metric can have different scopes when the
methods, observation points, selection rules, sampling procedures, or
collection systems differ. Section 7, Section 8, and Section 9
discuss these cases in more detail.
5.3. Separate Metric Results from Inferred Causes
Keep the measured result separate from the operational explanation.
A delay value is not a measurement of queueing unless the metric
specifically defines it as such. A loss ratio is not a measurement
of congestion. A reordering result is not a measurement of ECMP
behavior.
If analysis infers a cause, report the evidence that supports the
inference and any material uncertainty.
5.4. Consider Multiple Metrics Together
Related metrics can constrain an interpretation. Consider delay,
delay variation, and loss together when examining queueing or path
behavior. Reordering together with delay changes can provide
evidence of a path change. Some capacity methods use loss and delay
during qualification and reporting [RFC9097]. Cross-metric
correlation is supporting evidence, not proof that one metric caused
another.
5.5. Consider Measurements Across Protocol Layers
Performance measurements at different protocol layers characterize
different aspects of network behavior. For example, link-layer
retransmissions can increase IP packet delay without causing IP
packet loss, while link-layer discards can contribute to IP packet
loss. Transport-layer recovery mechanisms can also affect the
relationship between IP packet delivery and transport performance.
Results at different layers may therefore reflect related network
conditions without showing the same behavior [RFC3432] [RFC6703].
When associating results across layers, consider the metric
definitions, observation points, traffic populations, directions, and
measurement intervals. Differences in packet identification,
encapsulation, retransmission, and aggregation can also affect the
relationship between measurements at different layers.
Cross-layer measurements can provide complementary evidence for
interpreting IPPM results. However, correlation between results at
different layers does not establish causality. Such results should
retain their respective metric semantics, and any inference about
interlayer relationships requires supporting evidence.
Liu Expires 27 April 2027 [Page 14]
Internet-Draft Measurement Interpretation October 2026
5.6. Relate Network Measurements to Application Performance
Network operators often measure IP-layer performance, while users
experience application performance. The two perspectives do not
necessarily align. Network loss, delay, and capacity can affect
application behavior, but transport protocols, endpoint processing,
application design, and buffering can also influence application
performance. [RFC6703] distinguishes network characterization from
application performance estimation, while [RFC6390] discusses the
relationship between network performance, application-specific
metrics, and user experience.
When relating network measurements to application performance,
consider the application traffic, transport behavior, endpoints,
paths, and measurement intervals. Network measurements may cover
only part of the path or traffic that an application uses.
Differences in measurement scope or application workload can also
affect the relationship between network and application results.
IPPM measurements can provide evidence about the network's
contribution to application performance, but they do not directly
establish application performance or user experience. Any inference
from network metrics to application performance requires additional
evidence or an explicit model that accounts for relevant application
and transport behavior.
5.7. Consider Direction, Observation Scope, and Measurement Role
Record the direction, endpoints, observation points, and measurement
roles represented by the result. A one-way result does not describe
the reverse path. A result at one observation point does not
describe behavior outside that point's visibility. A reflected
measurement includes the forward path, remote processing, and the
return path. Operational conclusions should remain within that
visibility.
5.8. Consider Flow and Path Selection
Packet fields and encapsulation can affect forwarding, load
balancing, filtering, policing, and queueing. Relevant fields can
include source and destination addresses, transport ports, flow
labels, DSCP, packet size, and tunnel information.
A change in result after these fields change can indicate flow- or
path-dependent behavior rather than random measurement variation.
Liu Expires 27 April 2027 [Page 15]
Internet-Draft Measurement Interpretation October 2026
5.9. Consider Timing and State Changes
Interpret results in the interval in which the measurement produced
them. Routing updates, link events, queue bursts, policy changes,
endpoint events, and measurement-system changes can produce transient
effects.
Correlation with such events requires compatible timestamps and
sufficient time resolution. Long aggregation intervals can hide
short events.
5.10. Consider the Observed Sample Population
Identify which packets, observations, or intervals contributed to the
result. Packets that the metric classifies as lost do not contribute
one-way delay samples. Sampled passive traffic does not directly
describe unsampled traffic. Reordering results depend on the packets
that arrive, while loss or duplication can change that observed
population. Capacity methods can exclude intervals that fail
qualification criteria.
Interpret the result for the population defined by the metric and
method before extending it to a broader population.
5.11. Consider Measurement Representativeness
The measured population may differ from the traffic or service to
which the result is later applied. Active probes can differ from
production traffic. Passive measurements depend on traffic
availability, observation-point placement, and sampling. Hybrid
methods may mark or select only part of production traffic. When
representativeness matters to the conclusion, report the relevant
differences rather than assuming equivalence.
5.12. Treat Correlation as Supporting Evidence, Not Proof
Network and measurement-system events often correlate with metric
results. Correlation can make an explanation more plausible, but
common timing does not establish causality and several events can
overlap. Reports should distinguish the metric result, correlated
evidence, and any inferred explanation.
Liu Expires 27 April 2027 [Page 16]
Internet-Draft Measurement Interpretation October 2026
5.13. Report Uncertainty
If the available evidence does not support a unique cause or broader
generalization, retain that uncertainty. At minimum, the report can
state the result, relevant parameters, measured population,
observation scope, interval, and the evidence used for
interpretation.
6. Metric-Specific Interpretation Considerations
The common principles above apply across metrics, but different
metric families have distinct interpretation concerns. This section
discusses representative IPPM metric families. It is not intended to
enumerate every metric defined or maintained by IPPM. In each case,
interpretation begins with the specific metric definition rather than
with a generic label such as "loss", "delay", or "capacity".
6.1. Connectivity
Connectivity is not a single generic Boolean property. [RFC2678]
defines several Type-P connectivity metrics, including instantaneous
and interval, unidirectional and bidirectional, and temporal
connectivity. Interpretation therefore needs to identify the
specific connectivity metric, Type-P, endpoints, direction or
directions, and time semantics involved.
A negative connectivity result establishes lack of connectivity under
the conditions of the selected metric, but it does not identify the
cause or location of the failure by itself. Possible explanations
include routing or forwarding state, filtering, endpoint behavior,
security policy, or measurement-system behavior.
Do not generalize a positive result beyond the semantics of the
selected metric. In particular, an interval connectivity result can
establish that connectivity existed at one or more relevant times
within an interval without establishing continuous connectivity
throughout that interval. Likewise, connectivity for one Type-P or
direction does not establish connectivity for other packet types,
traffic classes, directions, paths, or times.
6.2. Packet Loss
[RFC7680] defines the Type-P-One-way-Packet-Loss singleton result as
either successful reception or loss for a packet sent from a
specified source to a specified destination at a specified time. The
loss-threshold waiting time, Tmax, defines loss: the metric
classifies a packet as lost when the destination does not receive it
within Tmax. The singleton loss result is closely related to the
Liu Expires 27 April 2027 [Page 17]
Internet-Draft Measurement Interpretation October 2026
corresponding one-way delay result: reception within Tmax produces a
finite delay, while failure to receive the packet within Tmax
produces an undefined delay.
Preserve these semantics. A packet that the metric classifies as
lost does not identify a discard location or cause; the metric
establishes only that the destination did not receive the packet
within the defined conditions. The configured waiting threshold
separates a very large delay from a loss result, so Tmax forms part
of the measurement context. Type-P, path information when available,
and measurement error or calibration information can also matter.
Stream and statistical loss results add another interpretation layer.
A loss ratio summarizes singleton outcomes over a defined sample, and
the packet-generation or sampling process determines which times and
packets the sample represents. Do not treat two loss ratios as
directly comparable merely because their numerical values match when
their Type-P, Tmax, sampling discipline, intervals, or packet
populations differ.
Packet loss can also change the population available to other
metrics. A packet that is lost does not contribute a finite one-way
delay sample, can make an IP packet delay variation value undefined
for a selected pair, and can interact with reordering and capacity
qualification.
6.3. Delay
[RFC7679] defines Type-P-One-way-Delay for a packet sent from a
specified source to a specified destination at a specified time. A
finite result represents the elapsed wire time from transmission of
the first bit at the source to reception of the last bit at the
destination. If the destination does not receive the packet within
the loss-threshold waiting time, Tmax, the metric reports an
undefined one-way delay. [RFC2681] defines corresponding round-trip
delay metrics with different directional semantics.
A measured delay value establishes the delay defined by the metric;
it does not decompose that value into propagation, serialization or
transmission, queueing, processing, timestamping, or other
components. An increase or decrease in delay therefore does not by
itself identify which component changed. Path changes, queueing,
endpoint or reflector processing, tunneling, and measurement-system
behavior can all affect observed delay.
The measurement method and its error model also affect the result.
For one-way delay, clock synchronization, accuracy, resolution, and
the relationship between host time and wire time contribute to
Liu Expires 27 April 2027 [Page 18]
Internet-Draft Measurement Interpretation October 2026
measurement uncertainty. Type-P, packet size, the selected path, and
Tmax are also part of the measurement context. A delay statistic
covers only packets that produce defined delay values; it does not
characterize packets that the metric classifies as lost or packets
outside the measured population.
6.4. Delay Variation
[RFC3393] defines IP Packet Delay Variation (ipdv) for a selected
pair of packets as the difference between their one-way delays. The
interpretation of an ipdv value therefore depends on the underlying
one-way delay metric and on the selection function that identifies
the two packets. Parameters such as the packet stream, packet size,
Type-P, measurement interval, and selection function are part of the
meaning of the result.
If either selected packet does not produce a defined one-way delay,
the corresponding singleton ipdv value is undefined. Loss can change
not only the observed distribution of delay variation but also which
packet pairs contribute defined values. A singleton ipdv value alone
does not support statistical inference; sample construction and the
statistic that summarizes the sample also matter.
Because ipdv is a differential measurement, a constant clock offset
can cancel, but relative clock skew or drift over the interval
between selected packets can still contribute error. Delay variation
is therefore not independent of clock behavior. The term "jitter"
has several operational meanings; when referring to the [RFC3393]
metric, the defined ipdv terminology is less ambiguous.
Increased or changed delay variation can be consistent with variable
queueing, path changes, multipath behavior, scheduling, endpoint
processing, or measurement-system effects. The metric result alone
does not identify which explanation applies.
6.5. Packet Reordering
[RFC4737] defines a reordered singleton and several sample metrics
that quantify different dimensions of packet reordering. Identify
the reordering metric that the report uses, the original packet-order
information, the stream characteristics, and the relevant thresholds
and parameters. Reordering metrics operate even when a stream also
contains lost or duplicate packets.
A sequence discontinuity does not by itself establish reordering.
When a received packet indicates that earlier packets are missing,
later observations can classify those packets as reordered or lost.
A later arrival confirms reordering only when the packet appears in a
Liu Expires 27 April 2027 [Page 19]
Internet-Draft Measurement Interpretation October 2026
position that violates the original sequence. The selected metric
therefore needs to distinguish a temporary sequence gap from a
confirmed reordered packet.
Loss, duplication, and reordering interact in the receiver's
observation of the stream. Waiting thresholds, sequence-number
interpretation, duplicate handling, packet-size patterns, and the
measurement window can affect sample results and derived ratios. A
reordering result establishes ordering behavior for the measured
stream, but it does not by itself identify the mechanism that
produced it. Multipath forwarding, path changes, parallel
processing, and link-layer behavior are possible explanations that
require additional evidence.
6.6. Packet Duplication
[RFC5560] defines one-way packet arrival count and one-way packet
duplication for an individual packet. The duplication value counts
additional uncorrupted and identical copies that the destination
receives within the interval between the send time and maximum
waiting time, T0. If exactly one copy arrives, the duplication value
is zero; if no copy arrives within the interval, the duplication
metric is undefined rather than a positive duplication value.
Packet identity drives the interpretation. [RFC5560] requires the
implementation to specify which information fields it compares when
determining whether packets are identical, and identity does not
require every bit in the received packets to match. Fragmentation
and packet-field changes along the path can affect how the
measurement recognizes copies.
The measurement method also matters. In an active system, the sender
can avoid transmitting multiple packets with identical identifying
information within the relevant interval. In a passive system, the
original source can transmit distinct packets that appear identical
under the available identification fields, creating false positives
if the observation system cannot distinguish them. Apparent
duplication can also result from capture or correlation behavior. A
duplication result therefore establishes additional observed copies
according to the metric's identity rules, not the network mechanism
that produced those copies.
Liu Expires 27 April 2027 [Page 20]
Internet-Draft Measurement Interpretation October 2026
6.7. Capacity-related Metrics
Capacity-related results depend strongly on terminology and metric
definition. [RFC5136] distinguishes IP-layer capacity, usage,
utilization, and available capacity and emphasizes that capacity is
meaningful only with respect to a specified protocol layer, Type-P,
path or link, time, and interval. Do not conflate these quantities
with one another or with generic "bandwidth" or application
throughput.
As a concrete IPPM measurement example, [RFC9097] defines Type-P-One-
way-IP-Capacity and Maximum IP-Layer Capacity using active methods.
[RFC9097] determines Maximum IP-Layer Capacity over specified sub-
intervals and qualifies the result with other performance metrics and
thresholds. The Type-P, number of flows, offered load, sub-interval
duration, test interval, qualification criteria, sender and receiver
behavior, and competing traffic are therefore part of the
interpretation context. [RFC9097] also recommends reporting loss
ratios and round-trip delay statistics alongside Maximum IP-Layer
Capacity results.
A change in a capacity-related result does not identify whether path
capacity, competing traffic, shaping or policing, packet treatment,
endpoint limits, physical-layer conditions, or the measurement
procedure changed. Some active capacity methods can perturb the
measured environment because they offer substantial load by design.
Tie the reported value to the selected capacity metric rather than a
generic throughput result, and report measurement-induced effects
when they affect interpretation.
6.8. End-to-End and Hop-by-Hop Interpretation
The relationship between end-to-end and hop-by-hop results depends on
the metric and measurement method. [RFC9343] provides an example of
a method that supports both measurement scopes.
Do not assume that hop-by-hop metric results combine directly into
the corresponding end-to-end result. The relationship depends on the
metric and measurement method. Delay components may accumulate along
a path, but timestamp locations, processing boundaries, and
measurement errors affect the relationship between per-hop and end-
to-end delay. Packet loss across multiple segments does not combine
by adding loss ratios. Reordering observed at one point can be
corrected or changed later in the path. End-to-end capacity can
depend on the limiting portion of the path rather than on an additive
combination of per-hop capacity values.
Liu Expires 27 April 2027 [Page 21]
Internet-Draft Measurement Interpretation October 2026
When associating hop-by-hop observations with an end-to-end result,
align the packet or traffic population, path, direction, measurement
interval, metric parameters, and observation points. Differences
among these elements can produce apparent inconsistencies even when
each individual result is valid.
Hop-by-hop information can narrow the location associated with an
end-to-end performance change, but it does not by itself establish
the operational cause. Attribution still requires supporting
evidence appropriate to the affected segment or node.
6.9. Cross-Metric Interpretation
Operational analysis often combines several metrics because no single
metric captures all aspects of performance. Such combinations can
help when measurements cover compatible traffic populations, paths,
directions, and time intervals. [RFC6703] shows that the intended
use of the measurements can shape the choice and reporting of loss,
delay, delay variation, reordering, and capacity-related results.
Before drawing a joint conclusion, verify that the metrics refer to
comparable scopes and measurement conditions. For example, do not
combine a delay statistic from one Type-P or traffic class with a
loss ratio from a different path or interval. Likewise, interpret a
capacity result qualified with particular loss or delay thresholds
together with those associated measurements, not unrelated
observations from another test.
Multiple metrics can strengthen or weaken an operational hypothesis,
but their combination does not by itself establish causality. Multi-
metric evidence becomes strongest when measurements align packet or
traffic populations, paths, directions, parameters, and timing, and
when the measurement method or analysis defines the relationship
among the metrics.
7. Considerations for Active Performance Measurements
Active Methods of Measurement generate a packet stream for
measurement and provide substantial a priori knowledge of that
stream, including its endpoints and relevant packet or stream
characteristics [RFC7799]. This control supports repeatable
experiments and tests of specific hypotheses. At the same time, the
generated stream can differ from production traffic and can influence
the measured network conditions. Interpretation of an active result
therefore depends on both the metric definition and the
characteristics and effects of the active measurement stream.
Liu Expires 27 April 2027 [Page 22]
Internet-Draft Measurement Interpretation October 2026
7.1. Active Measurement Stream and Representativeness
The packet and stream characteristics used by an active measurement
are part of the interpretation context. Relevant characteristics can
include source and destination addresses, Type-P or equivalent
packet-treatment parameters, transport ports, packet sizes, DSCP
values, flow labels, encapsulation, packet rate, packet timing, test
duration, and endpoint placement.
An active measurement can characterize the specified measurement
stream accurately without representing another application, traffic
class, flow, or packet population. Differences in packet or stream
characteristics can affect path selection, queue selection,
filtering, policing, security treatment, and endpoint processing.
Reports that generalize an active result beyond the measurement
stream should explain why the measurement traffic represents the
traffic or service of interest.
7.2. Measurement-induced Effects
Because active methods add a generated stream to the network, the
measurement activity can influence the measured quantity [RFC7799].
The significance of this effect depends on the metric and the
measurement stream. A sparse probe stream can have little effect on
network conditions, while a sustained or high-rate stream used for a
capacity-related measurement can increase queueing, contention,
congestion, or network adaptation.
The offered load, packet size, timing pattern, duration, and
concurrency of the active stream are part of the measurement context,
together with any additional loading traffic used by the method. Do
not present a result as describing an unperturbed network when the
measurement changes the conditions experienced by the measured stream
or other traffic.
7.3. One-way Active Measurements
One-way active measurements associate results with a specific source-
to-destination direction. This is useful for isolating directional
behavior, but different metrics introduce different interpretation
requirements.
For a loss metric, the applicable definition and parameters classify
an expected packet as lost when the receiver does not receive it,
while leaving the discard location and operational cause unknown.
For one-way delay and delay variation, timestamp semantics, clock
synchronization, clock accuracy, and the received packet population
form part of the interpretation context. For reordering or
Liu Expires 27 April 2027 [Page 23]
Internet-Draft Measurement Interpretation October 2026
duplication metrics, the controlled source stream and packet-
identification information can help establish expected packet order
and correspondence, but the metric-specific definitions still
determine how events are classified.
Interpret a direction-specific active result as a result for that
direction and measurement stream, not as evidence that a specific
device, link, queue, or operational mechanism caused the observed
behavior.
7.4. Two-way and Reflected Active Measurements
Two-way or reflected active measurements introduce an additional
interpretation boundary because the observed exchange can include a
forward path, processing at a reflector or remote endpoint, and a
reverse path. A round-trip result characterizes the complete
measurement exchange defined by the method; it does not by itself
identify the contribution of each direction or of reflector
processing.
For loss, a missing response can result from failure to deliver the
forward packet, failure to process or reflect the packet, or failure
to deliver the response. For round-trip delay, an increased value
can reflect conditions on either direction and, depending on the
protocol and timestamp semantics, processing at the remote endpoint.
Do not infer one-way components from a round-trip result unless the
measurement method and available timestamps support that inference.
Reflector-side information, directional measurements, or protocol
timestamps can reduce ambiguity, but keep any additional conclusion
consistent with the metric semantics and clock requirements.
7.5. OWAMP, TWAMP, and STAMP
OWAMP, TWAMP, and STAMP illustrate different active measurement
arrangements. OWAMP supports measurement of one-way characteristics
such as one-way delay and one-way loss [RFC4656]. TWAMP builds on
the OWAMP architecture and adds two-way or round-trip measurement
capabilities; the protocol can use reflector timestamps to account
for processing behavior [RFC5357]. STAMP supports both one-way and
round-trip performance measurements, including delay, delay
variation, and packet loss [RFC8762].
The protocol used for a measurement does not remove the
interpretation considerations associated with the underlying metric.
Interpret a protocol result together with the metric definition,
session configuration, packet and stream parameters, endpoint roles,
timestamp semantics, and the traffic represented by the test.
Liu Expires 27 April 2027 [Page 24]
Internet-Draft Measurement Interpretation October 2026
For reflected protocols, sender-side observations may not localize an
operational condition. For protocols that support one-way
measurements, the applicable timestamp and clock requirements remain
important. Protocol-specific fields can also influence forwarding or
other packet treatment when they contribute to path selection or
policy.
7.6. Active Measurement over Multipath
A single active measurement flow can exercise only one ECMP or link-
aggregation component path, depending on the network's path-selection
behavior. Changing source or destination addresses, transport ports,
IPv6 flow labels, encapsulation, or other fields can move the
measurement stream to a different component path and therefore change
the measured result.
Controlled variation of flow identifiers can help reveal differential
treatment across component paths. However, interpret a changed
result after changing a flow identifier as evidence about a different
measurement stream that may also use a different path, not as a
repeat of the same condition.
7.7. Controlled Active Measurements
Use the controllability of active measurement to test operational
hypotheses. Examples include measuring both directions, varying flow
identifiers, comparing one-way and round-trip measurements, changing
packet sizes or traffic classes when appropriate, adjusting the probe
schedule or offered load, or measuring from multiple vantage points.
A controlled change is useful when the changed parameter and the
resulting change in measurement scope are both understood. Altering
packet characteristics can change forwarding, queueing, policy, or
security treatment, while changing probe rate can change the load
imposed by the measurement itself. Treat a follow-up active test as
a related experiment whose differences form part of the
interpretation; do not assume that it reproduces the original
condition.
8. Considerations for Passive Performance Measurements
[RFC7799] defines Passive Methods of Measurement as methods that
observe an undisturbed and unmodified packet stream of interest at
one or more Observation Points. Passive methods can provide direct
evidence about production traffic without generating the stream of
interest, but the resulting interpretation depends on the selected
stream, observation coverage, packet correspondence, capture and
export behavior, and the traffic that happened to be present during
Liu Expires 27 April 2027 [Page 25]
Internet-Draft Measurement Interpretation October 2026
the measurement interval.
8.1. Observation Scope and Stream Selection
A passive result describes traffic that the observation function
selects at specified Observation Points. Some passive methods
observe all packets at an Observation Point, while others first apply
filtering or other selection criteria. The selected stream of
interest therefore forms part of the measurement definition and
interpretation context.
The absence of a packet from an observation does not, by itself,
establish network packet loss. The packet may bypass the Observation
Point, fail the selection criteria, or escape capture or export.
When an analyst infers loss or another transfer property by comparing
observations at multiple points, the conclusion covers only the
network segment and packet population that those observations cover.
For encrypted traffic, the available protocol information can further
limit what an on-path observer can measure or infer. Network-layer
observations may remain possible even when encryption prevents access
to transport-layer information needed to characterize connection
performance (see Section 4.4).
8.2. Packet Correspondence Across Observation Points
Many passive packet-transfer metrics require observations at more
than one point and therefore require a method that establishes
correspondence between packets at those points [RFC7799].
Encapsulation, header changes, fragmentation, replication,
reordering, packet-identification limits, timestamp resolution, or
observation-system behavior can disrupt packet correspondence.
For loss-related analysis, compare observations from the same packet
population. For delay and delay variation, packet matching and
timestamp location and synchronization can affect the result. For
reordering and duplication, the method used to establish packet
identity and order is part of the interpretation context.
If multiple paths exist, an upstream Observation Point and a
downstream Observation Point can cover different packet populations.
Incomplete observation coverage or path divergence can create
apparent loss or duplication unless the method establishes
correspondence and coverage.
Liu Expires 27 April 2027 [Page 26]
Internet-Draft Measurement Interpretation October 2026
8.3. Traffic Availability and A Priori Stream Knowledge
Passive measurement observes only traffic that exists during the
measurement interval. If a service, traffic class, endpoint pair, or
path carries little or no traffic, the measurement provides little or
no evidence about how that traffic would perform under other
conditions.
Passive methods also often have less a priori knowledge of the stream
than active methods [RFC7799]. Applications and users can determine
packet rate, flow duration, protocol mix, packet size, endpoints, and
path use rather than the measurement system. This is useful for
observing real service behavior, but it can make comparisons across
intervals or populations difficult when the traffic mix itself
changes.
Match the reported scope to the observed traffic population.
Generalization to other traffic, paths, loads, or time periods
requires supporting evidence.
8.4. Sampling, Aggregation, Export, and Collection Effects
Passive measurement systems can use packet sampling, flow sampling,
filtering, aggregation, export, or other data-reduction mechanisms.
Capture loss, exporter loss, collector overload, buffering limits,
and processing limits can remove observations independently of packet
transfer in the measured network.
Do not interpret a missing record or incomplete observation as
network packet loss without supporting evidence. Where the
distinction matters, the measurement system should account for or
report loss and omission that capture, sampling, export, collection,
and processing introduce.
Aggregation can hide transient behavior and differences among packet
populations, paths, or traffic classes. In addition, RFC 7799 notes
that communication or export of passive measurement results can
create traffic load; consider this management and collection traffic
when it can affect the network or the measured values.
8.5. Selection Effects and Observed Population
Passive measurement results reflect packets that traverse the
selected Observation Points and that the observation system captures.
This can create selection effects. For example, a delay distribution
built from packets matched at two Observation Points excludes packets
that the network loses, routing diverts outside the observation
coverage, or the observation system omits.
Liu Expires 27 April 2027 [Page 27]
Internet-Draft Measurement Interpretation October 2026
Such a result can be valid for the observed population while
remaining unrepresentative of the full traffic population. Reports
should state the inclusion conditions for the measured sample and
note any systematic difference between the observed and unobserved
populations.
8.6. Passive Measurement-System State
Observation interfaces, filters, sampling configuration, timestamping
functions, exporter behavior, collector capacity, and analysis
pipelines are part of the passive measurement system. Changes or
faults in these components can alter the measured data while the
packet-transfer behavior of the network remains unchanged.
Check unexpected changes in passive results against measurement-
system state as well as network state. The required checks depend on
the metric: loss-related interpretation can require capture and
export loss information, delay-related interpretation can require
timestamp and clock status, and packet correspondence metrics can
require validation of identification and matching behavior.
9. Considerations for Hybrid Performance Measurements
Hybrid Methods of Measurement combine attributes of active and
passive methods [RFC7799]. The particular combination matters for
interpretation. RFC 7799 distinguishes, among other cases, Hybrid
Type I methods that augment or modify a single stream of interest or
otherwise modify its treatment, and Hybrid Type II methods that
coordinate two or more streams of interest measured using different
method characteristics. Hybrid interpretation should begin by
identifying which active and passive attributes are present and how
they can affect the result.
The Alternate-Marking Method provides an example of performance
measurement on live traffic. [RFC9341] discusses its applicability
to Passive and Hybrid measurements and classifies implementations
that modify marking fields at domain edges as Hybrid Type I,
according to [RFC7799].
9.1. Identify the Hybrid Construction
A hybrid result should identify how the method departs from purely
passive observation or purely active generation. Relevant questions
include whether the measurement function modifies or augments an
existing packet stream, generates additional load or measurement
streams, coordinates multiple streams, or controls specific packet or
stream characteristics.
Liu Expires 27 April 2027 [Page 28]
Internet-Draft Measurement Interpretation October 2026
These distinctions limit the scope of generalization from the result.
A method that marks production packets, one that observes production
traffic while adding a separate load stream, and one that analyzes an
active stream together with a production stream can all be hybrid,
but they do not have the same interpretation properties.
9.2. Combining Active Measurements with On-Path Hybrid Techniques
Active measurement methods can be combined with on-path hybrid
measurement techniques to obtain additional information from
intermediate nodes. For example,
[I-D.ietf-ippm-on-path-active-measurements] describes the use of
active test packets with Alternate Marking or In Situ OAM (IOAM) to
complement end-to-end measurements with on-path observations. These
observations can help identify the portion of a measured path
associated with a performance change.
When interpreting the combined results, distinguish the end-to-end
measurement result from observations collected at intermediate nodes.
Check whether the observations cover the same measurement stream,
path, direction, and time interval. Differences in observation
coverage, measurement parameters, timestamping, or packet treatment
can affect the relationship between the results. When relating
active measurement results to production traffic, distinguish path
congruence from forwarding-treatment equivalence as described in
[RFC10014].
9.3. Measurement Marking, Augmentation, and Treatment Equivalence
Hybrid Type I methods can add or modify fields used to identify
packet groups, measurement intervals, or measurement state. Such
augmentation is useful for packet correspondence and measurement
control, but it can also change packet treatment if the modified
field affects forwarding, filtering, queueing, policy, or other
behavior.
Do not assume that a marked or augmented stream represents the
corresponding unmodified production stream. RFC 7799 notes that
Hybrid results match Passive results only when modified and
unmodified packets receive equivalent treatment. Where
interpretation depends on such equivalence, establish or validate it
rather than assume it.
Liu Expires 27 April 2027 [Page 29]
Internet-Draft Measurement Interpretation October 2026
9.4. Partial Controllability and Traffic Availability
Hybrid methods can combine controlled measurement state with traffic
characteristics determined by production applications. For example,
a method can control marking periods or metadata while packet timing,
packet sizes, endpoints, and offered load remain determined by the
production stream.
This combination provides more measurement structure than passive
observation while preserving many production-traffic characteristics,
but the method cannot control some experimental variables
independently. A lack of suitable production traffic limits what the
method can measure, and changes in the production traffic mix can
affect comparisons across marking periods or measurement intervals.
9.5. Consistency of Measurement State Across Observation Points
Hybrid measurement can depend on consistent interpretation of
markings, packet groups, timestamps, counters, or other measurement
state across Observation Points. Inconsistent marking state,
interval boundaries, packet classification, counter resets, or
timestamp behavior can produce differences that originate in the
measurement function rather than in packet transfer.
Observation points need compatible measurement state, and transitions
between measurement intervals need consistent handling. For methods
based on counters or timestamps, alignment of measurement periods and
clocks is part of the interpretation context.
9.6. Coordinated Streams and Hybrid Type II Interpretation
Hybrid Type II methods can use two or more coordinated streams of
interest with different measurement-method characteristics [RFC7799].
Joint analysis of these streams can provide information unavailable
from either stream alone, but coordination does not imply that the
streams experience identical network treatment.
Before comparing or combining results, check whether the streams use
the same paths, traffic classes, packet sizes, timing intervals,
endpoints, and network conditions. Differences between an active
stream and a production stream can be informative, but do not
attribute them to an operational cause when the stream
characteristics themselves differ.
Liu Expires 27 April 2027 [Page 30]
Internet-Draft Measurement Interpretation October 2026
9.7. Production Traffic Representativeness
When a hybrid method operates on production traffic, the measured
population can closely reflect real service behavior. The result
nevertheless applies to the traffic selected, marked, observed, or
correlated by the method. Unselected traffic can use different
paths, classes, or packet characteristics, and the measurement
mechanism itself can introduce selection effects.
Reports should identify the production traffic that the method
includes and state whether marking, selection, or augmentation could
affect packet treatment or sample composition.
9.8. Sampling, Aggregation, and Collection Effects
Hybrid methods can rely on counters, packet samples, exported
records, or aggregated measurement intervals and can inherit the
observation and collection limits of passive measurement. In
addition, active components can introduce state, load, or packet
modifications that require separate interpretation.
Interpret a hybrid measurement result together with the state of both
the measured traffic and the measurement function. Collection loss,
sampling, inconsistent marking state, generated load, or differences
among coordinated streams can all affect interpretation without
implying that the underlying metric definition is invalid.
10. Interpretation Context and Supporting Evidence
Metric definition, parameters, measurement method, and observed
population establish the primary meaning of a result. Other
information can support or limit a broader interpretation. Its value
depends on how closely it matches the measured traffic, path or
observation scope, direction, and time interval.
10.1. Measurement Metadata and Intended Use
Useful metadata includes the metric definition or registry entry,
fixed and runtime parameters, measurement method, timestamps,
direction, measurement or observation points, packet or traffic
selection, packet characteristics, sampling or marking configuration,
aggregation interval, statistical function, and relevant clock
information. [RFC8911] requires operators to supply Runtime
Parameter values when they execute a measurement and to report those
values with the results.
Liu Expires 27 April 2027 [Page 31]
Internet-Draft Measurement Interpretation October 2026
The intended use also matters. [RFC6703] shows that intended use
shapes measurement design, parameter selection, and reporting. A
result sufficient for one purpose can be insufficient for a broader
conclusion about other traffic, paths, intervals, or application
behavior.
10.2. Path, Routing, and Forwarding Context
Routing and forwarding information can show whether the measured
traffic could have experienced a route change, next-hop change,
forwarding inconsistency, tunnel change, or different component path.
This information is most useful when the result varies by flow,
direction, or time.
Control-plane state does not always identify the data path that
packets traverse. When interpretation depends on the actual path,
use forwarding-plane or path-specific evidence. In multipath
environments, match path information, as far as practical, to the
fields and traffic population represented by the metric.
10.3. Resource and Traffic-Treatment Context
Interface state, utilization, queue state, discard counters, policer
or shaper state, filtering state, and similar information can show
whether a proposed explanation is consistent with conditions during
the measurement. Queue and discard information can support an
interpretation of loss or delay; utilization, competing traffic,
traffic class, and qualification conditions can be relevant to
capacity results. Validation state and counters provide one form of
traffic-treatment context where networks deploy validation functions.
These data are not direct explanations unless their scope matches the
measurement. A device counter can cover several traffic populations
or time intervals, and an overlapping counter increment does not
prove that the measured traffic caused or experienced that increment.
When supporting evidence comes from another protocol layer, identify
its measurement scope and relationship to the IP packet population
before using it to interpret an IPPM result (see Section 5.5).
10.4. Measurement-System Context
The measurement system can affect the observations. For active
measurements, relevant state includes session status, endpoint or
reflector availability, processing limits, timestamping behavior, and
local rate limits. For passive and hybrid measurements, relevant
state includes capture status, sampling or selection configuration,
marking state, exporter behavior, collector capacity, record loss,
and processing-pipeline state.
Liu Expires 27 April 2027 [Page 32]
Internet-Draft Measurement Interpretation October 2026
Use this context when either the measured network or the measurement
system could cause a gap or change. Separate collection loss,
timestamping errors, overload, and configuration changes from the
packet-transfer behavior represented by the metric.
10.5. OAM, Telemetry, and Event Context
OAM mechanisms, telemetry, device logs, and event records can provide
measurement and network-state information. [RFC10014] distinguishes
path congruence from forwarding-treatment equivalence for OAM
packets. OAM packets can follow the same path as production traffic
while receiving different forwarding treatment. This distinction
matters when interpreting whether OAM measurement results represent
the performance of production traffic. [RFC9232] describes telemetry
as including data generation, collection, correlation, and
consumption for network visibility and operation. Such data can show
whether a result is consistent with a routing event, interface event,
resource condition, policy change, or measurement-system change.
Data granularity limits the correlation. A telemetry series with
samples every several minutes cannot localize a short per-packet
event within that interval. Path-discovery or OAM packets may also
follow a different path or receive different treatment from the
traffic that the metric represents.
10.6. Operator- and Controller-Provided Context
Operators and controllers can provide information unavailable to the
measurement system, including maintenance events, intended policy,
controller-computed paths, rule-distribution status, customer
attachment information, and known failures. Such information can
narrow the set of plausible interpretations.
It remains supporting context rather than part of the metric result.
Across administrative boundaries, treat incomplete disclosure as
uncertainty rather than filling gaps with assumptions.
11. Applying the Interpretation Framework
This section describes how to use the preceding considerations when
analysts compare, correlate, or generalize results. It does not
define a troubleshooting procedure.
Liu Expires 27 April 2027 [Page 33]
Internet-Draft Measurement Interpretation October 2026
11.1. Define the Intended Use and Required Scope
State the conclusion that the measurement aims to support. [RFC6703]
shows that intended use affects measurement design and reporting.
Apply the same principle to interpretation: compare the scope of the
conclusion with the scope established by the metric, parameters,
measured population, and method.
Make any generalization beyond that scope explicit and support it
with evidence or stated assumptions. When the intended use involves
application performance, identify which aspects of application
behavior the network measurements can represent and what additional
evidence supports the interpretation (see Section 5.6).
11.2. Align Scope and Time Before Correlation
External evidence is most useful when it refers to the same packet or
traffic population, path or observation scope, direction, and
interval as the result. Routing changes, forwarding events, queue
counters, policy changes, endpoint events, and measurement-system
events can all be relevant, but temporal overlap alone does not
establish causality.
Time resolution also matters. Clock synchronization, timestamp
location, aggregation period, telemetry sampling interval, and
retention resolution limit the precision of a correlation. Do not
infer finer causal localization than the available data support.
11.3. Compare Like Measurement Results Before Combining Them
Results that share a broad metric name may not support comparison.
Check the metric definition, fixed and runtime parameters, output
statistic, traffic population, path, direction, interval, and
measurement method [RFC8911].
The same applies across Active, Passive, and Hybrid measurements.
Different results can reflect different network behavior, but they
can also follow from different populations, observation points,
sampling rules, packet treatment, or method-induced effects.
11.4. Use Complementary Measurements to Reduce Ambiguity
Different metrics and methods can provide complementary evidence when
the analysis makes their scopes explicit. Loss together with delay
or queue information can constrain some explanations. Active
measurements can test selected packet characteristics or vantage
points; passive measurements can show behavior in observed production
traffic; hybrid methods can add measurement structure while retaining
Liu Expires 27 April 2027 [Page 34]
Internet-Draft Measurement Interpretation October 2026
some production-traffic characteristics. Active measurements
combined with on-path telemetry can also provide intermediate
observations that help interpret end-to-end results (see
Section 9.2).
Do not merge measurements that cover different populations or
conditions as if they measured the same event. Their differences can
still be useful evidence.
11.5. Treat Follow-up Measurements as Tests of a Hypothesis
A follow-up measurement can test whether a proposed explanation is
consistent with new observations. Active measurements can vary
direction, packet fields, flow identifiers, or vantage points.
Passive analysis can compare observation points, traffic classes,
paths, or intervals. Hybrid methods can compare marking periods,
measurement groups, or selected populations.
Changing the configuration also changes the experiment. A follow-up
result can support or weaken a hypothesis, but it does not alter the
original result or guarantee reproduction of the original conditions.
11.6. Account for Measurement-Method Effects
Measurement activity can affect the measured environment or the
completeness of the observations. Active probes consume network and
endpoint resources. Hybrid methods can modify packet fields,
treatment, or offered load. Passive methods leave the stream of
interest unchanged, but limited capture, export, and collection
resources can omit observations; export traffic can also add load.
These effects matter when they are large enough to change the
measured property or the completeness of the data.
11.7. Interpretation Across Administrative Boundaries
A measurement that spans several administrative domains can remain
valid even when the observer cannot identify which domain contributed
to the result. Internal routing, forwarding, filtering, policing,
validation, or measurement-system information may be unavailable.
Coordination can reduce uncertainty, but lack of visibility is not
evidence of attribution. Statements about another domain should
separate measured facts from explanations that shared operational
evidence supports.
Liu Expires 27 April 2027 [Page 35]
Internet-Draft Measurement Interpretation October 2026
11.8. Report Result, Evidence, Inference, and Uncertainty Separately
A report that includes interpretation should distinguish:
* the metric result and its measurement scope;
* the supporting evidence;
* any generalization or inferred operational explanation; and
* remaining uncertainty, assumptions, and plausible alternatives.
Where relevant, include the metric definition or registry entry,
fixed and runtime parameters, measurement method, traffic population,
observation scope, and interval. This keeps the metric result
separate from the reasoning built on top of it.
12. Security Considerations
This document does not change the security properties of existing
measurement, routing, forwarding, or security mechanisms. The
measurements and supporting context used during interpretation create
the main security considerations.
Do not create broad exemptions for measurement traffic from
filtering, policing, or validation. If operations require an
exception, limit its scope and keep it consistent with local policy.
Active measurements can expose path selection, filtering, policing,
or other traffic-treatment behavior when operators vary packet
fields, source addresses, traffic classes, or flow identifiers.
Operators should authorize such measurements and keep them consistent
with operational policy.
Passive and hybrid measurements can expose information about
production traffic, observation points, path behavior, and marking
state. Access controls should protect detailed measurement data and
configuration.
Supporting context can also be sensitive. Routing and forwarding
state, policy configuration, customer attachment information,
counters, logs, observation-system state, and controller information
can reveal topology, policy, or customer relationships. Reports
shared outside an administrative domain should disclose only the
information their purpose requires.
Liu Expires 27 April 2027 [Page 36]
Internet-Draft Measurement Interpretation October 2026
The integrity and freshness of supporting context shape the resulting
interpretation. Stale, incomplete, inconsistent, or modified
telemetry, counters, logs, measurement records, or controller state
can lead to incorrect attribution.
13. Privacy Considerations
Performance measurement data can contain source and destination
addresses, endpoint identifiers, timestamps, flow identifiers, packet
fields, traffic classes, marking state, observation-point
information, and delivery outcomes. Correlation with operational
context can reveal network structure, endpoint activity, customer
relationships, or policy behavior.
Passive and hybrid measurements can observe production traffic. Even
without payload collection, metadata such as addresses, timing,
packet treatment, path information, marking state, and traffic volume
can reveal information about users, services, or traffic patterns.
Collect only the information needed for the measurement and its
intended interpretation. Reports should omit customer mappings,
detailed policy, internal topology, or other sensitive information
that the intended purpose does not require. Local policy should
govern access and retention.
Across administrative boundaries, a domain may disclose the measured
result or a supported interpretation without disclosing the
underlying internal evidence. Reporting and operational procedures
should preserve that distinction.
14. IANA Considerations
This document has no IANA actions.
15. Informative References
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2678, DOI 10.17487/RFC2678, September
1999, <https://www.rfc-editor.org/rfc/rfc2678>.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
September 1999, <https://www.rfc-editor.org/rfc/rfc2681>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/rfc/rfc2827>.
Liu Expires 27 April 2027 [Page 37]
Internet-Draft Measurement Interpretation October 2026
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002,
<https://www.rfc-editor.org/rfc/rfc3393>.
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432,
DOI 10.17487/RFC3432, December 2002,
<https://www.rfc-editor.org/rfc/rfc3432>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/rfc/rfc3704>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<https://www.rfc-editor.org/rfc/rfc4656>.
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
S., and J. Perser, "Packet Reordering Metrics", RFC 4737,
DOI 10.17487/RFC4737, November 2006,
<https://www.rfc-editor.org/rfc/rfc4737>.
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity",
RFC 5136, DOI 10.17487/RFC5136, February 2008,
<https://www.rfc-editor.org/rfc/rfc5136>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/rfc/rfc5357>.
[RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric",
RFC 5560, DOI 10.17487/RFC5560, May 2009,
<https://www.rfc-editor.org/rfc/rfc5560>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/rfc/rfc6291>.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390,
DOI 10.17487/RFC6390, October 2011,
<https://www.rfc-editor.org/rfc/rfc6390>.
Liu Expires 27 April 2027 [Page 38]
Internet-Draft Measurement Interpretation October 2026
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
IP Network Performance Metrics: Different Points of View",
RFC 6703, DOI 10.17487/RFC6703, August 2012,
<https://www.rfc-editor.org/rfc/rfc6703>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <https://www.rfc-editor.org/rfc/rfc7679>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <https://www.rfc-editor.org/rfc/rfc7680>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/rfc/rfc7799>.
[RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced
Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
RFC 8704, DOI 10.17487/RFC8704, February 2020,
<https://www.rfc-editor.org/rfc/rfc8704>.
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
Two-Way Active Measurement Protocol", RFC 8762,
DOI 10.17487/RFC8762, March 2020,
<https://www.rfc-editor.org/rfc/rfc8762>.
[RFC8911] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
Akhter, "Registry for Performance Metrics", RFC 8911,
DOI 10.17487/RFC8911, November 2021,
<https://www.rfc-editor.org/rfc/rfc8911>.
[RFC9065] Fairhurst, G. and C. Perkins, "Considerations around
Transport Header Confidentiality, Network Operations, and
the Evolution of Internet Transport Protocols", RFC 9065,
DOI 10.17487/RFC9065, July 2021,
<https://www.rfc-editor.org/rfc/rfc9065>.
[RFC9097] Morton, A., Geib, R., and L. Ciavattone, "Metrics and
Methods for One-Way IP Capacity", RFC 9097,
DOI 10.17487/RFC9097, November 2021,
<https://www.rfc-editor.org/rfc/rfc9097>.
Liu Expires 27 April 2027 [Page 39]
Internet-Draft Measurement Interpretation October 2026
[RFC9232] Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and
A. Wang, "Network Telemetry Framework", RFC 9232,
DOI 10.17487/RFC9232, May 2022,
<https://www.rfc-editor.org/rfc/rfc9232>.
[RFC9312] Kühlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", RFC 9312, DOI 10.17487/RFC9312,
September 2022, <https://www.rfc-editor.org/rfc/rfc9312>.
[RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
and T. Zhou, "Alternate-Marking Method", RFC 9341,
DOI 10.17487/RFC9341, December 2022,
<https://www.rfc-editor.org/rfc/rfc9341>.
[RFC9343] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
Pang, "IPv6 Application of the Alternate-Marking Method",
RFC 9343, DOI 10.17487/RFC9343, December 2022,
<https://www.rfc-editor.org/rfc/rfc9343>.
[RFC10014] Pignataro, C., Farrel, A., and T. Mizrahi, "Guidelines for
Characterizing the Term "OAM"", BCP 161, RFC 10014,
DOI 10.17487/RFC10014, June 2026,
<https://www.rfc-editor.org/rfc/rfc10014>.
[I-D.ietf-ippm-on-path-active-measurements]
Fioccola, G., Zhu, K., Zhou, T., Zhu, Y., and X. Min, "On-
Path Telemetry for Active Performance Measurements", Work
in Progress, Internet-Draft, draft-ietf-ippm-on-path-
active-measurements-03, 28 August 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-on-
path-active-measurements-03>.
Acknowledgements
The author thanks Giuseppe Fioccola for reviewing this document and
significantly helpful comments to improve the document, and Ruediger
Geib, Tim Chown, and Ike Kunze for their helpful comments and
discussion.
Author's Address
Libin Liu
Zhongguancun Laboratory
Beijing
China
Email: liulb@zgclab.edu.cn
Liu Expires 27 April 2027 [Page 40]