draft-ietf-ippm-asymmetrical-pkts-07.txt		draft-ietf-ippm-asymmetrical-pkts-08.txt
	Network Working Group G. Mirsky		Network Working Group G. Mirsky
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Standards Track E. Ruffini		Intended status: Standards Track E. Ruffini
	Expires: 6 November 2025 OutSys		Expires: 6 December 2025 OutSys
	H. Nydell		H. Nydell
	Cisco Systems		Cisco Systems
	R. Foote		R. Foote
	Nokia		Nokia
	W. Hawkins		W. Hawkins
	University of Cincinnati		University of Cincinnati
	5 May 2025		4 June 2025
	Performance Measurement with Asymmetrical Traffic Using STAMP		Performance Measurement with Asymmetrical Traffic Using STAMP
	draft-ietf-ippm-asymmetrical-pkts-07		draft-ietf-ippm-asymmetrical-pkts-08
	Abstract		Abstract
	This document describes an optional extension to a Simple Two-way		This document describes an optional extension to a Simple Two-way
	Active Measurement Protocol (STAMP) that enables control of the		Active Measurement Protocol (STAMP) that enables control of the
	length and/or number of reflected packets during a single STAMP test		length and/or number of reflected packets during a single STAMP test
	session. In some use cases, the use of asymmetrical test packets		session. In some use cases, the use of asymmetrical test packets
	allow for the creation of more realistic flows of test packets and,		allow for the creation of more realistic flows of test packets and,
	thus, a closer approximation between active performance measurements		thus, a closer approximation between active performance measurements
	and conditions experienced by the monitored application.		and conditions experienced by the monitored application.
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 6 November 2025.		This Internet-Draft will expire on 6 December 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2025 IETF Trust and the persons identified as the		Copyright (c) 2025 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 10, line 41 ¶		skipping to change at page 10, line 41 ¶
	Return Path Control Code Sub-TLV with the Control Code flag set to No		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		Reply Requested in the same test packet as the Reflected Test Packet
	Control TLV is non-zero. A Session-Reflector that supports both TLVs		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		MUST set the U flag to 1 in Return Path and Reflected Test Packet
	Control TLVs in the reflected STAMP packet. Furthermore, the		Control TLVs in the reflected STAMP packet. Furthermore, the
	Session-Reflector SHOULD log a notification to inform an operator		Session-Reflector SHOULD log a notification to inform an operator
	about the misconstructed STAMP packet.		about the misconstructed STAMP packet.
	Reflected Test Packet Control TLV can be combined with the Class of		Reflected Test Packet Control TLV can be combined with the Class of
	Service TLV [RFC8972] to augment rate testing or testing in a		Service TLV [RFC8972] to augment rate testing or testing in a
	multicast network with monitoring the onsistency of Differentiated		multicast network with monitoring the consistency of Differentiated
	Services Code Point and Explicit Congestion Notification values in		Services Code Point and Explicit Congestion Notification values in
	forward and reverse directions of the particular STAMP test session.		forward and reverse directions of the particular STAMP test session.
	4. Security Considerations		4. Security Considerations
	Security considerations discussed in [RFC7497], [RFC8762],[RFC8972],		Security considerations discussed in [RFC7497], [RFC8762],[RFC8972],
	and [RFC9503] apply to this document. Furthermore, spoofed STAMP		and [RFC9503] apply to this document. Furthermore, spoofed STAMP
	test packets with the Reflected Test Packet Control TLV can be		test packets with the Reflected Test Packet Control TLV can be
	exploited to conduct a Denial-of-Service (DoS) attack. Hence,		exploited to conduct a Denial-of-Service (DoS) attack. Hence,
	implementations MUST use an identity protection mechanism. For		implementations MUST use an identity protection mechanism. For
	skipping to change at page 11, line 14 ¶		skipping to change at page 11, line 14 ¶
	source of the STAMP packet against a pre-defined list of trusted		source of the STAMP packet against a pre-defined list of trusted
	nodes. Furthermore, an implementation that supports this		nodes. Furthermore, an implementation that supports this
	specification MUST provide administrative control of support of the		specification MUST provide administrative control of support of the
	Reflected Test Packet Control TLV on a Session-Reflector with it		Reflected Test Packet Control TLV on a Session-Reflector with it
	being disabled by default. Also, either STAMP authentication mode		being disabled by default. Also, either STAMP authentication mode
	[RFC8762] or HMAC TLV [RFC8972] SHOULD be used for a STAMP test		[RFC8762] or HMAC TLV [RFC8972] SHOULD be used for a STAMP test
	session containing the Reflected Test Packet Control TLV.		session containing the Reflected Test Packet Control TLV.
	Furthermore, a DoS attack using the Reflected Test Packet Control TLV		Furthermore, a DoS attack using the Reflected Test Packet Control TLV
	might target the STAMP Session-Reflector by overloading it with test		might target the STAMP Session-Reflector by overloading it with test
	packet reflection, e.g., extremely small intervals and/or too many		packet reflection, e.g., minuscule intervals and/or an excessive
	concurrent test sessions. To mitigate that, a Session-Reflector		number of concurrent test sessions. To mitigate that, a Session-
	implementation that supports the new TLV MUST provide a mechanism to		Reflector implementation that supports the new TLV MUST provide a
	limit the reflection rate and volume of STAMP test packets (see		mechanism to limit the reflection rate and volume of STAMP test
	Section 2 for detailed discussion).		packets (see Section 2 for detailed discussion).
	Considering the potential number of reflected packets generated by a		Considering the potential number of reflected packets generated by a
	single test packet sent to a multicast address, parameters in the		single test packet sent to a multicast address, parameters in the
	first STAMP test packet with the Reflected Test Packet Control TLV		first STAMP test packet with the Reflected Test Packet Control TLV
	MUST be selected conservatively. Consider the Number of the		MUST be selected conservatively. Consider the Number of the
	Reflected Packets field value set to one. As a result, a Session-		Reflected Packets field value set to one. As a result, a Session-
	Sender, by counting the packets reflected after originating a first		Sender, by counting the packets reflected after originating a first
	STAMP test packet with the Reflected Test Packet Control TLV, can		STAMP test packet with the Reflected Test Packet Control TLV, can
	evaluate the load caused by using the Reflected Test Packet Control		evaluate the load caused by using the Reflected Test Packet Control
	TLV in which more than a single reflected packet to the same		TLV in which more than a single reflected packet to the same
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 5 ¶
	expected to complete transmitting all reflected packets in response		expected to complete transmitting all reflected packets in response
	to the Reflected Test Packet Control TLV in the previous test packet.		to the Reflected Test Packet Control TLV in the previous test packet.
	In some scenarios the Reflected Test Packet Control TLV might induce		In some scenarios the Reflected Test Packet Control TLV might induce
	congestion on the transient bottleneck. Section 10 of [RFC9097]		congestion on the transient bottleneck. Section 10 of [RFC9097]
	specifies security requirements for capacity measurements with		specifies security requirements for capacity measurements with
	asymmetric UDP loads. When planning In-Service capacity measurement		asymmetric UDP loads. When planning In-Service capacity measurement
	operators SHOULD follow recommendations formulated in Section 7 of		operators SHOULD follow recommendations formulated in Section 7 of
	[RFC7497]. Section 3.1.5 of [RFC8085] determines that a UDP		[RFC7497]. Section 3.1.5 of [RFC8085] determines that a UDP
	congestion control SHOULD respond quickly to experienced congestion		congestion control SHOULD respond quickly to experienced congestion
	and account for loss rate and response time when choosing a new rate.		and account for loss rate and response time when choosing a new rate.
	Appendix A of [RFC9097] offers an example pseudo-code for a UDP load		Appendix A of [RFC9097] offers pseudocode for a UDP load rate
	rate adjustment algorithm with congestion control.		adjustment algorithm with congestion control.
	5. Implementation Status		5. Implementation Status
	Note to RFC Editor: This section MUST be removed before publication		Note to RFC Editor: This section MUST be removed before publication
	of the document.		of the document.
	This section records the status of known implementations of the		This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of this		protocol defined by this specification at the time of posting of this
	Internet-Draft, and is based on a proposal described in [RFC7942].		Internet-Draft, and is based on a proposal described in [RFC7942].
	The description of implementations in this section is intended to		The description of implementations in this section is intended to
	skipping to change at page 15, line 41 ¶		skipping to change at page 15, line 41 ¶
	R. Foote, "Simple Two-Way Active Measurement Protocol		R. Foote, "Simple Two-Way Active Measurement Protocol
	(STAMP) Extensions for Segment Routing Networks",		(STAMP) Extensions for Segment Routing Networks",
	RFC 9503, DOI 10.17487/RFC9503, October 2023,		RFC 9503, DOI 10.17487/RFC9503, October 2023,
	<https://www.rfc-editor.org/info/rfc9503>.		<https://www.rfc-editor.org/info/rfc9503>.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-ippm-capacity-protocol]		[I-D.ietf-ippm-capacity-protocol]
	Ciavattone, L. and R. Geib, "Test Protocol for One-way IP		Ciavattone, L. and R. Geib, "Test Protocol for One-way IP
	Capacity Measurement", Work in Progress, Internet-Draft,		Capacity Measurement", Work in Progress, Internet-Draft,
	draft-ietf-ippm-capacity-protocol-15, 30 April 2025,		draft-ietf-ippm-capacity-protocol-18, 2 June 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-		<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
	capacity-protocol-15>.		capacity-protocol-18>.
	[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,		[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
	Aitken, P., and A. Akhter, "A Framework for Large-Scale		Aitken, P., and A. Akhter, "A Framework for Large-Scale
	Measurement of Broadband Performance (LMAP)", RFC 7594,		Measurement of Broadband Performance (LMAP)", RFC 7594,
	DOI 10.17487/RFC7594, September 2015,		DOI 10.17487/RFC7594, September 2015,
	<https://www.rfc-editor.org/info/rfc7594>.		<https://www.rfc-editor.org/info/rfc7594>.
	[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", BCP 205,		Code: The Implementation Status Section", BCP 205,
	RFC 7942, DOI 10.17487/RFC7942, July 2016,		RFC 7942, DOI 10.17487/RFC7942, July 2016,
End of changes. 9 change blocks.
	14 lines changed or deleted		14 lines changed or added
This html diff was produced by rfcdiff 1.49. The latest version is available from https://github.com/ietf-tools/rfcdiff