Performance Measurement with Asymmetrical Packets in STAMP
draft-mirsky-ippm-asymmetrical-pkts-04
| Document | Type | Active Internet-Draft (candidate for ippm WG) | |
|---|---|---|---|
| Authors | Greg Mirsky , Ernesto Ruffini , Henrik Nydell , Richard "Footer" Foote | ||
| Last updated | 2024-04-09 (Latest revision 2024-02-20) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Call For Adoption By WG Issued | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mirsky-ippm-asymmetrical-pkts-04
Network Working Group G. Mirsky
Internet-Draft Ericsson
Intended status: Standards Track E. Ruffini
Expires: 23 August 2024 OutSys
H. Nydell
Cisco Systems
R. Foote
Nokia
20 February 2024
Performance Measurement with Asymmetrical Packets in STAMP
draft-mirsky-ippm-asymmetrical-pkts-04
Abstract
This document describes an optional extension to a Simple Two-way
Active Measurement Protocol (STAMP) that enables the use of STAMP
test and reflected packets of variable length 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 23 August 2024.
Mirsky, et al. Expires 23 August 2024 [Page 1]
Internet-Draft Asymmetrical Packets in STAMP February 2024
Copyright Notice
Copyright (c) 2024 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 . . . . . . . . . . . . . . . . . 5
2.1.1. Layer 2 Address Group Sub-TLV . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Using Reflected Test Packet Control TLV in Combination with
Other TLVs . . . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Reflected Test Packet Control TLV Type . . . . . . . . . 9
6.2. Reflected Test Packet Control TLV Type . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 23 August 2024 [Page 2]
Internet-Draft Asymmetrical Packets in STAMP February 2024
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
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Reflected Test Packet Control TLV Format
Mirsky, et al. Expires 23 August 2024 [Page 3]
Internet-Draft Asymmetrical Packets in STAMP February 2024
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
length of the Session-Reflector packet in the mode matching mode
of the received STAMP test packet, as defined in Section 4.3 of
[RFC8762] with all the present in the received STAMP test packet
STAMP extension TLVs [RFC8972], excluding the Extra Padding TLV,
present in the received STAMP test packet, and the value in the
Length of the Reflected Packet aligned at a four-octets boundary.
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 to
the value of the Number of the Reflected Test Packets.
Mirsky, et al. Expires 23 August 2024 [Page 4]
Internet-Draft Asymmetrical Packets in STAMP February 2024
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].
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:
Mirsky, et al. Expires 23 August 2024 [Page 5]
Internet-Draft Asymmetrical Packets in STAMP February 2024
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 EUI-48
Address Group Mask to its MAC Address and the result is different
from 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 or 20. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
Mirsky, et al. Expires 23 August 2024 [Page 6]
Internet-Draft Asymmetrical Packets in STAMP February 2024
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.
3.2. Active Performance Measurement in Multicast Environment
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 of the monitoring performance of a multicast flow, despite that
the destination IP address is multicast. 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 Session-
Reflector 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. Adding a Reflected Test Packet
Control TLV allows Session-Sender to limit the number of replies. It
may do so by selecting Session-Reflectors, for example:
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;
Mirsky, et al. Expires 23 August 2024 [Page 7]
Internet-Draft Asymmetrical Packets in STAMP February 2024
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.
3.3. Using Reflected Test Packet Control TLV in Combination with Other
TLVs
[RFC9503] defines the Return Path TLV that, when used in the
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 the [RFC7594]) for further
processong 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.
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 attack. Hence, implementations MUST
use an identity protection mechanism. For example, verify the
information about the source of the STAMP packet against a pre-
defined list of trusted nodes. Also, STAMP authentication mode
[RFC8762] or HMAC TLV [RFC8972] could be used for a STAMP test
Mirsky, et al. Expires 23 August 2024 [Page 8]
Internet-Draft Asymmetrical Packets in STAMP February 2024
session containing the Reflected Test Packet Control TLV.
Considering the potential number of reflected packets that can be
generated by a single test packet sent to a Multicast address, when
sending such messages a Session-Sender SHOULD sign packets using the
HMAC TLV.
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
TBA
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 sub-registry according to
Table 1.
+=======+===================================+===============+
| Value | Description | Reference |
+=======+===================================+===============+
| TBA1 | Reflected Test Packet Control TLV | This document |
+-------+-----------------------------------+---------------+
Table 1: New Reflected Test Packet Control Type TLV
6.2. 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 Sub-TLV Types sub-registry
according to Table 2.
Mirsky, et al. Expires 23 August 2024 [Page 9]
Internet-Draft Asymmetrical Packets in STAMP February 2024
+=======+===============+====================+===============+
| Value | Description | TLV Used | Reference |
+=======+===============+====================+===============+
| TBA2 | Layer 2 | Reflected Test | This document |
| | Address Group | Packet Control TLV | |
+-------+---------------+--------------------+---------------+
| TBA3 | Layer 3 | Reflected Test | This document |
| | Address Group | Packet Control TLV | |
+-------+---------------+--------------------+---------------+
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>.
[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>.
[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>.
Mirsky, et al. Expires 23 August 2024 [Page 10]
Internet-Draft Asymmetrical Packets in STAMP February 2024
7.2. Informative References
[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>.
Authors' Addresses
Greg Mirsky
Ericsson
Email: gregimirsky@gmail.com
Ernesto Ruffini
OutSys
via Caracciolo, 65
20155 Milano
Italy
Email: eruffini@outsys.org
Henrik Nydell
Cisco Systems
Email: hnydell@cisco.com
Richard Foote
Nokia
Email: footer.foote@nokia.com
Mirsky, et al. Expires 23 August 2024 [Page 11]