RFC 10052

Performance Measurement with Asymmetrical Traffic Using the Simple Two-Way Active Measurement Protocol (STAMP)

📅 published September 2026, from ietf

Performance Measurement with Asymmetrical Traffic Using the Simple Two-Way Active Measurement Protocol (STAMP) 🎀

Okay bestie, the title block first, because it tells you who made this and how official it is. 💅

This is RFC 10052, a Standards Track document, which means it's an actual Internet Standard and not just an idea someone had. It was published in September 2026, and the ISSN is 2070-1721. The authors are G. Mirsky (Ciena Corporation), E. Ruffini (OutSys), H. Nydell (Cisco Systems), R. Foote (Nokia), and W. Hawkins (University of Cincinnati). It's from the IETF, the group that writes the Internet's rules. The header doesn't list anything it obsoletes or updates, so it stands on its own. 🌸

Abstract

Okay so this doc adds an optional extension to STAMP (the Simple Two-way Active Measurement Protocol) 🦋. It lets a Session-Reflector send back asymmetrical packets, which means response packets that are a different size or a different number from what the Session-Sender sent. Normal STAMP is perfectly symmetrical, but some measurement situations are way better if the replies look different, so they match real app traffic more closely. ✨

The extension defines the Reflected Test Packet Control TLV and the procedures that go with it. It also looks at the challenges of active performance measurement, including in multicast environments, and describes STAMP behaviors that make measurement more efficient and reduce the network impact. Iconic. 👑

Status of This Memo

This is an Internet Standards Track document. 🌈

It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it went through public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more info on Internet Standards, check Section 2 of RFC 7841.

For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc10052. 💖

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) as they were in effect on the date this document was published. Please actually read these, because they explain your rights and restrictions for this document. Code Components extracted from this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License describes.

Table of Contents 📋

   1.  Introduction
   2.  Conventions Used in This Document
     2.1.  Terminology
     2.2.  Acronyms
     2.3.  Requirements Language
   3.  Reflected Test Packet Control TLV
     3.1.  Address Group Sub-TLVs
       3.1.1.  Layer 2 Address Group Sub-TLV
       3.1.2.  Layer 3 Address Group Sub-TLV
   4.  Operational Considerations
     4.1.  Rate Measurement
       4.1.1.  Operational Considerations for Performing Rate
               Measurement
     4.2.  Active Performance Measurement in a Multicast Environment
     4.3.  Using Reflected Test Packet Control TLV in Combination with
           Other TLVs
   5.  Security Considerations
   6.  IANA Considerations
     6.1.  Reflected Test Packet Control TLV Type
     6.2.  Conformant Reflected Packet STAMP TLV Flag
     6.3.  Layer 2 and Layer 3 Address Group Sub-TLV Types
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction ✨

STAMP is defined in [RFC8762], and that's where the base STAMP functionality lives. 🧚 Then [RFC8972] introduces a TLV structure that lets a Session-Sender include optional instructions for Session-Reflectors, which extends what base STAMP can do. New STAMP TLVs can be defined for scenarios like the ones in [RFC7497], which talks about coordinating messages between the source and destination. That coordination helps deliver one of the core principles of IP performance metric measurement: keeping the test traffic from messing with user flows. 🫶

By default, STAMP is symmetrical. The Session-Reflector and the Session-Sender send the same number of packets, and those packets are the same length. But sometimes it would be really useful for the Session-Reflector to answer with asymmetrical test packets, like in the rate measurements discussed in [RFC7497]. That means packets whose length doesn't match the test packet the Session-Sender sent, and/or packets that aren't sent as a direct reply to a packet from the Session-Sender. The optional extension in this document gives operators the tools to build those asymmetrical packets between a Session-Sender and a Session-Reflector. 💅

Measuring performance in a multicast network with an active measurement method (Section 3.4 of [RFC7799]) is a whole different beast compared to unicast. 😭 This document looks at those challenges and specifies the procedures and STAMP extensions that make measurements more efficient and have less impact on the network. 🌸

2. Conventions Used in This Document 💅

2.1. Terminology

This document uses terms defined in [RFC8762], specifically Session-Sender, Session-Reflector, and symmetrical packets. 🦋

