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, . 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, . [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393, November 2002, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [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, . [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, . [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, . [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, . [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, . [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, . [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, . 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, . [RFC9232] Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Network Telemetry Framework", RFC 9232, DOI 10.17487/RFC9232, May 2022, . [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, . [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, . 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]