RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Max
All section numbers below refer to RFC 8912 

9.1. Summary

   This category includes multiple indexes to the Registry Entries: the element ID and Metric Name.

9.1.1. ID (Identifier)

   20

9.1.2. Name

   RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Max

9.1.3. URI
 
   URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Max

9.1.4. Description

   RTDelay:
   This metric assesses the delay of a stream of ICMP packets exchanged between two hosts (which are the two measurement 
   points). The output is the round-trip delay for all successfully exchanged packets expressed as the maximum of their 
   conditional delay distribution.

9.1.5. Change Controller

   IETF

9.1.6. Version (of Registry Format)

   1.0

9.2. Metric Definition

   This category includes columns to prompt the entry of all necessary details related to the metric definition, including 
   the RFC reference and values of input factors, called "Fixed Parameters".

9.2.1. Reference Definition

   Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 
   September 1999, <https://www.rfc-editor.org/info/rfc2681>. [RFC2681]

   Section 2.4 of [RFC2681] provides the reference definition of the singleton (single value) round-trip delay metric. 
   Section 3.4 of [RFC2681] provides the reference definition expanded to cover a multi-singleton sample. Note that terms 
   such as "singleton" and "sample" are defined in Section 11 of [RFC2330].

   Note that although the definition of round-trip delay between the Source (Src) and the Destination (Dst) as provided in 
   Section 2.4 of [RFC2681] is directionally ambiguous in the text, this metric tightens the definition further to recognize 
   that 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 packet from the Dst (when neither is lost).

   Finally, note that the variable "dT" is used in [RFC2681] to refer to the value of round-trip delay in metric definitions 
   and methods. The variable "dT" has been reused in other IPPM literature to refer to different quantities and cannot be 
   used as a global variable name.

   Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI 10.17487/RFC6673, August 2012, 
   <https://www.rfc-editor.org/info/rfc6673>. [RFC6673]

   Both Delay and Loss metrics employ a maximum waiting time for 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 [RFC6673].

9.2.2. Fixed Parameters

   Type-P as defined in Section 13 of [RFC2330]:

     IPv4 header values:

         DSCP:  Set to 0
         TTL:  Set to 255
         Protocol:  Set to 01 (ICMP)

      IPv6 header values:

         DSCP:  Set to 0
         Hop Count:  Set to 255
         Next Header:  Set to 128 decimal (ICMP)
         Flow Label:  Set to 0
         Extension Headers:  None

      ICMP header values:

         Type:  8 (Echo Request)
         Code:  0
         Checksum:  The checksum MUST be calculated and the non-zero checksum 
         included in the header
         (Identifier and sequence number set at runtime)

         ICMP Payload:
            Total of 32 bytes of random information, constant per test

   Other measurement Parameters:

   Tmax:  A loss threshold waiting time with value 3.0, expressed in units of seconds, as a positive value of type 
   decimal64 with fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a resolution of 0.0001 seconds (0.1 ms), 
   with lossless conversion to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905].

9.3. Method of Measurement

   This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed 
   to ensure an unambiguous method for implementations.

9.3.1. Reference Methods

   The methodology for this metric (equivalent to Type-P-Round-trip-Delay-Poisson-Stream) is defined as in Section 2.6 of 
   [RFC2681] (for singletons) and Section 3.6 of [RFC2681] (for samples) using the Type-P and Tmax defined in the Fixed 
   Parameters column.

   The reference method distinguishes between long-delayed packets and lost packets by implementing a maximum waiting time 
   for packet arrival. Tmax is the waiting time used as the threshold to declare a packet lost. Lost packets SHALL be 
   designated as having undefined delay and counted for the RTLoss metric.

   The calculations on the delay (RTD) SHALL be performed on the conditional distribution, conditioned on successful packet 
   arrival within Tmax. Also, when all packet delays are stored, the process that calculates the RTD value MUST enforce the 
   Tmax threshold on stored values before calculations. See Section 4.1 of [RFC3393] for details on the conditional 
   distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

   The reference method requires some way to distinguish between different packets in a stream to establish correspondence 
   between sending times and receiving times for each successfully arriving packet. Sequence numbers or other send-order 
   identification MUST be retained at the Src or included with each packet to disambiguate packet reordering if it occurs.

   The measurement process will determine the sequence numbers applied to test packets after the Fixed and Runtime Parameters 
   are passed to that process. The ICMP measurement process and protocol will dictate the format of sequence numbers and other
   Identifiers.

   Refer to Section 4.4 of [RFC6673] for an expanded discussion of the instruction to "send a Type-P packet back to the Src 
   as quickly as possible" in Section 2.6 of [RFC2681]. Section 8 of [RFC6673] presents additional requirements that MUST 
   be included in the Method of Measurement for this metric.

