OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Max
All section numbers below refer to RFC 8912

7.1. Summary

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

7.1.1. ID (Identifier)

   9

7.1.2. Name

   OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Max

7.1.3. URI

   URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Max

7.1.4. Description

   OWDelay:
   This metric assesses the delay of a stream of packets exchanged between two hosts (or measurement points) 
   and reports the maximum of one-way delay for all successfully exchanged packets based on their conditional 
   delay distribution.

7.1.5. Change Controller

   IETF

7.1.6. Version (of Registry Format)

   1.0

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

7.2.1. Reference Definition

   For delay:

   Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance
   Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, 
   <https://www.rfc-editor.org/info/rfc7679>. [RFC7679]

   Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011,
   <https://www.rfc-editor.org/info/rfc6049>. [RFC6049]

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

   Only successful packet transfers with finite delay are included in the sample, as prescribed in 
   Section 4.1.2 of [RFC6049].

7.2.2. Fixed Parameters

   Type-P:

      IPv4 header values:

         DSCP:  Set to 0
         TTL:  Set to 255
         Protocol:  Set to 17 (UDP)

      IPv6 header values:

         DSCP:  Set to 0
         Hop Count:  Set to 255
         Next Header:  Set to 17 (UDP)
         Flow Label:  Set to 0
         Extension Headers:  None

   UDP header values:

   Checksum:  The checksum MUST be calculated and the non-zero checksum included in the header

   UDP Payload:  TWAMP-Test packet formats (Section 4.1.2 of [RFC5357])
		Security features in use influence the number of Padding octets
		250 octets total, including the TWAMP format type, which MUST be reported

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

   See the Packet Stream Generation section for two additional Fixed Parameters.

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

7.3.1. Reference Methods

   The methodology for this metric (equivalent to Type-P-One-way-Delay-Poisson-Stream) is defined as in 
   Section 3.6 of [RFC7679] (for singletons) and Section 4.6 of [RFC7679] (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 OWLoss metric.

   The calculations on the one-way delay 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 one-way delay 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.

   Since a standard measurement protocol is employed [RFC5357], the measurement process will determine the
   sequence numbers or timestamps applied to test packets after the Fixed and Runtime Parameters are passed 
   to that process. The measurement protocol dictates the format of sequence numbers and timestamps conveyed 
   in the TWAMP-Test packet payload.

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

   Section 11.1.3 of [RFC2330] provides three methods to generate Poisson sampling intervals. The reciprocal 
   of lambda is the average packet spacing; thus, the Runtime Parameter is Reciprocal_lambda = 1⁠/lambda, in
   seconds.

   Method 3 SHALL be used. Where given a start time (Runtime Parameter), the subsequent send times are all
   computed prior to measurement by computing the pseudorandom distribution of inter-packet send times
   (truncating the distribution as specified in the Parameter Trunc), and the Src sends each packet at the 
   computed times.

   Note that Trunc is the upper limit on inter-packet times in the Poisson distribution. A random value greater
   than Trunc is set equal to Trunc instead.

   Reciprocal_lambda:  Average packet interval for Poisson streams, expressed in units of seconds, as a positive
   value of type decimal64 with fraction digits = 4 (see Section 9.3 of [RFC6020]) with a resolution of 0.0001
   seconds (0.1 ms), and with lossless conversion to/from the 32-bit NTP timestamp as per Section 6 of 
   [RFC5905]. Reciprocal_lambda = 1 second.

   Trunc:  Upper limit on Poisson distribution, expressed in units of seconds, as a positive value of type
   decimal64 with fraction digits = 4 (see Section 9.3 of [RFC6020]) with a resolution of 0.0001 seconds 
   (0.1 ms), and with lossless conversion to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905] 
   (values above this limit will be clipped and set to the limit value). Trunc = 30.0000 seconds.

7.3.3. Traffic Filtering (Observation) Details

   N/A

7.3.4. Sampling Distribution

   N/A

7.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]).

   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.

   Tf:  A time, 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]. When T0 is "all-zeros", an ending time and date is ignored and Tf is 
   interpreted as the duration of the measurement interval.

7.3.6. Roles

   Src:  Launches each packet and waits for return transmissions from the Dst.  An example is the TWAMP 
   Session-Sender.

   Dst:  Waits for each packet from the Src and sends a return packet to the Src.  An example is the TWAMP 
   Session-Reflector.

7.4. Output

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

7.4.1. Type

   Types are discussed in the subsections below.

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

   The maximum SHALL be calculated using the conditional distribution of all packets with a finite value 
   of one-way 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].

7.4.3. Metric Units

   The maximum of one-way delay is expressed in seconds.

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

   For one-way delay measurements, the error calibration must include an assessment of the internal clock
   synchronization with its external reference (this internal clock is supplying timestamps for measurement). 
   In practice, the time offsets [RFC5905] of clocks at both the Source and Destination are needed to 
   estimate the systematic error due to imperfect clock synchronization (the time offsets [RFC5905] are 
   smoothed; thus, the random variation is not usually represented in the results).

   time_offset: The time value of the result is expressed in units of seconds, as a signed 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].

   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. In any measurement, the measurement function SHOULD report its current estimate 
   of the time offset [RFC5905] as an indicator of the degree of synchronization.

   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.

7.5. Administrative Items

7.5.1. Status

   Current

7.5.2. Requester

   RFC 8912

7.5.3. Revision

   1.0

7.5.4. Revision Date

   2021-11-17

7.6. Comments and Remarks

   None