rfc8912_July24_acm2.txt		rfc8912.txt
	Internet Engineering Task Force (IETF) A. Morton		Internet Engineering Task Force (IETF) A. Morton
	Request for Comments: 8912 AT&T Labs		Request for Comments: 8912 AT&T Labs
	Category: Standards Track M. Bagnulo		Category: Standards Track M. Bagnulo
	ISSN: 2070-1721 UC3M		ISSN: 2070-1721 UC3M
	P. Eardley		P. Eardley
	BT		BT
	K. D'Souza		K. D'Souza
	AT&T Labs		AT&T Labs
	July 2021		August 2021
	Initial Performance Metrics Registry Entries		Initial Performance Metrics Registry Entries
	Abstract		Abstract
	This memo defines the set of initial entries for the IANA Registry of		This memo defines the set of initial entries for the IANA Registry of
	Performance Metrics. The set includes UDP Round-Trip Latency and		Performance Metrics. The set includes UDP Round-Trip Latency and
	Loss, Packet Delay Variation, DNS Response Latency and Loss, UDP		Loss, Packet Delay Variation, DNS Response Latency and Loss, UDP
	Poisson One-Way Delay and Loss, UDP Periodic One-Way Delay and Loss,		Poisson One-Way Delay and Loss, UDP Periodic One-Way Delay and Loss,
	ICMP Round-Trip Latency and Loss, and TCP Round-Trip Delay and Loss.		ICMP Round-Trip Latency and Loss, and TCP Round-Trip Delay and Loss.
	skipping to change at line 666 ¶		skipping to change at line 666 ¶
	TotalPkts: The count of packets sent by the Src to the Dst during		TotalPkts: The count of packets sent by the Src to the Dst during
	the measurement interval.		the measurement interval.
	For RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile:		For RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile:
	95Percentile: The time value of the result is expressed in units of		95Percentile: The time value of the result is expressed in units of
	seconds, as a positive value of type decimal64 with fraction		seconds, as a positive value of type decimal64 with fraction
	digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of		digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of
	0.000000001 seconds (1.0 ns).		0.000000001 seconds (1.0 ns).
	Percent_LossRatio: The numeric value of the result is expressed in		For RTLoss_Active_IP-UDP-Periodic_RFC8912sec4_Percent_LossRatio:
			Percent_LossRatio The numeric value of the result is expressed in
	units of lost packets to total packets times 100%, as a positive		units of lost packets to total packets times 100%, as a positive
	value of type decimal64 with fraction digits = 9 (see Section 9.3		value of type decimal64 with fraction digits = 9 (see Section 9.3
	of [RFC6020]) with a resolution of 0.0000000001.		of [RFC6020]) with a resolution of 0.0000000001.
	4.4.3. Metric Units		4.4.3. Metric Units
	The 95th percentile of round-trip delay is expressed in seconds.		The 95th percentile of round-trip delay is expressed in seconds.
	The round-trip loss ratio is expressed as a percentage of lost		The round-trip loss ratio is expressed as a percentage of lost
	packets to total packets sent.		packets to total packets sent.
	skipping to change at line 1149 ¶		skipping to change at line 1151 ¶
	host in the Src Role will send the first packet to the host in the		host in the Src Role will send the first packet to the host in the
	Dst Role and will ultimately receive the corresponding return		Dst Role and will ultimately receive the corresponding return
	packet from the Dst (when neither is lost).		packet from the Dst (when neither is lost).
	For Loss:		For Loss:
	Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI		Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI
	10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/		10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/
	rfc6673>. [RFC6673]		rfc6673>. [RFC6673]
	For DNS Response Loss, the entities in [RFC1035] must be mapped		For DNS Response Loss, the entities in [RFC1035] must be mapped to
	to [RFC6673]. The Local Host with its User Program and Resolver		[RFC6673]. The Local Host with its User Program and Resolver take
	take the Role of "Src", and the Foreign Name Server takes the Role		the Role of "Src", and the Foreign Name Server takes the Role of
	of "Dst".		"Dst".
	Both response time and Loss metrics employ a maximum waiting time		Both response time and Loss metrics employ a maximum waiting time
	for received responses, so the count of lost packets to total		for received responses, so the count of lost packets to total
	packets sent is the basis for the loss determination as per		packets sent is the basis for the loss determination as per
	Section 4.3 of [RFC6673].		Section 4.3 of [RFC6673].
	6.2.2. Fixed Parameters		6.2.2. Fixed Parameters
	Type-P as defined in Section 13 of [RFC2330]:		Type-P as defined in Section 13 of [RFC2330]:
	IPv4 header values:		IPv4 header values:
	skipping to change at line 1414 ¶		skipping to change at line 1416 ¶
	packet is not received at the Src within a waiting time of		packet is not received at the Src within a waiting time of
	Tmax seconds.		Tmax seconds.
	RCODE: The value of the RCODE field in the DNS Response header,		RCODE: The value of the RCODE field in the DNS Response header,
	expressed as a uint64 as specified in Section 9.2 of [RFC6020].		expressed as a uint64 as specified in Section 9.2 of [RFC6020].
	Non-zero values convey errors in the response, and such replies		Non-zero values convey errors in the response, and such replies
	must be analyzed separately from successful requests.		must be analyzed separately from successful requests.
	Logical: The numeric value of the result is expressed as a Logical		Logical: The numeric value of the result is expressed as a Logical
	value, where 1 = Lost and 0 = Received, as a positive value of		value, where 1 = Lost and 0 = Received, as a positive value of
	type uint8 (represents integer values between 0 and 255, inclusively		type uint8 (represents integer values between 0 and 255,
	(see Section 9.2 of [RFC6020]). Note that for queries with outcome		inclusively (see Section 9.2 of [RFC6020]). Note that for queries
	1 = Lost, dT and RCODE will be set to the maximum for decimal64		with outcome 1 = Lost, dT and RCODE will be set to the maximum for
	and uint64, respectively.		decimal64 and uint64, respectively.
	6.4.3. Metric Units		6.4.3. Metric Units
	RTDNS: Round-trip delay, dT, is expressed in seconds.		RTDNS: Round-trip delay, dT, is expressed in seconds.
	RLDNS: The Logical value, where 1 = Lost and 0 = Received.		RLDNS: The Logical value, where 1 = Lost and 0 = Received.
	6.4.4. Calibration		6.4.4. Calibration
	Section 3.7.3 of [RFC7679] provides a means to quantify the		Section 3.7.3 of [RFC7679] provides a means to quantify the
	skipping to change at line 1536 ¶		skipping to change at line 1538 ¶
	URL: https://www.iana.org/performance-metrics/OWDelay_Active_IP-UDP-		URL: https://www.iana.org/performance-metrics/OWDelay_Active_IP-UDP-
	Poisson-Payload250B_RFC8912sec7_Seconds_StdDev		Poisson-Payload250B_RFC8912sec7_Seconds_StdDev
	URL: https://www.iana.org/performance-metrics/OWLoss_Active_IP-UDP-		URL: https://www.iana.org/performance-metrics/OWLoss_Active_IP-UDP-
	Poisson-Payload250B_RFC8912sec7_Percent_LossRatio		Poisson-Payload250B_RFC8912sec7_Percent_LossRatio
	7.1.4. Description		7.1.4. Description
	OWDelay: This metric assesses the delay of a stream of packets		OWDelay: This metric assesses the delay of a stream of packets
	exchanged between two hosts (or measurement points) and reports		exchanged between two hosts (or measurement points) and reports
	the <statistic> one-way delay for all successfully exchanged		the <statistic> of one-way delay for all successfully exchanged
	packets based on their conditional delay distribution.		packets based on their conditional delay distribution.
	where <statistic> is one of:		where <statistic> is one of:
	* 95Percentile		* 95Percentile
	* Mean		* Mean
	* Min		* Min
	* Max		* Max
	* StdDev		* StdDev
	OWLoss: This metric assesses the loss ratio of a stream of packets		OWLoss: This metric assesses the loss ratio of a stream of packets
	exchanged between two hosts (which are the two measurement		exchanged between two hosts (which are the two measurement
	points). The output is the one-way loss ratio for all		points). The output is the one-way loss ratio for all transmitted
	transmitted packets expressed as a percentage.		packets expressed as a percentage.
	7.1.5. Change Controller		7.1.5. Change Controller
	IETF		IETF
	7.1.6. Version (of Registry Format)		7.1.6. Version (of Registry Format)
	1.0		1.0
	7.2. Metric Definition		7.2. Metric Definition
	skipping to change at line 1640 ¶		skipping to change at line 1642 ¶
	250 octets total, including the TWAMP format type, which		250 octets total, including the TWAMP format type, which
	MUST be reported		MUST be reported
	Other measurement Parameters:		Other measurement Parameters:
	Tmax: A loss threshold waiting time with value 3.0, expressed in		Tmax: A loss threshold waiting time with value 3.0, expressed in
	units of seconds, as a positive value of type decimal64 with		units of seconds, as a positive value of type decimal64 with
	fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a		fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a
	resolution of 0.0001 seconds (0.1 ms), with lossless conversion		resolution of 0.0001 seconds (0.1 ms), with lossless conversion
	to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905].		to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905].
	See the Packet Stream Generation section for two		See the Packet Stream Generation section for two additional Fixed
	additional Fixed Parameters.		Parameters.
	7.3. Method of Measurement		7.3. Method of Measurement
	This category includes columns for references to relevant sections of		This category includes columns for references to relevant sections of
	the RFC(s) and any supplemental information needed to ensure an		the RFC(s) and any supplemental information needed to ensure an
	unambiguous method for implementations.		unambiguous method for implementations.
	7.3.1. Reference Methods		7.3.1. Reference Methods
	The methodology for this metric (equivalent to Type-P-One-way-Delay-		The methodology for this metric (equivalent to Type-P-One-way-Delay-
	skipping to change at line 1930 ¶		skipping to change at line 1932 ¶
	7.4.2.6. Percent_LossRatio		7.4.2.6. Percent_LossRatio
	Percent_LossRatio: The numeric value of the result is expressed in		Percent_LossRatio: The numeric value of the result is expressed in
	units of lost packets to total packets times 100%, as a positive		units of lost packets to total packets times 100%, as a positive
	value of type decimal64 with fraction digits = 9 (see Section 9.3		value of type decimal64 with fraction digits = 9 (see Section 9.3
	of [RFC6020]) with a resolution of 0.0000000001.		of [RFC6020]) with a resolution of 0.0000000001.
	7.4.3. Metric Units		7.4.3. Metric Units
	The <statistic> of one-way delay is expressed in seconds,		The <statistic> of one-way delay is expressed in seconds.
	where <statistic> is one of:
	* 95Percentile
	* Mean
	* Min
	* Max
	* StdDev
	The one-way loss ratio is expressed as a percentage of lost packets		The one-way loss ratio is expressed as a percentage of lost packets
	to total packets sent.		to total packets sent.
	7.4.4. Calibration		7.4.4. Calibration
	Section 3.7.3 of [RFC7679] provides a means to quantify the		Section 3.7.3 of [RFC7679] provides a means to quantify the
	systematic and random errors of a time measurement. Calibration in-		systematic and random errors of a time measurement. Calibration in-
	situ could be enabled with an internal loopback that includes as much		situ could be enabled with an internal loopback that includes as much
	of the measurement system as possible, performs address manipulation		of the measurement system as possible, performs address manipulation
	skipping to change at line 2093 ¶		skipping to change at line 2084 ¶
	* Mean		* Mean
	* Min		* Min
	* Max		* Max
	* StdDev		* StdDev
	OWLoss: This metric assesses the loss ratio of a stream of packets		OWLoss: This metric assesses the loss ratio of a stream of packets
	exchanged between two hosts (which are the two measurement		exchanged between two hosts (which are the two measurement
	points). The output is the one-way loss ratio for all		points). The output is the one-way loss ratio for all transmitted
	transmitted packets expressed as a percentage.		packets expressed as a percentage.
	8.1.5. Change Controller		8.1.5. Change Controller
	IETF		IETF
	8.1.6. Version (of Registry Format)		8.1.6. Version (of Registry Format)
	1.0		1.0
	8.2. Metric Definition		8.2. Metric Definition
	skipping to change at line 2180 ¶		skipping to change at line 2171 ¶
	142 octets total, including the TWAMP format (and format		142 octets total, including the TWAMP format (and format
	type MUST be reported, if used)		type MUST be reported, if used)
	Other measurement Parameters:		Other measurement Parameters:
	Tmax: A loss threshold waiting time with value 3.0, expressed in		Tmax: A loss threshold waiting time with value 3.0, expressed in
	units of seconds, as a positive value of type decimal64 with		units of seconds, as a positive value of type decimal64 with
	fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a		fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a
	resolution of 0.0001 seconds (0.1 ms), with lossless conversion		resolution of 0.0001 seconds (0.1 ms), with lossless conversion
	to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905].		to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905].
	See the Packet Stream Generation section for three		See the Packet Stream Generation section for three additional Fixed
	additional Fixed Parameters.		Parameters.
	8.3. Method of Measurement		8.3. Method of Measurement
	This category includes columns for references to relevant sections of		This category includes columns for references to relevant sections of
	the RFC(s) and any supplemental information needed to ensure an		the RFC(s) and any supplemental information needed to ensure an
	unambiguous method for implementations.		unambiguous method for implementations.
	8.3.1. Reference Methods		8.3.1. Reference Methods
	The methodology for this metric (equivalent to Type-P-One-way-Delay-		The methodology for this metric (equivalent to Type-P-One-way-Delay-
	skipping to change at line 2311 ¶		skipping to change at line 2302 ¶
	Dst: Waits for each packet from the Src and sends a return packet to		Dst: Waits for each packet from the Src and sends a return packet to
	the Src. An example is the TWAMP Session-Reflector.		the Src. An example is the TWAMP Session-Reflector.
	8.4. Output		8.4. Output
	This category specifies all details of the output of measurements		This category specifies all details of the output of measurements
	using the metric.		using the metric.
	8.4.1. Type		8.4.1. Type
	Latency and Loss Types are discussed in the subsections below.		The Loss Types are discussed in the subsections below.
	8.4.2. Reference Definition		8.4.2. Reference Definition
	For all output types:		For all output types:
	T0: The start of a measurement interval (format "date-time" as		T0: The start of a measurement interval (format "date-time" as
	specified in Section 5.6 of [RFC3339]; see also "date-and-time" in		specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
	Section 3 of [RFC6991]). The UTC Time Zone is required by		Section 3 of [RFC6991]). The UTC Time Zone is required by
	Section 6.1 of [RFC2330].		Section 6.1 of [RFC2330].
	skipping to change at line 2623 ¶		skipping to change at line 2614 ¶
	1.0		1.0
	9.2. Metric Definition		9.2. Metric Definition
	This category includes columns to prompt the entry of all necessary		This category includes columns to prompt the entry of all necessary
	details related to the metric definition, including the RFC reference		details related to the metric definition, including the RFC reference
	and values of input factors, called "Fixed Parameters".		and values of input factors, called "Fixed Parameters".
	9.2.1. Reference Definition		9.2.1. Reference Definition
	For Delay:		For delay:
	Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay		Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
	Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999,		Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999,
	<https://www.rfc-editor.org/info/rfc2681>. [RFC2681]		<https://www.rfc-editor.org/info/rfc2681>. [RFC2681]
	Section 2.4 of [RFC2681] provides the reference definition of the		Section 2.4 of [RFC2681] provides the reference definition of the
	singleton (single value) round-trip delay metric. Section 3.4 of		singleton (single value) round-trip delay metric. Section 3.4 of
	[RFC2681] provides the reference definition expanded to cover a		[RFC2681] provides the reference definition expanded to cover a
	multi-singleton sample. Note that terms such as "singleton" and		multi-singleton sample. Note that terms such as "singleton" and
	"sample" are defined in Section 11 of [RFC2330].		"sample" are defined in Section 11 of [RFC2330].
	Note that although the definition of round-trip delay between the		Note that although the definition of round-trip delay between the
	Source (Src) and the Destination (Dst) as provided in Section 2.4 of		Source (Src) and the Destination (Dst) as provided in Section 2.4
	[RFC2681] is directionally ambiguous in the text, this metric		of [RFC2681] is directionally ambiguous in the text, this metric
	tightens the definition further to recognize that the host in the Src		tightens the definition further to recognize that the host in the
	Role will send the first packet to the host in the Dst Role and will		Src Role will send the first packet to the host in the Dst Role
	ultimately receive the corresponding return packet from the Dst (when		and will ultimately receive the corresponding return packet from
	neither is lost).		the Dst (when neither is lost).
	Finally, note that the variable "dT" is used in [RFC2681] to refer to		Finally, note that the variable "dT" is used in [RFC2681] to refer
	the value of round-trip delay in metric definitions and methods. The		to the value of round-trip delay in metric definitions and
	variable "dT" has been reused in other IPPM literature to refer to		methods. The variable "dT" has been reused in other IPPM
	different quantities and cannot be used as a global variable name.		literature to refer to different quantities and cannot be used as
			a global variable name.
	For Loss:		For loss:
	Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI 10.17487/		Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI
	RFC6673, August 2012, <https://www.rfc-editor.org/info/rfc6673>.		10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/
	[RFC6673]		rfc6673>. [RFC6673]
	Both Delay and Loss metrics employ a maximum waiting time for		Both Delay and Loss metrics employ a maximum waiting time for
	received packets, so the count of lost packets to total packets sent		received packets, so the count of lost packets to total packets sent
	is the basis for the loss ratio calculation as per Section 6.1 of		is the basis for the loss ratio calculation as per Section 6.1 of
	[RFC6673].		[RFC6673].
	9.2.2. Fixed Parameters		9.2.2. Fixed Parameters
	Type-P as defined in Section 13 of [RFC2330]:		Type-P as defined in Section 13 of [RFC2330]:
	IPv4 header values:		IPv4 header values:
	skipping to change at line 2807 ¶		skipping to change at line 2799 ¶
	as specified in Section 5.6 of [RFC3339]; see also "date-and-time"		as specified in Section 5.6 of [RFC3339]; see also "date-and-time"
	in Section 3 of [RFC6991]). The UTC Time Zone is required by		in Section 3 of [RFC6991]). The UTC Time Zone is required by
	Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is		Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is
	unspecified and Tf is to be interpreted as the duration of the		unspecified and Tf is to be interpreted as the duration of the
	measurement interval. The start time is controlled through other		measurement interval. The start time is controlled through other
	means.		means.
	Count: The total count of ICMP Echo Requests to send, formatted as a		Count: The total count of ICMP Echo Requests to send, formatted as a
	uint16, as per Section 9.2 of [RFC6020].		uint16, as per Section 9.2 of [RFC6020].
	See the Packet Stream Generation section for additional		See the Packet Stream Generation section for additional Runtime
	Runtime Parameters.		Parameters.
	9.3.6. Roles		9.3.6. Roles
	Src: Launches each packet and waits for return transmissions from		Src: Launches each packet and waits for return transmissions from
	the Dst.		the Dst.
	Dst: Waits for each packet from the Src and sends a return packet to		Dst: Waits for each packet from the Src and sends a return packet to
	the Src (ICMP Echo Reply, Type 0).		the Src (ICMP Echo Reply, Type 0).
	9.4. Output		9.4. Output
	This category specifies all details of the output of measurements		This category specifies all details of the output of measurements
	using the metric.		using the metric.
	9.4.1. Type		9.4.1. Type
	Latency and Loss Types are discussed in the subsections below.		For LossRatio, the count of lost packets to total packets sent is the
			basis for the loss ratio calculation as per Section 6.1 of [RFC6673].
	9.4.2. Reference Definition		9.4.2. Reference Definition
	For all output types:		For all output types:
	T0: The start of a measurement interval (format "date-time" as		T0: The start of a measurement interval (format "date-time" as
	specified in Section 5.6 of [RFC3339]; see also "date-and-time" in		specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
	Section 3 of [RFC6991]). The UTC Time Zone is required by		Section 3 of [RFC6991]). The UTC Time Zone is required by
	Section 6.1 of [RFC2330].		Section 6.1 of [RFC2330].
	Tf: The end of a measurement interval (format "date-time" as		Tf: The end of a measurement interval (format "date-time" as
	specified in Section 5.6 of [RFC3339]; see also "date-and-time" in		specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
	Section 3 of [RFC6991]). The UTC Time Zone is required by		Section 3 of [RFC6991]). The UTC Time Zone is required by
	Section 6.1 of [RFC2330].		Section 6.1 of [RFC2330].
	TotalCount: The count of packets actually sent by the Src to the Dst		TotalCount: The count of packets actually sent by the Src to the Dst
	during the measurement interval.		during the measurement interval.
			For LossRatio, the count of lost packets to total packets sent is the
			basis for the loss ratio calculation as per Section 4.1 of [RFC7680].
	For each <statistic> or Percent_LossRatio, one of the following		For each <statistic> or Percent_LossRatio, one of the following
	subsections applies.		subsections applies.
	9.4.2.1. Mean		9.4.2.1. Mean
	The mean SHALL be calculated using the conditional distribution of		The mean SHALL be calculated using the conditional distribution of
	all packets with a finite value of round-trip delay (undefined delays		all packets with a finite value of round-trip delay (undefined delays
	are excluded) -- a single value, as follows:		are excluded) -- a single value, as follows:
	See Section 4.1 of [RFC3393] for details on the conditional		See Section 4.1 of [RFC3393] for details on the conditional
	skipping to change at line 2912 ¶		skipping to change at line 2908 ¶
	FiniteDelay[j] >= FiniteDelay[n] for all n		FiniteDelay[j] >= FiniteDelay[n] for all n
	Max: The time value of the result is expressed in units of seconds,		Max: The time value of the result is expressed in units of seconds,
	as a positive value of type decimal64 with fraction digits = 9		as a positive value of type decimal64 with fraction digits = 9
	(see Section 9.3 of [RFC6020]) with a resolution of		(see Section 9.3 of [RFC6020]) with a resolution of
	0.000000001 seconds (1.0 ns), and with lossless conversion to/from		0.000000001 seconds (1.0 ns), and with lossless conversion to/from
	the 64-bit NTP timestamp as per Section 6 of [RFC5905].		the 64-bit NTP timestamp as per Section 6 of [RFC5905].
	9.4.2.4. Percent_LossRatio		9.4.2.4. Percent_LossRatio
	For LossRatio, the count of lost packets to total packets sent is the
	basis for the loss ratio calculation as per Section 4.1 of [RFC7680].
	Percent_LossRatio: The numeric value of the result is expressed in		Percent_LossRatio: The numeric value of the result is expressed in
	units of lost packets to total packets times 100%, as a positive		units of lost packets to total packets times 100%, as a positive
	value of type decimal64 with fraction digits = 9 (see Section 9.3		value of type decimal64 with fraction digits = 9 (see Section 9.3
	of [RFC6020]) with a resolution of 0.0000000001.		of [RFC6020]) with a resolution of 0.0000000001.
	9.4.3. Metric Units		9.4.3. Metric Units
	The <statistic> of round-trip delay is expressed in seconds, where		The <statistic> of round-trip delay is expressed in seconds, where
	<statistic> is one of:		<statistic> is one of:
	skipping to change at line 3049 ¶		skipping to change at line 3042 ¶
	packets expressed as the <statistic> of their conditional delay		packets expressed as the <statistic> of their conditional delay
	distribution, where <statistic> is one of:		distribution, where <statistic> is one of:
	* Mean		* Mean
	* Min		* Min
	* Max		* Max
	RTDelay Singleton: This metric assesses the round-trip delay of TCP		RTDelay Singleton: This metric assesses the round-trip delay of TCP
	packets initiating a single connection (or 3-way handshake), exchanged between two		packets initiating a single connection (or 3-way handshake),
	hosts. We consider the measurement of round-trip delay based on a		exchanged between two hosts. We consider the measurement of
	single Observation Point (OP) [RFC7011] somewhere in the network.		round-trip delay based on a single Observation Point (OP)
	The output is the single measurement of Round-trip delay, or		[RFC7011] somewhere in the network. The output is the single
	Singleton.		measurement of Round-trip delay, or Singleton.
	RTLoss: This metric assesses the estimated loss count for TCP		RTLoss: This metric assesses the estimated loss count for TCP
	packets constituting a single connection, exchanged between two		packets constituting a single connection, exchanged between two
	hosts. We consider the measurement of round-trip delay based on a		hosts. We consider the measurement of round-trip delay based on a
	single OP [RFC7011] somewhere in the network. The output is the		single Observation Point (OP) [RFC7011] somewhere in the network.
	estimated loss count for the measurement interval.		The output is the estimated loss count for the measurement
			interval.
	10.1.5. Change Controller		10.1.5. Change Controller
	IETF		IETF
	10.1.6. Version (of Registry Format)		10.1.6. Version (of Registry Format)
	1.0		1.0
	10.2. Metric Definition		10.2. Metric Definition
	skipping to change at line 3227 ¶		skipping to change at line 3221 ¶
	The Traffic Filter at the OP is configured to observe a single TCP		The Traffic Filter at the OP is configured to observe a single TCP
	connection. When the SYN/SYN-ACK/ACK handshake occurs, it offers the		connection. When the SYN/SYN-ACK/ACK handshake occurs, it offers the
	first opportunity to measure both RTD_fwd (on the SYN to SYN-ACK		first opportunity to measure both RTD_fwd (on the SYN to SYN-ACK
	pair) and RTD_rev (on the SYN-ACK to ACK pair). Label this singleton		pair) and RTD_rev (on the SYN-ACK to ACK pair). Label this singleton
	of RTDelay as RTDelay_HS (composed using the Forward and Reverse		of RTDelay as RTDelay_HS (composed using the Forward and Reverse
	measurement pair). RTDelay_HS SHALL be treated separately from other		measurement pair). RTDelay_HS SHALL be treated separately from other
	RTDelays on data-bearing packets and their ACKs. The RTDelay_HS		RTDelays on data-bearing packets and their ACKs. The RTDelay_HS
	value MAY be used as a consistency check on the composed values of		value MAY be used as a consistency check on the composed values of
	RTDelay for payload-bearing packets.		RTDelay for payload-bearing packets.
	For payload-bearing packets, the OP measures the time interval		For payload-bearing packets, each observation of an out-of-order or
	between observation of a packet with sequence number "s" and the		duplicate segment infers a loss count, but the composition of round-
	corresponding ACK with the same sequence number. When the payload is		trip loss counts will be conducted over a measurement interval that
	transferred from host A to host B, the observed interval is RTD_fwd.		is synonymous with a single TCP connection.
	Because many data transfers are unidirectional (say, in the Forward		Because many data transfers are unidirectional (say, in the Forward
	direction from host A to host B), it is necessary to use pure ACK		direction from host A to host B), it is necessary to use pure ACK
	packets with Timestamp (TSval) and packets with the Timestamp value		packets with Timestamp (TSval) and packets with the Timestamp value
	echo to perform a RTD_rev measurement. The time interval between		echo to perform a RTD_rev measurement. The time interval between
	observation of the ACK from B to A, and the Corresponding Packet with		observation of the ACK from B to A, and the Corresponding Packet with
	a Timestamp Echo Reply (TSecr) field [RFC7323], is the RTD_rev.		a Timestamp Echo Reply (TSecr) field [RFC7323], is the RTD_rev.
	Delay Measurement Filtering Heuristics:		Delay Measurement Filtering Heuristics:
	skipping to change at line 3649 ¶		skipping to change at line 3643 ¶
	Ed., "A One-Way Loss Metric for IP Performance Metrics		Ed., "A One-Way Loss Metric for IP Performance Metrics
	(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January		(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
	2016, <https://www.rfc-editor.org/info/rfc7680>.		2016, <https://www.rfc-editor.org/info/rfc7680>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8911] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.		[RFC8911] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
	Akhter, "Registry for Performance Metrics", RFC 8911,		Akhter, "Registry for Performance Metrics", RFC 8911,
	DOI 10.17487/RFC8911, July 2021,		DOI 10.17487/RFC8911, August 2021,
	<https://www.rfc-editor.org/info/rfc8911>.		<https://www.rfc-editor.org/info/rfc8911>.
	[Strowes] Strowes, S., "Passively Measuring TCP Round-Trip Times",		[Strowes] Strowes, S., "Passively Measuring TCP Round-Trip Times",
	Communications of the ACM, Vol. 56 No. 10, Pages 57-64,		Communications of the ACM, Vol. 56 No. 10, Pages 57-64,
	DOI 10.1145/2507771.2507781, October 2013,		DOI 10.1145/2507771.2507781, October 2013,
	<https://dl.acm.org/doi/10.1145/2507771.2507781>.		<https://dl.acm.org/doi/10.1145/2507771.2507781>.
	[Trammell-14]		[Trammell-14]
	Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data		Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data
	Integrity Signals for Passive Measurement", In: Dainotti		Integrity Signals for Passive Measurement", In: Dainotti
End of changes. 26 change blocks.
	74 lines changed or deleted		68 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/