Performance Measurement with Asymmetrical Traffic Using Simple Two-Way Active Measurement Protocol (STAMP)
draft-ietf-ippm-asymmetrical-pkts-10

Network Working Group                                          G. Mirsky
Internet-Draft                                                  Ericsson
Intended status: Standards Track                              E. Ruffini
Expires: 14 August 2026                                           OutSys
                                                               H. Nydell
                                                           Cisco Systems
                                                                R. Foote
                                                                   Nokia
                                                              W. Hawkins
                                                University of Cincinnati
                                                        10 February 2026

 Performance Measurement with Asymmetrical Traffic Using Simple Two-Way
                  Active Measurement Protocol (STAMP)
                  draft-ietf-ippm-asymmetrical-pkts-10

Abstract

   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 specified in this
   document allows operators 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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Mirsky, et al.           Expires 14 August 2026                 [Page 1]
Internet-Draft      Asymmetrical Traffic Using STAMP       February 2026

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 14 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Reflected Test Packet Control TLV . . . . . . . . . . . . . .   4
     2.1.  Address Group Sub-TLVs  . . . . . . . . . . . . . . . . .   7
       2.1.1.  Layer 2 Address Group Sub-TLV . . . . . . . . . . . .   7
       2.1.2.  Layer 3 Address Group Sub-TLV . . . . . . . . . . . .   8
   3.  Operational Considerations  . . . . . . . . . . . . . . . . .   9
     3.1.  Rate Measurement  . . . . . . . . . . . . . . . . . . . .   9
       3.1.1.  Operational Considerations for Performing Rate
               Measurement . . . . . . . . . . . . . . . . . . . . .   9
     3.2.  Active Performance Measurement in Multicast
           Environment . . . . . . . . . . . . . . . . . . . . . . .   9
     3.3.  Using Reflected Test Packet Control TLV in Combination with
           Other TLVs  . . . . . . . . . . . . . . . . . . . . . . .  11
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   5.  Implementation Status . . . . . . . . . . . . . . . . . . . .  12
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  14
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  Reflected Test Packet Control TLV Type  . . . . . . . . .  14

Mirsky, et al.           Expires 14 August 2026                 [Page 2]
Internet-Draft      Asymmetrical Traffic Using STAMP       February 2026

     7.2.  Conformant Reflected Packet STAMP TLV Flag  . . . . . . .  15
     7.3.  Layer 2 and Layer 3 Address Group Sub-TLV Types . . . . .  15
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   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 a Session-Reflector exchange
   packets symmetrically: 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 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 operators the tools to create such Asymmetrical Packets between
   a Session-Sender and a Session-Reflector.

   Measurement of performance metrics in a multicast network using an
   active measurement method (Section 3.4 of [RFC7799]) 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.

1.1.  Terminology

   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.

Mirsky, et al.           Expires 14 August 2026                 [Page 3]
Internet-Draft      Asymmetrical Traffic Using STAMP       February 2026

   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.

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

2.  Reflected Test Packet Control TLV

   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                           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 1: Reflected Test Packet Control TLV Format

   The descriptions of the fields are as follows:

      STAMP TLV Flags is a one-octet field.

      Type is a one-octet field that identifies the Reflected Test
      Packet Control TLV.  This field is set to TBA1 (Section 7.1).

Mirsky, et al.           Expires 14 August 2026                 [Page 4]
Internet-Draft      Asymmetrical Traffic Using STAMP       February 2026

      Length is a two-octet field.  The value is variable, and MUST NOT
      be smaller than 12 octets.

      Length of the Reflected Packet is 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 is 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 is 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 is an optional field that includes additional information
      communicated by a Session-Sender.

   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:

      The length of the reflected test packet MUST be the largest of
      the:

   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 TLV present in combination with
       Reflected Test Packet Control TLV is to support a scenario when a
       Session-Reflector is requested to transmit a sequence of packets
       shorter than the received STAMP packet.

Mirsky, et al.           Expires 14 August 2026                 [Page 5]
Internet-Draft      Asymmetrical Traffic Using STAMP       February 2026

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

Mirsky, et al.           Expires 14 August 2026                 [Page 6]
Internet-Draft      Asymmetrical Traffic Using STAMP       February 2026

   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:

      The requested length exceeds the MTU of the egress interface of
      the Session-Reflector if the length of the received reflected
      STAMP packet is less than 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 if the length of the received
      reflected STAMP packet equals the value of the Length of the
      "Reflected Packet" field.

2.1.  Address Group Sub-TLVs

2.1.1.  Layer 2 Address Group Sub-TLV

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

               Figure 2: Layer 2 Address Group Sub-TLV Format

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

      EUI-48 Address Group Mask: A six-octet field that represents the
      bitmask to be applied to the Session-Reflector MAC address.