This document uses terms defined in [RFC8972], specifically STAMP Session Identifier (SSID), STAMP TLV Flags, and Sub-TLVs. 🎀

This document uses terms defined in [RFC7497], specifically In-Service and Out-of-Service. 🌈

Here's the sneaky part: "asymmetrical packets" has two meanings, depending on the context. 🙈 The first is asymmetry in packet size between a packet sent by a Session-Reflector and the packet it received from the Session-Sender. The second is asymmetry in the number of packets the Session-Reflector transmits in response to receiving a single STAMP-Test packet. Not me having to explain this twice. 💀

In this document, a multicast network means a communication network model where a sender transmits a single packet addressed to a multicast group, and the network delivers copies of that packet to multiple receivers that have joined the group. ✨

2.2. Acronyms

  • CE: Congestion Experienced
  • ECN: Explicit Congestion Notification
  • EUI: Extended Unique Identifier
  • MAC: Media Access Control
  • STAMP: Simple Two-way Active Measurement Protocol
  • TLV: Type-Length-Value

2.3. Requirements Language

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

3. Reflected Test Packet Control TLV ✨

okay bestie, this section is where the magic happens 🧚 It adds an optional STAMP extension called the Reflected Test Packet Control TLV, plus a brand new bit flag in the STAMP TLV Flags field. The TLV's format is 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                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Reflected Test Packet Control TLV Format

Here's what each field does, babe 💅

  • STAMP TLV Flags: A one-octet field [RFC8972].
  • Type: A one-octet field that identifies the Reflected Test Packet Control TLV. This field is set to 12 (Section 6.1).
  • Length: A two-octet field. The value is variable and MUST NOT be smaller than 12 octets.
  • Length of the Reflected Packet: A two-octet field. The value is an unsigned integer that is the requested length of a reflected test packet in octets.
  • Number of the Reflected Packets: A two-octet field. The value is an unsigned integer that is the number of reflected test packets that the Session-Reflector is requested to transmit in response to receiving a STAMP-Test packet with the Reflected Test Packet Control TLV.
  • Interval Between the Reflected Packets: A four-octet field. The value is an unsigned integer set to the interval in nanoseconds between the transmission of the consecutive reflected test packets in response to receiving a STAMP-Test packet with the Reflected Test Packet Control TLV.
  • Sub-TLVs: An optional field that includes additional information communicated by a Session-Sender.

Also, there's an extra STAMP TLV flag [RFC8972] called the Conformant Reflected Packet 🦋 IANA gave it a spot in the "STAMP TLV Flags" registry (Section 6.2), and it's the one-bit C flag (3). 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:

  • The length of the reflected test packet MUST be the largest of:
    • a. The length of a base Session-Reflector packet in the mode (unauthenticated or authenticated) of the received STAMP-Test packet, as defined in Section 4.3 of [RFC8762], including all STAMP extension TLVs [RFC8972] present in the received STAMP-Test packet but excluding any Extra Padding TLVs. The rationale to exclude any Extra Padding TLVs present in combination with the Reflected Test Packet Control TLV is to support a scenario in which a Session-Reflector is requested to transmit a sequence of packets shorter than the received STAMP packet.
    • b. The value in the Length of the Reflected Packet field of the Reflected Test Packet Control TLV aligned at a four-octet boundary.

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 4 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 Conformant Reflected Packet STAMP TLV flag (Section 6.2) to 1 and MUST transmit a single reflected packet of the length equal to the 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 Packets field.

If the value of the Number of the Reflected Packets field is greater than 1, 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 prevent excessive congestion caused by reflected packets, a Session-Reflector that supports the Reflected Test Packet Control TLV MUST enforce limits on both the data rate (bytes per second) and the total data volume (bytes) of the STAMP payload it generates 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 6.2) to 1 and MUST transmit a single reflected packet of the length calculated by the rules listed above. Otherwise, the Session-Reflector MUST set the C flag to 0 in each reflected test packet.

