diff options
Diffstat (limited to 'doc/rfc/rfc8912.txt')
| -rw-r--r-- | doc/rfc/rfc8912.txt | 3769 |
1 files changed, 3769 insertions, 0 deletions
diff --git a/doc/rfc/rfc8912.txt b/doc/rfc/rfc8912.txt new file mode 100644 index 0000000..22ce148 --- /dev/null +++ b/doc/rfc/rfc8912.txt @@ -0,0 +1,3769 @@ + + + + +Internet Engineering Task Force (IETF) A. Morton +Request for Comments: 8912 AT&T Labs +Category: Standards Track M. Bagnulo +ISSN: 2070-1721 UC3M + P. Eardley + BT + K. D'Souza + AT&T Labs + November 2021 + + + Initial Performance Metrics Registry Entries + +Abstract + + This memo defines the set of initial entries for the IANA Registry of + Performance Metrics. The set includes UDP Round-Trip Latency and + Loss, Packet Delay Variation, DNS Response Latency and Loss, UDP + 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. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8912. + +Copyright Notice + + Copyright (c) 2021 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 + 1.1. Requirements Language + 2. Scope + 3. Registry Categories and Columns + 4. UDP Round-Trip Latency and Loss Registry Entries + 4.1. Summary + 4.1.1. ID (Identifier) + 4.1.2. Name + 4.1.3. URI + 4.1.4. Description + 4.1.5. Change Controller + 4.1.6. Version (of Registry Format) + 4.2. Metric Definition + 4.2.1. Reference Definition + 4.2.2. Fixed Parameters + 4.3. Method of Measurement + 4.3.1. Reference Methods + 4.3.2. Packet Stream Generation + 4.3.3. Traffic Filtering (Observation) Details + 4.3.4. Sampling Distribution + 4.3.5. Runtime Parameters and Data Format + 4.3.6. Roles + 4.4. Output + 4.4.1. Type + 4.4.2. Reference Definition + 4.4.3. Metric Units + 4.4.4. Calibration + 4.5. Administrative Items + 4.5.1. Status + 4.5.2. Requester + 4.5.3. Revision + 4.5.4. Revision Date + 4.6. Comments and Remarks + 5. Packet Delay Variation Registry Entry + 5.1. Summary + 5.1.1. ID (Identifier) + 5.1.2. Name + 5.1.3. URI + 5.1.4. Description + 5.1.5. Change Controller + 5.1.6. Version (of Registry Format) + 5.2. Metric Definition + 5.2.1. Reference Definition + 5.2.2. Fixed Parameters + 5.3. Method of Measurement + 5.3.1. Reference Methods + 5.3.2. Packet Stream Generation + 5.3.3. Traffic Filtering (Observation) Details + 5.3.4. Sampling Distribution + 5.3.5. Runtime Parameters and Data Format + 5.3.6. Roles + 5.4. Output + 5.4.1. Type + 5.4.2. Reference Definition + 5.4.3. Metric Units + 5.4.4. Calibration + 5.5. Administrative Items + 5.5.1. Status + 5.5.2. Requester + 5.5.3. Revision + 5.5.4. Revision Date + 5.6. Comments and Remarks + 6. DNS Response Latency and Loss Registry Entries + 6.1. Summary + 6.1.1. ID (Identifier) + 6.1.2. Name + 6.1.3. URI + 6.1.4. Description + 6.1.5. Change Controller + 6.1.6. Version (of Registry Format) + 6.2. Metric Definition + 6.2.1. Reference Definition + 6.2.2. Fixed Parameters + 6.3. Method of Measurement + 6.3.1. Reference Methods + 6.3.2. Packet Stream Generation + 6.3.3. Traffic Filtering (Observation) Details + 6.3.4. Sampling Distribution + 6.3.5. Runtime Parameters and Data Format + 6.3.6. Roles + 6.4. Output + 6.4.1. Type + 6.4.2. Reference Definition + 6.4.3. Metric Units + 6.4.4. Calibration + 6.5. Administrative Items + 6.5.1. Status + 6.5.2. Requester + 6.5.3. Revision + 6.5.4. Revision Date + 6.6. Comments and Remarks + 7. UDP Poisson One-Way Delay and Loss Registry Entries + 7.1. Summary + 7.1.1. ID (Identifier) + 7.1.2. Name + 7.1.3. URI + 7.1.4. Description + 7.1.5. Change Controller + 7.1.6. Version (of Registry Format) + 7.2. Metric Definition + 7.2.1. Reference Definition + 7.2.2. Fixed Parameters + 7.3. Method of Measurement + 7.3.1. Reference Methods + 7.3.2. Packet Stream Generation + 7.3.3. Traffic Filtering (Observation) Details + 7.3.4. Sampling Distribution + 7.3.5. Runtime Parameters and Data Format + 7.3.6. Roles + 7.4. Output + 7.4.1. Type + 7.4.2. Reference Definition + 7.4.3. Metric Units + 7.4.4. Calibration + 7.5. Administrative Items + 7.5.1. Status + 7.5.2. Requester + 7.5.3. Revision + 7.5.4. Revision Date + 7.6. Comments and Remarks + 8. UDP Periodic One-Way Delay and Loss Registry Entries + 8.1. Summary + 8.1.1. ID (Identifier) + 8.1.2. Name + 8.1.3. URI + 8.1.4. Description + 8.1.5. Change Controller + 8.1.6. Version (of Registry Format) + 8.2. Metric Definition + 8.2.1. Reference Definition + 8.2.2. Fixed Parameters + 8.3. Method of Measurement + 8.3.1. Reference Methods + 8.3.2. Packet Stream Generation + 8.3.3. Traffic Filtering (Observation) Details + 8.3.4. Sampling Distribution + 8.3.5. Runtime Parameters and Data Format + 8.3.6. Roles + 8.4. Output + 8.4.1. Type + 8.4.2. Reference Definition + 8.4.3. Metric Units + 8.4.4. Calibration + 8.5. Administrative Items + 8.5.1. Status + 8.5.2. Requester + 8.5.3. Revision + 8.5.4. Revision Date + 8.6. Comments and Remarks + 9. ICMP Round-Trip Latency and Loss Registry Entries + 9.1. Summary + 9.1.1. ID (Identifier) + 9.1.2. Name + 9.1.3. URI + 9.1.4. Description + 9.1.5. Change Controller + 9.1.6. Version (of Registry Format) + 9.2. Metric Definition + 9.2.1. Reference Definition + 9.2.2. Fixed Parameters + 9.3. Method of Measurement + 9.3.1. Reference Methods + 9.3.2. Packet Stream Generation + 9.3.3. Traffic Filtering (Observation) Details + 9.3.4. Sampling Distribution + 9.3.5. Runtime Parameters and Data Format + 9.3.6. Roles + 9.4. Output + 9.4.1. Type + 9.4.2. Reference Definition + 9.4.3. Metric Units + 9.4.4. Calibration + 9.5. Administrative Items + 9.5.1. Status + 9.5.2. Requester + 9.5.3. Revision + 9.5.4. Revision Date + 9.6. Comments and Remarks + 10. TCP Round-Trip Delay and Loss Registry Entries + 10.1. Summary + 10.1.1. ID (Identifier) + 10.1.2. Name + 10.1.3. URI + 10.1.4. Description + 10.1.5. Change Controller + 10.1.6. Version (of Registry Format) + 10.2. Metric Definition + 10.2.1. Reference Definition + 10.2.2. Fixed Parameters + 10.3. Method of Measurement + 10.3.1. Reference Methods + 10.3.2. Packet Stream Generation + 10.3.3. Traffic Filtering (Observation) Details + 10.3.4. Sampling Distribution + 10.3.5. Runtime Parameters and Data Format + 10.3.6. Roles + 10.4. Output + 10.4.1. Type + 10.4.2. Reference Definition + 10.4.3. Metric Units + 10.4.4. Calibration + 10.5. Administrative Items + 10.5.1. Status + 10.5.2. Requester + 10.5.3. Revision + 10.5.4. Revision Date + 10.6. Comments and Remarks + 11. Security Considerations + 12. IANA Considerations + 13. References + 13.1. Normative References + 13.2. Informative References + Acknowledgments + Authors' Addresses + +1. Introduction + + This memo defines an initial set of entries for the Performance + Metrics Registry. It uses terms and definitions from the IP + Performance Metrics (IPPM) literature, primarily [RFC2330]. + + Although there are several standard templates for organizing + specifications of Performance Metrics (see [RFC7679] for an example + of the traditional IPPM template, based to a large extent on the + Benchmarking Methodology Working Group's traditional template in + [RFC1242], and see [RFC6390] for a similar template), none of these + templates were intended to become the basis for the columns of an + IETF-wide Registry of metrics. While examining aspects of metric + specifications that need to be registered, it became clear that none + of the existing metric templates fully satisfy the particular needs + of a Registry. + + Therefore, [RFC8911] defines the overall format for a Performance + Metrics Registry. Section 5 of [RFC8911] also gives guidelines for + those requesting registration of a Metric -- that is, the creation of + one or more entries in the Performance Metrics Registry: + + | In essence, there needs to be evidence that (1) a candidate + | Registered Performance Metric has significant industry interest or + | has seen deployment and (2) there is agreement that the candidate + | Registered Performance Metric serves its intended purpose. + + The process defined in [RFC8911] also requires that new entries be + administered by IANA through the Specification Required policy + [RFC8126], which will ensure that the metrics are tightly defined. + +1.1. 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. Scope + + This document defines a set of initial Performance Metrics Registry + Entries. Most are Active Performance Metrics, which are based on + RFCs prepared in the IPPM Working Group of the IETF, according to + their framework [RFC2330] and its updates. + +3. Registry Categories and Columns + + This memo uses the terminology defined in [RFC8911]. + + This section provides the categories and columns of the Registry, for + easy reference. An entry (row) therefore gives a complete + description of a Registered Metric. + + Registry Categories and Columns are shown below in this format: + + Category + ------------------... + Column | Column |... + + Summary + --------------------------------------------------------------- + Identifier | Name | URI | Desc. | Reference | Change | Ver | + | | | | | Controller | + + Metric Definition + ----------------------------------------- + Reference Definition | Fixed Parameters | + + Method of Measurement + --------------------------------------------------------------------- + Reference | Packet | Traffic | Sampling | Runtime | Role | + Method | Stream | Filter | Distribution | Parameters | | + | Generation | + Output + ----------------------------------------- + Type | Reference | Units | Calibration | + | Definition | | | + + Administrative Information + ------------------------------------- + Status |Requester | Rev | Rev. Date | + + Comments and Remarks + -------------------- + +4. UDP Round-Trip Latency and Loss Registry Entries + + This section specifies an initial Registry Entry for UDP Round-Trip + Latency and another entry for the UDP Round-Trip Loss Ratio. + + Note: Each Registry Entry only produces a "raw" output or a + statistical summary. To describe both "raw" and one or more + statistics efficiently, the Identifier, Name, and Output + categories can be split, and a single section can specify two or + more closely related metrics. For example, this section specifies + two Registry Entries with many common columns. See Section 7 for + an example specifying multiple Registry Entries with many common + columns. + + All column entries besides the ID, Name, Description, and Output + Reference Method categories are the same; thus, this section defines + two closely related Registry Entries. As a result, IANA has also + assigned a corresponding URL to each of the two Named Metrics. + +4.1. Summary + + This category includes multiple indexes to the Registry Entries: the + element ID and Metric Name. + +4.1.1. ID (Identifier) + + IANA has allocated the numeric Identifiers 1 and 2 for the two Named + Metric Entries in Section 4. See Section 4.1.2 for mapping to Names. + +4.1.2. Name + + 1: RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile + + 2: RTLoss_Active_IP-UDP-Periodic_RFC8912sec4_Percent_LossRatio + +4.1.3. URI + + URL: https://www.iana.org/assignments/performance-metrics/ + RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile + + URL: https://www.iana.org/assignments/performance-metrics/ + RTLoss_Active_IP-UDP-Periodic_RFC8912sec4_Percent_LossRatio + +4.1.4. Description + + RTDelay: This metric assesses the delay of a stream of 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 95th percentile of their + conditional delay distribution. + + RTLoss: This metric assesses the loss ratio of a stream of packets + exchanged between two hosts (which are the two measurement + points). The output is the round-trip loss ratio for all + transmitted packets expressed as a percentage. + +4.1.5. Change Controller + + IETF + +4.1.6. Version (of Registry Format) + + 1.0 + +4.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". + +4.2.1. Reference Definition + + For delay: + + 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. + + For loss: + + 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]. + +4.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 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: + Total of 100 bytes + + 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]. + +4.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. + +4.3.1. Reference Methods + + The methodology for this metric (equivalent to Type-P-Round-trip- + Delay and 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. However, the Periodic stream will be + generated according to [RFC3432]. + + 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 [RFC6673]. + + The calculations on the delay (RTT) 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 RTT 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. + + If a standard measurement protocol is employed, then 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 chosen measurement protocol will dictate the + format of sequence numbers and timestamps, if they are conveyed in + the packet payload. + + 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. + +4.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 3 of [RFC3432] prescribes the method for generating Periodic + streams using associated Parameters. + + incT: The nominal duration of the inter-packet interval, first bit + to first bit, with value 0.0200, 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). + + dT: The duration of the interval for allowed sample start times, + with value 1.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). + + Note: An initiation process with a number of control exchanges + resulting in unpredictable start times (within a time interval) + may be sufficient to avoid synchronization of periodic streams and + is a valid replacement for selecting a start time at random from a + fixed interval. + + The T0 Parameter will be reported as a measured Parameter. + Parameters incT and dT are Fixed Parameters. + +4.3.3. Traffic Filtering (Observation) Details + + N/A + +4.3.4. Sampling Distribution + + N/A + +4.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. + +4.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. + +4.4. Output + + This category specifies all details of the output of measurements + using the metric. + +4.4.1. Type + + Percentile: For the conditional distribution of all packets with a + valid value of round-trip delay (undefined delays are excluded), this + is a single value corresponding to the 95th percentile, 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. + + The percentile = 95, meaning that the reported delay, "95Percentile", + is the smallest value of round-trip delay for which the Empirical + Distribution Function, EDF(95Percentile), is greater than or equal to + 95% of the singleton round-trip delay values in the conditional + distribution. See Section 11.3 of [RFC2330] for the definition of + the percentile statistic using the EDF. + + 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]. + +4.4.2. Reference Definition + + For all outputs: + + 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]. + + TotalPkts: The count of packets sent by the Src to the Dst during + the measurement interval. + + 95Percentile: 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). + + Percent_LossRatio: The numeric value of the result is expressed in + units of lost packets to total packets times 100%, as a positive + value of type decimal64 with fraction digits = 9 (see Section 9.3 + of [RFC6020]) with a resolution of 0.0000000001. + +4.4.3. Metric Units + + The 95th percentile of round-trip delay is expressed in seconds. + + The round-trip loss ratio is expressed as a percentage of lost + packets to total packets sent. + +4.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. + +4.5. Administrative Items + +4.5.1. Status + + Current + +4.5.2. Requester + + RFC 8912 + +4.5.3. Revision + + 1.0 + +4.5.4. Revision Date + + 2021-11-17 + +4.6. Comments and Remarks + + None + +5. Packet Delay Variation Registry Entry + + This section gives an initial Registry Entry for a Packet Delay + Variation (PDV) metric. + +5.1. Summary + + This category includes multiple indexes to the Registry Entry: the + element ID and Metric Name. + +5.1.1. ID (Identifier) + + IANA has allocated the numeric Identifier 3 for the Named Metric + Entry in Section 5. See Section 5.1.2 for mapping to Name. + +5.1.2. Name + + 3: OWPDV_Active_IP-UDP-Periodic_RFC8912sec5_Seconds_95Percentile + +5.1.3. URI + + URL: https://www.iana.org/assignments/performance-metrics/ + OWPDV_Active_IP-UDP-Periodic_RFC8912sec5_Seconds_95Percentile + +5.1.4. Description + + This metric assesses packet delay variation with respect to the + minimum delay observed on the periodic stream. The output is + expressed as the 95th percentile of the one-way packet delay + variation distribution. + +5.1.5. Change Controller + + IETF + +5.1.6. Version (of Registry Format) + + 1.0 + +5.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". + +5.2.1. Reference Definition + + Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP + Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, + <https://www.rfc-editor.org/info/rfc2330>. [RFC2330] + + Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric + for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393, + November 2002, <https://www.rfc-editor.org/info/rfc3393>. [RFC3393] + + Morton, A. and B. Claise, "Packet Delay Variation Applicability + Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009, + <https://www.rfc-editor.org/info/rfc5481>. [RFC5481] + + Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time + Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, + DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/ + rfc5905>. [RFC5905] + + See Sections 2.4 and 3.4 of [RFC3393]. The measured singleton delay + differences are referred to by the variable name "ddT" (applicable to + all forms of delay variation). However, this Metric Entry specifies + the PDV form defined in Section 4.2 of [RFC5481], where the singleton + PDV for packet i is referred to by the variable name "PDV(i)". + +5.2.2. Fixed Parameters + + 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: + Total of 200 bytes + + 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]. + + F: A selection function unambiguously defining the packets from + the stream selected for the metric. See Section 4.2 of + [RFC5481] for the PDV form. + + See the Packet Stream Generation section for two additional Fixed + Parameters. + +5.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. + +5.3.1. Reference Methods + + See Sections 2.6 and 3.6 of [RFC3393] for general singleton element + calculations. This Metric Entry requires implementation of the PDV + form defined in Section 4.2 of [RFC5481]. Also see measurement + considerations in Section 8 of [RFC5481]. + + 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. + + 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. 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. + + If a standard measurement protocol is employed, then 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 chosen measurement protocol will dictate the + format of sequence numbers and timestamps, if they are conveyed in + the packet payload. + +5.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 3 of [RFC3432] prescribes the method for generating Periodic + streams using associated Parameters. + + incT: The nominal duration of the inter-packet interval, first bit + to first bit, with value 0.0200, 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). + + dT: The duration of the interval for allowed sample start times, + with value 1.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). + + Note: An initiation process with a number of control exchanges + resulting in unpredictable start times (within a time interval) + may be sufficient to avoid synchronization of periodic streams and + is a valid replacement for selecting a start time at random from a + fixed interval. + + The T0 Parameter will be reported as a measured Parameter. + Parameters incT and dT are Fixed Parameters. + +5.3.3. Traffic Filtering (Observation) Details + + N/A + +5.3.4. Sampling Distribution + + N/A + +5.3.5. Runtime Parameters and Data Format + + 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. + +5.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 (when required by the test protocol). + +5.4. Output + + This category specifies all details of the output of measurements + using the metric. + +5.4.1. Type + + Percentile: For the conditional distribution of all packets with a + valid value of one-way delay (undefined delays are excluded), this is + a single value corresponding to the 95th percentile, 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. + + The percentile = 95, meaning that the reported delay, "95Percentile", + is the smallest value of one-way PDV for which the Empirical + Distribution Function, EDF(95Percentile), is greater than or equal to + 95% of the singleton one-way PDV values in the conditional + distribution. See Section 11.3 of [RFC2330] for the definition of + the percentile statistic using the EDF. + +5.4.2. Reference Definition + + 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]. + + 95Percentile: 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]. + +5.4.3. Metric Units + + The 95th percentile of one-way PDV is expressed in seconds. + +5.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 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. + +5.5. Administrative Items + +5.5.1. Status + + Current + +5.5.2. Requester + + RFC 8912 + +5.5.3. Revision + + 1.0 + +5.5.4. Revision Date + + 2021-11-17 + +5.6. Comments and Remarks + + Lost packets represent a challenge for delay variation metrics. See + Section 4.1 of [RFC3393] and the delay variation applicability + statement [RFC5481] for extensive analysis and comparison of PDV and + an alternate metric, IPDV (Inter-Packet Delay Variation). + +6. DNS Response Latency and Loss Registry Entries + + This section gives initial Registry Entries for DNS Response Latency + and Loss from a network user's perspective, for a specific named + resource. The metric can be measured repeatedly for different named + resources. [RFC2681] defines a round-trip delay metric. We build on + that metric by specifying several of the input Parameters to + precisely define two metrics for measuring DNS latency and loss. + + All column entries besides the ID, Name, Description, and Output + Reference Method categories are the same; thus, this section defines + two closely related Registry Entries. As a result, IANA has assigned + corresponding URLs to each of the two Named Metrics. + +6.1. Summary + + This category includes multiple indexes to the Registry Entries: the + element ID and Metric Name. + +6.1.1. ID (Identifier) + + IANA has allocated the numeric Identifiers 4 and 5 for the two Named + Metric Entries in Section 6. See Section 6.1.2 for mapping to Names. + +6.1.2. Name + + 4: RTDNS_Active_IP-UDP-Poisson_RFC8912sec6_Seconds_Raw + + 5: RLDNS_Active_IP-UDP-Poisson_RFC8912sec6_Logical_Raw + +6.1.3. URI + + URL: https://www.iana.org/assignments/performance-metrics/ + RTDNS_Active_IP-UDP-Poisson_RFC8912sec6_Seconds_Raw + + URL: https://www.iana.org/assignments/performance-metrics/ + RLDNS_Active_IP-UDP-Poisson_RFC8912sec6_Logical_Raw + +6.1.4. Description + + This is a metric for DNS Response performance from a network user's + perspective, for a specific named resource. The metric can be + measured repeatedly using different resource names. + + RTDNS: This metric assesses the response time, the interval from the + query transmission to the response. + + RLDNS: This metric indicates that the response was deemed lost. In + other words, the response time exceeded the maximum waiting time. + +6.1.5. Change Controller + + IETF + +6.1.6. Version (of Registry Format) + + 1.0 + +6.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". + +6.2.1. Reference Definition + + For Delay: + + Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November + 1987, <https://www.rfc-editor.org/info/rfc1035> (and updates). + [RFC1035] + + 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]. + + For DNS Response Latency, the entities in [RFC1035] must be mapped + to [RFC2681]. The Local Host with its User Program and Resolver + take the Role of "Src", and the Foreign Name Server takes the Role + of "Dst". + + Note that although the definition of round-trip delay between the + Source (Src) and the Destination (Dst) at T 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). + + For Loss: + + Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI + 10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/ + rfc6673>. [RFC6673] + + For DNS Response Loss, the entities in [RFC1035] must be mapped to + [RFC6673]. The Local Host with its User Program and Resolver take + the Role of "Src", and the Foreign Name Server takes the Role of + "Dst". + + Both response time and Loss metrics employ a maximum waiting time + for received responses, so the count of lost packets to total + packets sent is the basis for the loss determination as per + Section 4.3 of [RFC6673]. + +6.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 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: + Source port: 53 + Destination port: 53 + Checksum: The checksum MUST be calculated and the non-zero + checksum included in the header + + Payload: + The payload contains a DNS message as defined in [RFC1035] with + the following values: + + The DNS header section contains: + Identification (see the Runtime column) + QR: Set to 0 (Query) + OPCODE: Set to 0 (standard query) + AA: Not set + TC: Not set + RD: Set to 1 (recursion desired) + RA: Not set + RCODE: Not set + QDCOUNT: Set to 1 (only one entry) + ANCOUNT: Not set + NSCOUNT: Not set + ARCOUNT: Not set + + The Question section contains: + QNAME: The Fully Qualified Domain Name (FQDN) provided as + input for the test; see the Runtime column + + QTYPE: The query type provided as input for the test; see + the Runtime column + + QCLASS: Set to 1 for IN + + The other sections do not contain any Resource Records + (RRs). + + Other measurement Parameters: + Tmax: A loss threshold waiting time (and to help disambiguate + queries). The value is 5.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]. + + Observation: Reply packets will contain a DNS Response and may + contain RRs. + +6.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. + +6.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 Timeout 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 + response packet lost. Lost packets SHALL be designated as having + undefined delay and counted for the RLDNS metric. + + The calculations on the delay (RTT) 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 RTT 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 + reply. + + DNS messages bearing queries provide for random ID Numbers in the + Identification header field, so more than one query may be launched + while a previous request is outstanding when the ID Number is used. + Therefore, the ID Number MUST be retained at the Src and included + with each response packet to disambiguate packet reordering if it + occurs. + + If a DNS Response does not arrive within Tmax, the response time + RTDNS is undefined, and RLDNS = 1. The Message ID SHALL be used to + disambiguate the successive queries that are otherwise identical. + + Since the ID Number field is only 16 bits in length, it places a + limit on the number of simultaneous outstanding DNS queries during a + stress test from a single Src address. + + 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]. However, the DNS server is + expected to perform all required functions to prepare and send a + response, so the response time will include processing time and + network delay. Section 8 of [RFC6673] presents additional + requirements that SHALL be included in the Method of Measurement for + this metric. + + In addition to operations described in [RFC2681], the Src MUST parse + the DNS headers of the reply and prepare the query response + information for subsequent reporting as a measured result, along with + the round-trip delay. + +6.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. + +6.3.3. Traffic Filtering (Observation) Details + + N/A + +6.3.4. Sampling Distribution + + N/A + +6.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. + + 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]. + + 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). + + ID: The 16-bit Identifier assigned by the program that generates the + query. The ID value must vary in successive queries (a list of + IDs is needed); see Section 4.1.1 of [RFC1035]. This Identifier + is copied into the corresponding reply and can be used by the + requester (Src) to match replies with any outstanding queries. + + QNAME: The domain name of the query, formatted as specified in + Section 4 of [RFC6991]. + + QTYPE: The query type, which will correspond to the IP address + family of the query (decimal 1 for IPv4 or 28 for IPv6), formatted + as a uint16, as per Section 9.2 of [RFC6020]. + +6.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. + +6.4. Output + + This category specifies all details of the output of measurements + using the metric. + +6.4.1. Type + + Raw: For each DNS query packet sent, sets of values as defined in the + next column, including the status of the response, only assigning + delay values to successful query-response pairs. + +6.4.2. Reference Definition + + For all outputs: + + T: The time the DNS query was sent during the 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]. + + dT: The time value of the round-trip delay to receive the DNS + Response, 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]. This value is undefined when the response + packet is not received at the Src within a waiting time of + Tmax seconds. + + RCODE: The value of the RCODE field in the DNS Response header, + expressed as a uint64 as specified in Section 9.2 of [RFC6020]. + Non-zero values convey errors in the response, and such replies + must be analyzed separately from successful requests. + + Logical: The numeric value of the result is expressed as a Logical + value, where 1 = Lost and 0 = Received, as a positive value of + type uint8 (represents integer values between 0 and 255, + inclusively (see Section 9.2 of [RFC6020]). Note that for queries + with outcome 1 = Lost, dT and RCODE will be set to the maximum for + decimal64 and uint64, respectively. + +6.4.3. Metric Units + + RTDNS: Round-trip delay, dT, is expressed in seconds. + + RLDNS: The Logical value, where 1 = Lost and 0 = Received. + +6.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 and payload 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. + +6.5. Administrative Items + +6.5.1. Status + + Current + +6.5.2. Requester + + RFC 8912 + +6.5.3. Revision + + 1.0 + +6.5.4. Revision Date + + 2021-11-17 + +6.6. Comments and Remarks + + None + +7. UDP Poisson One-Way Delay and Loss Registry Entries + + This section specifies five initial Registry Entries for UDP Poisson + One-Way Delay and one entry for UDP Poisson One-Way Loss. + + All column entries besides the ID, Name, Description, and Output + Reference Method categories are the same; thus, this section defines + six closely related Registry Entries. As a result, IANA has assigned + corresponding URLs to each of the Named Metrics. + +7.1. Summary + + This category includes multiple indexes to the Registry Entries: the + element ID and Metric Name. + +7.1.1. ID (Identifier) + + IANA has allocated the numeric Identifiers 6-11 for the six Named + Metric Entries in Section 7. See Section 7.1.2 for mapping to Names. + +7.1.2. Name + + 6: + OWDelay_Active_IP-UDP-Poisson- + Payload250B_RFC8912sec7_Seconds_95Percentile + + 7: OWDelay_Active_IP-UDP-Poisson- + Payload250B_RFC8912sec7_Seconds_Mean + + 8: OWDelay_Active_IP-UDP-Poisson- + Payload250B_RFC8912sec7_Seconds_Min + + 9: OWDelay_Active_IP-UDP-Poisson- + Payload250B_RFC8912sec7_Seconds_Max + + 10: + OWDelay_Active_IP-UDP-Poisson- + Payload250B_RFC8912sec7_Seconds_StdDev + + 11: + OWLoss_Active_IP-UDP-Poisson- + Payload250B_RFC8912sec7_Percent_LossRatio + +7.1.3. URI + + URL: https://www.iana.org/assignments/performance-metrics/ + OWDelay_Active_IP-UDP-Poisson- + Payload250B_RFC8912sec7_Seconds_95Percentile + + URL: https://www.iana.org/assignments/performance-metrics/ + OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Mean + + URL: https://www.iana.org/assignments/performance-metrics/ + OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Min + + URL: https://www.iana.org/assignments/performance-metrics/ + OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Max + + URL: https://www.iana.org/assignments/performance-metrics/ + OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_StdDev + + URL: https://www.iana.org/assignments/performance-metrics/ + OWLoss_Active_IP-UDP-Poisson- + Payload250B_RFC8912sec7_Percent_LossRatio + +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 <statistic> of one-way delay for all successfully exchanged + packets based on their conditional delay distribution. + + where <statistic> is one of: + + * 95Percentile + + * Mean + + * Min + + * Max + + * StdDev + + OWLoss: This metric assesses the loss ratio of a stream of packets + exchanged between two hosts (which are the two measurement + points). The output is the one-way loss ratio for all transmitted + packets expressed as a percentage. + +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]. + + For loss: + + Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A + One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, + RFC 7680, DOI 10.17487/RFC7680, January 2016, <https://www.rfc- + editor.org/info/rfc7680>. [RFC7680] + + Section 2.4 of [RFC7680] provides the reference definition of the + singleton (single value) one-way Loss metric. Section 3.4 of + [RFC7680] 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]. + +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]. + + 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 + subsections applies. + +7.4.2.1. Percentile95 + + The 95th percentile 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 of [RFC3393] for details on the percentile statistic + (where round-trip delay should be substituted for "ipdv"). + + The percentile = 95, meaning that the reported delay, "95Percentile", + is the smallest value of one-way delay for which the Empirical + Distribution Function, EDF(95Percentile), is greater than or equal to + 95% of the singleton one-way delay values in the conditional + distribution. See Section 11.3 of [RFC2330] for the definition of + the percentile statistic using the EDF. + + 95Percentile: 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.2.2. Mean + + The mean 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.2.2 of [RFC6049] for details on calculating this + statistic; see also Section 4.2.3 of [RFC6049]. + + Mean: 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.2.3. Min + + The minimum 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 details on calculating this + statistic; see also Section 4.3.3 of [RFC6049]. + + Min: 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.2.4. Max + + 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.2.5. Std_Dev + + The standard deviation (Std_Dev) 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 6.1.4 of [RFC6049] for a closely related method for + calculating this statistic. The formula is the classic calculation + for the standard deviation of a population. + + Define Population Std_Dev_Delay as follows: + + _ _ + | N | + | --- | + | 1 \ 2 | + Std_Dev = SQRT | ------- > (Delay[n] - MeanDelay) | + | (N) / | + | --- | + | n = 1 | + |_ _| + + where all packets n = 1 through N have a value for Delay[n], + MeanDelay is calculated per Section 7.4.2.2, and SQRT[] is the Square + Root function: + + Std_Dev: 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.2.6. 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 + value of type decimal64 with fraction digits = 9 (see Section 9.3 + of [RFC6020]) with a resolution of 0.0000000001. + +7.4.3. Metric Units + + 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 + to total packets sent. + +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 + +8. UDP Periodic One-Way Delay and Loss Registry Entries + + This section specifies five initial Registry Entries for UDP Periodic + One-Way Delay and one entry for UDP Periodic One-Way Loss. + + All column entries besides the ID, Name, Description, and Output + Reference Method categories are the same; thus, this section defines + six closely related Registry Entries. As a result, IANA has assigned + corresponding URLs to each of the six Named Metrics. + +8.1. Summary + + This category includes multiple indexes to the Registry Entries: the + element ID and Metric Name. + +8.1.1. ID (Identifier) + + IANA has allocated the numeric Identifiers 12-17 for the six Named + Metric Entries in Section 8. See Section 8.1.2 for mapping to Names. + +8.1.2. Name + + 12: + OWDelay_Active_IP-UDP-Periodic20m- + Payload142B_RFC8912sec8_Seconds_95Percentile + + 13: + OWDelay_Active_IP-UDP-Periodic20m- + Payload142B_RFC8912sec8_Seconds_Mean + + 14: + OWDelay_Active_IP-UDP-Periodic20m- + Payload142B_RFC8912sec8_Seconds_Min + + 15: + OWDelay_Active_IP-UDP-Periodic20m- + Payload142B_RFC8912sec8_Seconds_Max + + 16: + OWDelay_Active_IP-UDP-Periodic20m- + Payload142B_RFC8912sec8_Seconds_StdDev + + 17: + OWLoss_Active_IP-UDP-Periodic20m- + Payload142B_RFC8912sec8_Percent_LossRatio + +8.1.3. URI + + URL: https://www.iana.org/assignments/performance-metrics/ + OWDelay_Active_IP-UDP-Periodic20m- + Payload142B_RFC8912sec8_Seconds_95Percentile + + URL: https://www.iana.org/assignments/performance-metrics/ + OWDelay_Active_IP-UDP-Periodic20m- + Payload142B_RFC8912sec8_Seconds_Mean + + URL: https://www.iana.org/assignments/performance-metrics/ + OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Min + + URL: https://www.iana.org/assignments/performance-metrics/ + OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Max + + URL: https://www.iana.org/assignments/performance-metrics/ + OWDelay_Active_IP-UDP-Periodic20m- + Payload142B_RFC8912sec8_Seconds_StdDev + + URL: https://www.iana.org/assignments/performance-metrics/ + OWLoss_Active_IP-UDP-Periodic20m- + Payload142B_RFC8912sec8_Percent_LossRatio + +8.1.4. Description + + OWDelay: This metric assesses the delay of a stream of packets + exchanged between two hosts (or measurement points) and reports + the <statistic> of one-way delay for all successfully exchanged + packets based on their conditional delay distribution. + + where <statistic> is one of: + + * 95Percentile + + * Mean + + * Min + + * Max + + * StdDev + + OWLoss: This metric assesses the loss ratio of a stream of packets + exchanged between two hosts (which are the two measurement + points). The output is the one-way loss ratio for all transmitted + packets expressed as a percentage. + +8.1.5. Change Controller + + IETF + +8.1.6. Version (of Registry Format) + + 1.0 + +8.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". + +8.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]. + + For loss: + + Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A + One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, + RFC 7680, DOI 10.17487/RFC7680, January 2016, <https://www.rfc- + editor.org/info/rfc7680>. [RFC7680] + + Section 2.4 of [RFC7680] provides the reference definition of the + singleton (single value) one-way Loss metric. Section 3.4 of + [RFC7680] 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]. + +8.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 + + 142 octets total, including the TWAMP format (and format + type MUST be reported, if used) + + 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 three additional Fixed + Parameters. + +8.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. + +8.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. However, a + Periodic stream is used, as defined in [RFC3432]. + + 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. + +8.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 3 of [RFC3432] prescribes the method for generating Periodic + streams using associated Parameters. + + incT: The nominal duration of the inter-packet interval, first bit + to first bit, with value 0.0200, 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]. + + dT: The duration of the interval for allowed sample start times, + with value 1.0000, 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]. + + T0: The actual start time of the periodic stream, determined from T0 + and dT. + + Note: An initiation process with a number of control exchanges + resulting in unpredictable start times (within a time interval) + may be sufficient to avoid synchronization of periodic streams and + is a valid replacement for selecting a start time at random from a + fixed interval. + + These stream Parameters will be specified as Runtime Parameters. + +8.3.3. Traffic Filtering (Observation) Details + + N/A + +8.3.4. Sampling Distribution + + N/A + +8.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. + +8.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. + +8.4. Output + + This category specifies all details of the output of measurements + using the metric. + +8.4.1. Type + + Latency and Loss Types are discussed in the subsections below. + +8.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]. + + 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 + subsections applies. + +8.4.2.1. Percentile95 + + The 95th percentile 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 of [RFC3393] for details on the percentile statistic + (where round-trip delay should be substituted for "ipdv"). + + The percentile = 95, meaning that the reported delay, "95Percentile", + is the smallest value of one-way delay for which the Empirical + Distribution Function, EDF(95Percentile), is greater than or equal to + 95% of the singleton one-way delay values in the conditional + distribution. See Section 11.3 of [RFC2330] for the definition of + the percentile statistic using the EDF. + + 95Percentile: 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]. + +8.4.2.2. Mean + + The mean 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.2.2 of [RFC6049] for details on calculating this + statistic; see also Section 4.2.3 of [RFC6049]. + + Mean: 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]. + +8.4.2.3. Min + + The minimum 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 details on calculating this + statistic; see also Section 4.3.3 of [RFC6049]. + + Min: 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]. + +8.4.2.4. Max + + 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]. + +8.4.2.5. Std_Dev + + Std_Dev 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 6.1.4 of [RFC6049] for a closely related method for + calculating this statistic. The formula is the classic calculation + for the standard deviation of a population. + + Define Population Std_Dev_Delay as follows: + + _ _ + | N | + | --- | + | 1 \ 2 | + Std_Dev = SQRT | ------- > (Delay[n] - MeanDelay) | + | (N) / | + | --- | + | n = 1 | + |_ _| + + where all packets n = 1 through N have a value for Delay[n], + MeanDelay is calculated per Section 8.4.2.2, and SQRT[] is the Square + Root function: + + Std_Dev: 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]. + +8.4.2.6. 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 + value of type decimal64 with fraction digits = 9 (see Section 9.3 + of [RFC6020] with a resolution of 0.0000000001. + +8.4.3. Metric Units + + 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 + to total packets sent. + +8.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. + +8.5. Administrative Items + +8.5.1. Status + + Current + +8.5.2. Requester + + RFC 8912 + +8.5.3. Revision + + 1.0 + +8.5.4. Revision Date + + 2021-11-17 + +8.6. Comments and Remarks + + None + +9. ICMP Round-Trip Latency and Loss Registry Entries + + This section specifies three initial Registry Entries for ICMP + Round-Trip Latency and another entry for the ICMP Round-Trip Loss + Ratio. + + All column entries besides the ID, Name, Description, and Output + Reference Method categories are the same; thus, this section defines + four closely related Registry Entries. As a result, IANA has + assigned corresponding URLs to each of the four Named Metrics. + +9.1. Summary + + This category includes multiple indexes to the Registry Entries: the + element ID and Metric Name. + +9.1.1. ID (Identifier) + + IANA has allocated the numeric Identifiers 18-21 for the four Named + Metric Entries in Section 9. See Section 9.1.2 for mapping to Names. + +9.1.2. Name + + 18: RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Mean + + 19: RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Min + + 20: RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Max + + 21: RTLoss_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Percent_LossRatio + +9.1.3. URI + + URL: https://www.iana.org/assignments/performance-metrics/ + RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Mean + + URL: https://www.iana.org/assignments/performance-metrics/ + RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Min + + URL: https://www.iana.org/assignments/performance-metrics/ + RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Max + + URL: https://www.iana.org/assignments/performance-metrics/ + RTLoss_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Percent_LossRatio + +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 <statistic> of their + conditional delay distribution, where <statistic> is one of: + + * Mean + + * Min + + * Max + + RTLoss: This metric assesses the loss ratio of a stream of ICMP + packets exchanged between two hosts (which are the two measurement + points). The output is the round-trip loss ratio for all + transmitted packets expressed as a percentage. + +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 + + For delay: + + 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. + + For loss: + + 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 and Loss 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. + + For each <statistic> or Percent_LossRatio, one of the following + subsections applies. + +9.4.2.1. Mean + + The mean 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.2.2 of [RFC6049] for details on calculating this + statistic; see also Section 4.2.3 of [RFC6049]. + + Mean: 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.2.2. Min + + The minimum 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 details on calculating this + statistic; see also Section 4.3.3 of [RFC6049]. + + Min: 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.2.3. Max + + 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.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 + units of lost packets to total packets times 100%, as a positive + value of type decimal64 with fraction digits = 9 (see Section 9.3 + of [RFC6020]) with a resolution of 0.0000000001. + +9.4.3. Metric Units + + The <statistic> of round-trip delay is expressed in seconds, where + <statistic> is one of: + + * Mean + + * Min + + * Max + + The round-trip loss ratio is expressed as a percentage of lost + packets to total packets sent. + +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 + +10. TCP Round-Trip Delay and Loss Registry Entries + + This section specifies four initial Registry Entries for the Passive + assessment of TCP Round-Trip Delay (RTD) and another entry for the + TCP Round-Trip Loss Count. + + All column entries besides the ID, Name, Description, and Output + Reference Method categories are the same; thus, this section defines + four closely related Registry Entries. As a result, IANA has + assigned corresponding URLs to each of the four Named Metrics. + +10.1. Summary + + This category includes multiple indexes to the Registry Entries: the + element ID and Metric Name. + +10.1.1. ID (Identifier) + + IANA has allocated the numeric Identifiers 22-26 for the five Named + Metric Entries in Section 10. See Section 10.1.2 for mapping to + Names. + +10.1.2. Name + + 22: RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Mean + + 23: RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Min + + 24: RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Max + + 25: RTDelay_Passive_IP-TCP-HS_RFC8912sec10_Seconds_Singleton + + Note that a midpoint observer only has the opportunity to compose a + single RTDelay on the TCP handshake. + + 26: RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count + +10.1.3. URI + + URL: https://www.iana.org/assignments/performance-metrics/ + RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Mean + + URL: https://www.iana.org/assignments/performance-metrics/ + RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Min + + URL: https://www.iana.org/assignments/performance-metrics/ + RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Max + + URL: https://www.iana.org/assignments/performance-metrics/ + RTDelay_Passive_IP-TCP-HS_RFC8912sec10_Seconds_Singleton + + URL: https://www.iana.org/assignments/performance-metrics/ + RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count + +10.1.4. Description + + RTDelay: This metric assesses the round-trip delay of TCP packets + constituting a single connection, exchanged between two hosts. We + consider the measurement of round-trip delay based on a single + Observation Point (OP) [RFC7011] somewhere in the network. The + output is the round-trip delay for all successfully exchanged + packets expressed as the <statistic> of their conditional delay + distribution, where <statistic> is one of: + + * Mean + + * Min + + * Max + + RTDelay Singleton: This metric assesses the round-trip delay of TCP + packets initiating a single connection (or 3-way handshake), + exchanged between two hosts. We consider the measurement of + round-trip delay based on a single Observation Point (OP) + [RFC7011] somewhere in the network. The output is the single + measurement of Round-trip delay, or Singleton. + + RTLoss: This metric assesses the estimated loss count for TCP + packets constituting a single connection, exchanged between two + hosts. We consider the measurement of round-trip delay based on a + single OP [RFC7011] somewhere in the network. The output is the + estimated loss count for the measurement interval. + +10.1.5. Change Controller + + IETF + +10.1.6. Version (of Registry Format) + + 1.0 + +10.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". + +10.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] + + Although there is no RFC that describes Passive Measurement of round- + trip delay, the parallel definition for Active Measurement is + provided in [RFC2681]. + + This metric definition uses the term "wire time" as defined in + Section 10.2 of [RFC2330], and the terms "singleton" and "sample" as + defined in Section 11 of [RFC2330]. (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.) + + With the OP [RFC7011] typically located between the hosts + participating in the TCP connection, the round-trip delay metric + requires two individual measurements between the OP and each host, + such that the Spatial Composition [RFC6049] of the measurements + yields a round-trip delay singleton (we are extending the composition + of one-way subpath delays to subpath round-trip delay). + + Using the direction of TCP SYN transmission to anchor the + nomenclature, host A sends the SYN, and host B replies with SYN-ACK + during connection establishment. The direction of SYN transfer is + considered the Forward direction of transmission, from A through the + OP to B (the Reverse direction is B through the OP to A). + + Traffic Filters reduce the packet streams at the OP to a Qualified + bidirectional flow of packets. + + In the definitions below, Corresponding Packets are transferred in + different directions and convey a common value in a TCP header field + that establishes correspondence (to the extent possible). Examples + may be found in the TCP timestamp fields. + + For a real number, RTD_fwd, >> the round-trip delay in the Forward + direction from the OP to host B at time T' is RTD_fwd << it is + REQUIRED that the OP observed a Qualified Packet to host B at wire + time T', that host B received that packet and sent a Corresponding + Packet back to host A, and the OP observed the Corresponding Packet + at wire time T' + RTD_fwd. + + For a real number, RTD_rev, >> the round-trip delay in the Reverse + direction from the OP to host A at time T'' is RTD_rev << it is + REQUIRED that the OP observed a Qualified Packet to host A at wire + time T'', that host A received that packet and sent a Corresponding + Packet back to host B, and that the OP observed the Corresponding + Packet at wire time T'' + RTD_rev. + + Ideally, the packet sent from host B to host A in both definitions + above SHOULD be the same packet (or, when measuring RTD_rev first, + the packet from host A to host B in both definitions should be the + same). + + The REQUIRED Composition Function for a singleton of round-trip delay + at time T (where T is the earliest of T' and T'' above) is: + + RTDelay = RTD_fwd + RTD_rev + + Note that when the OP is located at host A or host B, one of the + terms composing RTDelay will be zero or negligible. + + Using the abbreviation HS to refer to the TCP handshake: when the + Qualified and Corresponding Packets are a TCP-SYN and a TCP-SYN-ACK, + RTD_fwd == RTD_HS_fwd. + + When the Qualified and Corresponding Packets are a TCP-SYN-ACK and a + TCP-ACK, RTD_rev == RTD_HS_rev. + + The REQUIRED Composition Function for a singleton of round-trip delay + for the connection handshake is: + + RTDelay_HS = RTD_HS_fwd + RTD_HS_rev + + The definition of round-trip loss count uses the nomenclature + developed above, based on observation of the TCP header sequence + numbers and storing the sequence number gaps observed. Packet losses + can be inferred from: + + Out-of-order segments: TCP segments are transmitted with + monotonically increasing sequence numbers, but these segments may + be received out of order. Section 3 of [RFC4737] describes the + notion of "next expected" sequence numbers, which can be adapted + to TCP segments (for the purpose of detecting reordered packets). + Observation of out-of-order segments indicates loss on the path + prior to the OP and creates a gap. + + Duplicate segments: Section 2 of [RFC5560] defines identical packets + and is suitable for evaluation of TCP packets to detect + duplication. Observation of a segment duplicates a segment + previously observed (and thus no corresponding observed segment + gap) indicates loss on the path following the OP (e.g., the + segment overlaps part of the octet stream already observed at the + OP). + + Each observation of an out-of-order or duplicate segment infers a + singleton of loss, but the composition of round-trip loss counts will + be conducted over a measurement interval that is synonymous with a + single TCP connection. + + With the above observations in the Forward direction over a + measurement interval, the count of out-of-order and duplicate + segments is defined as RTL_fwd. Comparable observations in the + Reverse direction are defined as RTL_rev. + + For a measurement interval (corresponding to a single TCP connection) + T0 to Tf, the REQUIRED Composition Function for the two single- + direction counts of inferred loss is: + + RTLoss = RTL_fwd + RTL_rev + +10.2.2. Fixed Parameters + + Traffic Filters: + IPv4 header values: + DSCP: Set to 0 + Protocol: Set to 06 (TCP) + + IPv6 header values: + DSCP: Set to 0 + Hop Count: Set to 255 + Next Header: Set to 6 (TCP) + Flow Label: Set to 0 + Extension Headers: None + + TCP header values: + Flags: ACK, SYN, FIN, set as required + Timestamps Option (TSopt): Set. See Section 3.2 of [RFC7323] + +10.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. + +10.3.1. Reference Methods + + The foundational methodology for this metric is defined in Section 4 + of [RFC7323] using the Timestamps option with modifications that + allow application at a mid-path OP [RFC7011]. Further details and + applicable heuristics were derived from [Strowes] and [Trammell-14]. + + 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 + 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 + of RTDelay as RTDelay_HS (composed using the Forward and Reverse + measurement pair). RTDelay_HS SHALL be treated separately from other + RTDelays on data-bearing packets and their ACKs. The RTDelay_HS + value MAY be used as a consistency check on the composed values of + RTDelay for payload-bearing packets. + + For payload-bearing packets, the OP measures the time interval + between observation of a packet with sequence number "s" and the + corresponding ACK with the same sequence number. When the payload is + transferred from host A to host B, the observed interval is RTD_fwd. + + For payload-bearing packets, each observation of an out-of-order or + duplicate segment infers a loss count, but the composition of round- + trip loss counts will be conducted over a measurement interval that + is synonymous with a single TCP connection. + + Because many data transfers are unidirectional (say, in the Forward + direction from host A to host B), it is necessary to use pure ACK + packets with Timestamp (TSval) and packets with the Timestamp value + echo to perform a RTD_rev measurement. The time interval between + observation of the ACK from B to A, and the Corresponding Packet with + a Timestamp Echo Reply (TSecr) field [RFC7323], is the RTD_rev. + + Delay Measurement Filtering Heuristics: + + * If data payloads were transferred in both Forward and Reverse + directions, then the Round-Trip Time Measurement rule in + Section 4.1 of [RFC7323] could be applied. This rule essentially + excludes any measurement using a packet unless it makes progress + in the transfer (advances the left edge of the send window, + consistent with [Strowes]). + + * A different heuristic from [Trammell-14] is to exclude any RTD_rev + that is larger than previously observed values. This would tend + to exclude Reverse measurements taken when the application has no + data ready to send, because considerable time could be added to + RTD_rev from this source of error. + + * Note that the above heuristic assumes that host A is sending data. + Host A expecting a download would mean that this heuristic should + be applied to RTD_fwd. + + * The statistic calculations to summarize the delay (RTDelay) SHALL + be performed on the conditional distribution, conditioned on + successful Forward and Reverse measurements that follow the + heuristics. + + Method for Inferring Loss: + + * The OP tracks sequence numbers and stores gaps for each direction + of transmission, as well as the next expected sequence number as + discussed in [Trammell-14] and [RFC4737]. Loss is inferred from + out-of-order segments and duplicate segments. + + Loss Measurement Filtering Heuristics: + + * [Trammell-14] adds a window of evaluation based on the RTDelay. + + * Distinguish reordered packets from out-of-order segments due to + loss, because the sequence number gap is filled during the same + RTDelay window. Segments detected as reordered according to + [RFC4737] MUST reduce the loss count inferred from out-of-order + segments. + + * Spurious (unneeded) retransmissions (observed as duplicates) can + also be reduced in this way, as described in [Trammell-14]. + + Sources of Error: + + * The principal source of RTDelay error is the host processing time + to return a packet that defines the termination of a time + interval. The heuristics above intend to mitigate these errors by + excluding measurements where host processing time is a significant + part of RTD_fwd or RTD_rev. + + * A key source of RTLoss error is observation loss, as described in + Section 3 of [Trammell-14]. + +10.3.2. Packet Stream Generation + + N/A + +10.3.3. Traffic Filtering (Observation) Details + + The Fixed Parameters above give a portion of the Traffic Filter. + Other aspects will be supplied as Runtime Parameters (below). + +10.3.4. Sampling Distribution + + This metric requires a complete sample of all packets that qualify + according to the Traffic Filter criteria. + +10.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 host A 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 host B 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: Optionally, 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]), or the duration (see + T0). The UTC Time Zone is required by Section 6.1 of [RFC2330]. + Alternatively, the end of the measurement interval MAY be + controlled by the measured connection, where the second pair of + FIN and ACK packets exchanged between host A and host B + effectively ends the interval. + + TTL or Hop Limit: Set at desired value. + +10.3.6. Roles + + host A: Launches the SYN packet to open the connection. The Role of + "host A" is synonymous with the IP address used at host A. + + host B: Replies with the SYN-ACK packet to open the connection. The + Role of "host B" is synonymous with the IP address used at host B. + +10.4. Output + + This category specifies all details of the output of measurements + using the metric. + +10.4.1. Type + + RTDelay Types are discussed in the subsections below. + + For RTLoss: The count of lost packets. + +10.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 end of the measurement interval MAY + be controlled by the measured connection, where the second pair of + FIN and ACK packets exchanged between host A and host B + effectively ends the interval. + + RTDelay_Passive_IP-TCP-HS: The round-trip delay of the handshake is + a Singleton. + + RTLoss: The count of lost packets. + + For each <statistic>, Singleton, or Loss Count, one of the following + subsections applies. + +10.4.2.1. Mean + + The mean 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.2.2 of [RFC6049] for details on calculating this + statistic; see also Section 4.2.3 of [RFC6049]. + + Mean: 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]. + +10.4.2.2. Min + + The minimum 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 details on calculating this + statistic; see also Section 4.3.3 of [RFC6049]. + + Min: 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]. + +10.4.2.3. Max + + 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]. + +10.4.2.4. Singleton + + The singleton SHALL be calculated using the successful RTD_fwd (on + the SYN to SYN-ACK pair) and RTD_rev (on the SYN-ACK to ACK pair), + see Section 10.3.1. + + The singleton 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 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]. + +10.4.2.5. Loss Counts + + RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count: The count of lost + packets. + + Observation of an out-of-order segment or duplicate segment infers a + loss count, after application of the Definitions of Section 10.2.1 + and the Loss Measurement Filtering Heuristics of Section 10.3.1. The + composition of round-trip loss counts will be conducted over a + measurement interval that is synonymous with a single TCP connection. + + For a measurement interval (corresponding to a single TCP connection) + T0 to Tf, the REQUIRED Composition Function for the two single- + direction counts of inferred loss is: + + RTLoss = RTL_fwd + RTL_rev + + Packet count: The numeric value of the result is expressed in units + of lost packets, as a positive value of type uint64 (represents + integer values between 0 and 18446744073709551615, inclusively + (see Section 9.2 of [RFC6020]). + +10.4.3. Metric Units + + The <statistic> of round-trip delay is expressed in seconds, where + <statistic> is one of: + + * Mean + + * Min + + * Max + + The round-trip delay of the TCP handshake singleton is expressed in + seconds. + + The round-trip loss count is expressed as a number of packets. + +10.4.4. Calibration + + Passive Measurements at an OP could be calibrated against an Active + Measurement (with loss emulation) at host A or host B, where the + Active Measurement represents the ground truth. + +10.5. Administrative Items + +10.5.1. Status + + Current + +10.5.2. Requester + + RFC 8912 + +10.5.3. Revision + + 1.0 + +10.5.4. Revision Date + + 2021-11-17 + +10.6. Comments and Remarks + + None + +11. Security Considerations + + These Registry Entries represent no known implications for Internet + security. With the exception of [RFC1035], each RFC referenced above + contains a Security Considerations section. Further, the Large-scale + Measurement of Broadband Performance (LMAP) framework [RFC7594] + provides both security and privacy considerations for measurements. + + There are potential privacy considerations for observed traffic, + particularly for Passive Metrics as discussed in Section 10. An + attacker that knows that its TCP connection is being measured can + modify its behavior to skew the measurement results. + +12. IANA Considerations + + IANA has populated the Performance Metrics Registry defined in + [RFC8911] with the values defined in Sections 4 through 10. + + See the IANA Considerations section of [RFC8911] for additional + considerations. + +13. References + +13.1. Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, <https://www.rfc-editor.org/info/rfc1035>. + + [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>. + + [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, + "Framework for IP Performance Metrics", RFC 2330, + DOI 10.17487/RFC2330, May 1998, + <https://www.rfc-editor.org/info/rfc2330>. + + [RFC2681] 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>. + + [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: + Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, + <https://www.rfc-editor.org/info/rfc3339>. + + [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation + Metric for IP Performance Metrics (IPPM)", RFC 3393, + DOI 10.17487/RFC3393, November 2002, + <https://www.rfc-editor.org/info/rfc3393>. + + [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network + performance measurement with periodic streams", RFC 3432, + DOI 10.17487/RFC3432, November 2002, + <https://www.rfc-editor.org/info/rfc3432>. + + [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, + S., and J. Perser, "Packet Reordering Metrics", RFC 4737, + DOI 10.17487/RFC4737, November 2006, + <https://www.rfc-editor.org/info/rfc4737>. + + [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. + Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", + RFC 5357, DOI 10.17487/RFC5357, October 2008, + <https://www.rfc-editor.org/info/rfc5357>. + + [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation + Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, + March 2009, <https://www.rfc-editor.org/info/rfc5481>. + + [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", + RFC 5560, DOI 10.17487/RFC5560, May 2009, + <https://www.rfc-editor.org/info/rfc5560>. + + [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, + "Network Time Protocol Version 4: Protocol and Algorithms + Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, + <https://www.rfc-editor.org/info/rfc5905>. + + [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for + the Network Configuration Protocol (NETCONF)", RFC 6020, + DOI 10.17487/RFC6020, October 2010, + <https://www.rfc-editor.org/info/rfc6020>. + + [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of + Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, + <https://www.rfc-editor.org/info/rfc6049>. + + [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, + DOI 10.17487/RFC6673, August 2012, + <https://www.rfc-editor.org/info/rfc6673>. + + [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", + RFC 6991, DOI 10.17487/RFC6991, July 2013, + <https://www.rfc-editor.org/info/rfc6991>. + + [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, + "Specification of the IP Flow Information Export (IPFIX) + Protocol for the Exchange of Flow Information", STD 77, + RFC 7011, DOI 10.17487/RFC7011, September 2013, + <https://www.rfc-editor.org/info/rfc7011>. + + [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. + Scheffenegger, Ed., "TCP Extensions for High Performance", + RFC 7323, DOI 10.17487/RFC7323, September 2014, + <https://www.rfc-editor.org/info/rfc7323>. + + [RFC7679] 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>. + + [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, + Ed., "A One-Way Loss Metric for IP Performance Metrics + (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January + 2016, <https://www.rfc-editor.org/info/rfc7680>. + + [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>. + + [RFC8911] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. + Akhter, "Registry for Performance Metrics", RFC 8911, + DOI 10.17487/RFC8911, November 2021, + <https://www.rfc-editor.org/info/rfc8911>. + + [Strowes] Strowes, S., "Passively Measuring TCP Round-Trip Times", + Communications of the ACM, Vol. 56 No. 10, Pages 57-64, + DOI 10.1145/2507771.2507781, October 2013, + <https://dl.acm.org/doi/10.1145/2507771.2507781>. + + [Trammell-14] + Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data + Integrity Signals for Passive Measurement", In: Dainotti + A., Mahanti A., Uhlig S. (eds) Traffic Monitoring and + Analysis. TMA 2014. Lecture Notes in Computer Science, + vol 8406. Springer, Berlin, Heidelberg, + DOI 10.1007/978-3-642-54999-1_2, March 2014, + <https://link.springer.com/ + chapter/10.1007/978-3-642-54999-1_2>. + +13.2. Informative References + + [RFC1242] Bradner, S., "Benchmarking Terminology for Network + Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, + July 1991, <https://www.rfc-editor.org/info/rfc1242>. + + [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New + Performance Metric Development", BCP 170, RFC 6390, + DOI 10.17487/RFC6390, October 2011, + <https://www.rfc-editor.org/info/rfc6390>. + + [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting + IP Network Performance Metrics: Different Points of View", + RFC 6703, DOI 10.17487/RFC6703, August 2012, + <https://www.rfc-editor.org/info/rfc6703>. + + [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>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + +Acknowledgments + + The authors thank Brian Trammell for suggesting the term "Runtime + Parameters", which led to the distinction between Runtime and Fixed + Parameters implemented in this memo, for identifying the IP Flow + Information Export (IPFIX) metric with Flow Key as an example, for + suggesting the Passive TCP RTD Metric and supporting references, and + for many other productive suggestions. Thanks to Peter Koch, who + provided several useful suggestions for disambiguating successive DNS + queries in the DNS Response time metric. + + The authors also acknowledge the constructive reviews and helpful + suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, + Yaakov Stein, and participants in the LMAP Working Group. Thanks to + Michelle Cotton for her early IANA reviews, and to Amanda Baber for + answering questions related to the presentation of the Registry and + accessibility of the complete template via URL. + +Authors' Addresses + + Al Morton + AT&T Labs + 200 Laurel Avenue South + Middletown, NJ 07748 + United States of America + + Phone: +1 732 420 1571 + Email: acmorton@att.com + + + Marcelo Bagnulo + Universidad Carlos III de Madrid + Av. Universidad 30 + 28911 Leganes Madrid + Spain + + Phone: 34 91 6249500 + Email: marcelo@it.uc3m.es + URI: http://www.it.uc3m.es + + + Philip Eardley + BT + Adastral Park, Martlesham Heath + Ipswich + United Kingdom + + Email: philip.eardley@bt.com + + + Kevin D'Souza + AT&T Labs + 200 Laurel Avenue South + Middletown, NJ 07748 + United States of America + + Phone: +1 732 420 2514 + Email: kld@att.com |