Performance Measurement with Asymmetrical Traffic Using STAMP
draft-ietf-ippm-asymmetrical-pkts-05

Network Working Group                                          G. Mirsky
Internet-Draft                                                  Ericsson
Intended status: Standards Track                              E. Ruffini
Expires: 2 October 2025                                           OutSys
                                                               H. Nydell
                                                           Cisco Systems
                                                                R. Foote
                                                                   Nokia
                                                              W. Hawkins
                                                University of Cincinnati
                                                           31 March 2025

     Performance Measurement with Asymmetrical Traffic Using STAMP
                  draft-ietf-ippm-asymmetrical-pkts-05

Abstract

   This document describes an optional extension to a Simple Two-way
   Active Measurement Protocol (STAMP) that enables control of the
   length and/or number of reflected packets during a single STAMP test
   session.  In some use cases, the use of asymmetrical test packets
   allow for the creation of more realistic flows of test packets and,
   thus, a closer approximation between active performance measurements
   and conditions experienced by the monitored application.

   Also, the document includes an analysis of challenges related to
   performance monitoring in a multicast network.  It defines 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.

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

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

   This Internet-Draft will expire on 2 October 2025.

Mirsky, et al.           Expires 2 October 2025                 [Page 1]
Internet-Draft      Asymmetrical Traffic Using STAMP          March 2025

Copyright Notice

   Copyright (c) 2025 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Reflected Test Packet Control TLV . . . . . . . . . . . . . .   3
     2.1.  Address Group Sub-TLVs  . . . . . . . . . . . . . . . . .   6
       2.1.1.  Layer 2 Address Group Sub-TLV . . . . . . . . . . . .   6
       2.1.2.  Layer 3 Address Group Sub-TLV . . . . . . . . . . . .   6
   3.  Theory of Operation . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Rate Measurement  . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Active Performance Measurement in Multicast
           Environment . . . . . . . . . . . . . . . . . . . . . . .   8
     3.3.  Using Reflected Test Packet Control TLV in Combination with
           Other TLVs  . . . . . . . . . . . . . . . . . . . . . . .   9
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Reflected Test Packet Control TLV Type  . . . . . . . . .  10
     6.2.  Layer 2 and Layer 3 Address Group Sub-TLV Types . . . . .  11
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] defined
   the STAMP base functionalities.  STAMP Protocol Optional Extensions
   [RFC8972] introduces a TLV structure that allows the Session-Sender
   to include optional instructions for Session-Reflector.  New STAMP
   TLVs can be defined to support the scenarios in [RFC7497], which
   discusses the coordination of messaging between the source and
   destination to help deliver one of the fundamental principles of IP

Mirsky, et al.           Expires 2 October 2025                 [Page 2]
Internet-Draft      Asymmetrical Traffic Using STAMP          March 2025

   performance metric measurements, minimizing the test traffic effect
   on user flows.  In some scenarios, e.g., rate measurements discussed
   in [RFC7497], it is beneficial not only to use a variable size of the
   test packets transmitted downstream while controlling length, number,
   and interpacket interval for reflected test packets.

   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 defines procedures and STAMP
   extensions to achieve more efficient measurements with a lesser
   impact on a network.

1.1.  Abbreviations

   STAMP Simple Two-way Active Measurement Protocol

   DoS Denial-of-Service

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 document defines a new optional STAMP extension, Reflected Test
   Packet Control TLV.  The format of the Reflected Test Packet Control
   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                           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Mirsky, et al.           Expires 2 October 2025                 [Page 3]
Internet-Draft      Asymmetrical Traffic Using STAMP          March 2025

             Figure 1: Reflected Test Packet Control TLV Format

   The interpretation of the fields is as follows:

      STAMP TLV Flags is a one-octet field.

      Type is a one-octet field that identifies the Reflected Test
      Packet Control TLV.  IANA is requested (Section 6.1) to assign
      (TBA1) value.

      Length is a two-octet field.  The value is variable, not smaller
      than 12 octets.

      Length of the Reflected Packet is a four-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 four-octet field.  The value
      is an unsigned integer that is the number of reflected test
      packets 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 - an optional field that includes additional information
      communicated by a Session-Sender.

   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:

Mirsky, et al.           Expires 2 October 2025                 [Page 4]
Internet-Draft      Asymmetrical Traffic Using STAMP          March 2025

   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.
   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 such 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 [RFC8972], the Session-Reflector MUST use
   the Extra Padding TLV (Section 4.1 of [RFC8972]) to increase the
   length of the reflected test packet.

      The number of reflected test packets in the sequence MUST equal
      the value of the Number of the Reflected Test Packets.

      If the value of the Number of the Reflected Packets 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 in nanoseconds.  If a
      Session-Reflector that recognizes the Reflected Test Control TLV
      cannot sustain the transmission of reflected test packets at the
      interval requested in the Interval Between the Reflected Packets
      field on the received TLV, the Session-Reflector MUST set the U
      flag [RFC8972] to 1, and MUST transmit a single reflected packet.
      Otherwise, the Session-Reflector MUST set the U flag to 0 in each
      of reflected test packets.

      If the value of the Number of the Reflected Packets 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 equals zero, is according to the local nodal
      policy.  The received STAMP test packet is 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 2 October 2025                 [Page 5]