If the Number of the Reflected Packets field is set to 0, the Session-Reflector MUST NOT send any reflected packets. Furthermore, in this case, the Session-Reflector SHOULD discard the received STAMP-Test packet. However, a local policy MAY override this default behavior and specify an alternative handling. Note that this behavior of the Session-Reflector is demonstrated when the Control Code Flags field of the Return Path Control Code sub-TLV (Section 4.1.1 of [RFC9503]) is set to No Reply Requested. If this is the intended behavior, use of the Return Path TLV is preferable.

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 figure out which case set the C flag to 1, an implementation of a Session-Sender can check the following:

  • If the length of the received reflected STAMP packet is less than the value of the Length of the Reflected Packet field, the requested length exceeds the MTU of the egress interface of the Session-Reflector.
  • If the length of the received reflected STAMP packet equals the value of the Length of the Reflected Packet field, the requested data rate and/or the data volume exceed the limits set at the Session-Reflector.

3.1. Address Group Sub-TLVs 🎀

A multicast network that uses an active performance measurement method for In-Service rate estimation MUST include a rate control mechanism that bounds and regulates the generation of measurement packets. Because multicast replication can amplify probe traffic across the distribution tree, uncontrolled probe emission risks introducing congestion, altering traffic asymmetry, or otherwise perturbing the conditions being measured. The rate control mechanism MUST ensure that probe traffic remains non-intrusive, predictable, and consistent with the operational characteristics of the multicast topology. Aligning probe generation behavior with the timing and packet selection semantics of the asymmetric packet measurement method makes it possible for observations collected at receivers to remain valid and comparable. To allow for deployment on networks with different characteristics (i.e., latency, throughput, etc.), implementations SHOULD provide operators with the ability to configure rate limits and pacing parameters that prevent excessive or uneven probe replication while still enabling statistically meaningful measurement samples.

3.1.1. Layer 2 Address Group Sub-TLV 🌸

An optional Layer 2 Address Group sub-TLV is a variable-length sub-TLV that includes a Layer 2 Address Group Mask and Address Group fields used by the Session-Sender to select the Session-Reflectors for a response. The Layer 2 Address Group sub-TLV can convey EUI-48 (Extended Unique Identifier), EUI-64 [IEEE-802.3-2022], and a 16-bit short address for local identification within a Personal Area Network [IEEE-802.15.4-2024]. 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          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~           Layer 2 Address Group Mask (variable length)        ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~           Layer 2 Address Group (variable length)             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Layer 2 Address Group Sub-TLV Format

Where:

  • Sub-TLV Flags: An eight-bit field. The format, values, and interpretation of flags are as defined for STAMP TLV Flags [RFC8972]. Flag values are taken from the "STAMP TLV Flags" registry [IANA-STAMP].
  • Sub-TLV Type: A one-octet field. IANA has assigned value 10 (Section 6.3).
  • Sub-TLV Length: A two-octet field whose value equals the length of the Value field of the Layer 2 Address Group sub-TLV in octets. Because the lengths of the Layer 2 Address Group Mask and Layer 2 Address Group fields MUST be equal, valid values for the Sub-TLV Length are 4, 12, and 16. Any other value MUST be considered by the Session-Reflector as a malformed sub-TLV.

The Value field of the Layer 2 Address Group sub-TLV consists of the following fields:

  • Layer 2 Address Group Mask: A field that represents the bitmask to be applied to all MAC addresses associated with the Session-Reflector. The length of the field is 1/2 the value of the sub-TLV Length field.
  • Layer 2 Address Group: A field that represents the group to which this TLV is addressed. The length of the field is 1/2 the value of the sub-TLV Length field.

If the Session-Reflector applies the value of the Layer 2 Address Group Mask field (using a bitwise AND) to any of its MAC addresses with the same length and the result is equal to the value of the Layer 2 Address Group field, then the Session-Reflector MUST stop processing the Layer 2 Address Group sub-TLV and continue processing the received test packet. If no matches are found, the Session-Reflector MUST stop processing the received packet.

3.1.2. Layer 3 Address Group Sub-TLV 🦋

Okay so the Layer 3 Address Group sub-TLV is totally optional 🫶. It's a variable-length sub-TLV that carries the IP Prefix and IP Prefix Length fields, which the Session-Sender uses to pick which Session-Reflectors get to answer. It's giving guest list for the reply party 🎀. Figure 3 is the layout, and yes it looks like a lot, but it's really just a grid of bits 💅.

    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          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Length |                   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                       IP Prefix                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Layer 3 Address Group Sub-TLV Format 🌸

Here's the breakdown, where we go:

Sub-TLV Flags: This is an eight-bit field 💖. The format, values, and interpretation of the flags are the same as for STAMP TLV Flags [RFC8972]. The flag values themselves come from the "STAMP TLV Flags" registry [IANA-STAMP] ✨.

Sub-TLV Type: A one-octet field. IANA has assigned the value 11 (Section 6.3) 🧚.

Sub-TLV Length: A two-octet field. Its value is either 8 (if the IP Prefix is the prefix for an IPv4 address) or 20 (if the IP Prefix is the prefix for an IPv6 address). Any other value MUST be considered by the Session-Reflector as a malformed sub-TLV 🙈. Not me letting a weird length slide.

The Value field of the Layer 3 Address Group sub-TLV has these fields inside it:

Prefix Length: A one-octet unsigned integer field. It holds the length, in bits, of the prefix in the IP Prefix field 🍓.

Reserved: A three-octet field. The field MUST be zeroed on transmission and ignored on receipt 🫧.

IP Prefix: A variable-length field. It's four octets long if the IP Prefix is the prefix for an IPv4 address, or 16 if it's the prefix for an IPv6 address 🌈.

Now for the processing part, which is lowkey the fun bit 👑. When the Session-Reflector handles this sub-TLV, it builds an IP mask from the value n in the Prefix Length field. The mask is an IP address of the family given by the sub-TLV Length field, where the n most-significant bits are set to 1 and every other bit is set to 0. Once the mask exists, the Session-Reflector applies it (using a bitwise AND) to each of its IP addresses of the same family. If the result equals the value in the IP Prefix field for one of them, then the Session-Reflector MUST stop processing the Layer 3 Address Group sub-TLV and continue processing the received test packet ⭐. If there are no matches, the Session-Reflector MUST stop processing the received packet 💀. No match, no reply, periodt.

4. Operational Considerations ✨

4.1. Rate Measurement 🌸

Bestie, [RFC7497] is the one that defines the problem of access rate measurement in access networks 🦋. One of the essential requirements for a test protocol is being able to control packet characteristics on the tested path, like asymmetric rate and asymmetric packet size 💜. The Reflected Test Packet Control TLV, defined in Section 3, meets the requirements for measuring access rate. It gives you optional controls over the number of reflected test packets, the size of the reflected packet(s), and the time interval (aka the rate) for sending the sequence of reflected test packets 🎀. The access rate metric and the method of measuring access rate are out of the scope of this document, so don't come for me about those 🙈. The UDP Speed Test (see [RFC9097] and [RFC9946]) also lets you measure access bandwidth 🌈.

4.1.1. Operational Considerations for Performing Rate Measurement 💅

General considerations for using a testing protocol for rate measurement are documented in Section 7 of [RFC7497] 📚. These considerations are specific to In-Service and Out-of-Service rate measurement. For Out-of-Service testing, an operator may use a very high traffic rate and/or volume to create congestion in the bottleneck. That means high values for the Length of the Reflected Packet and/or Number of the Reflected Packets fields, and/or low values for the Interval Between the Reflected Packets field of the Reflected Test Packet Control TLV (i.e., the stuff that makes it go brrr) 🔥. For In-Service rate testing, though, the operator can start low on rate and/or volume and slowly ramp up with each transmitted Reflected Test Packet Control TLV. Gentle is the move here 🫶.

A service subscriber doing extensive rate measurements on the operational network SHOULD consider bullet item 6 in Section 11 of [RFC9946] and keep an eye on any limits their Service Provider has put on their service 👀. Real talk: active measurement can generate data volumes that may cause the people running the test to violate their service-level agreements with their Service Provider 😭. Read the fine print, bestie.

4.2. Active Performance Measurement in a Multicast Environment 🦋

For performance measurements using STAMP in a multicast environment, the Session-Sender is expected to be the root and the Session-Reflectors are the leaves of the same multicast distribution tree 🌳. How the multicast tree gets built is outside the scope of this document 🤷‍♀️.