Mirsky, et al.           Expires 14 August 2026                 [Page 7]
Internet-Draft      Asymmetrical Traffic Using STAMP       February 2026

      EUI-48 Address Group: A six-octet field that represents the group
      that this TLV is addressed to.  If the Session-Reflector applies
      the EUI-48 Address Group Mask to its MAC address and the result is
      different from the EUI-48 Address Group, then the Session-
      Reflector MUST stop processing the received test packet.

2.1.2.  Layer 3 Address Group Sub-TLV

   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                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 3: Layer 3 Address Group Sub-TLV Format

   The Value field of the Layer 3 Address Group Sub-TLV consists of the
   following fields:

      Address Family: A one-octet field that indicates the type of the
      IP address contained in the "IP Prefix" field.  If that is IPv4
      address, then the value MUST be set to 1.  For an IPv6 address,
      the value MUST be set to 2.  Other values MUST be considered
      invalid.

      Prefix Length: A one-octet unsigned integer field that contains
      the length, in bits, of the prefix of the value in the "IP Prefix"
      field.

      Reserved: A two-octet field.  The field MUST be set to zeros on
      transmission and ignored on receipt.

Mirsky, et al.           Expires 14 August 2026                 [Page 8]
Internet-Draft      Asymmetrical Traffic Using STAMP       February 2026

      IP Prefix: A variable-length field.  Depending on the value of the
      "Address Family" field, the field contains either an IPv4 or IPv6
      address.  If the former, the length is four octets; if the latter
      - 16 octets.

3.  Operational Considerations

3.1.  Rate Measurement

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

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

3.2.  Active Performance Measurement in Multicast Environment

   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.

Mirsky, et al.           Expires 14 August 2026                 [Page 9]
Internet-Draft      Asymmetrical Traffic Using STAMP       February 2026

   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 may 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:

      Randomly 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;

      Having a specific vendor NIC by specifying a Layer 2 Address Group
      Sub-TLV with the EUI-48 Address Group Mask set to 0xFFFFFF000000;

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

Mirsky, et al.           Expires 14 August 2026                [Page 10]
Internet-Draft      Asymmetrical Traffic Using STAMP       February 2026

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

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

4.  Security Considerations

   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.

Mirsky, et al.           Expires 14 August 2026                [Page 11]
Internet-Draft      Asymmetrical Traffic Using STAMP       February 2026

   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.

5.  Implementation Status

   Note to RFC Editor: This section MUST be removed before publication
   of the document.

Mirsky, et al.           Expires 14 August 2026                [Page 12]
Internet-Draft      Asymmetrical Traffic Using STAMP       February 2026

   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/do
   cumentation/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:

   *  Authenticated and Unauthenticated modes

   *  Stateless and stateful operation

   *  9 standardized and to-be standardized extensions

   - Version compatibility: N/A

Mirsky, et al.           Expires 14 August 2026                [Page 13]
Internet-Draft      Asymmetrical Traffic Using STAMP       February 2026

   - 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

6.  Acknowledgments

   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.

7.  IANA Considerations

   Note to the RFC Editor: Please update all TBA1/TBA2/TBA3/TBA4 through
   the document with the values assigned by IANA.

7.1.  Reflected Test Packet Control TLV Type

   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.

Mirsky, et al.           Expires 14 August 2026                [Page 14]
Internet-Draft      Asymmetrical Traffic Using STAMP       February 2026

         +=======+===============================+===============+
         | Value | Description                   | Reference     |
         +=======+===============================+===============+
         |  TBA1 | Reflected Test Packet Control | This document |
         +-------+-------------------------------+---------------+

            Table 1: New Reflected Test Packet Control Type TLV

7.2.  Conformant Reflected Packet STAMP TLV Flag

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

            Table 2: Conformant Reflected Packet STAMP TLV Flag

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

   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 | This document |
    |       |                       | Packet Control |               |
    +-------+-----------------------+----------------+---------------+
    |  TBA3 | Layer 3 Address Group | Reflected Test | This document |
    |       |                       | Packet Control |               |
    +-------+-----------------------+----------------+---------------+

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

8.  References

8.1.  Normative References

Mirsky, et al.           Expires 14 August 2026                [Page 15]
Internet-Draft      Asymmetrical Traffic Using STAMP       February 2026

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

8.2.  Informative References

   [I-D.ietf-ippm-capacity-protocol]
              Ciavattone, L. and R. Geib, "UDP Speed Test Protocol for
              One-way IP Capacity Metric Measurement", Work in Progress,
              Internet-Draft, draft-ietf-ippm-capacity-protocol-25, 16
              September 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-ippm-capacity-protocol-25>.

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

Mirsky, et al.           Expires 14 August 2026                [Page 16]
Internet-Draft      Asymmetrical Traffic Using STAMP       February 2026

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

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

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

Authors' Addresses

   Greg Mirsky
   Ericsson
   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

Mirsky, et al.           Expires 14 August 2026                [Page 17]