]> Zhongguancun Laboratory

Beijing China liulb@zgclab.edu.cn

Operations and Management IPPM 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.

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 . This document focuses primarily on active performance measurements, where measurement traffic is generated for the purpose of measuring packet delivery behavior . 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 OWAMP , TWAMP , and STAMP . 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 . Existing IPPM reporting guidance also recognizes that packet loss can have multiple causes and that reporting context is important for interpretation . 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, 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 . describes the general problem of observed loss and ambiguous causes in active performance measurements. summarizes operational conditions associated with loss observed by active performance measurements, including validation-related discard such as SAV. discusses the implications of loss interpretation ambiguity for different measurement methods and metrics, including delay and delay variation interpretation. discusses interpretation considerations. discusses how the considerations relate to active, hybrid, and passive performance measurements. discusses sources of additional operational context, and discusses deployment and operational considerations. and discuss security and privacy considerations, respectively.

Terminology The terms Active Performance Measurement, Passive Performance Measurement, and Hybrid Performance Measurement are used consistently with the classification in . 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. 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. 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 . 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. 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.

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 updates. Therefore, even when measurement protocols operate correctly, interpreting their results may require additional operational context. This section describes five aspects of the problem. describes the distinction between observable loss and unobservable causes. discusses ambiguity in one-way and two-way measurements. discusses flow-dependent, path-dependent, and time-dependent loss. discusses delay and delay variation interpretation. discusses the relationship between measurement traffic and operational context.

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.

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. 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.

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.

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.

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.

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.

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. 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.

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.

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.

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.

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 . 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.

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. 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.

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.

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. 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.

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.

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. 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.

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.

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. 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.

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 . 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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. 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.

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.

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.

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.

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.

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.

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.

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 . 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.

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. 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.

Deployment and Operational Considerations While 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.

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.

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.

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.

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.

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.

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.

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.

IANA Considerations This document has no IANA actions.

Informative References This memo defines a metric for round-trip delay of packets across Internet paths. [STANDARDS-TRACK] This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memo refers to a metric for variation in delay of packets across Internet paths. The metric is based on the difference in the One-Way- Delay of selected packets. This difference in delay is called 'IP Packet Delay variation.' The metric is valid for measurements between two hosts both in the case that they have synchronized clocks and in the case that they are not synchronized. We discuss both in this draft. BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources (such as GPS and CDMA). OWAMP enables the interoperability of these measurements. [STANDARDS-TRACK] The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. [STANDARDS-TRACK] Consumers of IP network performance metrics have many different uses in mind. This memo provides "long-term" reporting considerations (e.g., hours, days, weeks, or months, as opposed to 10 seconds), based on analysis of the points of view of two key audiences. It describes how these audience categories affect the selection of metric parameters and options when seeking information that serves their needs. This document is not an Internet Standards Track specification; it is published for informational purposes. This memo defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2679 obsolete. This memo defines a metric for one-way loss of packets across Internet paths. It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2680 obsolete. This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge. This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704. This document describes the Simple Two-way Active Measurement Protocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss. Network telemetry is a technology for gaining network insight and facilitating efficient and automated network management. It encompasses various techniques for remote data generation, collection, correlation, and consumption. This document describes an architectural framework for network telemetry, motivated by challenges that are encountered as part of the operation of networks and by the requirements that ensue. This document clarifies the terminology and classifies the modules and components of a network telemetry system from different perspectives. The framework and taxonomy help to set a common ground for the collection of related work and provide guidance for related technique and standard developments. Zhongguancun Laboratory Tsinghua University Tsinghua University Zhongguancun Laboratory Huawei Source address validation (SAV) is an important means to mitigate IP source address spoofing [RFC2827]. This document analyzes the gaps in current operational mechanisms for intra-domain SAV. It also identifies the properties that new intra-domain SAV mechanisms are expected to provide. Tsinghua University Zhongguancun Laboratory Zhongguancun Laboratory Huawei USA National Institute of Standards and Technology This document analyzes the problem space and provides a gap analysis of existing inter-domain source address validation (SAV) mechanisms. Based on these findings, it outlines the technical requirements for future improvements.

Acknowledgements The author would like to thank Giuseppe Fioccola for reviewing earlier versions of this document and for his helpful comments and suggestions.