According to [RFC8972], a Session-Reflector demultiplexes a STAMP Session by a tuple made of source and destination IP addresses, source and destination UDP port numbers, or the source IP address and STAMP Session Identifier 🔑. That's still true when you're monitoring the performance of a multicast flow, even though the destination IP address is a multicast address. So there's no special behavior defined for a Session-Reflector receiving a STAMP-Test packet over a multicast tree. It just 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 it MUST use one of the IP addresses associated with the node as the source IP address for that packet 📬. The result? A Session-Sender may get multiple replies from multiple counterpart Session-Reflectors 💌. To narrow down who answers, the Session-Sender may include a Reflected Test Packet Control TLV plus either a Layer 2 Address Group sub-TLV or a Layer 3 Address Group sub-TLV to limit the Session-Reflectors that respond 🎀.

The multicast environment itself can be configured to help avoid network congestion if one test packet sets off a huge number of concurrent replies all aimed at the same endpoint 🚦. Depending on the multicast implementation, adding the Reflected Test Packet Control TLV could let the multicast environment limit the replies by changing the Reflected Test Packet Control TLV sub-TLV values in any STAMP packets it sees. That way, replies only come from reflectors that are:

  • Randomly selected, by specifying a Layer 2 Address Group sub-TLV: for example, setting the EUI-48 Address Group Mask to 0xF and the EUI-48 Address Group to 0x1. As a result, only 1 out of 16 reflectors will reply 🎲;
  • Hosted on a specific vendor Network Interface Card, by specifying a Layer 2 Address Group sub-TLV with the EUI-48 Address Group Mask set to 0xFFFFFF000000; and 🏷️
  • Belonging to specific IP networks, for example, a subnet dedicated to IPv6-over-IPv4 encapsulation, by specifying the appropriate Layer 3 Address Group sub-TLV 🌐.

Multicast traffic is also intrinsically asymmetrical 🦋. The upstream (source-to-receiver) direction usually dominates, and the return path gets less attention because multicast is mostly one-to-many and sends comparatively little downstream or receiver-to-source traffic 📉. You can use the value of the Length of the Reflected Packet field to make sure the reflected packet carries all the timestamps and requested info, which are crucial for the measurement. Keep it as short as possible, though, so you don't flood the network with useless data 🧹.

4.3. Using Reflected Test Packet Control TLV in Combination with Other TLVs 💜

[RFC9503] defines the Return Path TLV. Paired with the Return Address Sub-TLV, it lets a Session-Sender ask for the reflected packet to be sent to a different address than the Session-Sender's own 🔀. These STAMP extensions can be combined with the Reflected Test 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 📊. Here's an example: in a multicast scenario, the Session-Sender sits close to the actual multicast source (say, a camera transmitting live video). That way the test packets follow the same path as the video stream packets in one direction, but the reflected test packets take another route to the place where the data gets analyzed 🎥✨.

For compatibility with [RFC9503], a Session-Sender MUST NOT include a Return Path Control Code sub-TLV with the Control Code Flags set to No Reply Requested in a test packet that also contains a Reflected Test Packet Control TLV with a non-zero value 🚫. A Session-Reflector that supports both TLVs MUST set the U flag to 1 in both the Return Path and Reflected Test Packet Control TLVs within the reflected STAMP packet 🏳️‍🌈. And the Session-Reflector SHOULD log a notification to tell an operator about the misconstructed STAMP packet 📝. Someone has to be the responsible adult in the room 🫶.

The Reflected Test Packet Control TLV can be combined with the Class of Service TLV [RFC8972] to boost rate testing, or for testing in a multicast network that checks whether Differentiated Services Code Point and ECN values stay consistent in the forward and reverse directions of a particular STAMP-Test session 🌈🦋.

5. Security Considerations 🔐

okay bestie, this is the scary-but-important part, so read it slowly 😭🔒 everything in [RFC7497], [RFC8762], [RFC8972], and [RFC9503] applies here too, so all those security notes come along for the ride 🎀. but there's extra drama: spoofed STAMP-Test packets carrying the Reflected Test Packet Control TLV can be used to run a Denial-of-Service (DoS) attack 💀. so implementations MUST use an identity protection mechanism 🛡️. for example, the Session-Reflector may verify the info about where a STAMP packet came from against a pre-defined list of trusted nodes 👀.

ps: an implementation that supports this specification MUST provide administrative control of support of the Reflected Test Packet Control TLV on a Session-Reflector, and it has to be disabled by default 🙅‍♀️