Internet-Draft      Asymmetrical Traffic Using STAMP          March 2025

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 value
   is TBA2 (Section 6.2).  The value of the Length field MUST be equal
   to 12.  The format of 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     EUI-48 Address Group Mask                 |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |                               |
   |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|                               |
   |                       EUI-48 Address Group                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 2: Layer 2 Address Group Sub-TLV Format

   The Value field 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.

      EUI-48 Address Group: A six-octet field that represents the group
      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 Network Prefix, and IP Prefix
   Length.  The Type value is TBA3 (Section 6.2).  The value of the
   Length field MUST be equal to 8 if the value of the Address Family
   family is set to IPv4.  The value of the Length field MUST be equal
   to 20 if the value of the Address Family field is set to IPv6.  The
   format of Layer 3 Address Group sub-TLV is presented in Figure 3.

Mirsky, et al.           Expires 2 October 2025                 [Page 6]
Internet-Draft      Asymmetrical Traffic Using STAMP          March 2025

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

               Figure 3: Layer 3 Address Group Sub-TLV Format

   The Value field consists of the following fields:

      Address Family: A one-octet field that indicates the type of IP
      address contained in the IP Network Prefix field.  If that is IPv4
      address, then the value MUST be set to 1.  For the 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 network prefix part of the value in
      the IP Network Prefix field.

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

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

3.  Theory of Operation

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 UDP Speed Test
   ([RFC9097] and [I-D.ietf-ippm-capacity-protocol]) also allows for the
   measurement of access bandwidth.

Mirsky, et al.           Expires 2 October 2025                 [Page 7]
Internet-Draft      Asymmetrical Traffic Using STAMP          March 2025

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.

   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, the behavior of a Session-Reflector upon receiving a STAMP
   test packet over a multicast tree is as defined in [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.

   The Session-Sender has to pay more attention when sending a multicast
   STAMP packet.  Instead of possibly receiving a reply from a single
   Session-Reflector, the Session-Sender may now receive multiple
   replies from multiple counterparts: its STAMP Session has a 1:N
   relation.  Network traffic is another aspect that needs attention:
   network congestion may happen if a single packet can generate
   millions of concurrent replies, all directed to the same endpoint.
   Depending on the multicast-implementation, adding a Reflected Test
   Packet Control TLV allows Session-Sender to limit the number of
   replies.  If a multicast environment allows selecting Session-
   Reflectors, this may, for example, be done by

      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

Mirsky, et al.           Expires 2 October 2025                 [Page 8]
Internet-Draft      Asymmetrical Traffic Using STAMP          March 2025

   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.

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

   [RFC9503] defines the Return Path TLV that, 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 could be used in the multicast
   scenario when, for example, the Session-Sender is close to the actual
   multicast frames generator (for example, a camera transmitting live
   video) so that the test packets follow the same path as the video
   stream packets in one direction.  The data center where the test data
   are analyzed could be far away, and it would be better to have
   reflected packets return there.

   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 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 onsistency 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 [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 could verify the information about the source of the STAMP
   packet against a pre-defined list of trusted nodes.  Also, either
   STAMP authentication mode [RFC8762] or HMAC TLV [RFC8972] SHOULD be
   used for a STAMP test session containing the Reflected Test Packet

Mirsky, et al.           Expires 2 October 2025                 [Page 9]
Internet-Draft      Asymmetrical Traffic Using STAMP          March 2025

   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., extremely small intervals and/or too many
   concurrent test sessions.  To mitigate that, an implementation that
   supports the new TLV MUST control the rate and volume of reflection
   of STAMP test packets by the Session-Reflector.

   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.

5.  Acknowledgments

   The authors thank Zhang Li and Ruediger Geib for their thorough
   reviews and helpful suggestions, which improved the document.

6.  IANA Considerations

6.1.  Reflected Test Packet Control TLV Type

   The IANA is requested to assign a new value for the Reflected Test
   Packet Control TLV from the STAMP TLV Types registry according to
   Table 1.

Mirsky, et al.           Expires 2 October 2025                [Page 10]
Internet-Draft      Asymmetrical Traffic Using STAMP          March 2025

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

            Table 1: New Reflected Test Packet Control Type TLV

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

   The 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
   according to Table 2.

    +=======+=======================+================+===============+
    | 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 2: STAMP sub-TLV Types for the Reflected Test Packet
                               Control TLV

7.  References

7.1.  Normative References

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

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

Mirsky, et al.           Expires 2 October 2025                [Page 11]
Internet-Draft      Asymmetrical Traffic Using STAMP          March 2025

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

7.2.  Informative References

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

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

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

   [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

Mirsky, et al.           Expires 2 October 2025                [Page 12]
Internet-Draft      Asymmetrical Traffic Using STAMP          March 2025

   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 2 October 2025                [Page 13]