| Internet-Draft | Asymmetrical Traffic Using STAMP | February 2026 |
| Mirsky, et al. | Expires 7 August 2026 | [Page] |
This document specifies an optional extension to the Simple Two-way Active Measurement Protocol (STAMP) to control the length and/or number of packets sent by a Session-Reflector in response to a single test packet from the Session-Sender during a STAMP test session. By default, a STAMP Session-Sender and Session-Reflector exchange packets symmetrically: the number of packets sent by the Session-Reflector and the Session-Sender are the same as is the length of the packets sent by the Session-Reflector and the Session-Sender. However, there are cases where a Session-Reflector responding with Asymmetrical Packets would ensure a closer approximation between active performance measurements and the conditions experienced by monitored application. The STAMP extension proposed in this document allows the operator to establish tests where a Session-Reflector sends Asymmetrical Packets, packets whose length is not symmetrical to test packet sent by the Session-Sender and/or packets that are not sent in direct response to a packet received from a Session-Sender. The document also includes an analysis of challenges related to performance monitoring in a multicast network. It specifies procedures and STAMP extensions to achieve more efficient measurements with a lesser impact on a network.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 7 August 2026.¶
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.¶
Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] defines the base STAMP functionalities. STAMP Optional Extensions [RFC8972] introduces a TLV structure that allows a Session-Sender to include optional instructions for Session-Reflectors to extend the functionality of the base STAMP protocol. New STAMP TLVs can be defined to support scenarios like the ones described in [RFC7497], which discusses the coordination of messaging between the source and destination to help deliver one of the fundamental principles of IP performance metric measurements, minimizing the test traffic effect on user flows. By default, a STAMP Session-Sender and Session-Reflector exchange packets symmetrically: the number of packets sent by the Session-Reflector and the Session-Sender are the same as is the length of the packets sent by the Session-Reflector and the Session-Sender. That is, the number of packets sent by the Session-Reflector and the Session-Sender are the same and the length of the packets sent by the Session-Reflector and the Session-Sender are the same. However, in some scenarios, e.g., rate measurements discussed in [RFC7497], it would be beneficial for a Session-Reflector to respond with a Asymmetrical Test packets: packets whose length is not symmetrical to test packet sent by the Session-Sender and/or packets that are not sent in direct response to a packet received from a Session-Sender. The optional extension defined in this document gives the operator the tools to create such Assymetrical Packets between a Session-Sender and a Session-Reflector.¶
Measurement of performance metrics in a multicast network using an active measurement method has specific challenges compared to what operators experience monitoring in a unicast network. This document analyzes these challenges and specifies procedures and STAMP extensions to achieve more efficient measurements with a lesser impact on a network.¶
The document uses terms defined in [RFC8762] , especially Session-Sender, Session-Reflector and Symmetrical Packets. The document uses terms defined in [RFC8972] , especially STAMP Session Identifier (SSID), STAMP TLV Flags and Sub-TLVs. The document uses the terms In-Service and Out-of-Service defined in [RFC7497]. In this document, Asymmetrical Packets has two meanings, depending on the context. First, an Asymmetrical Packet means a packet sent by a Session-Reflector with a size different from the packet sent by the Session-Sender. The second, third, fourth, etc. packets sent by the Session-Reflector in response to a single test packet received from a Session-Sender are also referred to as Asymmetrical Packets. In this document, a Multicast Network means a network that sends data from a single source to multiple destinations by transmitting a single packet to a single, specially designated address.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This section defines a new optional STAMP extension, Reflected Test Packet Control TLV and a new STAMP TLV Flag value. The format of this TLV is presented in Figure 1.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length of the Reflected Packet |Number of the Reflected Packets| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interval Between the Reflected Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Sub-TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The descriptions of the fields are as follows:¶
Also, a new STAMP TLV flag [RFC8972], Conformant Reflected Packet is allocated by IANA from "STAMP TLV Flags" subregistry (Section 7.2): the one-bit C flag (TBA4). A Session-Sender MUST zero this flag on transmission, and the Session-Reflector MUST ignore its value on the receipt of a STAMP test packet with a STAMP TLV.¶
A Session-Sender MAY include the Reflected Test Packet Control TLV in a STAMP test packet. If the received STAMP test packet includes the Reflected Test Packet Control TLV, the Session-Reflector MUST transmit a sequence of reflected test packets according to the following rules:¶
In a case where the length of the reflected packet calculated by this rule is longer than the length of the reflected packet calculated by the rules in Section 3 of [RFC8972], the Session-Reflector MUST use the Extra Padding TLV (Section 4.1 of [RFC8972]) to increase the length of the reflected test packet. If the calculated length of the reflected packet exceeds the maximum transmission unit (MTU) of the interface to reach the Session-Sender, the Session-Reflector MUST set the C (Conformant Reflected Packet) STAMP TLV flag (Section 7.2) to 1, and MUST transmit a single reflected packet of the length equal to MTU of the egress interface. Otherwise, the Session-Reflector MUST set the C flag to 0 in each reflected test packet.¶
The number of reflected test packets in the sequence MUST equal the value of the "Number of the Reflected Test Packets" field.¶
If the value of the "Number of the Reflected Packets" field is larger than one, the interval between the transmission of two consecutive reflected packets in the sequence MUST be equal to the value in the "Interval Between the Reflected Packets" field in nanoseconds. To reduce the risk of creating unacceptable levels of congestion in the network that carries the reflected packets, an implementation of a Session-Reflector that supports the Reflected Test Control TLV MUST provide a limit on the data rate (bytes per second) and the data volume (total bytes) that would be generated in response to an incoming test packet. If a test packet is received that would generate traffic that exceeds either of these limits, the Session-Reflector MUST set the C flag (Section 7.2) to 1, and MUST transmit a single reflected packet. Otherwise, the Session-Reflector MUST set the C flag to 0 in each reflected test packet.¶
If the value of the "Number of the Reflected Packets" field equals zero, then the Session-Reflector MUST NOT send a reflected packet. Processing of the received STAMP test packet with the Reflected Test Packet Control TLV, in which the value of the "Number of the Reflected Packets" field equals zero, is according to local policy. The received STAMP test packet MUST be discarded if no policy to handle these cases is configured on the node.¶
Each reflected test packet in the sequence is formed according to Section 4.3 of [RFC8762].¶
As defined above, there are two cases when a Session-Reflector will set the C flag in the reflected packet. To disambiguate which case led to the C flag being set to 1, an implementation of Session-Sender may use the following:¶
Layer 2 Address Group Sub-TLV: A 16-octet sub-TLV that includes the EUI-48 Address Group Mask and EUI-48 Address Group. The Type of the sub-TLV is TBA2 (Section 7.3). The value of the sub-TLV Length field MUST be equal to 12. The format of the Layer 2 Address Group Sub-TLV is presented in Figure 2.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Flags | Sub-TLV Type | Sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EUI-48 Address Group Mask | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | EUI-48 Address Group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Value field of the Layer 2 Address Group Sub-TLV consists of the following fields:¶
Layer 3 Address Group Sub-TLV: A variable-length sub-TLV that includes the IP address family, IP prefix, and IP prefix length. The Type of the sub-TLV is TBA3 (Section 7.3). The value of the sub-TLV Length field MUST be equal to 8 if the value of the Address Family field is set to 1 (i.e., IPv4). The value of the sub-TLV Length field MUST be equal to 20 if the value of the Address Family field is set to 2 (i.e., IPv6). The format of Layer 3 Address Group Sub-TLV is presented in Figure 3.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Flags | Sub-TLV Type | Sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family| Prefix Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IP Prefix ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Value field of the Layer 3 Address Group Sub-TLV consists of the following fields:¶
[RFC7497] defines the problem of access rate measurement in access networks. Essential requirements identified for a test protocol are the ability to control packet characteristics on the tested path, such as asymmetric rate and asymmetric packet size. The Reflected Test Packet Control TLV, defined in Section 2, conforms to the requirements for measuring access rate by providing optional controls of the number of reflected test packets, the size of the reflected packet(s), and the time interval, i.e., rate, in transmitting the sequence of the reflected test packets. The access rate metric and method of access rate measurement are out of the scope of this document. The UDP Speed Test ([RFC9097] and [I-D.ietf-ippm-capacity-protocol]) also allows for the measurement of access bandwidth.¶
General considerations for using a testing protocol for rate measurement are documented in Section 7 of [RFC7497]. These considerations are specific for In-Service and Out-of-Service (using the terminology of [RFC7497]) rate measurement. In the Out-of-Service testing, an operator may use a very high traffic rate and/or volume (i.e., high values for the Length of the Reflected Packet and/or Number of the Reflected Packets parameters, and/or low values for the Interval Between the Reflected Packets parameter of the Reflected Test Packet Control TLV) to create congestion in the bottleneck. However, when performing In-Service rate testing, an operator may start with a low rate and/or volume and gradually increase them with each transmitted Reflected Test Packet Control TLV.¶
For performance measurements using STAMP in a multicast environment, a Session-Sender is expected to be the root and Session-Reflectors leaves of the same multicast distribution tree. The mechanism of constructing the multicast tree is outside the scope of this document.¶
According to [RFC8972], a STAMP Session is demultiplexed by a Session-Reflector by the tuple that consists of source and destination IP addresses, source and destination UDP port numbers, or the source IP address and STAMP Session Identifier. That is also the case when monitoring performance of a multicast flow, despite the fact that the destination IP address is a multicast address. Therefore, there is no special behavior defined for a Session-Reflector upon receiving a STAMP test packet over a multicast tree. It processes the packet according to [RFC8762] and [RFC8972]. The Session-Reflector MUST use the source IP address of the received STAMP test packet as the destination IP address of the reflected test packet, and MUST use one of the IP addresses associated with the node as the source IP address for that packet. As a result, a Session-Sender may receive multiple replies from multiple counterparts Session-Reflectors. Such a Session-Sender COULD include a Reflected Test Packet Control TLV and include either a Layer 2 Address Group Sub-TLV or Layer 3 Address Group Sub-TLV to limit the Session-Reflectors that respond.¶
The multicast environment itself could be configured to help alleviate the possibility that network congestion may occur if a single test packet generates a large number of concurrent replies, all directed to the same endpoint. Depending on the multicast-implementation, adding the Reflected Test Packet Control TLV could allow the multicast environment to limit the number of replies by updating fields of any STAMP packets it sees by modifying their Reflected Test Packet Control TLV Sub-TLV values:¶
Multicast traffic is also intrinsically asymmetrical, and focus on the return path is usually limited. The Length of the Reflected Packet value can be used to ensure the reflected packet transports all the timestamps and requested information, crucial for the underlying measure, but is as short as possible so as not to flood the network with useless data.¶
[RFC9503] defines the Return Path TLV which, when used in combination with the Return Address Sub-TLV, allows a Session-Sender to request the reflected packet be sent to a different address from the Session-Sender one. These STAMP extensions could be used in combination with the Reflected Packet Control TLV, defined in this document, to direct the reflected STAMP test packets to a collector of measurement data (according to [RFC7594]) for further processing and network analytics. An example of the use case is a multicast scenario when, for example, the Session-Sender is close to the actual multicast source (such as a camera transmitting live video) so that the test packets follow the same path as the video stream packets in one direction but the reflected test packets follow another to a destination where the data would be analyzed.¶
For compatibility with [RFC9503], a Session-Sender MUST NOT include a Return Path Control Code Sub-TLV with the Control Code flag set to No Reply Requested in the same test packet as the Reflected Test Packet Control TLV is non-zero. A Session-Reflector that supports both TLVs MUST set the U flag to 1 in Return Path and Reflected Test Packet Control TLVs in the reflected STAMP packet. Furthermore, the Session-Reflector SHOULD log a notification to inform an operator about the misconstructed STAMP packet.¶
Reflected Test Packet Control TLV can be combined with the Class of Service TLV [RFC8972] to augment rate testing or testing in a multicast network with monitoring the consistency of Differentiated Services Code Point and Explicit Congestion Notification values in forward and reverse directions of the particular STAMP test session.¶
Security considerations discussed in [RFC7497], [RFC8762],[RFC8972], and [RFC9503] apply to this document. Furthermore, spoofed STAMP test packets with the Reflected Test Packet Control TLV can be exploited to conduct a Denial-of-Service (DoS) attack. Hence, implementations MUST use an identity protection mechanism. For example, the Session-Reflector may verify the information about the source of the STAMP packet against a pre-defined list of trusted nodes. Furthermore, an implementation that supports this specification MUST provide administrative control of support of the Reflected Test Packet Control TLV on a Session-Reflector with it being disabled by default. Also, either STAMP authentication mode [RFC8762] or HMAC TLV [RFC8972] SHOULD be used for a STAMP test session containing the Reflected Test Packet Control TLV.¶
Furthermore, a DoS attack using the Reflected Test Packet Control TLV might target the STAMP Session-Reflector by overloading it with test packet reflection, e.g., minuscule intervals and/or an excessive number of concurrent test sessions. To mitigate that, a Session-Reflector implementation that supports the new TLV MUST provide a mechanism to limit the reflection rate and volume of STAMP test packets (see Section 2 for detailed discussion).¶
Considering the potential number of reflected packets generated by a single test packet sent to a multicast address, parameters in the first STAMP test packet with the Reflected Test Packet Control TLV MUST be selected conservatively. Consider the Number of the Reflected Packets field value set to one. As a result, a Session-Sender, by counting the packets reflected after originating a first STAMP test packet with the Reflected Test Packet Control TLV, can evaluate the load caused by using the Reflected Test Packet Control TLV in which more than a single reflected packet to the same multicast destination is requested. To mitigate the risk of using the Reflected Test Packet Control TLV in a multicast network further, a Session-Sender SHOULD sign packets using the HMAC TLV when sending such messages in unauthenticated mode [RFC8762]. But even with the HMAC TLV, the Reflected Test Packet Control TLV could be exploited by a replay attack. To mitigate that risk, a STAMP Session-Reflector SHOULD use the value of the Sequence Number field [RFC8762] of the received STAMP test packet. If that value compared to the received in the previous test packet of the same STAMP test session is not increasing, then the Session-Reflector MUST respond with a single reflected packet, setting the U flag to 1 [RFC8972].¶
A Session-Sender SHOULD NOT send the next STAMP test packet with the Reflected Test Packet Control TLV before the Session-Reflector is expected to complete transmitting all reflected packets in response to the Reflected Test Packet Control TLV in the previous test packet. In some scenarios the Reflected Test Packet Control TLV might induce congestion on the transient bottleneck. Section 10 of [RFC9097] specifies security requirements for capacity measurements with asymmetric UDP loads. When planning In-Service capacity measurement operators SHOULD follow recommendations formulated in Section 7 of [RFC7497]. Section 3.1.5 of [RFC8085] determines that a UDP congestion control SHOULD respond quickly to experienced congestion and account for loss rate and response time when choosing a new rate. Appendix A of [RFC9097] offers sample pseudocode for a UDP load rate adjustment algorithm with congestion control.¶
Note to RFC Editor: This section MUST be removed before publication of the document.¶
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶
According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶
- The organization responsible for the implementation: Will Hawkins (Individual).¶
- The implementation's name: Teaparty.¶
- A brief general description: Teaparty is an open source implementation of the Simple Two-Way Active Measurement Protocol and many of the optional extensions. The implementation can function as a Session-Sender and Session-Reflector. It contains support for Authenticated and Unauthenticated modes. It also contains an implementation of a STAMP dissector for Wireshark.¶
- The implementation's level of maturity: Interoperable with Junos OS Evolved STAMP/TWAMP-Light implementations (https://www.juniper.net/documentation/us/en/software/junos/standards/topics/concept/rpm.html), Nokia's TWAMP Light implementation (https://github.com/nokia/twampy), and Cujo's TWAMP Light implementation (https://github.com/getCUJO/twamp-light).¶
- Coverage: Includes support for:¶
- Version compatibility: N/A¶
- Licensing: GPLv3.¶
- Implementation experience: Incorporating the Reflected Packet Control TLV into the Teaparty implementation was no challenge from the protocol perspective (because the specification is well written and the authors were responsive to requests for clarification) but did require enhancements to the underlying mechanics. No extensions (or components of the base functionality) before the Reflected Packet Control TLV required support for the Session-Reflector to generate ongoing responses to a test packet from a Session-Sender. As a result, all responses were generated and sent upon receipt of a test packet with no further processing. The functionality required to implement the Reflected Packet Control TLV was already on the list of upcoming additions to Teaparty, whether this extension was proposed or not (a complete implementation of the Access Report extension requires such support). Overall, implementation was straightforward.¶
- Contact information: Source code is available at https://github.com/cerfcast/teaparty. Author is available at https://datatracker.ietf.org/person/hawkinsw@obs.cr¶
- The date when information about this particular implementation was last updated: April 28, 2025¶
The authors thank Zhang Li, Ruediger Geib, Rakesh Gandhi, Giuseppe Fiocolla, Xiao Min, and Greg White for their thorough reviews and helpful suggestions, which improved the document.¶
IANA is requested to assign a new value for the Reflected Test Packet Control TLV from the STAMP TLV Types registry under the "Simple Two-way Active Measurement Protocol (STAMP) TLV Types" registry group according to Table 1.¶
| Value | Description | Reference |
|---|---|---|
| TBA1 | Reflected Test Packet Control | This document |
IANA is requested to allocate a bit position for the Conformant Reflected Packet flag from the "STAMP TLV Flags" registry under the "Simple Two-way Active Measurement Protocol (STAMP) TLV Types" registry group according to Table 2.¶
| Bit position | Symbol | Description | Reference |
|---|---|---|---|
| TBA4 | C | Conformance | This document |
IANA is requested to assign new values for the Layer 2 and Layer 3 Address Group Sub-TLV Types from the "STAMP Sub-TLV Types" registry under the "Simple Two-way Active Measurement Protocol (STAMP) TLV Types" registry group according to according to Table 3.¶
| Value | Description | TLV Used | Reference |
|---|---|---|---|
| TBA2 | Layer 2 Address Group | Reflected Test Packet Control | This document |
| TBA3 | Layer 3 Address Group | Reflected Test Packet Control | This document |