also, either the STAMP authentication mode [RFC8762] or the HMAC (Hashed Message Authentication Code) TLV [RFC8972] SHOULD be used for a STAMP-Test session containing the Reflected Test Packet Control TLV 🔑. note that if integrity protection is enabled, any in-path modification will cause verification to fail, unless the modifying element is within the trust boundary and can recompute the integrity check 🧐.

a DoS attack using the Reflected Test Packet Control TLV might also 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 3 for a detailed discussion) 🚦.

multicast check 👀 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. this way, a Session-Sender can count the packets reflected after originating a first STAMP-Test packet with the Reflected Test Packet Control TLV, and then 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 further mitigate the risk of using the Reflected Test Packet Control TLV in a multicast network, 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 value in the previous test packet of the same STAMP-Test session, is not monotonically increasing, then the Session-Reflector MUST respond with a single reflected packet, setting the U flag to 1 [RFC8972] 🙅. that may not indicate a replay attack. it could mean there is packet re-ordering or packet duplication in the network 🌀. an operator can use other diagnostic methods to characterize and localize the problem 🔍. an implementation of the Session-Reflector can use the Serial Number Arithmetic [RFC1982] or any of the other methods to verify the correct ordering of test packets 🧠.

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 the transmission of 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 Sections 3 and 7 of [RFC7497] 🗒️. if the underlay network is ECN-capable, a Session-Reflector may receive STAMP-Test packets with the ECN field marked as Congestion Experienced (CE) 🚩. ECN markings give an indication of incipient congestion, not packet loss 🌡️. however, the interpretation of what counts as "significant congestion," and the operational thresholds for reacting to ECN-CE, depend on the specific deployment, service objectives, and operator policy 🏢. operators should be aware that In-Service capacity measurements may influence congestion conditions, potentially contributing to ECN-CE marking in the network 📡. implementations and operational procedures SHOULD ensure that the use of STAMP for In-Service measurement does not unintentionally degrade data traffic or lead to misinterpretation of ECN-related congestion signals 🫧. appropriate thresholds and mitigation actions remain deployment-specific and SHOULD be guided by operator policy and network performance objectives 🎯.

last bit, and it's a good one 🥹 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 🐇. and Section 8.1 of [RFC9097] specifies the load rate adjustment algorithm, with its sample pseudocode offered in Appendix A of [RFC9097] 🧑‍💻✨.

6. IANA Considerations 📋

6.1. Reflected Test Packet Control TLV Type

IANA has assigned a new value for the Reflected Test Packet Control TLV in the "STAMP TLV Types" registry under the "Simple Two-way Active Measurement Protocol (STAMP) TLV Types" registry group, as follows 🦋:

        +=======+===============================+===========+
        | Value | Description                   | Reference |
        +=======+===============================+===========+
        | 12    | Reflected Test Packet Control | RFC 10052 |
        +-------+-------------------------------+-----------+

           Table 1: Reflected Test Packet Control TLV Type

6.2. Conformant Reflected Packet STAMP TLV Flag

IANA has allocated a bit position for the Conformant Reflected Packet STAMP TLV flag in the "STAMP TLV Flags" registry under the "Simple Two-way Active Measurement Protocol (STAMP) TLV Types" registry group, as follows 🌸.

         +==============+========+=============+===========+
         | Bit position | Symbol | Description | Reference |
         +==============+========+=============+===========+
         | 3            | C      | Conformant  | RFC 10052 |
         +--------------+--------+-------------+-----------+

         Table 2: Conformant Reflected Packet STAMP TLV Flag

6.3. Layer 2 and Layer 3 Address Group Sub-TLV Types

IANA has assigned values for the Layer 2 Address Group and Layer 3 Address Group sub-TLV Types in the "STAMP Sub-TLV Types" registry under the "Simple Two-way Active Measurement Protocol (STAMP) TLV Types" registry group, as follows 🧚.

   +=======+=======================+================+===========+
   | Value | Description           | TLV Used       | Reference |
   +=======+=======================+================+===========+
   | 10    | Layer 2 Address Group | Reflected Test | RFC 10052 |
   |       |                       | Packet Control |           |
   +-------+-----------------------+----------------+-----------+
   | 11    | Layer 3 Address Group | Reflected Test | RFC 10052 |
   |       |                       | Packet Control |           |
   +-------+-----------------------+----------------+-----------+

     Table 3: STAMP Sub-TLV Types for the Reflected Test Packet
                            Control TLV