9.3.2. Packet Stream Generation

   This section provides details regarding packet traffic, which is used as the basis for measurement. In IPPM Metrics, this 
   is called the "stream"; this stream can easily be described by providing the list of stream Parameters.

   The ICMP metrics use a sending discipline called "SendOnRcv" or Send On Receive. This is a modification of Section 3 of 
   [RFC3432], which prescribes the method for generating Periodic streams using associated Parameters as defined below for 
   this description:

   incT:  The nominal duration of the inter-packet interval, first bit to first bit.

   dT:  The duration of the interval for allowed sample start times.

   The incT stream Parameter will be specified as a Runtime Parameter, and dT is not used in SendOnRcv.

   A SendOnRcv sender behaves exactly like a Periodic stream generator while all reply packets arrive with RTD < incT, and 
   the inter-packet interval will be constant.

   If a reply packet arrives with RTD >= incT, then the inter-packet interval for the next sending time is nominally RTD.

   If a reply packet fails to arrive within Tmax, then the inter-packet interval for the next sending time is nominally Tmax.

   If an immediate Send On Reply arrival is desired, then set incT = 0.

9.3.3. Traffic Filtering (Observation) Details

   N/A

9.3.4. Sampling Distribution

   N/A

9.3.5. Runtime Parameters and Data Format

   Runtime Parameters are input factors that must be determined, configured into the measurement system, and reported with 
   the results for the context to be complete.

   Src:  The IP address of the host in the Src Role (format ipv4‑address-no-zone value for IPv4 or 
   ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]).

   Dst:  The IP address of the host in the Dst Role (format ipv4‑address-no-zone value for IPv4 or 
   ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]).

   incT:  The nominal duration of the inter-packet interval, first bit to first bit, expressed in units of seconds, 
   as a positive value of type decimal64 with fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a resolution 
   of 0.0001 seconds (0.1 ms).

   T0:  A time, the start of a measurement interval (format "date‑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 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 measurement interval. 
   The start time is controlled through other means.

   Count:  The total count of ICMP Echo Requests to send, formatted as a uint16, as per Section 9.2 of [RFC6020].

   See the Packet Stream Generation section for additional Runtime Parameters.

9.3.6. Roles

   Src:  Launches each packet and waits for return transmissions from the Dst.

   Dst:  Waits for each packet from the Src and sends a return packet to the Src (ICMP Echo Reply, Type 0).

9.4. Output

   This category specifies all details of the output of measurements using the metric.

9.4.1. Type

   Latency Types are discussed in the subsections below.

9.4.2. Reference Definition

   For all output types:

   T0:  The start of a measurement interval (format "date‑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 Section 6.1 of [RFC2330].

   Tf:  The end of a measurement interval (format "date‑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 Section 6.1 of [RFC2330].

   TotalCount:
   The count of packets actually sent by the Src to the Dst during the measurement interval.

   The maximum SHALL be calculated using the conditional distribution of all packets with a finite value of round-trip delay
   (undefined delays are excluded) -- a single value, as follows:

   See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see 
   Section 5 of [RFC6703] for background on this analysis choice.

   See Section 4.3.2 of [RFC6049] for a closely related method for calculating this statistic; see also Section 4.3.3 of 
   [RFC6049]. The formula is as follows:

   Max = (FiniteDelay[j])

	such that for some index, j, where 1 <= j <= N FiniteDelay[j] >= FiniteDelay[n] for all n

   Max:
   The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction 
   digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of 0.000000001 seconds (1.0 ns), and with lossless 
   conversion to/from the 64-bit NTP timestamp as per Section 6 of [RFC5905].

9.4.3. Metric Units

   The maximum of round-trip delay is expressed in seconds.

9.4.4. Calibration

   Section 3.7.3 of [RFC7679] provides a means to quantify the systematic and random errors of a time measurement. Calibration 
   in-situ could be enabled with an internal loopback at the Source host that includes as much of the measurement system as 
   possible, performs address manipulation as needed, and provides some form of isolation (e.g., deterministic delay) to avoid
   send-receive interface contention. Some portion of the random and systematic error can be characterized in this way.

   When a measurement controller requests a calibration measurement, the loopback is applied and the result is output in the 
   same format as a normal measurement, with an additional indication that it is a calibration result.

   Both internal loopback calibration and clock synchronization can be used to estimate the available accuracy of the Output 
   Metric Units. For example, repeated loopback delay measurements will reveal the portion of the output result resolution that 
   is the result of system noise and is thus inaccurate.

9.5. Administrative Items

9.5.1. Status

   Current

9.5.2. Requester

   RFC 8912

9.5.3. Revision

   1.0

9.5.4. Revision Date

   2021-11-17

9.6. Comments and Remarks

   None