Considerations for Interpreting Packet Loss Observed by Active Performance Measurements
draft-liu-ippm-active-loss-considerations-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-07-01 | ||
| 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-active-loss-considerations-00
IPPM L. Liu
Internet-Draft Zhongguancun Laboratory
Intended status: Informational 1 July 2026
Expires: 2 January 2027
Considerations for Interpreting Packet Loss Observed by Active
Performance Measurements
draft-liu-ippm-active-loss-considerations-00
Abstract
Active performance measurement protocols and metrics are commonly
used to measure packet loss, delay, delay variation, reachability,
and path behavior. When an active measurement packet is not
received, a response is missing, or a measurement exchange times out,
the measurement result identifies the observable outcome but often
does not identify the underlying cause.
Loss observed by active performance measurements can be associated
with congestion, queue discard, link or forwarding failures, routing
changes, endpoint or reflector behavior, administrative filtering,
policing, multipath effects, or validation-related packet discard
such as Source Address Validation (SAV). Different operational
conditions can produce similar measurement observations, but they may
have different meanings and require different troubleshooting
actions.
This document discusses considerations for interpreting packet loss
observed by active performance measurements. It provides a common
set of considerations for separating measured outcomes from inferred
causes, describes operational conditions that can lead to observed
loss, discusses implications for one-way and two-way measurements,
delay and delay variation interpretation, OWAMP, TWAMP, STAMP, and
measurements over ECMP and link aggregation. It also discusses how
some considerations may apply to hybrid and passive performance
measurements and identifies sources of operational context that can
help operators and measurement systems reason about possible
explanations.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Liu Expires 2 January 2027 [Page 1]
Internet-Draft Active Loss Interpretation July 2026
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 2 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Observable Loss and Unobservable Causes . . . . . . . . . 9
3.2. Ambiguity in One-way and Two-way Measurements . . . . . . 9
3.3. Flow-dependent, Path-dependent, and Time-dependent
Loss . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Delay and Delay Variation Interpretation . . . . . . . . 10
3.5. Measurement Traffic and Operational Context . . . . . . . 11
4. Operational Conditions Associated with Observed Loss . . . . 11
4.1. Congestion and Queue Discard . . . . . . . . . . . . . . 11
4.2. Link, Forwarding, and Routing Failures . . . . . . . . . 12
4.3. Endpoint and Reflector Behavior . . . . . . . . . . . . . 13
4.4. Policy, Filtering, and Policing . . . . . . . . . . . . . 13
4.5. Validation-related Discard . . . . . . . . . . . . . . . 14
4.6. Multipath and Load-balancing Effects . . . . . . . . . . 14
4.7. Transient Loss During Convergence or Updates . . . . . . 15
5. Implications for Active Performance Measurement Results . . . 15
5.1. Implications for Packet Loss Measurement . . . . . . . . 16
5.2. Implications for One-way Measurement . . . . . . . . . . 16
Liu Expires 2 January 2027 [Page 2]
Internet-Draft Active Loss Interpretation July 2026
5.3. Implications for Two-way and Reflected Measurement . . . 17
5.4. Implications for Delay and Delay Variation
Interpretation . . . . . . . . . . . . . . . . . . . . . 17
5.5. Implications for OWAMP, TWAMP, and STAMP . . . . . . . . 18
5.6. Implications for Measurement over ECMP and Link
Aggregation . . . . . . . . . . . . . . . . . . . . . . . 18
6. Considerations for Measurement Result Interpretation . . . . 19
6.1. Separating Observed Loss from Inferred Cause . . . . . . 19
6.2. Considering Direction and Measurement Role . . . . . . . 19
6.3. Considering Flow and Path Selection . . . . . . . . . . . 20
6.4. Considering Timing and Transient Events . . . . . . . . . 20
6.5. Considering Delay and Delay Variation . . . . . . . . . . 20
6.6. Considering Measurement Traffic Representativeness . . . 21
6.7. Considering Validation-related Discard . . . . . . . . . 21
7. Applicability to Active, Hybrid, and Passive Performance
Measurements . . . . . . . . . . . . . . . . . . . . . . 21
8. Possible Sources of Additional Context . . . . . . . . . . . 22
8.1. Measurement Result Reporting . . . . . . . . . . . . . . 23
8.2. Routing and Forwarding State . . . . . . . . . . . . . . 23
8.3. Interface, Queue, and Discard Counters . . . . . . . . . 23
8.4. Policy, Filtering, Policing, and Validation State . . . . 24
8.5. Endpoint, Reflector, and Session State . . . . . . . . . 24
8.6. OAM and Telemetry Correlation . . . . . . . . . . . . . . 24
8.7. Operator-provided or Controller-provided Context . . . . 24
9. Deployment and Operational Considerations . . . . . . . . . . 25
9.1. Correlation with Network Events . . . . . . . . . . . . . 25
9.2. Interpretation Across Administrative Boundaries . . . . . 25
9.3. Limitations of Cause Attribution . . . . . . . . . . . . 26
9.4. Use of Controlled Measurements . . . . . . . . . . . . . 26
9.5. Reporting Uncertainty . . . . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
13. Informative References . . . . . . . . . . . . . . . . . . . 28
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction
The IP Performance Measurement (IPPM) framework and related protocols
are used to measure packet loss, delay, delay variation,
reachability, and other aspects of packet delivery behavior [RFC7679]
[RFC7680] [RFC2681] [RFC3393]. This document focuses primarily on
active performance measurements, where measurement traffic is
generated for the purpose of measuring packet delivery behavior
[RFC7799]. Active measurement methods commonly rely on test packets
sent between measurement points and, in reflected methods, on
response packets generated by a remote endpoint. Examples include
Liu Expires 2 January 2027 [Page 3]
Internet-Draft Active Loss Interpretation July 2026
OWAMP [RFC4656], TWAMP [RFC5357], and STAMP [RFC8762].
When an active measurement packet is not received, a response is
missing, or a measurement exchange times out, the measurement system
can usually identify the observable outcome. For example, a packet
can be counted as lost, a response can be reported as missing, or a
sample can be treated as incomplete. However, the measurement result
alone often does not identify why the packet was not delivered.
There are many possible causes of packet loss. Packets can be
discarded because of congestion or queue overflow, link failure,
forwarding failure, routing convergence, endpoint or reflector
behavior, administrative filtering, policing, load-balancing
behavior, packet corruption, or other operational conditions.
Packets can also be discarded by validation mechanisms, including
Source Address Validation (SAV), when the source address or
validation context is not accepted by the network [RFC2827] [RFC3704]
[RFC8704]. Existing IPPM reporting guidance also recognizes that
packet loss can have multiple causes and that reporting context is
important for interpretation [RFC6703].
This creates an interpretation problem. A packet counted as lost by
an active measurement is lost from the perspective of that
measurement, but the operational meaning of the loss can differ
depending on the cause. Congestion-related loss may suggest
capacity, queue management, or traffic engineering issues.
Forwarding or routing loss may suggest control-plane or data-plane
instability. Endpoint or reflector behavior may indicate
measurement-system issues. Policy, filtering, policing, or
validation-related discard may indicate that the packet was not
delivered because of the treatment applied by a device, endpoint, or
network domain. These causes may produce similar measurement
observations, while requiring different operational responses.
Although packet loss is the primary focus of this document, similar
interpretation issues can also arise for delay and delay variation
observations. Delay and delay variation values are measured for
packets that are successfully received, and they can be affected by
queueing, path selection, timestamping behavior, endpoint or
reflector processing, and selective loss. Therefore, loss, delay,
and delay variation are often interpreted together when reasoning
about active measurement results.
The ambiguity can be greater in one-way, two-way, reflected, and
multipath measurements. In a one-way measurement, loss is observed
in one direction but the discard point may be unknown. In a two-way
or reflected measurement, a missing response may be caused by loss of
the forward packet, loss of the reflected packet, reflector behavior,
Liu Expires 2 January 2027 [Page 4]
Internet-Draft Active Loss Interpretation July 2026
or policy applied in either direction. In ECMP or link aggregation
environments, loss may depend on flow identifiers and component
paths. During routing, forwarding, policy, or validation-state
changes, loss may be transient and difficult to distinguish from
other short-lived events.
This document focuses on the relationship between observable outcomes
from active performance measurements and the operational context
needed to interpret them. It does not define new metrics, protocols,
or mechanisms for determining the cause of every loss event, and it
does not assign a single cause to all observed loss. Instead, it
provides a common set of considerations for separating measured
outcomes from inferred causes and for identifying operational context
that can make particular explanations more or less plausible. Some
of these considerations may also be applicable to hybrid and passive
performance measurements, as discussed in Section 7.
Section 3 describes the general problem of observed loss and
ambiguous causes in active performance measurements. Section 4
summarizes operational conditions associated with loss observed by
active performance measurements, including validation-related discard
such as SAV. Section 5 discusses the implications of loss
interpretation ambiguity for different measurement methods and
metrics, including delay and delay variation interpretation.
Section 6 discusses interpretation considerations. Section 7
discusses how the considerations relate to active, hybrid, and
passive performance measurements. Section 8 discusses sources of
additional operational context, and Section 9 discusses deployment
and operational considerations. Section 10 and Section 11 discuss
security and privacy considerations, respectively.
2. Terminology
The terms Active Performance Measurement, Passive Performance
Measurement, and Hybrid Performance Measurement are used consistently
with the classification in [RFC7799]. Where terms are already
defined in existing IPPM, OWAMP, TWAMP, STAMP, or SAV-related
documents, this document uses those terms consistently with their
existing definitions.
Active Performance Measurement: A measurement method in which
dedicated measurement traffic is generated for the purpose of
measuring packet delivery behavior. This document primarily focuses
on active performance measurements.
Passive Performance Measurement: A measurement method that observes
existing traffic without generating dedicated measurement packets for
the purpose of the measurement.
Liu Expires 2 January 2027 [Page 5]
Internet-Draft Active Loss Interpretation July 2026
Hybrid Performance Measurement: A measurement method that combines
aspects of active and passive measurement. For example, a hybrid
method may use production traffic with additional marking, sampling,
or measurement processing.
Active Measurement Packet: A packet generated, transmitted, received,
or reflected for the purpose of performing an active performance
measurement. Active measurement packets include, but are not limited
to, packets used by OWAMP, TWAMP, STAMP, and other active measurement
methods.
Observed Loss: An active measurement observation indicating that an
expected active measurement packet or response was not received, or
that a measurement exchange did not complete as expected. Observed
loss describes the measurement outcome and does not by itself
identify the underlying cause.
Observed Delay and Delay Variation: Measurement observations derived
from packets that are successfully received and timestamped. Such
observations describe the measured timing behavior of the received
packets, but they do not by themselves identify all operational
conditions that contributed to the delay or delay variation.
Loss Cause: The operational condition or mechanism that caused a
measurement packet or response not to be delivered. Examples include
congestion, queue discard, link failure, forwarding failure, routing
convergence, endpoint behavior, administrative filtering, policing,
multipath behavior, or validation-related discard.
Inferred Loss Cause: A loss cause identified by analysis or
correlation rather than directly observed by the active measurement
result alone. An inferred cause may be supported by operational
context such as counters, logs, routing events, endpoint state, OAM
information, or telemetry.
Measurement Flow: A set of measurement packets that share packet
header fields or other properties relevant to forwarding, load
balancing, filtering, policing, validation, or treatment by a
network. Measurement flows with different header fields may
experience different paths or policies.
Measurement Endpoint: A system that sends, receives, reflects, or
reports measurement packets or measurement results. A measurement
endpoint may act as a sender, receiver, reflector, session-sender,
session-reflector, or other measurement role depending on the
measurement protocol in use.
Liu Expires 2 January 2027 [Page 6]
Internet-Draft Active Loss Interpretation July 2026
Reflector: A measurement endpoint that receives an active measurement
packet and sends a corresponding response or reflected packet. In
reflected measurement methods, a missing response can be caused by
loss in the forward direction, loss in the reverse direction,
reflector behavior, policy, validation, or other causes.
One-way Measurement: A measurement in which packets are measured from
a sending measurement endpoint to a receiving measurement endpoint in
one direction.
Two-way Measurement: A measurement in which the observed result
depends on packet delivery in both the forward and reverse
directions. A two-way measurement may use a reflected packet or
response packet.
Operational Context: Control-plane, management-plane, data-plane,
OAM, telemetry, endpoint, controller, or operator-provided
information that can help interpret observed loss. Such context may
include routing state, forwarding state, interface state, queue and
discard counters, policy state, filtering state, policing state,
validation state, endpoint logs, event records, or measurement
configuration.
Validation-related Discard: Packet discard by a validation function
that decides whether a packet is acceptable according to a validation
context. Source Address Validation is one example of a validation
function. Such discard may appear as observed loss in active
measurements.
Source Address Validation (SAV): A function that checks whether the
source address of a packet is valid according to validation state or
rules applied by a network device or network domain. SAV can be
applied at customer-facing interfaces, provider-facing interfaces,
peer-facing interfaces, or other ingress points
[I-D.ietf-savnet-intra-domain-problem-statement]
[I-D.ietf-savnet-inter-domain-problem-statement].
Validation Context: The information used by a validation function
when deciding whether a packet is acceptable. For SAV, the
validation context may include the source address, receiving
interface, customer attachment point, routing information, prefix
ownership information, local policy, or other information used to
construct or apply validation state.
Path-dependent Loss: Observed loss that occurs only on certain paths,
interfaces, component links, ingress points, or load-balancing
outcomes.
Liu Expires 2 January 2027 [Page 7]
Internet-Draft Active Loss Interpretation July 2026
Transient Loss: Observed loss that occurs for a limited period of
time due to a temporary operational condition, such as routing
convergence, topology change, forwarding update, policy update,
endpoint state change, or validation-state update.
3. Problem Statement
Active performance measurements are commonly used to characterize
packet delivery behavior in IP networks. Packet loss, delay, delay
variation, reachability, and related measurement results are often
used by operators and measurement systems to infer whether a measured
path or service is experiencing performance degradation, forwarding
problems, endpoint problems, or other operational issues.
The observable result of an active measurement is not always
sufficient to identify the cause of loss. A measurement endpoint may
determine that an expected packet or response was not received, but
may not be able to determine whether the packet was discarded because
of congestion, forwarding failure, routing change, link failure,
policy filtering, policing, endpoint behavior, validation, or another
condition. This is an interpretation problem around the relationship
between measured outcomes and inferred causes, not a problem with the
definition of packet loss itself.
A packet counted as lost by a measurement method is still lost from
the perspective of that measurement. However, the operational
meaning of the loss depends on why the packet was not delivered.
Treating all observed loss as congestion can lead to unnecessary
capacity or queue-management investigation. Treating all missing
responses as endpoint failure can lead to misdirected
troubleshooting. Treating all unexplained loss as policy or
validation loss can hide genuine performance degradation.
Delay and delay variation observations can also require
interpretation. A measured delay value describes the timing of a
packet that was successfully received, but it may be influenced by
queueing, path selection, timestamping behavior, endpoint or
reflector processing, or other operational conditions. In addition,
when loss is selective, delay and delay variation statistics are
computed only from the delivered subset of packets. This can affect
how delay-related results are interpreted together with observed
loss.
The problem is not limited to persistent failures. Observed loss can
be flow-dependent, path-dependent, direction-dependent, or time-
dependent. It can occur only for certain packet header fields,
certain ECMP or link aggregation outcomes, certain directions, or
certain intervals during routing, forwarding, policy, or validation
Liu Expires 2 January 2027 [Page 8]
Internet-Draft Active Loss Interpretation July 2026
updates. Therefore, even when measurement protocols operate
correctly, interpreting their results may require additional
operational context.
This section describes five aspects of the problem. Section 3.1
describes the distinction between observable loss and unobservable
causes. Section 3.2 discusses ambiguity in one-way and two-way
measurements. Section 3.3 discusses flow-dependent, path-dependent,
and time-dependent loss. Section 3.4 discusses delay and delay
variation interpretation. Section 3.5 discusses the relationship
between measurement traffic and operational context.
3.1. Observable Loss and Unobservable Causes
Observed loss is a measurement outcome. It indicates that an
expected packet or response was not received, or that a measurement
exchange did not complete as expected. It does not, by itself,
identify the device, interface, queue, policy, endpoint, or mechanism
responsible for the loss.
This distinction is important because many operational conditions can
produce the same observation. An active measurement packet that is
discarded by a congested queue, discarded by a filtering policy, lost
during convergence, discarded by a validation function, or never
processed by a reflector may appear as a lost packet or missing
response at the measurement endpoint.
IPPM metrics can correctly report the loss while leaving the cause
unresolved. The unresolved cause becomes important when measurement
results are used for troubleshooting, service assurance, or
operational decisions.
3.2. Ambiguity in One-way and Two-way Measurements
In a one-way measurement, a packet is sent from one measurement
endpoint to another. If the receiver does not receive the packet,
the measurement can report loss in that direction. However, the
discard point and cause may remain unknown without additional
information.
In a two-way or reflected measurement, the ambiguity is greater. A
missing response may mean that the forward packet did not reach the
reflector, that the reflector received the packet but did not
generate a response, that the reflected packet was lost on the return
path, or that filtering, policing, validation, congestion, or
endpoint behavior affected either direction.
Liu Expires 2 January 2027 [Page 9]
Internet-Draft Active Loss Interpretation July 2026
This ambiguity affects interpretation of protocols such as TWAMP and
STAMP, where the sender may observe an incomplete exchange without
direct visibility into all points along the forward and reverse
paths. The same issue can occur with any reflected measurement
method when only the sender-side outcome is available.
3.3. Flow-dependent, Path-dependent, and Time-dependent Loss
Observed loss can depend on packet header fields and path selection.
In ECMP, link aggregation, segment routing, tunneling, or policy-
based forwarding environments, packets between the same measurement
endpoints may traverse different component paths depending on source
and destination addresses, transport ports, protocol numbers, IPv6
flow labels, encapsulation fields, or other fields.
If different paths have different congestion levels, link conditions,
policy state, validation state, or forwarding behavior, loss may
appear only for some measurement flows. A measurement using one flow
may report no loss, while another measurement between the same
endpoints but with different header fields may report loss. This
does not necessarily indicate inconsistency in the measurement
method; it may reflect different treatment of different packets.
Observed loss can also be time-dependent. Loss during routing
convergence, forwarding updates, topology changes, policy changes,
queue microbursts, endpoint overload, or validation-state updates may
disappear after the event. Coarse aggregation can hide such behavior
and make correlation with operational events difficult.
3.4. Delay and Delay Variation Interpretation
Delay and delay variation observations describe timing behavior for
packets that are successfully received and timestamped. They do not
directly identify the operational conditions that contributed to the
measured values.
For example, increased delay or delay variation may be associated
with queueing, path changes, load balancing, tunneling behavior,
endpoint processing, reflector processing, timestamping behavior, or
other conditions. These conditions may overlap with those that cause
packet loss, but the measurement observation alone may not
distinguish among them.
Observed loss can also affect delay and delay variation
interpretation. When packets are lost, they do not contribute delay
samples. If loss is selective, delay statistics may describe only
the subset of packets that were delivered, rather than the full set
of packets transmitted by the measurement.
Liu Expires 2 January 2027 [Page 10]
Internet-Draft Active Loss Interpretation July 2026
3.5. Measurement Traffic and Operational Context
Measurement traffic may differ from the production traffic or service
behavior that the measurement is intended to characterize. Active
measurement packets may use different source addresses, destination
addresses, transport ports, packet sizes, DSCP values,
encapsulations, flow labels, or endpoint addresses. These
differences can affect forwarding, load balancing, filtering,
policing, validation, and endpoint processing.
This is not unique to any one cause of packet loss. However, it is
important for interpreting observed loss because the cause may depend
on exactly how the active measurement packet was treated. A
measurement packet using an infrastructure address, loopback address,
dedicated test prefix, or specific UDP port may experience different
treatment from application traffic or customer traffic.
Therefore, interpretation should consider the measurement
configuration and packet characteristics together with the
operational context. The relevant question is not only whether loss
occurred, but also which packets experienced loss, when the loss
occurred, what direction was affected, what path was likely used, and
what network or endpoint state existed at the time.
4. Operational Conditions Associated with Observed Loss
This section summarizes operational conditions that may be associated
with loss observed by active performance measurements. The list is
not exhaustive and is not intended to define a complete taxonomy of
network faults. Its purpose is to provide a structure for
interpreting IPPM results and to show that similar measurement
observations can arise from different conditions. Some of these
conditions may also affect observed delay and delay variation, even
when they do not result in packet loss.
4.1. Congestion and Queue Discard
Congestion and queue discard are common causes of packet loss. An
active measurement packet may be discarded when a queue overflows,
when an active queue management mechanism marks or discards packets,
or when transient microbursts exceed available buffering.
Liu Expires 2 January 2027 [Page 11]
Internet-Draft Active Loss Interpretation July 2026
For IPPM interpretation, congestion-related loss is not only a
question of whether congestion exists somewhere in the network. It
can also depend on the packet type and treatment used by the
measurement traffic, including DSCP, packet size, flow identifiers,
queue selection, and path selection. Loss observed by one
measurement flow may not represent loss for another traffic class or
packet type.
Congestion-related loss is often interpreted as performance
degradation. This interpretation may be appropriate when loss
correlates with high utilization, queue occupancy, queue drops,
latency increase, or congestion indicators. However, packet loss
alone does not prove congestion. Other causes can produce similar
loss observations without implying that the path lacks capacity.
Congestion-related loss can be persistent or transient. Persistent
congestion may be visible over longer measurement intervals, while
short-lived bursts may require fine-grained timing information.
Aggregated loss ratios may hide the burst structure and make it
difficult to distinguish congestion from other transient events.
4.2. Link, Forwarding, and Routing Failures
Packets may be lost because of link failures, physical errors,
forwarding-plane faults, FIB inconsistencies, routing loops,
blackholes, tunnel failures, or routing convergence. Such loss may
affect all traffic on a path or only traffic using a particular
route, tunnel, next hop, or component link.
Routing and forwarding failures can resemble congestion loss in IPPM
results. A measurement may report lost packets or missing responses
without indicating whether packets were queued and discarded,
forwarded along an unexpected path, or sent into a blackhole. In
reflected measurements, a routing or forwarding problem on either the
forward or return path can appear as the same sender-side timeout.
Correlation with routing events, interface state, forwarding state,
and path information can help distinguish these cases.
Routing convergence can also produce transient loss. During the
interval in which different devices have different routing or
forwarding state, some packets may be discarded or forwarded along
paths that are not yet stable. Such events can overlap with other
causes, including policy or validation updates.
Liu Expires 2 January 2027 [Page 12]
Internet-Draft Active Loss Interpretation July 2026
4.3. Endpoint and Reflector Behavior
Loss observed by active measurements can be caused by behavior at
measurement endpoints or reflectors. A receiver may be unavailable,
overloaded, not configured to process the measurement traffic, or
unable to process packets at the offered rate. A reflector may
receive a packet but fail to generate or transmit a response because
of local policy, resource limits, implementation behavior, or session
state.
Endpoint-related causes are especially important in two-way and
reflected measurements. A missing response may be interpreted as
network loss even when the forward packet reached the reflector.
Without reflector-side information, sender-side observations may not
distinguish endpoint behavior from network discard.
Endpoint configuration can also affect interpretation. Source
address selection, interface binding, firewall rules, rate limits,
session state, timestamping behavior, and authentication or
authorization state may affect whether measurement packets are
accepted, processed, or reflected.
4.4. Policy, Filtering, and Policing
Packets may be discarded because of administrative policy, access
control lists, firewall rules, service filters, anti-abuse
mechanisms, or policing. Such behavior may be intentional and
locally correct, even though it appears as loss to the measurement
system.
Policy-related loss can be source-address-dependent, destination-
dependent, protocol-dependent, port-dependent, DSCP-dependent,
direction-dependent, or interface-dependent. This is particularly
relevant to IPPM because active measurement packets may use
addresses, ports, authentication state, packet sizes, or DSCP values
that differ from the traffic being characterized. An active
measurement packet may be filtered while production traffic is
allowed, or production traffic may be filtered while the active
measurement packet is allowed, depending on the policy and packet
characteristics.
Policing can also produce loss patterns that resemble congestion.
Unlike general queue congestion, policing may apply only to specific
traffic classes, rates, customers, protocols, or interfaces.
Interpreting such loss may require policy configuration, policer
counters, or class-specific discard information.
Liu Expires 2 January 2027 [Page 13]
Internet-Draft Active Loss Interpretation July 2026
4.5. Validation-related Discard
Validation-related discard occurs when a packet is discarded because
a validation function determines that the packet is not acceptable in
the applicable context. Source Address Validation is one example.
SAV is used to limit packets with spoofed source addresses and is
commonly associated with ingress filtering and uRPF-related
mechanisms [RFC2827] [RFC3704] [RFC8704].
In well-configured and stable deployments, SAV is expected to have no
effect on measurement packets that use legitimate source addresses
and valid paths. The primary interpretation issue is not normal SAV
operation, but the possibility that validation-related discard is one
cause among several possible causes of observed loss when validation
state is stale, incomplete, inconsistent with forwarding state, or
applied to measurement traffic with a different validation context.
For example, an active measurement packet using a legitimate source
address may arrive on an interface where that source is not
considered valid because routing, policy, or validation state is
temporarily inconsistent. A reflected packet may use a source
address or return path that is valid in general but not accepted in
the selected validation context. In such cases, the measurement may
observe loss, timeout, or missing response, while the cause remains
indistinguishable from other discard causes without additional
context.
Validation-related discard should not be assumed whenever SAV is
deployed. Conversely, the possibility of validation-related discard
should not be ignored when loss is source-address-dependent,
interface-dependent, path-dependent, or correlated with validation-
state changes. Interpretation should be based on measurement results
together with operational evidence such as validation state,
counters, routing state, and event timing.
4.6. Multipath and Load-balancing Effects
In networks using ECMP, link aggregation, or other multipath
mechanisms, packet loss may depend on the component path selected for
a measurement flow. Different component paths may have different
congestion levels, link states, forwarding behavior, policy
configuration, or validation state.
Liu Expires 2 January 2027 [Page 14]
Internet-Draft Active Loss Interpretation July 2026
This can cause flow-specific or intermittent loss. A measurement
flow assigned to one component path may be delivered successfully,
while another flow between the same endpoints may experience loss. A
change in UDP port number, IPv6 flow label, source address,
destination address, or encapsulation field may change the path and
therefore change the observed result.
Multipath effects can complicate repeatability. Repeating a
measurement with different header fields may test a different path
rather than reproducing the same condition. Aggregate loss
statistics can also hide the fact that loss is concentrated on one
component path.
4.7. Transient Loss During Convergence or Updates
Transient loss can occur during routing convergence, link failure and
restoration, FIB updates, tunnel reoptimization, policy changes,
security rule updates, validation-state changes, endpoint restart, or
measurement session changes. Such loss may last for a short interval
and disappear without a persistent failure.
Transient loss can be difficult to interpret because multiple changes
may occur at nearly the same time. A burst of loss during
convergence may be caused by forwarding disruption, queue buildup,
micro-loops, policy update, validation update, or endpoint state
changes. Measurement results alone may not distinguish among these
causes.
Fine-grained timing information is important for interpreting
transient loss. Packet timestamps, sequence numbers, short-interval
loss statistics, and event logs can help determine whether observed
loss coincides with routing, forwarding, policy, endpoint, or
validation events.
5. Implications for Active Performance Measurement Results
Different loss causes can appear in active performance measurement
results in similar observable ways. A lost packet is reported as
lost, a missing response is reported as missing, and a timeout is
reported as a timeout. The main implications are often for
interpretation rather than for the syntactic form of the result. The
interpretation issue is not limited to loss metrics. Delay and delay
variation observations may also require operational context, because
measured timing values can be affected by queueing, path selection,
endpoint or reflector processing, timestamping behavior, and the
subset of packets that were successfully received.
Liu Expires 2 January 2027 [Page 15]
Internet-Draft Active Loss Interpretation July 2026
This section focuses on the implications of loss interpretation
ambiguity for specific active measurement methods and metrics, rather
than on identifying the cause of loss. Such ambiguity is not limited
to packet loss metrics. It can also affect the interpretation of
one-way and two-way measurements, delay and delay variation samples,
protocol-specific observations, and results in multipath
environments.
5.1. Implications for Packet Loss Measurement
Packet loss measurement determines whether transmitted measurement
packets are received at the intended endpoint or whether expected
packets are missing. The metric can report observed loss without
identifying the cause.
This means that the same packet loss ratio can have different
operational meanings. Loss caused by queue overflow suggests a
different operational condition from loss caused by ACL filtering,
forwarding blackhole, reflector overload, policing, or validation-
related discard. Therefore, a packet loss result should not be
interpreted as a specific cause unless supported by additional
evidence.
Loss patterns can provide useful clues. Loss associated with high
utilization may suggest congestion. Loss associated with a
particular source address, interface, policy, or validation context
may suggest filtering or validation. Loss associated with a
particular flow identifier may suggest load-balancing or component-
path behavior. Loss concentrated in a short interval may suggest
transient events.
5.2. Implications for One-way Measurement
In one-way measurement, the result describes packet delivery behavior
in one direction. If a packet is not received, the measurement can
report loss in that direction, but the discard point and cause may be
unknown.
One-way measurements can help isolate directionality, because each
direction can be measured separately. However, even a direction-
specific result may have multiple causes, including congestion,
routing failure, filtering, policing, validation, or receiver
behavior along that direction.
Liu Expires 2 January 2027 [Page 16]
Internet-Draft Active Loss Interpretation July 2026
Delay and delay variation in one-way measurements are computed only
for packets that are successfully received. Packets that are lost
due to any cause do not contribute delay samples. If loss is
selective rather than random, the received packets may not represent
the full transmitted set.
5.3. Implications for Two-way and Reflected Measurement
In two-way or reflected measurement, the result depends on delivery
of a forward packet, reflector processing, and delivery of a response
or reflected packet. A missing response therefore has multiple
possible explanations.
The forward packet may have been lost before reaching the reflector.
The reflector may have received the packet but failed to process or
reflect it. The reflected packet may have been lost on the return
path. Policy, policing, filtering, validation, congestion, or
endpoint behavior may affect either direction.
This ambiguity means that a missing response should normally be
interpreted as an incomplete exchange rather than proof of a specific
failure location. When available, reflector-side information can
help distinguish forward-path loss, reflector behavior, and return-
path loss.
5.4. Implications for Delay and Delay Variation Interpretation
Delay and delay variation metrics are computed from packets that are
successfully received and timestamped. A measured delay value or
delay variation value describes the observed timing behavior of those
packets, but it does not by itself identify all operational
conditions that contributed to the value.
Increased delay or delay variation may be associated with queueing,
congestion, path changes, load balancing, tunneling behavior,
endpoint processing, reflector processing, timestamping behavior, or
clock-related issues. Some of these conditions may also cause packet
loss, while others may affect timing without causing loss.
Loss can also affect the sample population used for delay statistics.
Lost packets do not produce delay samples. If loss is random with
respect to path and packet treatment, the remaining samples may still
describe the delivered traffic reasonably well. If loss is
selective, the delay statistics may describe only the subset of
packets that avoided the affected queue, path, policy, reflector
condition, or validation context.
Liu Expires 2 January 2027 [Page 17]
Internet-Draft Active Loss Interpretation July 2026
For example, in a multipath environment, packets on one component
path may be lost while packets on another path are delivered. Delay
statistics computed from delivered packets then describe the
delivered paths, not the path where packets were lost. A report that
includes loss, delay, delay variation, and relevant packet or path
context is therefore more useful than delay statistics alone.
5.5. Implications for OWAMP, TWAMP, and STAMP
OWAMP, TWAMP, and STAMP are examples of active performance
measurement protocols that can produce observations affected by
different loss causes [RFC4656] [RFC5357] [RFC8762]. These protocols
can measure loss, delay, and delay variation, but the measurement
result may not identify why a packet or response was not delivered,
or why a particular delay or delay variation value was observed.
For OWAMP-style one-way measurement, loss can occur along the sender-
to-receiver path or at the receiver. For TWAMP-style and STAMP-style
reflected measurement, loss can occur in the forward direction, at
the reflector, or in the reverse direction. A sender-side timeout
may therefore represent several different operational conditions.
Packet fields used by these protocols and their implementations can
affect interpretation. Source address, destination address, UDP
ports, packet size, DSCP, flow label, encapsulation, authentication
state, and reflector address can influence forwarding, load
balancing, filtering, policing, validation, or endpoint processing.
5.6. Implications for Measurement over ECMP and Link Aggregation
Measurements over ECMP or link aggregation can be affected by
component-path selection. A single-flow measurement may exercise
only one path and may not reveal loss on other paths. A multi-flow
measurement may expose path-dependent loss but may also require
careful interpretation of which flow used which path.
If loss affects only some component paths, aggregate statistics may
show partial or intermittent loss. Such results can be caused by
congestion, link errors, forwarding inconsistency, policy
differences, validation differences, or other path-specific
conditions.
Interpretation of measurements over ECMP and link aggregation can
benefit from recording the header fields used for path selection,
using controlled variation of flow identifiers, and correlating
results with component-path or interface-level context.
Liu Expires 2 January 2027 [Page 18]
Internet-Draft Active Loss Interpretation July 2026
6. Considerations for Measurement Result Interpretation
When packet loss, timeouts, missing responses, incomplete samples,
delay values, or delay variation values are observed, interpretation
should separate the measurement outcome from any inferred cause. The
outcome may be directly measured; the cause usually requires
additional evidence.
The considerations in this section are intended to help operators and
measurement systems reason about observed loss. They do not imply
that any particular cause is present. Instead, they identify factors
that can make one interpretation more or less plausible, while
keeping the measured outcome distinct from the operational
hypothesis.
6.1. Separating Observed Loss from Inferred Cause
Measurement reports and operational analyses should distinguish
between observed loss and inferred cause. For example, reporting
that a packet was not received is different from reporting that the
packet was not delivered because of congestion, filtering, endpoint
behavior, or validation.
If the cause is unknown, the result should be reported as observed
loss or missing response. If the cause is inferred, the supporting
context should be identified when possible. This distinction reduces
the risk of treating an operational hypothesis as a measured fact.
6.2. Considering Direction and Measurement Role
Interpretation should consider the direction of the measurement and
the role of each endpoint. In one-way measurements, loss is
associated with a direction, but the point of discard may still be
unknown. In reflected measurements, a missing response may involve
the forward path, reflector behavior, or the return path.
Where possible, measurements in both directions and information from
both endpoints can help reduce ambiguity. For example, reflector-
side records indicating whether a forward packet was received and
whether a response was generated can help distinguish forward-path
loss from return-path loss.
Liu Expires 2 January 2027 [Page 19]
Internet-Draft Active Loss Interpretation July 2026
6.3. Considering Flow and Path Selection
Interpretation should consider the packet header fields used by the
measurement and the path-selection behavior of the network. Changes
in source address, destination address, transport ports, flow label,
encapsulation, DSCP, or packet size can change forwarding, load
balancing, filtering, policing, validation, or endpoint treatment.
If loss changes when packet headers change, the result may indicate
flow-dependent or path-dependent behavior. The change should not
automatically be interpreted as random instability or measurement
error.
6.4. Considering Timing and Transient Events
Timing is important when interpreting observed loss. Loss that
occurs near routing updates, forwarding changes, link events, policy
updates, queue bursts, endpoint restarts, or validation-state changes
may be related to those events.
Fine-grained timing information can help distinguish short-lived
events from persistent conditions. Coarse aggregation can hide loss
bursts and make correlation difficult. Measurement timestamps and
operational event timestamps should be sufficiently aligned for the
intended analysis.
6.5. Considering Delay and Delay Variation
Delay and delay variation results should be interpreted together with
the packets and paths that produced the samples. A delay value is
associated with a delivered packet, and a delay variation value is
derived from a set of delivered packets. If the delivered packets
represent only part of the transmitted measurement traffic, the
timing results may not represent packets that were lost or packets
that followed different paths.
Interpretation should consider whether delay or delay variation
changes correlate with congestion indicators, queue counters, path
changes, endpoint or reflector load, timestamping behavior, or clock-
related issues. Where loss and delay are observed together, reports
should avoid assuming that one necessarily caused the other unless
supported by additional context.
Liu Expires 2 January 2027 [Page 20]
Internet-Draft Active Loss Interpretation July 2026
6.6. Considering Measurement Traffic Representativeness
Measurement traffic may not experience the same treatment as the
traffic or service being characterized. Differences in packet type,
addressing, port numbers, DSCP, encapsulation, packet size, or
endpoint placement can affect the observed result.
This consideration is general and applies to many loss causes. For
example, an active measurement packet may avoid congestion
experienced by application traffic, may be filtered while application
traffic is allowed, may use a different ECMP path, or may use a
source address with a different validation context.
Therefore, interpretation should be tied to the specific measurement
traffic used. A successful measurement does not prove that all
traffic would be delivered, and a failed measurement does not prove
that all traffic would fail.
6.7. Considering Validation-related Discard
Validation-related discard, including SAV, should be considered as
one possible explanation for observed loss when the loss pattern is
consistent with validation behavior. This may include loss
associated with a particular source address, source prefix, ingress
interface, direction, component path, or validation-state update.
At the same time, the presence of SAV in a network does not imply
that observed loss was caused by SAV. In stable deployments with
correct validation state and legitimate measurement source addresses,
SAV should normally have little or no effect on active measurement
packets. Evidence such as validation counters, rule state, source-
prefix information, routing state, and event timing is needed before
attributing loss to validation.
This balanced interpretation avoids both over-attributing loss to
validation mechanisms and ignoring validation-related discard when it
is operationally plausible.
7. Applicability to Active, Hybrid, and Passive Performance
Measurements
This document primarily focuses on active performance measurements.
In active measurements, dedicated measurement packets are generated
for the purpose of measuring packet delivery behavior. This makes it
possible to control packet timing, packet header fields, endpoint
roles, and measurement sessions, but it also means that the
measurement traffic may not receive exactly the same treatment as
production traffic.
Liu Expires 2 January 2027 [Page 21]
Internet-Draft Active Loss Interpretation July 2026
Many considerations in this document can also be relevant to hybrid
and passive performance measurements. In passive measurements, the
observed traffic is existing traffic rather than dedicated
measurement traffic. In hybrid measurements, measurement functions
may be combined with production traffic, for example through marking,
sampling, or additional measurement processing. These approaches may
improve representativeness for the observed traffic, but they can
have different limitations, such as reduced control over packet
fields, dependence on traffic availability, sampling effects, or
different visibility into endpoint behavior.
For hybrid and passive measurements, the distinction between measured
outcome and inferred cause remains important. A packet loss
observation, delay observation, or delay variation observation still
may not directly identify whether the underlying condition was
congestion, forwarding behavior, policy, policing, endpoint behavior,
validation-related discard, or another cause. Operational context
remains necessary for interpretation.
However, not all considerations for active measurements apply
directly. In active measurements, the operator can often vary source
addresses, flow identifiers, packet sizes, DSCP values, or
measurement intervals in a controlled way. In passive or hybrid
measurements, such control may be limited or unavailable.
Conversely, passive or hybrid measurements may observe real service
traffic and may therefore avoid some representativeness issues
associated with dedicated active measurement packets.
8. Possible Sources of Additional Context
Active performance measurement results can indicate that packets were
lost, responses were missing, samples were incomplete, or delay and
delay variation values were observed. Additional context can make
some explanations more or less plausible, but it may not always
identify a definitive cause. Such context can help determine whether
an observed result is consistent with congestion, forwarding failure,
endpoint behavior, filtering, policing, validation, or another cause.
The context discussed in this section can come from measurement
systems, routers, controllers, management systems, OAM tools,
telemetry systems, endpoints, or operators. Availability and
granularity vary by deployment and administrative domain.
Liu Expires 2 January 2027 [Page 22]
Internet-Draft Active Loss Interpretation July 2026
8.1. Measurement Result Reporting
Measurement reports can support interpretation when they preserve
relevant detail. Useful information includes timestamps, sequence
numbers, measurement direction, endpoint roles, packet header fields,
measurement flow identifiers, packet size, DSCP, encapsulation,
timestamping method, clock information when relevant, and whether the
event was a one-way loss, missing response, incomplete exchange,
delay sample, or delay variation sample.
Reports should avoid implying a discard cause unless supported by
evidence. If the cause is inferred, the report should distinguish
the inference from the observed measurement outcome.
8.2. Routing and Forwarding State
Routing and forwarding state can help determine whether loss may be
related to route changes, next-hop changes, convergence, blackholes,
tunnel state, ECMP changes, or forwarding inconsistencies. Such
information can be especially useful when loss is transient or path-
dependent.
Forwarding-plane information may be needed when the actual path
differs from the expected control-plane path. This can occur with
ECMP, link aggregation, tunnels, policy-based routing, segment
routing, or local forwarding decisions.
8.3. Interface, Queue, and Discard Counters
Interface counters, queue counters, and discard counters can help
identify whether loss correlates with physical errors, congestion,
queue drops, policing, filtering, or other discard mechanisms.
Counters that distinguish specific discard causes are more useful
than aggregate counters.
Per-interface, per-queue, per-class, per-policy, per-flow, or per-
rule counters can support more precise correlation with measurement
results. However, counters may be sampled at coarse intervals or may
not align exactly with measurement packets.
For delay and delay variation interpretation, utilization
information, queue occupancy, queueing delay indicators, timestamping
configuration, and clock synchronization information can also be
useful. These data can help determine whether observed timing
behavior is consistent with congestion, queueing, path changes,
endpoint processing, or measurement-system behavior.
Liu Expires 2 January 2027 [Page 23]
Internet-Draft Active Loss Interpretation July 2026
8.4. Policy, Filtering, Policing, and Validation State
Policy and filtering state can help explain whether measurement
packets were permitted or denied by ACLs, firewalls, service filters,
or local policy. Policing state can help determine whether loss was
caused by rate limiting applied to a traffic class, customer,
protocol, or interface.
Validation state can help interpret observed loss that may be
associated with validation-related discard. For SAV, relevant
information can include source prefix-to-interface mappings, expected
ingress points, validation rule installation state, rule update
events, and validation discard counters. Such information should be
interpreted together with routing and forwarding state.
8.5. Endpoint, Reflector, and Session State
Endpoint and reflector information can help distinguish network loss
from measurement-system behavior. Useful information includes
whether the endpoint was reachable, whether the session was active,
whether the reflector received the forward packet, whether it
generated a response, and whether local rate limits or policy
affected processing.
This information is particularly valuable for two-way and reflected
measurements, where sender-side observations alone may not identify
whether the failure occurred before the reflector, at the reflector,
or after the reflector.
8.6. OAM and Telemetry Correlation
OAM tools and telemetry systems can provide additional evidence,
including path information, event records, streaming telemetry,
device state, logs, and counters [RFC9232]. Such information can
help correlate measurement loss with operational events.
Path tracing and OAM mechanisms should be interpreted carefully in
multipath environments, because the packets used for path discovery
may not follow the same path or receive the same treatment as the
measurement packets.
8.7. Operator-provided or Controller-provided Context
Operators and controllers may have information not visible to
measurement endpoints, such as maintenance events, intended policy,
controller-computed paths, validation state, rule distribution
status, known failures, or customer attachment information.
Liu Expires 2 January 2027 [Page 24]
Internet-Draft Active Loss Interpretation July 2026
Across administrative boundaries, such information may be limited.
Operators may be able to share only partial information, and
measurement reports should avoid asserting another domain's discard
cause unless supported by evidence.
9. Deployment and Operational Considerations
While Section 8 identifies information sources that may help
interpretation, this section discusses operational practices for
using such information when deploying and operating active
measurements.
Measurement endpoints, source addresses, reflector addresses, packet
header fields, measurement intervals, reporting granularity,
authorization, traffic selection, and observation points can all
affect whether loss, delay, or delay variation is observed and how
the result is interpreted.
9.1. Correlation with Network Events
Measurement results should be interpreted in relation to relevant
network events when such events are available. These events include
routing changes, forwarding updates, link failures, tunnel changes,
ECMP or link aggregation changes, policy changes, policing changes,
validation updates, endpoint maintenance, and reflector restarts.
Temporal correlation alone does not prove causality. Multiple events
may occur during the same interval. Correlation should be used to
identify plausible explanations and guide further investigation.
9.2. Interpretation Across Administrative Boundaries
Inter-domain measurements can be difficult to interpret because the
measurement endpoint may not have visibility into policy, filtering,
policing, validation, or forwarding state in another domain. A
packet may be lost near the source, in a transit network, at an
interconnection point, near the destination, or on the return path.
Operational coordination can help, but the information shared across
domains may be limited by security, privacy, business, or operational
policy. Reports should distinguish observed outcomes from inferred
causes and avoid unsupported attribution to another domain.
Liu Expires 2 January 2027 [Page 25]
Internet-Draft Active Loss Interpretation July 2026
9.3. Limitations of Cause Attribution
Cause attribution may remain uncertain even with additional context.
Counters may be aggregated, logs may be incomplete, clocks may not be
synchronized, and operational state captured after the event may not
reflect the state at the time of loss.
Multiple causes can also coexist. For example, congestion, routing
convergence, endpoint behavior, filtering, and validation updates may
occur in the same interval. Interpretation should reflect
uncertainty when evidence does not support a definitive conclusion.
9.4. Use of Controlled Measurements
Controlled active measurements can help test hypotheses about loss
causes and timing behavior. Examples include measuring both
directions, varying flow identifiers to exercise multiple paths,
using different source addresses when authorized and operationally
safe, comparing one-way and reflected measurements, or measuring from
multiple vantage points.
Such measurements should be designed carefully. Changing packet
headers can change the path, policy, queue, or validation context.
Therefore, a controlled measurement may provide evidence about
related behavior rather than an exact reproduction of the original
event.
For hybrid and passive measurements, the ability to vary packet
fields or timing may be limited. In those cases, interpretation may
rely more heavily on traffic selection, observation-point placement,
marking information, sampling configuration, and correlation with
operational context.
9.5. Reporting Uncertainty
Measurement reports and operational analyses should report
uncertainty when the cause of loss is not known. A useful report can
state the observed outcome, the affected packets or flows, the time
interval, the available context, and the set of plausible causes.
Reporting uncertainty is preferable to assigning an unsupported
cause. It also helps avoid operational actions that are inconsistent
with the actual problem, such as treating policy-related loss as
congestion or treating congestion-related loss as a validation issue.
Liu Expires 2 January 2027 [Page 26]
Internet-Draft Active Loss Interpretation July 2026
10. Security Considerations
This document discusses interpretation of active measurement results
and does not change the security properties of existing IPPM
protocols, routing protocols, forwarding behavior, or validation
mechanisms. However, the collection and reporting of context for
loss interpretation can have security implications.
Measurement systems should not be used as a reason to weaken security
policy. Exempting measurement traffic from filtering, policing, or
validation can create opportunities for abuse if the exception is too
broad. Any exception should be narrowly scoped, explicitly
configured, and consistent with local security policy.
Active measurements can also reveal operational behavior. An
attacker or unauthorized measurement system might vary packet
headers, source addresses, or flow identifiers to infer filtering,
policing, validation, topology, or load-balancing behavior.
Measurement systems that intentionally vary source addresses or flow
identifiers to investigate path-dependent behavior should be operated
only by authorized parties and within the limits of local policy.
Hybrid and passive measurements can also reveal operational behavior,
especially when measurement results are correlated with production
traffic, marking information, traffic classes, or observation points.
Access to such measurement data should be controlled according to
local security policy.
Operational context used for interpretation may be sensitive.
Routing state, forwarding state, policy configuration, validation
state, source-prefix mappings, customer attachment information,
counters, and logs can reveal information about topology, security
policy, or customer relationships. Reports shared outside an
administrative domain should disclose only the information needed for
the intended purpose.
The integrity of operational context is also important. Stale,
incomplete, inconsistent, or maliciously modified telemetry,
counters, logs, or controller state can lead to unsupported
attribution of packet loss. Systems that use such information should
consider its trustworthiness, freshness, and whether it represents
intended state or actual installed state.
Liu Expires 2 January 2027 [Page 27]
Internet-Draft Active Loss Interpretation July 2026
11. Privacy Considerations
Active measurement packets and reports may include source addresses,
destination addresses, endpoint identifiers, timestamps, flow
identifiers, packet header fields, and delivery outcomes. When
correlated with operational context, this information can reveal
network structure, endpoint activity, customer relationships, or
policy behavior.
Hybrid and passive measurements may involve observations of
production traffic. Even when payload is not collected, metadata
such as addresses, timing, packet treatment, marking state, and
delivery outcomes can reveal information about users, services,
traffic patterns, or customer relationships. Such information should
be minimized, protected, and shared only with appropriate
authorization.
Such information can be sensitive even when user payload is not
collected, because source addresses, timing, and treatment outcomes
may reveal operational relationships or network structure. Fine-
grained per-packet or per-flow reporting can be especially useful for
diagnosis but may also increase privacy and confidentiality risks.
Measurement systems should apply data minimization appropriate to the
operational purpose. Reports should include the information needed
to support interpretation while avoiding unnecessary disclosure of
internal interface identifiers, customer mappings, policy details,
validation rules, or topology information. Access to detailed logs
and telemetry should be limited to authorized parties, and retention
periods should be consistent with local policy.
When measurement results are shared across administrative boundaries,
privacy considerations become more important. A domain may be
willing to disclose that loss was observed or that a cause is
plausible, but may not be willing to disclose detailed policy,
validation, customer, or topology information. Reports intended for
external sharing should be designed accordingly.
12. IANA Considerations
This document has no IANA actions.
13. Informative References
[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>.
Liu Expires 2 January 2027 [Page 28]
Internet-Draft Active Loss Interpretation July 2026
[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>.
[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>.
[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>.
[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>.
[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>.
Liu Expires 2 January 2027 [Page 29]
Internet-Draft Active Loss Interpretation July 2026
[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>.
[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>.
[I-D.ietf-savnet-intra-domain-problem-statement]
Qin, L., Li, D., Wu, J., Huang, M., and N. Geng, "Problem
Statement, Gap Analysis, and Requirements for Intra-domain
Source Address Validation", Work in Progress, Internet-
Draft, draft-ietf-savnet-intra-domain-problem-statement-
26, 1 June 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-savnet-intra-domain-problem-statement-26>.
[I-D.ietf-savnet-inter-domain-problem-statement]
Li, D., Qin, L., Liu, L., Huang, M., and K. Sriram,
"Problem Statement, Gap Analysis, and Requirements for
Inter-Domain Source Address Validation", Work in Progress,
Internet-Draft, draft-ietf-savnet-inter-domain-problem-
statement-18, 29 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
inter-domain-problem-statement-18>.
Acknowledgements
The author would like to thank Giuseppe Fioccola for reviewing
earlier versions of this document and for his helpful comments and
suggestions.
Author's Address
Libin Liu
Zhongguancun Laboratory
Beijing
China
Email: liulb@zgclab.edu.cn
Liu Expires 2 January 2027 [Page 30]