7. References 📚

7.1. Normative References

these are the must-read receipts 🧾 (the spec is built on them, no cap).

[IANA-STAMP]
           IANA, "STAMP Sub-TLV Types",
           <https://www.iana.org/assignments/stamp-tlv-types>.

[RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
           DOI 10.17487/RFC1982, August 1996,
           <https://www.rfc-editor.org/info/rfc1982>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC7497]  Morton, A., "Rate Measurement Test Protocol Problem
           Statement and Requirements", RFC 7497,
           DOI 10.17487/RFC7497, April 2015,
           <https://www.rfc-editor.org/info/rfc7497>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8762]  Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
           Two-Way Active Measurement Protocol", RFC 8762,
           DOI 10.17487/RFC8762, March 2020,
           <https://www.rfc-editor.org/info/rfc8762>.

[RFC8972]  Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A.,
           and E. Ruffini, "Simple Two-Way Active Measurement
           Protocol Optional Extensions", RFC 8972,
           DOI 10.17487/RFC8972, January 2021,
           <https://www.rfc-editor.org/info/rfc8972>.

[RFC9503]  Gandhi, R., Ed., Filsfils, C., Chen, M., Janssens, B., and
           R. Foote, "Simple Two-Way Active Measurement Protocol
           (STAMP) Extensions for Segment Routing Networks",
           RFC 9503, DOI 10.17487/RFC9503, October 2023,
           <https://www.rfc-editor.org/info/rfc9503>.

[RFC9946]  Morton, A., Ciavattone, L., and R. Geib, Ed., "The UDP
           Speed Test Protocol (UDPSTP) for One-Way IP Capacity
           Metric Measurement", RFC 9946, DOI 10.17487/RFC9946, April
           2026, <https://www.rfc-editor.org/info/rfc9946>.

7.2. Informative References

and these are the extra reading for when you want to go deeper 🌈📖.

[IEEE-802.3-2022]
           IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2022,
           DOI 10.1109/IEEESTD.2022.9844436, July 2022,
           <https://doi.org/10.1109/IEEESTD.2022.9844436>.

[IEEE-802.15.4-2024]
           IEEE, "IEEE Standard for Low-Rate Wireless Networks",
           IEEE Std 802.15.4-2024, DOI 10.1109/IEEESTD.2024.10794632,
           December 2024,
           <https://doi.org/10.1109/IEEESTD.2024.10794632>.

[RFC7594]  Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
           Aitken, P., and A. Akhter, "A Framework for Large-Scale
           Measurement of Broadband Performance (LMAP)", RFC 7594,
           DOI 10.17487/RFC7594, September 2015,
           <https://www.rfc-editor.org/info/rfc7594>.

[RFC7799]  Morton, A., "Active and Passive Metrics and Methods (with
           Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
           May 2016, <https://www.rfc-editor.org/info/rfc7799>.

[RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
           Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
           March 2017, <https://www.rfc-editor.org/info/rfc8085>.

[RFC9097]  Morton, A., Geib, R., and L. Ciavattone, "Metrics and
           Methods for One-Way IP Capacity", RFC 9097,
           DOI 10.17487/RFC9097, November 2021,
           <https://www.rfc-editor.org/info/rfc9097>.

Acknowledgments 🫶

big thank-yous 💖 the authors thank Zhang Li, Ruediger Geib, Rakesh Gandhi, Giuseppe Fioccola, Xiao Min, Greg White, and Rohan Bhosle for their thorough reviews and helpful suggestions, which improved the document 🎀✨.

Authors' Addresses ✨

okay bestie, the squad behind this spec 🫶 here's how to reach each of them:

Greg Mirsky 💖

  • Ciena Corporation
  • Email: gregimirsky@gmail.com

Ernesto Ruffini 🦋

  • OutSys
  • Email: eruffini@outsys.org

Henrik Nydell 🌸

  • Cisco Systems
  • Email: hnydell@cisco.com

Richard Foote 🧚

  • Nokia
  • Email: footer.foote@nokia.com

Will Hawkins 👑

  • University of Cincinnati
  • Email: hawkinsw@obs.cr
📦 where this page comes from