rfc8912xml2.original.xml   rfc8912.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc [
<?rfc toc="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocompact="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc tocdepth="3"?> <!ENTITY nbhy "&#8209;">
<?rfc tocindent="yes"?> <!ENTITY wj "&#8288;">
<?rfc symrefs="yes"?> ]>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
<?rfc inline="yes"?> docName="draft-ietf-ippm-initial-registry-16" number="8912"
<?rfc compact="yes"?> ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
<?rfc subcompact="no"?> consensus="true" xml:lang="en" tocInclude="true" tocDepth="3"
<rfc category="std" docName="draft-ietf-ippm-initial-registry-16" symRefs="true" sortRefs="true" version="3">
ipr="trust200902"> <!-- xml2rfc v2v3 conversion 2.43.0 -->
<front> <front>
<title abbrev="Initial Registry">Initial Performance Metrics Registry <title abbrev="Initial Performance Metrics Registry">Initial Performance Met rics Registry
Entries</title> Entries</title>
<seriesInfo name="RFC" value="8912"/>
<author fullname="Al Morton" initials="A." surname="Morton"> <author fullname="Al Morton" initials="A." surname="Morton">
<organization>AT&amp;T Labs</organization> <organization>AT&amp;T Labs</organization>
<address> <address>
<postal> <postal>
<street>200 Laurel Avenue South</street> <street>200 Laurel Avenue South</street>
<city>Middletown</city>
<city>Middletown,</city>
<region>NJ</region> <region>NJ</region>
<code>07748</code> <code>07748</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<phone>+1 732 420 1571</phone> <phone>+1 732 420 1571</phone>
<facsimile>+1 732 368 1192</facsimile>
<email>acmorton@att.com</email> <email>acmorton@att.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo"> <author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
<organization abbrev="UC3M">Universidad Carlos III de <organization abbrev="UC3M">Universidad Carlos III de
Madrid</organization> Madrid</organization>
<address> <address>
<postal> <postal>
<street>Av. Universidad 30</street> <street>Av. Universidad 30</street>
<city>Leganes</city> <city>Leganes</city>
<region>Madrid</region> <region>Madrid</region>
<code>28911</code> <code>28911</code>
<country>Spain</country>
<country>SPAIN</country>
</postal> </postal>
<phone>34 91 6249500</phone> <phone>34 91 6249500</phone>
<email>marcelo@it.uc3m.es</email> <email>marcelo@it.uc3m.es</email>
<uri>http://www.it.uc3m.es</uri> <uri>http://www.it.uc3m.es</uri>
</address> </address>
</author> </author>
<author fullname="Philip Eardley" initials="P." surname="Eardley"> <author fullname="Philip Eardley" initials="P." surname="Eardley">
<organization abbrev="BT">BT</organization> <organization abbrev="BT">BT</organization>
<address> <address>
<postal> <postal>
<street>Adastral Park, Martlesham Heath</street> <street>Adastral Park, Martlesham Heath</street>
<city>Ipswich</city> <city>Ipswich</city>
<country>United Kingdom</country>
<country>ENGLAND</country>
</postal> </postal>
<email>philip.eardley@bt.com</email> <email>philip.eardley@bt.com</email>
</address> </address>
</author> </author>
<author fullname="Kevin D'Souza" initials="K." surname="D'Souza"> <author fullname="Kevin D'Souza" initials="K." surname="D'Souza">
<organization>AT&amp;T Labs</organization> <organization>AT&amp;T Labs</organization>
<address> <address>
<postal> <postal>
<street>200 Laurel Avenue South</street> <street>200 Laurel Avenue South</street>
<city>Middletown</city>
<city>Middletown,</city>
<region>NJ</region> <region>NJ</region>
<code>07748</code> <code>07748</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<phone>+1 732 420 2514</phone>
<phone>+1 732 420 xxxx</phone>
<facsimile/>
<email>kld@att.com</email> <email>kld@att.com</email>
<uri/>
</address> </address>
</author> </author>
<date day="9" month="March" year="2020"/> <date month="November" year="2021"/>
<keyword>Loss</keyword>
<keyword>Delay</keyword>
<keyword>Delay Variation</keyword>
<keyword>ICMP ping</keyword>
<keyword>DNS Response</keyword>
<keyword>Poisson</keyword>
<keyword>Periodic</keyword>
<keyword>TCP</keyword>
<abstract> <abstract>
<t>This memo defines the set of Initial Entries for the IANA Performance <t>This memo defines the set of initial entries for the IANA Registry of P
Metrics Registry. The set includes: UDP Round-trip Latency and Loss, erformance
Metrics. The set includes UDP Round-Trip Latency and Loss,
Packet Delay Variation, DNS Response Latency and Loss, UDP Poisson Packet Delay Variation, DNS Response Latency and Loss, UDP Poisson
One-way Delay and Loss, UDP Periodic One-way Delay and Loss, ICMP One-Way Delay and Loss, UDP Periodic One-Way Delay and Loss, ICMP
Round-trip Latency and Loss, and TCP round-trip Latency and Loss.</t> Round-Trip Latency and Loss, and TCP Round-Trip Delay and Loss.</t>
</abstract> </abstract>
<note title="Requirements Language">
<t>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<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.</t>
<t/>
</note>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>This memo proposes an initial set of entries for the Performance <name>Introduction</name>
Metrics Registry. It uses terms and definitions from the IPPM <t>This memo defines an initial set of entries for the Performance
literature, primarily <xref target="RFC2330"/>.</t> Metrics Registry.
It uses terms and definitions from the IP Performance Metrics (IPPM)
literature, primarily <xref target="RFC2330" format="default"/>.</t>
<t>Although there are several standard templates for organizing <t>Although there are several standard templates for organizing
specifications of performance metrics (see <xref target="RFC7679"/> for specifications of Performance Metrics (see <xref target="RFC7679" format="
an example of the traditional IPPM template, based to large extent on default"/> for
an example of the traditional IPPM template, based to a large extent on
the Benchmarking Methodology Working Group's traditional template in the Benchmarking Methodology Working Group's traditional template in
<xref target="RFC1242"/>, and see <xref target="RFC6390"/> for a similar <xref target="RFC1242" format="default"/>, and see <xref target="RFC6390" format="default"/> for a similar
template), none of these templates were intended to become the basis for template), none of these templates were intended to become the basis for
the columns of an IETF-wide registry of metrics. While examining aspects the columns of an IETF-wide Registry of metrics. While examining aspects
of metric specifications which need to be registered, it became clear of metric specifications that need to be registered, it became clear
that none of the existing metric templates fully satisfies the that none of the existing metric templates fully satisfy the
particular needs of a registry.</t> particular needs of a Registry.</t>
<t>Therefore, <xref target="RFC8911" format="default"/> defines the
overall format for a Performance Metrics Registry. <xref target="RFC8911"
sectionFormat="of" section="5"/> also gives guidelines for those
requesting registration of a Metric -- that is, the creation of one or mor
e entries in
the Performance Metrics Registry:</t>
<t>Therefore, <xref target="I-D.ietf-ippm-metric-registry"/> defines the <blockquote>In essence, there needs to be
overall format for a Performance Metrics Registry. Section 5 of <xref evidence that (1) a candidate Registered Performance Metric has significan
target="I-D.ietf-ippm-metric-registry"/> also gives guidelines for those t
requesting registration of a Metric, that is the creation of entry(s) in industry interest or has seen deployment and (2) there is agreement that
the Performance Metrics Registry: "In essence, there needs to be
evidence that a candidate Registered Performance Metric has significant
industry interest, or has seen deployment, and there is agreement that
the candidate Registered Performance Metric serves its intended the candidate Registered Performance Metric serves its intended
purpose." The process in <xref target="I-D.ietf-ippm-metric-registry"/> purpose.</blockquote>
also requires that new entries are administered by IANA through
Specification Required policy, which will ensure that the metrics are
tightly defined.</t>
</section>
<section title="Scope"> <t>The process defined in <xref target="RFC8911" format="default"/>
also requires that new entries be administered by IANA through the
Specification Required policy <xref target="RFC8126"/>, which will
ensure that the metrics are tightly defined.</t>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section>
</section>
<section numbered="true" toc="default">
<name>Scope</name>
<t>This document defines a set of initial Performance Metrics Registry <t>This document defines a set of initial Performance Metrics Registry
entries. Most are Active Performance Metrics, which are based on RFCs Entries. Most are Active Performance Metrics, which are based on RFCs
prepared in the IPPM working group of the IETF, according to their prepared in the IPPM Working Group of the IETF, according to their
framework <xref target="RFC2330"/> and its updates.</t> framework <xref target="RFC2330" format="default"/> and its updates.</t>
</section> </section>
<!-- Section 3-->
<section title="Registry Categories and Columns"> <section numbered="true" toc="default">
<t>This memo uses the terminology defined in <xref <name>Registry Categories and Columns</name>
target="I-D.ietf-ippm-metric-registry"/>.</t> <t>This memo uses the terminology defined in <xref target="RFC8911" format
="default"/>.</t>
<t>This section provides the categories and columns of the registry, for <t>This section provides the categories and columns of the Registry, for
easy reference. An entry (row) therefore gives a complete description of easy reference. An entry (row) therefore gives a complete description of
a Registered Metric.</t> a Registered Metric.</t>
<t><figure> <t>Registry Categories and Columns are shown below in this format:</t>
<artwork><![CDATA[Legend: <artwork name="" type="" align="left" alt=""><![CDATA[
Registry Categories and Columns, shown as Category
Category ------------------...
------------------ Column | Column |...
Column | Column | ]]></artwork>
<artwork name="" type="" align="left" alt=""><![CDATA[
Summary Summary
Identifier | Name | URI | Desc. | Reference | Change Controller | Ver | ---------------------------------------------------------------
Identifier | Name | URI | Desc. | Reference | Change | Ver |
| | | | | Controller |
Metric Definition Metric Definition
----------------------------------------- -----------------------------------------
Reference Definition | Fixed Parameters | Reference Definition | Fixed Parameters |
Method of Measurement Method of Measurement
--------------------------------------------------------------------- ---------------------------------------------------------------------
Reference | Packet | Traffic | Sampling | Run-time | Role | Reference | Packet | Traffic | Sampling | Runtime | Role |
Method | Stream | Filter | Distribution | Parameters | | Method | Stream | Filter | Distribution | Parameters | |
| Generation | | Generation |
Output Output
----------------------------------------- -----------------------------------------
Type | Reference | Units | Calibration | Type | Reference | Units | Calibration |
| Definition | | | | Definition | | |
Administrative Information Administrative Information
Status |Requester | Rev | Rev.Date | -------------------------------------
Status |Requester | Rev | Rev. Date |
Comments and Remarks Comments and Remarks
-------------------- --------------------
]]></artwork> ]]></artwork>
</figure></t>
</section> </section>
<!-- Section 4 -->
<section title="UDP Round-trip Latency and Loss Registry Entries"> <section anchor="udp-rt-latency-loss-reg-entries" numbered="true" toc="defau
<t>This section specifies an initial registry entry for the UDP lt">
Round-trip Latency, and another entry for UDP Round-trip Loss Ratio.</t> <name>UDP Round-Trip Latency and Loss Registry Entries</name>
<t>This section specifies an initial Registry Entry for UDP
<t>Note: Each Registry entry only produces a "raw" output or a Round-Trip Latency and another entry for the UDP Round-Trip Loss Ratio.</t
>
<t indent="3">Note: Each Registry Entry only produces a "raw" output or a
statistical summary. To describe both "raw" and one or more statistics statistical summary. To describe both "raw" and one or more statistics
efficiently, the Identifier, Name, and Output Categories can be split efficiently, the Identifier, Name, and Output categories can be split,
and a single section can specify two or more closely-related metrics. and a single section can specify two or more closely related metrics.
For example, this section specifies two Registry entries with many For example, this section specifies two Registry Entries with many
common columns. See Section 7 for an example specifying multiple common columns. See <xref target="udp-poisson-owd-owl-reg"/> for an exampl
Registry entries with many common columns.</t> e specifying multiple
Registry Entries with many common columns.</t>
<t>All column entries beside the ID, Name, Description, and Output <t>All column entries besides the ID, Name, Description, and Output
Reference Method categories are the same, thus this section proposes two Reference Method categories are the same; thus, this section defines two
closely-related registry entries. As a result, IANA is also asked to closely related Registry Entries. As a result, IANA has also
assign a corresponding URL to each Named Metric.</t> assigned a corresponding URL to each of the two Named Metrics.</t>
<!-- 4.1 -->
<section title="Summary"> <section numbered="true" toc="default">
<t>This category includes multiple indexes to the registry entry: the <name>Summary</name>
element ID and metric name.</t> <t>This category includes multiple indexes to the Registry Entries: the
element ID and Metric Name.</t>
<section title="ID (Identifier)"> <!-- 4.1.1 -->
<t>IANA is asked to assign different numeric identifiers to each of <section numbered="true" toc="default">
the two Named Metrics.</t> <name>ID (Identifier)</name>
<t>IANA has allocated the numeric Identifiers 1 and 2 for the two
Named Metric Entries in <xref
target="udp-rt-latency-loss-reg-entries"/>. See <xref target="name412"/> for
mapping to Names.
</t>
</section> </section>
<!-- 4.1.2 -->
<section title="Name"> <section anchor="name412" numbered="true" toc="default">
<t>RTDelay_Active_IP-UDP-Periodic_RFCXXXXsec4_Seconds_95Percentile</t> <name>Name</name>
<dl>
<t>RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_Percent_LossRatio</t> <dt>1:</dt><dd>RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Pe
rcentile</dd>
<dt>2:</dt><dd>RTLoss_Active_IP-UDP-Periodic_RFC8912sec4_Percent_LossR
atio</dd>
</dl>
</section> </section>
<!-- 4.1.3 -->
<section numbered="true" toc="default">
<name>URI</name>
<section title="URI"> <t>URL: <eref target="https://www.iana.org/performance-metrics/RTDelay
<t>URL: https://www.iana.org/ ... &lt;name&gt;</t> _Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile"/></t>
<t>URL: <eref target="https://www.iana.org/performance-metrics/RTLoss_A
ctive_IP-UDP-Periodic_RFC8912sec4_Percent_LossRatio"/></t>
</section> </section>
<!-- 4.1.4 -->
<section title="Description"> <section numbered="true" toc="default">
<t>RTDelay: This metric assesses the delay of a stream of packets <name>Description</name>
exchanged between two hosts (which are the two measurement points), <dl newline="false" spacing="normal">
and the Output is the Round-trip delay for all successfully <dt>RTDelay:</dt>
<dd>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 exchanged packets expressed as the 95th percentile of their
conditional delay distribution.</t> conditional delay distribution.</dd>
<dt>RTLoss:</dt>
<t>RTLoss: This metric assesses the loss ratio of a stream of <dd>This metric assesses the loss ratio of a stream of
packets exchanged between two hosts (which are the two measurement packets exchanged between two hosts (which are the two measurement
points), and the Output is the Round-trip loss ratio for all points). The output is the round-trip loss ratio for all
successfully exchanged packets expressed as a percentage.</t> transmitted packets expressed as a percentage.</dd>
</dl>
</section> </section>
<section title="Change Controller"> <!-- 4.1.5 -->
<section numbered="true" toc="default">
<name>Change Controller</name>
<t>IETF</t> <t>IETF</t>
</section> </section>
<section title="Version (of Registry Format)"> <!-- 4.1.6 -->
<section numbered="true" toc="default">
<name>Version (of Registry Format)</name>
<t>1.0</t> <t>1.0</t>
</section> </section>
</section> </section>
<!-- 4.2 -->
<section title="Metric Definition"> <section numbered="true" toc="default">
<name>Metric Definition</name>
<t>This category includes columns to prompt the entry of all necessary <t>This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference details related to the metric definition, including the RFC reference
and values of input factors, called fixed parameters.</t> and values of input factors, called "Fixed Parameters".</t>
<section title="Reference Definition">
<t>Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
Metric for IPPM", RFC 2681, September 1999.</t>
<t><xref target="RFC2681"/></t> <!-- 4.2.1 -->
<section numbered="true" toc="default">
<name>Reference Definition</name>
<t>For delay:</t>
<t indent="3">Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-tri
p Delay
Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999,
&lt;https://www.rfc-editor.org/info/rfc2681&gt;.
<xref target="RFC2681"/></t>
<t>Section 2.4 of <xref target="RFC2681"/> provides the reference <t indent="3"><xref target="RFC2681" sectionFormat="of" section="2.4"/
definition of the singleton (single value) Round-trip delay metric. > provides the reference
Section 3.4 of <xref target="RFC2681"/> provides the reference definition of the singleton (single value) round-trip delay metric.
<xref target="RFC2681" sectionFormat="of" section="3.4"/>
provides the reference
definition expanded to cover a multi-singleton sample. Note that definition expanded to cover a multi-singleton sample. Note that
terms such as singleton and sample are defined in Section 11 of terms such as "singleton" and "sample" are defined in <xref target="RF
<xref target="RFC2330"/>.</t> C2330" sectionFormat="of" section="11"/>.</t>
<t indent="3">Note that although the definition of round-trip delay be
<t>Note that although the <xref target="RFC2681"/> definition of tween the
"Round-trip-Delay between Src and Dst" is directionally ambiguous in Source (Src) and the Destination (Dst) as provided in
the text, this metric tightens the definition further to recognize <xref target="RFC2681" sectionFormat="of" section="2.4"/>
that the host in the "Src" role will send the first packet to "Dst", is directionally ambiguous in the text, this metric
and ultimately receive the corresponding return packet from "Dst" tightens the definition further to recognize that the host in the
(when neither are lost).</t> Src Role will send the first packet to the host in the Dst Role
and will ultimately receive the corresponding return packet from the
<t>Finally, note that the variable "dT" is used in <xref Dst (when neither is lost).</t>
target="RFC2681"/> to refer to the value of Round-trip delay in <t indent="3">Finally, note that the variable "dT" is used in <xref ta
metric definitions and methods. The variable "dT" has been re-used rget="RFC2681" format="default"/> to refer to the value of round-trip delay in
in other IPPM literature to refer to different quantities, and 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.</t> cannot be used as a global variable name.</t>
<t>For loss:</t>
<t>Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August <t indent="3">Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673,
2012.</t> DOI 10.17487/RFC6673, August 2012,
&lt;https://www.rfc-editor.org/info/rfc6673&gt;.
<t><xref target="RFC6673"/></t> <xref target="RFC6673"/></t>
<t>Both Delay and Loss metrics employ a maximum waiting time for
<t>Both delay and loss metrics employ a maximum waiting time for
received packets, so the count of lost packets to total packets sent received packets, so the count of lost packets to total packets sent
is the basis for the loss ratio calculation as per Section 6.1 of is the basis for the loss ratio calculation as per <xref target="RFC66
<xref target="RFC6673"/>.</t> 73" sectionFormat="of" section="6.1"/>.</t>
</section> </section>
<!-- 4.2.2 -->
<section numbered="true" toc="default">
<name>Fixed Parameters</name>
<dl newline="true" spacing="normal">
<dt>Type-P as defined in <xref target="RFC2330" sectionFormat="of" sec
tion="13"/>:</dt><dd><t/>
<dl newline="true" spacing="normal">
<dt>IPv4 header values:</dt>
<dd><t/>
<dl newline="false" spacing="compact">
<dt>DSCP:</dt><dd>Set to 0</dd>
<dt>TTL:</dt><dd>Set to 255</dd>
<dt>Protocol:</dt><dd>Set to 17 (UDP)</dd>
</dl>
</dd>
</dl>
<dl newline="true" spacing="normal">
<dt>IPv6 header values:</dt>
<dd><t/><dl newline="false" spacing="compact">
<dt>DSCP:</dt><dd>Set to 0</dd>
<dt>Hop Count:</dt><dd>Set to 255</dd>
<dt>Next Header:</dt><dd>Set to 17 (UDP)</dd>
<dt>Flow Label:</dt><dd>Set to 0</dd>
<dt>Extension Headers:</dt><dd>None</dd>
</dl></dd>
</dl>
<section title="Fixed Parameters"> <dl newline="true" spacing="normal">
<t>Type-P as defined in Section 13 of <xref target="RFC2330"/>: <dt>UDP header values:</dt>
<list style="symbols"> <dd><t/><dl newline="false" spacing="compact">
<t>IPv4 header values: <list style="symbols"> <dt>Checksum:</dt><dd>The checksum <bcp14>MUST</bcp14> be calculate
<t>DSCP: set to 0</t> d and the
non-zero checksum included in the header</dd>
<t>TTL: set to 255</t> </dl></dd>
</dl>
<t>Protocol: set to 17 (UDP)</t>
</list></t>
<t>IPv6 header values:<list style="symbols">
<t>DSCP: set to 0</t>
<t>Hop Count: set to 255</t>
<t>Next Header: set to 17 (UDP)</t>
<t>Flow Label: set to zero</t>
<t>Extension Headers: none</t>
</list></t>
<t>UDP header values: <list style="symbols">
<t>Checksum: the checksum MUST be calculated and the
non-zero checksum included in the header</t>
</list></t>
<t>UDP Payload <list style="symbols"> <dl newline="true" spacing="normal">
<t>total of 100 bytes</t> <dt>UDP Payload:</dt>
</list></t> <dd><t/><dl newline="false" spacing="compact">
</list></t> <dt>Total of 100 bytes</dt><dd/>
</dl></dd>
</dl>
</dd>
</dl>
<t>Other measurement parameters:<list style="symbols"> <dl newline="true" spacing="normal">
<t>Tmax: a loss threshold waiting time<list style="symbols"> <dt>Other measurement Parameters:</dt>
<t>3.0, expressed in units of seconds, as a positive value <dd><t/>
of type decimal64 with fraction digits = 4 (see section 9.3 <dl newline="false" spacing="normal">
of <xref target="RFC6020"/>) and with resolution of 0.0001 <dt>Tmax:</dt><dd>A loss threshold waiting time with value 3.0, ex
seconds (0.1 ms), with lossless conversion to/from the pressed in units of seconds, as a positive value
32-bit NTP timestamp as per section 6 of <xref of type decimal64 with fraction digits = 4 (see <xref target="RFC
target="RFC5905"/>.</t> 6020" sectionFormat="of" section="9.3"/>) and with a resolution of 0.0001
</list></t> seconds (0.1 ms), with lossless conversion to/from the
</list></t> 32-bit NTP timestamp as per <xref target="RFC5905" sectionFormat=
"of" section="6"/>.</dd>
</dl>
</dd>
</dl>
</section> </section>
</section> </section>
<!-- 4.3 -->
<section title="Method of Measurement"> <section numbered="true" toc="default">
<name>Method of Measurement</name>
<t>This category includes columns for references to relevant sections <t>This category includes columns for references to relevant sections
of the RFC(s) and any supplemental information needed to ensure an of the RFC(s) and any supplemental information needed to ensure
unambiguous methods for implementations.</t> an unambiguous method for implementations.</t>
<!-- 4.3.1 -->
<section title="Reference Method"> <section numbered="true" toc="default">
<t>The methodology for this metric is defined as <name>Reference Methods</name>
Type-P-Round-trip-Delay-Poisson-Stream in section 2.6 of <xref <t>The methodology for this metric (equivalent to Type-P-Round-trip-
target="RFC2681">RFC 2681</xref> and section 3.6 of <xref Delay and Type-P-Round-trip-Delay-Poisson-Stream) is defined as in
target="RFC2681">RFC 2681</xref> using the Type-P and Tmax defined <xref target="RFC2681" sectionFormat="of" section="2.6"/> (for
under Fixed Parameters. However, the Periodic stream will be singletons) and <xref target="RFC2681" sectionFormat="of" section="3.
generated according to <xref target="RFC3432"/>.</t> 6"/>
(for samples) using the Type-P and Tmax defined in the
Fixed Parameters column. However, the Periodic stream will be
generated according to <xref target="RFC3432" format="default"/>.</t>
<t>The reference method distinguishes between long-delayed packets <t>The reference method distinguishes between long-delayed packets
and lost packets by implementing a maximum waiting time for packet and lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a arrival. Tmax is the waiting time used as the threshold to declare a
packet lost. Lost packets SHALL be designated as having undefined packet lost. Lost packets <bcp14>SHALL</bcp14> be designated as having
delay, and counted for the RTLoss metric.</t> undefined
delay and counted for the RTLoss metric <xref target="RFC6673"/>.</t>
<t>The calculations on the delay (RTT) SHALL be performed on the <t>The calculations on the delay (RTT) <bcp14>SHALL</bcp14> be perform
ed on the
conditional distribution, conditioned on successful packet arrival conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process within Tmax. Also, when all packet delays are stored, the process
which calculates the RTT value MUST enforce the Tmax threshold on that calculates the RTT value <bcp14>MUST</bcp14> enforce the Tmax thr
stored values before calculations. See section 4.1 of <xref eshold on
target="RFC3393"/> for details on the conditional distribution to stored values before calculations. See <xref target="RFC3393" sectionF
exclude undefined values of delay, and Section 5 of <xref ormat="of" section="4.1"/> for details on the conditional distribution to
target="RFC6703"/> for background on this analysis choice.</t> exclude undefined values of delay, and see <xref target="RFC6703" sect
ionFormat="of" section="5"/> for background on this analysis choice.</t>
<t>The reference method requires some way to distinguish between <t>The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving sending times and receiving times for each successfully arriving
packet. Sequence numbers or other send-order identification MUST be packet. Sequence numbers or other send-order identification <bcp14>MUS
T</bcp14> be
retained at the Src or included with each packet to disambiguate retained at the Src or included with each packet to disambiguate
packet reordering if it occurs.</t> packet reordering if it occurs.</t>
<t>If a standard measurement protocol is employed, then the <t>If a standard measurement protocol is employed, then the
measurement process will determine the sequence numbers or measurement process will determine the sequence numbers or
timestamps applied to test packets after the Fixed and Runtime timestamps applied to test packets after the Fixed and Runtime
parameters are passed to that process. The chosen measurement Parameters are passed to that process. The chosen measurement
protocol will dictate the format of sequence numbers and protocol will dictate the format of sequence numbers and
time-stamps, if they are conveyed in the packet payload.</t> timestamps, if they are conveyed in the packet payload.</t>
<t>Refer to <xref target="RFC6673" sectionFormat="of" section="4.4"/>
<t>Refer to Section 4.4 of <xref target="RFC6673"/> for expanded for an expanded
discussion of the instruction to "send a Type-P packet back to the discussion of the instruction to "send a Type-P packet back to the
Src as quickly as possible" in Section 2.6 of <xref Src as quickly as possible" in <xref target="RFC2681" sectionFormat="o
target="RFC2681">RFC 2681</xref>. Section 8 of <xref f" section="2.6"/>. <xref target="RFC6673" sectionFormat="of" section="8"/>
target="RFC6673"/> presents additional requirements which MUST be presents additional requirements that <bcp14>MUST</bcp14> be
included in the method of measurement for this metric.</t> included in the Method of Measurement for this metric.</t>
</section> </section>
<!-- 4.3.2 -->
<section title="Packet Stream Generation"> <section numbered="true" toc="default">
<t>This section gives the details of the packet traffic which is the <name>Packet Stream Generation</name>
basis for measurement. In IPPM metrics, this is called the Stream, <t>This section provides details regarding packet traffic, which is
and can easily be described by providing the list of stream used as the basis for measurement. In IPPM Metrics, this is called
parameters.</t> the "stream"; this stream can easily be described by providing the
list of stream Parameters.</t>
<t>Section 3 of <xref target="RFC3432"/> prescribes the method for <t><xref target="RFC3432" sectionFormat="of" section="3"/> prescribes
generating Periodic streams using associated parameters.</t> the method for
generating Periodic streams using associated Parameters.</t>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="incT">the nominal duration of inter-packet <dt>incT:</dt>
<dd>The nominal duration of the inter-packet
interval, first bit to first bit, with value 0.0200, expressed interval, first bit to first bit, with value 0.0200, expressed
in units of seconds, as a positive value of type decimal64 with in units of seconds, as a positive value of type decimal64 with
fraction digits = 4 (see section 9.3 of <xref fraction digits = 4 (see <xref target="RFC6020" sectionFormat="of"
target="RFC6020"/>) and with resolution of 0.0001 seconds (0.1 section="9.3"/>) and with a resolution of 0.0001 seconds (0.1
ms).</t> ms).</dd>
<dt>dT:</dt>
<t hangText="dT">the duration of the interval for allowed sample <dd>The duration of the interval for allowed sample
start times, with value 1.0, expressed in units of seconds, as a start times, with value 1.0, expressed in units of seconds, as a
positive value of type decimal64 with fraction digits = 4 (see positive value of type decimal64 with fraction digits = 4 (see
section 9.3 of <xref target="RFC6020"/>) and with resolution of <xref target="RFC6020" sectionFormat="of" section="9.3"/>) and wit
0.0001 seconds (0.1 ms).</t> h a resolution of
</list>NOTE: an initiation process with a number of control 0.0001 seconds (0.1 ms).</dd>
</dl>
<t indent="3">Note: An initiation process with a number of control
exchanges resulting in unpredictable start times (within a time exchanges resulting in unpredictable start times (within a time
interval) may be sufficient to avoid synchronization of periodic interval) may be sufficient to avoid synchronization of periodic
streams, and therefore a valid replacement for selecting a start streams and is a valid replacement for selecting a start time
time at random from a fixed interval.</t> at random from a fixed interval.</t>
<t>The T0 Parameter will be reported as a measured Parameter.
<t>The T0 parameter will be reported as a measured parameter.
Parameters incT and dT are Fixed Parameters.</t> Parameters incT and dT are Fixed Parameters.</t>
</section> </section>
<!-- 4.3.3 -->
<section title="Traffic Filtering (observation) Details"> <section numbered="true" toc="default">
<t>NA</t> <name>Traffic Filtering (Observation) Details</name>
<t>N/A</t>
</section> </section>
<!-- 4.3.4 -->
<section title="Sampling Distribution"> <section numbered="true" toc="default">
<t>NA</t> <name>Sampling Distribution</name>
<t>N/A</t>
</section> </section>
<!-- 4.3.5 -->
<section title="Run-time Parameters and Data Format"> <section numbered="true" toc="default">
<t>Run-time Parameters are input factors that must be determined, <name>Runtime Parameters and Data Format</name>
<t>Runtime Parameters are input factors that must be determined,
configured into the measurement system, and reported with the configured into the measurement system, and reported with the
results for the context to be complete.</t> results for the context to be complete.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Src:</dt>
<t hangText="Src">the IP address of the host in the Src Role <dd>The IP address of the host in the Src Role
(format ipv4-address-no-zone value for IPv4, or (format ipv4&nbhy;address-no-zone value for IPv4 or
ipv6-address-no-zone value for IPv6, see Section 4 of <xref ipv6-address-no-zone value for IPv6; see <xref target="RFC6991" se
target="RFC6991"/>)</t> ctionFormat="of" section="4"/>).</dd>
<dt>Dst:</dt>
<t hangText="Dst">the IP address of the host in the Dst Role <dd>The IP address of the host in the Dst Role
(format ipv4-address-no-zone value for IPv4, or (format ipv4&nbhy;address-no-zone value for IPv4 or
ipv6-address-no-zone value for IPv6, see section 4 of <xref ipv6-address-no-zone value for IPv6; see <xref target="RFC6991" se
target="RFC6991"/>)</t> ctionFormat="of" section="4"/>).</dd>
<dt>T0:</dt>
<t hangText="T0">a time, the start of a measurement interval, <dd>A time, the start of a measurement interval
(format "date-and-time" as specified in Section 5.6 of <xref (format "date&nbhy;time" as specified in <xref
target="RFC3339"/>, see also Section 3 of <xref target="RFC3339" sectionFormat="of" section="5.6"/>; see also
target="RFC6991"/>). The UTC Time Zone is required by Section "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
6.1 of <xref target="RFC2330"/>. When T0 is "all-zeros", a start "of" section="3"/>). The
time is unspecified and Tf is to be interpreted as the Duration UTC Time Zone is required by <xref target="RFC2330"
sectionFormat="of" section="6.1"/>. When T0 is "all-zeros", a star
t
time is unspecified and Tf is to be interpreted as the duration
of the measurement interval. The start time is controlled of the measurement interval. The start time is controlled
through other means.</t> through other means.</dd>
<dt>Tf:</dt>
<t hangText="Tf">a time, the end of a measurement interval, <dd>A time, the end of a measurement interval
(format "date-and-time" as specified in Section 5.6 of <xref (format "date&nbhy;time" as specified in <xref target="RFC3339"
target="RFC3339"/>, see also Section 3 of <xref sectionFormat="of" section="5.6"/>; see also
target="RFC6991"/>). The UTC Time Zone is required by Section "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
6.1 of <xref target="RFC2330"/>. When T0 is "all-zeros", a end "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
time date is ignored and Tf is interpreted as the Duration of tionFormat="of" section="6.1"/>. When T0 is "all-zeros", an ending
the measurement interval.</t> time and date is ignored and Tf is interpreted as the duration of
</list></t> the measurement interval.</dd>
</dl>
<t/>
</section> </section>
<!-- 4.3.6 -->
<section title="Roles"> <section numbered="true" toc="default">
<t><list style="hanging"> <name>Roles</name>
<t hangText="Src">launches each packet and waits for return <dl newline="false" spacing="normal">
transmissions from Dst.</t> <dt>Src:</dt>
<dd>Launches each packet and waits for return
<t hangText="Dst">waits for each packet from Src and sends a transmissions from the Dst.</dd>
return packet to Src.</t> <dt>Dst:</dt>
</list></t> <dd>Waits for each packet from the Src and sends a
return packet to the Src.</dd>
</dl>
</section> </section>
</section> </section>
<!-- 4.4 -->
<section title="Output"> <section numbered="true" toc="default">
<t>This category specifies all details of the Output of measurements <name>Output</name>
<t>This category specifies all details of the output of measurements
using the metric.</t> using the metric.</t>
<!-- 4.4.1 -->
<section title="Type"> <section numbered="true" toc="default">
<t>Percentile -- for the conditional distribution of all packets <name>Type</name>
with a valid value of Round-trip delay (undefined delays are <t>Percentile: For the conditional distribution of all packets
excluded), a single value corresponding to the 95th percentile, as with a valid value of round-trip delay (undefined delays are
excluded), this is a single value corresponding to the 95th percentile
, as
follows:</t> follows:</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for d
<t>See section 4.1 of <xref target="RFC3393"/> for details on the etails on the
conditional distribution to exclude undefined values of delay, and conditional distribution to exclude undefined values of delay, and see
Section 5 of <xref target="RFC6703"/> for background on this <xref target="RFC6703" sectionFormat="of" section="5"/> for background
on this
analysis choice.</t> analysis choice.</t>
<t>The percentile = 95, meaning that the reported delay, <t>The percentile = 95, meaning that the reported delay,
"95Percentile", is the smallest value of Round-trip delay for which "95Percentile", is the smallest value of round-trip delay for which
the Empirical Distribution Function (EDF), F(95Percentile) &gt;= 95% the Empirical Distribution Function, EDF(95Percentile), is greater
of the singleton Round-trip delay values in the conditional than or equal to 95% of the singleton round-trip delay values in the co
distribution. See section 11.3 of <xref target="RFC2330"/> for the nditional
distribution. See <xref target="RFC2330" sectionFormat="of" section="1
1.3"/> for the
definition of the percentile statistic using the EDF.</t> definition of the percentile statistic using the EDF.</t>
<t>For LossRatio, the count of lost packets to total packets sent is
<t>LossRatio -- the count of lost packets to total packets sent is the basis for the loss ratio calculation as per <xref target="RFC6673"
the basis for the loss ratio calculation as per Section 6.1 of <xref sectionFormat="of" section="6.1"/>.</t>
target="RFC6673"/>.</t>
</section> </section>
<!-- 4.4.2 -->
<section numbered="true" toc="default">
<name>Reference Definition</name>
<t>For all outputs:</t>
<dl newline="false" spacing="normal">
<dt>T0:</dt>
<dd>The start of a measurement interval (format
"date&nbhy;time" as specified in <xref target="RFC3339"
sectionFormat="of" section="5.6"/>; see also
"date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
"of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
tionFormat="of" section="6.1"/>.</dd>
<dt>Tf:</dt>
<dd>The end of a measurement interval (format
"date&nbhy;time" as specified in <xref target="RFC3339"
sectionFormat="of" section="5.6"/>; see also
"date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
"of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
tionFormat="of" section="6.1"/>.</dd>
<dt>TotalPkts:</dt>
<dd>The count of packets sent by the Src to the
Dst during the measurement interval.</dd>
</dl>
<section title="Reference Definition"> <dl newline="false" spacing="normal">
<t>For all outputs ---</t> <dt>95Percentile:</dt>
<dd>The time value of the result is expressed in units of seconds, a
<t><list style="hanging"> s a positive value of type decimal64 with fraction digits = 9 (see <xref target=
<t hangText="T0">the start of a measurement interval, (format "RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 s
"date-and-time" as specified in Section 5.6 of <xref econds (1.0 ns).</dd>
target="RFC3339"/>, see also Section 3 of <xref </dl>
target="RFC6991"/>). The UTC Time Zone is required by Section
6.1 of <xref target="RFC2330"/>.</t>
<t hangText="Tf">the end of a measurement interval, (format
"date-and-time" as specified in Section 5.6 of <xref
target="RFC3339"/>, see also Section 3 of <xref
target="RFC6991"/>). The UTC Time Zone is required by Section
6.1 of <xref target="RFC2330"/>.</t>
<t hangText="TotalPkts">the count of packets sent by the Src to
Dst during the measurement interval.</t>
</list></t>
<t/>
<t>For</t>
<t>RTDelay_Active_IP-UDP-Periodic_RFCXXXXsec4_Seconds_95Percentile:</t
>
<t><list style="hanging">
<t hangText="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 <xref
target="RFC6020"/>) with resolution of 0.000000001 seconds (1.0
ns).</t>
</list></t>
<t>For</t>
<t>RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_Percent_LossRatio:</t>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="Percentile">The numeric value of the result is <dt>Percent_LossRatio:</dt>
expressed in units of lost packets to total packets times 100%, <dd>The numeric value of the result is expressed in units of lost pa
as a positive value of type decimal64 with fraction digits = 9 ckets to total packets times 100%, as a positive value of type decimal64 with fr
(see section 9.3 of <xref target="RFC6020"/>) with resolution of action digits = 9 (see <xref target="RFC6020" sectionFormat="of" section="9.3"/>
0.0000000001.</t> ) with a resolution of
</list></t> 0.0000000001.</dd>
</dl>
</section> </section>
<!-- 4.4.3 -->
<section title="Metric Units"> <section numbered="true" toc="default">
<t>The 95th Percentile of Round-trip Delay is expressed in <name>Metric Units</name>
<t>The 95th percentile of round-trip delay is expressed in
seconds.</t> seconds.</t>
<t>The round-trip loss ratio is expressed as a percentage of lost
<t>The Round-trip Loss Ratio is expressed as a percentage of lost
packets to total packets sent.</t> packets to total packets sent.</t>
</section> </section>
<!-- 4.4.4 -->
<section title="Calibration"> <section numbered="true" toc="default">
<t>Section 3.7.3 of <xref target="RFC7679"/> provides a means to <name>Calibration</name>
<t><xref target="RFC7679" sectionFormat="of" section="3.7.3"/> provide
s a means to
quantify the systematic and random errors of a time measurement. quantify the systematic and random errors of a time measurement.
In-situ calibration could be enabled with an internal loopback at Calibration in-situ could be enabled with an internal loopback at
the Source host that includes as much of the measurement system as the Source host that includes as much of the measurement system as
possible, performs address manipulation as needed, and provides some possible, performs address manipulation as needed, and provides some
form of isolation (e.g., deterministic delay) to avoid send-receive form of isolation (e.g., deterministic delay) to avoid send-receive
interface contention. Some portion of the random and systematic interface contention. Some portion of the random and systematic
error can be characterized this way.</t> error can be characterized in this way.</t>
<t>When a measurement controller requests a calibration measurement, <t>When a measurement controller requests a calibration measurement,
the loopback is applied and the result is output in the same format the loopback is applied and the result is output in the same format
as a normal measurement with additional indication that it is a as a normal measurement, with an additional indication that it is a
calibration result.</t> calibration result.</t>
<t>Both internal loopback calibration and clock synchronization can <t>Both internal loopback calibration and clock synchronization can
be used to estimate the available accuracy of the Output Metric be used to estimate the available accuracy of the Output Metric
Units. For example, repeated loopback delay measurements will reveal Units. For example, repeated loopback delay measurements will reveal
the portion of the Output result resolution which is the result of the portion of the output result resolution that is the result of
system noise, and thus inaccurate.</t> system noise and is thus inaccurate.</t>
</section> </section>
</section> </section>
<!-- 4.5 -->
<section title="Administrative items"> <section numbered="true" toc="default">
<t/> <name>Administrative Items</name>
<!-- 4.5.1 -->
<section title="Status"> <section numbered="true" toc="default">
<name>Status</name>
<t>Current</t> <t>Current</t>
</section> </section>
<!-- 4.5.2 -->
<section title="Requester"> <section numbered="true" toc="default">
<t>This RFC number</t> <name>Requester</name>
<t>RFC 8912</t>
</section> </section>
<!-- 4.5.3 -->
<section title="Revision"> <section numbered="true" toc="default">
<name>Revision</name>
<t>1.0</t> <t>1.0</t>
</section> </section>
<!-- 4.5.4 -->
<section title="Revision Date"> <section numbered="true" toc="default">
<t>YYYY-MM-DD</t> <name>Revision Date</name>
<t>2021-11-17</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Comments and Remarks"> <name>Comments and Remarks</name>
<t>None.</t> <t>None</t>
</section> </section>
</section> </section>
<!-- Section 5 -->
<section title="Packet Delay Variation Registry Entry"> <section anchor="packet_delay_variation" numbered="true" toc="default">
<t>This section gives an initial registry entry for a Packet Delay <name>Packet Delay Variation Registry Entry</name>
Variation metric.</t> <t>This section gives an initial Registry Entry for a Packet Delay
Variation (PDV) metric.</t>
<section title="Summary"> <section numbered="true" toc="default">
<t>This category includes multiple indexes to the registry entries, <name>Summary</name>
the element ID and metric name.</t> <t>This category includes multiple indexes to the Registry Entry:
the element ID and Metric Name.</t>
<section title="ID (Identifier)"> <section numbered="true" toc="default">
<t>&lt;insert numeric identifier, an integer&gt;</t> <name>ID (Identifier)</name>
<t>IANA has allocated the numeric Identifier 3 for the
Named Metric Entry in <xref target="packet_delay_variation"/>. See <xref
target="name512"/> for mapping to Name.</t>
</section> </section>
<section title="Name"> <section anchor="name512" numbered="true" toc="default">
<t>OWPDV_Active_IP-UDP-Periodic_RFCXXXXsec5_Seconds_95Percentile</t> <name>Name</name>
<dl>
<dt>3:</dt><dd>OWPDV_Active_IP-UDP-Periodic_RFC8912sec5_Seconds_95Per
centile</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="URI"> <name>URI</name>
<t>URL: https://www.iana.org/ ... &lt;name&gt;</t> <t>URL: <eref target="https://www.iana.org/performance-metrics/OWPDV_A
ctive_IP-UDP-Periodic_RFC8912sec5_Seconds_95Percentile"/></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Description"> <name>Description</name>
<t>An assessment of packet delay variation with respect to the <t>This metric assesses packet delay variation with respect to the
minimum delay observed on the periodic stream, and the Output is minimum delay observed on the periodic stream. The output is
expressed as the 95th percentile of the packet delay variation expressed as the 95th percentile of the one-way packet delay variation
distribution.</t> distribution.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Change Controller"> <name>Change Controller</name>
<t>IETF</t> <t>IETF</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Version (of Registry Format)"> <name>Version (of Registry Format)</name>
<t>1.0</t> <t>1.0</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Metric Definition"> <name>Metric Definition</name>
<t>This category includes columns to prompt the entry of all necessary <t>This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference details related to the metric definition, including the RFC reference
and values of input factors, called fixed parameters.</t> and values of input factors, called "Fixed Parameters".</t>
<section numbered="true" toc="default">
<section title="Reference Definition"> <name>Reference Definition</name>
<t>Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for <t>Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for
IP Performance Metrics", RFC 2330, May 1998. <xref IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998,
target="RFC2330"/></t> &lt;https://www.rfc-editor.org/info/rfc2330&gt;. <xref
target="RFC2330"/></t>
<t>Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric <t>Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric
for IP Performance Metrics (IPPM)", RFC 3393, November 2002. <xref for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393,
target="RFC3393"/></t> November 2002,
&lt;https://www.rfc-editor.org/info/rfc3393&gt;. <xref
target="RFC3393"/></t>
<t>Morton, A. and B. Claise, "Packet Delay Variation Applicability <t>Morton, A. and B. Claise, "Packet Delay Variation Applicability
Statement", RFC 5481, March 2009. <xref target="RFC5481"/></t> Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009,
&lt;https://www.rfc-editor.org/info/rfc5481&gt;. <xref
<t>Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time target="RFC5481"/></t>
Protocol Version 4: Protocol and Algorithms Specification", RFC <t>Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network
5905, June 2010.<xref target="RFC5905"> </xref></t> Time Protocol Version 4: Protocol and Algorithms Specification", RFC
5905, DOI 10.17487/RFC5905, June 2010,
<t>See sections 2.4 and 3.4 of <xref target="RFC3393"/>. Singleton &lt;https://www.rfc-editor.org/info/rfc5905&gt;.
delay differences measured are referred to by the variable name <xref target="RFC5905"/></t>
<t>See Sections&nbsp;<xref target="RFC3393" section="2.4"
sectionFormat="bare"/> and <xref target="RFC3393" section="3.4"
sectionFormat="bare"/> of <xref target="RFC3393"/>. The measured singleton
delay differences are referred to by the variable name
"ddT" (applicable to all forms of delay variation). However, this "ddT" (applicable to all forms of delay variation). However, this
metric entry specifies the PDV form defined in section 4.2 of <xref Metric Entry specifies the PDV form defined in <xref target="RFC5481"
target="RFC5481"/>, where the singleton PDV for packet i is referred sectionFormat="of" section="4.2"/>, where the singleton PDV for packet i is refe
rred
to by the variable name "PDV(i)".</t> to by the variable name "PDV(i)".</t>
</section> </section>
<section numbered="true" toc="default">
<name>Fixed Parameters</name>
<dl newline="true" spacing="normal">
<dt>IPv4 header values:</dt>
<dd><t/>
<dl newline="false" spacing="compact">
<dt>DSCP:</dt><dd>Set to 0</dd>
<dt>TTL:</dt><dd>Set to 255</dd>
<dt>Protocol:</dt><dd>Set to 17 (UDP)</dd>
</dl>
</dd>
<section title="Fixed Parameters"> <dt>IPv6 header values:</dt>
<t><list style="symbols"> <dd><t/>
<t>IPv4 header values: <list style="symbols"> <dl newline="false" spacing="compact">
<t>DSCP: set to 0</t> <dt>DSCP:</dt><dd>Set to 0</dd>
<dt>Hop Count:</dt><dd>Set to 255</dd>
<t>TTL: set to 255</t> <dt>Next Header:</dt><dd>Set to 17 (UDP)</dd>
<dt>Flow Label:</dt><dd>Set to 0</dd>
<t>Protocol: set to 17 (UDP)</t> <dt>Extension Headers:</dt><dd>None</dd>
</list></t> </dl>
</dd>
<t>IPv6 header values:<list style="symbols">
<t>DSCP: set to 0</t>
<t>Hop Count: set to 255</t>
<t>Next Header: set to 17 (UDP)</t>
<t>Flow Label: set to zero</t>
<t>Extension Headers: none</t>
</list></t>
<t>UDP header values: <list style="symbols">
<t>Checksum: the checksum MUST be calculated and the
non-zero checksum included in the header</t>
</list></t>
<t>UDP Payload <list style="symbols"> <dt>UDP header values:</dt>
<t>total of 200 bytes</t> <dd><t/>
</list></t> <dl newline="false" spacing="compact">
</list></t> <dt>Checksum:</dt><dd>The checksum <bcp14>MUST</bcp14> be calcul
ated and the
non-zero checksum included in the header</dd>
</dl>
</dd>
<t>Other measurement parameters:</t> <dt>UDP Payload:</dt>
<dd><t/><dl newline="false" spacing="compact">
<dt>Total of 200 bytes</dt><dd/>
</dl>
</dd>
</dl>
<t><list style="hanging"> <dl newline="true" spacing="normal">
<t hangText="Tmax:">a loss threshold waiting time with value <dt>Other measurement Parameters:</dt>
<dd><t/>
<dl newline="false" spacing="normal">
<dt>Tmax:</dt>
<dd>A loss threshold waiting time with value
3.0, expressed in units of seconds, as a positive value of type 3.0, expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 4 (see section 9.3 of <xref decimal64 with fraction digits = 4 (see <xref target="RFC6020" sec
target="RFC6020"/>) and with resolution of 0.0001 seconds (0.1 tionFormat="of" section="9.3"/>) and with a resolution of 0.0001 seconds (0.1
ms), with lossless conversion to/from the 32-bit NTP timestamp ms), with lossless conversion to/from the 32-bit NTP timestamp
as per section 6 of <xref target="RFC5905"/>.</t> as per <xref target="RFC5905" sectionFormat="of" section="6"/>.</d
d>
<t hangText="F">a selection function unambiguously defining the <dt>F:</dt>
packets from the stream selected for the metric. See section 4.2 <dd>A selection function unambiguously defining the
of <xref target="RFC5481"/> for the PDV form.</t> packets from the stream selected for the metric. See <xref target=
</list>See the Packet Stream generation category for two "RFC5481" sectionFormat="of" section="4.2"/> for the PDV form.</dd>
</dl>
</dd>
</dl>
<t>See the Packet Stream Generation section for two
additional Fixed Parameters.</t> additional Fixed Parameters.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Method of Measurement"> <name>Method of Measurement</name>
<t>This category includes columns for references to relevant sections <t>This category includes columns for references to relevant sections
of the RFC(s) and any supplemental information needed to ensure an of the RFC(s) and any supplemental information needed to ensure
unambiguous methods for implementations.</t> an unambiguous method for implementations.</t>
<section numbered="true" toc="default">
<section title="Reference Method"> <name>Reference Methods</name>
<t>See section 2.6 and 3.6 of <xref target="RFC3393"/> for general <t>See Sections&nbsp;<xref target="RFC3393" section="2.6"
singleton element calculations. This metric entry requires sectionFormat="bare"/> and <xref target="RFC3393" section="3.6"
implementation of the PDV form defined in section 4.2 of <xref sectionFormat="bare"/> of <xref target="RFC3393"/> for general
target="RFC5481"/>. Also see measurement considerations in section 8 singleton element calculations. This Metric Entry requires
of <xref target="RFC5481"/>.</t> implementation of the PDV form defined in <xref target="RFC5481" secti
onFormat="of" section="4.2"/>. Also see measurement considerations in <xref targ
et="RFC5481" sectionFormat="of" section="8"/>.</t>
<t>The reference method distinguishes between long-delayed packets <t>The reference method distinguishes between long-delayed packets
and lost packets by implementing a maximum waiting time for packet and lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a arrival. Tmax is the waiting time used as the threshold to declare a
packet lost. Lost packets SHALL be designated as having undefined packet lost. Lost packets <bcp14>SHALL</bcp14> be designated as having undefined
delay.</t> delay.</t>
<t>The calculations on the one-way delay <bcp14>SHALL</bcp14> be perfo
<t>The calculations on the one-way delay SHALL be performed on the rmed on the
conditional distribution, conditioned on successful packet arrival conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process within Tmax. Also, when all packet delays are stored, the process
which calculates the one-way delay value MUST enforce the Tmax that calculates the one-way delay value <bcp14>MUST</bcp14> enforce th
threshold on stored values before calculations. See section 4.1 of e Tmax
<xref target="RFC3393"/> for details on the conditional distribution threshold on stored values before calculations. See <xref target="RFC3
to exclude undefined values of delay, and Section 5 of <xref 393" sectionFormat="of" section="4.1"/> for details on the conditional distribut
target="RFC6703"/> for background on this analysis choice.</t> ion
to exclude undefined values of delay, and see <xref target="RFC6703" s
ectionFormat="of" section="5"/> for background on this analysis choice.</t>
<t>The reference method requires some way to distinguish between <t>The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving sending times and receiving times for each successfully arriving
packet. Sequence numbers or other send-order identification MUST be packet. Sequence numbers or other send-order identification <bcp14>MUS
T</bcp14> be
retained at the Src or included with each packet to disambiguate retained at the Src or included with each packet to disambiguate
packet reordering if it occurs.</t> packet reordering if it occurs.</t>
<t>If a standard measurement protocol is employed, then the <t>If a standard measurement protocol is employed, then the
measurement process will determine the sequence numbers or measurement process will determine the sequence numbers or
timestamps applied to test packets after the Fixed and Runtime timestamps applied to test packets after the Fixed and Runtime
parameters are passed to that process. The chosen measurement Parameters are passed to that process. The chosen measurement
protocol will dictate the format of sequence numbers and protocol will dictate the format of sequence numbers and
time-stamps, if they are conveyed in the packet payload.</t> timestamps, if they are conveyed in the packet payload.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Packet Stream Generation"> <name>Packet Stream Generation</name>
<t>This section gives the details of the packet traffic which is the <t>This section provides details regarding packet traffic, which is
basis for measurement. In IPPM metrics, this is called the Stream, used as the
and can easily be described by providing the list of stream basis for measurement. In IPPM Metrics, this is called the "stream";
parameters.</t> this stream can easily be described by providing the list of stream
Parameters.</t>
<t>Section 3 of <xref target="RFC3432"/> prescribes the method for <t><xref target="RFC3432" sectionFormat="of" section="3"/> prescribes
generating Periodic streams using associated parameters.</t> the method for
generating Periodic streams using associated Parameters.</t>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="incT">the nominal duration of inter-packet <dt>incT:</dt>
<dd>The nominal duration of the inter-packet
interval, first bit to first bit, with value 0.0200, expressed interval, first bit to first bit, with value 0.0200, expressed
in units of seconds, as a positive value of type decimal64 with in units of seconds, as a positive value of type decimal64 with
fraction digits = 4 (see section 9.3 of <xref fraction digits = 4 (see <xref target="RFC6020" sectionFormat="of"
target="RFC6020"/>) and with resolution of 0.0001 seconds (0.1 section="9.3"/>) and with a resolution of 0.0001 seconds (0.1
ms).</t> ms).</dd>
<dt>dT:</dt>
<t hangText="dT">the duration of the interval for allowed sample <dd>The duration of the interval for allowed sample
start times, with value 1.0, expressed in units of seconds, as a start times, with value 1.0, expressed in units of seconds, as a
positive value of type decimal64 with fraction digits = 4 (see positive value of type decimal64 with fraction digits = 4 (see
section 9.3 of <xref target="RFC6020"/>) and with resolution of <xref target="RFC6020" sectionFormat="of" section="9.3"/>) and wit
0.0001 seconds (0.1 ms).</t> h a resolution of
</list>NOTE: an initiation process with a number of control 0.0001 seconds (0.1 ms).</dd>
</dl>
<t indent="3">Note: An initiation process with a number of control
exchanges resulting in unpredictable start times (within a time exchanges resulting in unpredictable start times (within a time
interval) may be sufficient to avoid synchronization of periodic interval) may be sufficient to avoid synchronization of periodic
streams, and therefore a valid replacement for selecting a start streams and is a valid replacement for selecting a start
time at random from a fixed interval.</t> time at random from a fixed interval.</t>
<t>The T0 Parameter will be reported as a measured Parameter.
<t>The T0 parameter will be reported as a measured parameter.
Parameters incT and dT are Fixed Parameters.</t> Parameters incT and dT are Fixed Parameters.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Traffic Filtering (observation) Details"> <name>Traffic Filtering (Observation) Details</name>
<t>NA</t> <t>N/A</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Sampling Distribution"> <name>Sampling Distribution</name>
<t>NA</t> <t>N/A</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Run-time Parameters and Data Format"> <name>Runtime Parameters and Data Format</name>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="Src">the IP address of the host in the Src Role <dt>Src:</dt>
(format ipv4-address-no-zone value for IPv4, or <dd>The IP address of the host in the Src Role
ipv6-address-no-zone value for IPv6, see Section 4 of <xref (format ipv4&nbhy;address-no-zone value for IPv4 or
target="RFC6991"/>)</t> ipv6-address-no-zone value for IPv6; see <xref target="RFC6991" se
ctionFormat="of" section="4"/>).</dd>
<t hangText="Dst">the IP address of the host in the Dst Role <dt>Dst:</dt>
(format ipv4-address-no-zone value for IPv4, or <dd>The IP address of the host in the Dst Role
ipv6-address-no-zone value for IPv6, see section 4 of <xref (format ipv4&nbhy;address-no-zone value for IPv4 or
target="RFC6991"/>)</t> ipv6-address-no-zone value for IPv6; see <xref target="RFC6991" se
ctionFormat="of" section="4"/>).</dd>
<t hangText="T0">a time, the start of a measurement interval, <dt>T0:</dt>
(format "date-and-time" as specified in Section 5.6 of <xref <dd>A time, the start of a measurement interval
target="RFC3339"/>, see also Section 3 of <xref (format "date&nbhy;time" as specified in <xref target="RFC3339"
target="RFC6991"/>). The UTC Time Zone is required by Section sectionFormat="of" section="5.6"/>; see also
6.1 of <xref target="RFC2330"/>. When T0 is "all-zeros", a start "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
time is unspecified and Tf is to be interpreted as the Duration "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
tionFormat="of" section="6.1"/>. 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 of the measurement interval. The start time is controlled
through other means.</t> through other means.</dd>
<dt>Tf:</dt>
<t hangText="Tf">a time, the end of a measurement interval, <dd>A time, the end of a measurement interval
(format "date-and-time" as specified in Section 5.6 of <xref (format "date&nbhy;time" as specified in <xref target="RFC3339"
target="RFC3339"/>, see also Section 3 of <xref sectionFormat="of" section="5.6"/>; see also
target="RFC6991"/>). The UTC Time Zone is required by Section "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
6.1 of <xref target="RFC2330"/>. When T0 is "all-zeros", a end "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
time date is ignored and Tf is interpreted as the Duration of tionFormat="of" section="6.1"/>. When T0 is "all-zeros", an ending
the measurement interval.</t> time and date is ignored and Tf is interpreted as the duration of
</list></t> the measurement interval.</dd>
</dl>
<t/>
</section> </section>
<section numbered="true" toc="default">
<section title="Roles"> <name>Roles</name>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="Src">launches each packet and waits for return <dt>Src:</dt>
transmissions from Dst.</t> <dd>Launches each packet and waits for return
transmissions from the Dst.</dd>
<t hangText="Dst">waits for each packet from Src and sends a <dt>Dst:</dt>
return packet to Src.</t> <dd>Waits for each packet from the Src and sends a return packet to
</list></t> the Src (when required by the test protocol).</dd>
</dl>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Output"> <name>Output</name>
<t>This category specifies all details of the Output of measurements <t>This category specifies all details of the output of measurements
using the metric.</t> using the metric.</t>
<section numbered="true" toc="default">
<section title="Type"> <name>Type</name>
<t>Percentile -- for the conditional distribution of all packets <t>Percentile: For the conditional distribution of all packets
with a valid value of one-way delay (undefined delays are excluded), with a valid value of one-way delay (undefined delays are excluded),
a single value corresponding to the 95th percentile, as follows:</t> this is a single value corresponding to the 95th percentile, as follow
s:</t>
<t>See section 4.1 of <xref target="RFC3393"/> for details on the <t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for d
conditional distribution to exclude undefined values of delay, and etails on the
Section 5 of <xref target="RFC6703"/> for background on this conditional distribution to exclude undefined values of delay, and see
<xref target="RFC6703" sectionFormat="of" section="5"/> for background
on this
analysis choice.</t> analysis choice.</t>
<t>The percentile = 95, meaning that the reported delay, <t>The percentile = 95, meaning that the reported delay,
"95Percentile", is the smallest value of one-way PDV for which the "95Percentile", is the smallest value of one-way PDV for which the
Empirical Distribution Function (EDF), F(95Percentile) &gt;= 95% of Empirical Distribution Function, EDF(95Percentile), is greater than
or equal to 95% of
the singleton one-way PDV values in the conditional distribution. the singleton one-way PDV values in the conditional distribution.
See section 11.3 of <xref target="RFC2330"/> for the definition of See <xref target="RFC2330" sectionFormat="of" section="11.3"/> for the definition of
the percentile statistic using the EDF.</t> the percentile statistic using the EDF.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Reference Definition"> <name>Reference Definition</name>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="T0">the start of a measurement interval, (format <dt>T0:</dt>
"date-and-time" as specified in Section 5.6 of <xref <dd>The start of a measurement interval (format
target="RFC3339"/>, see also Section 3 of <xref "date&nbhy;time" as specified in <xref target="RFC3339"
target="RFC6991"/>). The UTC Time Zone is required by Section sectionFormat="of" section="5.6"/>; see also
6.1 of <xref target="RFC2330"/>.</t> "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
"of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
<t hangText="Tf">the end of a measurement interval, (format tionFormat="of" section="6.1"/>.</dd>
"date-and-time" as specified in Section 5.6 of <xref <dt>Tf:</dt>
target="RFC3339"/>, see also Section 3 of <xref <dd>The end of a measurement interval (format
target="RFC6991"/>). The UTC Time Zone is required by Section "date&nbhy;time" as specified in <xref target="RFC3339"
6.1 of <xref target="RFC2330"/>.</t> sectionFormat="of" section="5.6"/>; see also
</list></t> "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
"of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
<t><list style="hanging"> tionFormat="of" section="6.1"/>.</dd>
<t hangText="95Percentile">The time value of the result is </dl>
<dl newline="false" spacing="normal">
<dt>95Percentile:</dt>
<dd>The time value of the result is
expressed in units of seconds, as a positive value of type expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 9 (see section 9.3 of <xref decimal64 with fraction digits =&nbsp;9 (see <xref target="RFC6020
target="RFC6020"/>) with resolution of 0.000000001 seconds (1.0 " sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds (
1.0
ns), and with lossless conversion to/from the 64-bit NTP ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" section
target="RFC5905">RFC</xref></t> ="6"/>.</dd>
</list></t> </dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Metric Units"> <name>Metric Units</name>
<t>The 95th Percentile of one-way PDV is expressed in seconds.</t> <t>The 95th percentile of one-way PDV is expressed in seconds.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Calibration"> <name>Calibration</name>
<t>Section 3.7.3 of <xref target="RFC7679"/> provides a means to <t><xref target="RFC7679" sectionFormat="of" section="3.7.3"/> provide
s a means to
quantify the systematic and random errors of a time measurement. quantify the systematic and random errors of a time measurement.
In-situ calibration could be enabled with an internal loopback that Calibration in-situ could be enabled with an internal loopback that
includes as much of the measurement system as possible, performs includes as much of the measurement system as possible, performs
address manipulation as needed, and provides some form of isolation address manipulation as needed, and provides some form of isolation
(e.g., deterministic delay) to avoid send-receive interface (e.g., deterministic delay) to avoid send-receive interface
contention. Some portion of the random and systematic error can be contention. Some portion of the random and systematic error can be
characterized this way.</t> characterized in this way.</t>
<t>For one-way delay measurements, the error calibration must <t>For one-way delay measurements, the error calibration must
include an assessment of the internal clock synchronization with its include an assessment of the internal clock synchronization with its
external reference (this internal clock is supplying timestamps for external reference (this internal clock is supplying timestamps for
measurement). In practice, the time offsets <xref target="RFC5905"/> measurement). In practice, the time offsets <xref target="RFC5905" for
of clocks at both the source and destination are needed to estimate mat="default"/>
of clocks at both the Source and Destination are needed to estimate
the systematic error due to imperfect clock synchronization (the the systematic error due to imperfect clock synchronization (the
time offsets are smoothed, thus the random variation is not usually time offsets are smoothed; thus, the random variation is not usually
represented in the results).<list style="hanging"> represented in the results).</t>
<t hangText="time_offset">The time value of the result is <dl newline="false" spacing="normal">
<dt>time_offset:</dt>
<dd>The time value of the result is
expressed in units of seconds, as a signed value of type expressed in units of seconds, as a signed value of type
decimal64 with fraction digits = 9 (see section 9.3 of <xref decimal64 with fraction digits&nbsp;=&nbsp;9 (see <xref target="RF
target="RFC6020"/>) with resolution of 0.000000001 seconds (1.0 C6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seco
nds (1.0
ns), and with lossless conversion to/from the 64-bit NTP ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" section
target="RFC5905">RFC</xref></t> ="6"/>.</dd>
</list></t> </dl>
<t>When a measurement controller requests a calibration measurement, <t>When a measurement controller requests a calibration measurement,
the loopback is applied and the result is output in the same format the loopback is applied and the result is output in the same format
as a normal measurement with additional indication that it is a as a normal measurement, with an additional indication that it is a
calibration result. In any measurement, the measurement function calibration result. In any measurement, the measurement function
SHOULD report its current estimate of time offset <xref <bcp14>SHOULD</bcp14> report its current estimate of the time offset <
target="RFC5905"/> as an indicator of the degree of xref target="RFC5905" format="default"/> as an indicator of the degree of
synchronization.</t> synchronization.</t>
<t>Both internal loopback calibration and clock synchronization can <t>Both internal loopback calibration and clock synchronization can
be used to estimate the available accuracy of the Output Metric be used to estimate the available accuracy of the Output Metric
Units. For example, repeated loopback delay measurements will reveal Units. For example, repeated loopback delay measurements will reveal
the portion of the Output result resolution which is the result of the portion of the output result resolution that is the result of
system noise, and thus inaccurate.</t> system noise and is thus inaccurate.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Administrative items"> <name>Administrative Items</name>
<t/> <section numbered="true" toc="default">
<name>Status</name>
<section title="Status">
<t>Current</t> <t>Current</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Requester"> <name>Requester</name>
<t>This RFC number</t> <t>RFC 8912</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Revision"> <name>Revision</name>
<t>1.0</t> <t>1.0</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Revision Date"> <name>Revision Date</name>
<t>YYYY-MM-DD</t> <t>2021-11-17</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Comments and Remarks"> <name>Comments and Remarks</name>
<t>Lost packets represent a challenge for delay variation metrics. See <t>Lost packets represent a challenge for delay variation metrics. See
section 4.1 of <xref target="RFC3393"/> and the delay variation <xref target="RFC3393" sectionFormat="of" section="4.1"/> and the delay
applicability statement<xref target="RFC5481"/> for extensive analysis variation
and comparison of PDV and an alternate metric, IPDV.</t> applicability statement <xref target="RFC5481" format="default"/> for ex
tensive analysis
and comparison of PDV and an alternate metric, IPDV (Inter-Packet
Delay Variation).</t>
</section> </section>
</section> </section>
<!-- Section 6 -->
<section title="DNS Response Latency and Loss Registry Entries"> <section anchor="dns_response_latency_and_loss" numbered="true" toc="default
<t>This section gives initial registry entries for DNS Response Latency ">
<name>DNS Response Latency and Loss Registry Entries</name>
<t>This section gives initial Registry Entries for DNS Response Latency
and Loss from a network user's perspective, for a specific named and Loss from a network user's perspective, for a specific named
resource. The metric can be measured repeatedly using different names. resource. The metric can be measured repeatedly for different named resour
<xref target="RFC2681">RFC 2681</xref> defines a Round-trip delay ces.
<xref target="RFC2681" format="default"></xref> defines a round-trip delay
metric. We build on that metric by specifying several of the input metric. We build on that metric by specifying several of the input
parameters to precisely define two metrics for measuring DNS latency and Parameters to precisely define two metrics for measuring DNS latency and
loss.</t> loss.</t>
<t>Note to IANA: Each Registry "Name" below specifies a single registry <t>All column entries besides the ID, Name, Description, and Output
entry, whose output format varies in accordance with the name.</t> Reference Method categories are the same; thus, this section defines two
closely related Registry Entries. As a result, IANA has
<t>All column entries beside the ID, Name, Description, and Output assigned corresponding URLs to each of the two Named Metrics.</t>
Reference Method categories are the same, thus this section proposes two <section numbered="true" toc="default">
closely-related registry entries. As a result, IANA is also asked to <name>Summary</name>
assign corresponding URLs to each Named Metric.</t> <t>This category includes multiple indexes to the Registry Entries:
the element ID and Metric Name.</t>
<section title="Summary"> <section numbered="true" toc="default">
<t>This category includes multiple indexes to the registry entries, <name>ID (Identifier)</name>
the element ID and metric name.</t> <t>IANA has allocated the numeric Identifiers 4 and 5 for the two
Named Metric Entries in <xref
<section title="ID (Identifier)"> target="dns_response_latency_and_loss"/>. See
<t>&lt;insert numeric identifier, an integer&gt;</t> <xref target="name612"/> for mapping to Names.</t>
<t>IANA is asked to assign different numeric identifiers to each of
the two Named Metrics.</t>
</section> </section>
<!-- 6.1.2 -->
<section title="Name"> <section anchor="name612" numbered="true" toc="default">
<t>RTDNS_Active_IP-UDP-Poisson_RFCXXXXsec6_Seconds_Raw</t> <name>Name</name>
<dl>
<t>RLDNS_Active_IP-UDP-Poisson_RFCXXXXsec6_Logical_Raw</t> <dt>4:</dt><dd>RTDNS_Active_IP-UDP-Poisson_RFC8912sec6_Seconds_Raw</d
d>
<dt>5:</dt><dd>RLDNS_Active_IP-UDP-Poisson_RFC8912sec6_Logical_Raw</
dd>
</dl>
</section> </section>
<!-- 6.1.3 -->
<section title="URI"> <section numbered="true" toc="default">
<t>URL: https://www.iana.org/ ... &lt;name&gt;</t> <name>URI</name>
<t>URL: <eref target="https://www.iana.org/performance-metrics/RTDNS_A
ctive_IP-UDP-Poisson_RFC8912sec6_Seconds_Raw"/></t>
<t>URL: <eref
target="https://www.iana.org/performance-metrics/RLDNS_Active_IP-UDP-Poisson_RFC
8912sec6_Logical_Raw"/></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Description"> <name>Description</name>
<t>This is a metric for DNS Response performance from a network <t>This is a metric for DNS Response performance from a network
user's perspective, for a specific named resource. The metric can be user's perspective, for a specific named resource. The metric can be
measured repeatedly using different resource names.</t> measured repeatedly using different resource names.</t>
<dl newline="false" spacing="normal">
<t>RTDNS: This metric assesses the response time, the interval from <dt>RTDNS:</dt><dd>This metric assesses the response time, the interva
the query transmission to the response.</t> l from
the query transmission to the response.</dd>
<t>RLDNS: This metric indicates that the response was deemed lost. <dt>RLDNS:</dt><dd>This metric indicates that the response was deemed
lost.
In other words, the response time exceeded the maximum waiting In other words, the response time exceeded the maximum waiting
time.</t> time.</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Change Controller"> <name>Change Controller</name>
<t>IETF</t> <t>IETF</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Version (of Registry Format)"> <name>Version (of Registry Format)</name>
<t>1.0</t> <t>1.0</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Metric Definition"> <name>Metric Definition</name>
<t>This category includes columns to prompt the entry of all necessary <t>This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference details related to the metric definition, including the RFC reference
and values of input factors, called fixed parameters.</t> and values of input factors, called "Fixed Parameters".</t>
<section title="Reference Definition">
<t>Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. (and updates)</t>
<t><xref target="RFC1035"/></t>
<t>Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
Metric for IPPM", RFC 2681, September 1999.</t>
<t><xref target="RFC2681"/></t>
<t>Section 2.4 of <xref target="RFC2681"/> provides the reference <!-- 6.2.1 -->
definition of the singleton (single value) Round-trip delay metric. <section numbered="true" toc="default">
Section 3.4 of <xref target="RFC2681"/> provides the reference <name>Reference Definition</name>
<t>For Delay:</t>
<t indent="3">Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November
1987, &lt;https://www.rfc-editor.org/info/rfc1035&gt; (and updates).
<xref target="RFC1035"/></t>
<t indent="3">Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-tri
p Delay
Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999,
&lt;https://www.rfc-editor.org/info/rfc2681&gt;.
<xref target="RFC2681"/></t>
<t indent="3"><xref target="RFC2681" sectionFormat="of" section="2.4"/
> provides the reference
definition of the singleton (single value) round-trip delay metric.
<xref target="RFC2681" sectionFormat="of" section="3.4"/> provides the
reference
definition expanded to cover a multi-singleton sample. Note that definition expanded to cover a multi-singleton sample. Note that
terms such as singleton and sample are defined in Section 11 of terms such as "singleton" and "sample" are defined in <xref target="RF
<xref target="RFC2330"/>.</t> C2330" sectionFormat="of" section="11"/>.</t>
<t indent="3">For DNS Response Latency, the entities in <xref target="
<t>For DNS Response Latency, the entities in <xref RFC1035" format="default"/> must be mapped to <xref target="RFC2681" format="def
target="RFC1035"/> must be mapped to <xref target="RFC2681"/>. The ault"/>. The
Local Host with its User Program and Resolver take the role of Local Host with its User Program and Resolver take the Role of
"Src", and the Foreign Name Server takes the role of "Dst".</t> "Src", and the Foreign Name Server takes the Role of "Dst".</t>
<t indent="3">Note that although the definition of round-trip delay be
<t>Note that although the <xref target="RFC2681"/> definition of tween the
"Round-trip-Delay between Src and Dst at T" is directionally Source (Src) and the Destination (Dst) at T as provided in
ambiguous in the text, this metric tightens the definition further <xref target="RFC2681" sectionFormat="of" section="2.4"/>
to recognize that the host in the "Src" role will send the first is directionally ambiguous in the text, this metric
packet to "Dst", and ultimately receive the corresponding return tightens the definition further to recognize that the host in the
packet from "Dst" (when neither are lost).</t> Src Role will send the first packet to the host in the Dst Role
and will ultimately receive the corresponding return packet from the
<t>Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August Dst (when neither is lost).</t>
2012.</t>
<t><xref target="RFC6673"/></t> <t>For Loss:</t>
<t indent="3">Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673,
DOI 10.17487/RFC6673, August 2012,
&lt;https://www.rfc-editor.org/info/rfc6673&gt;.
<xref target="RFC6673"/></t>
<t indent="3">For DNS Response Loss, the entities in <xref target="RFC1
035"/> must be mapped
to <xref target="RFC6673"/>. The Local Host with its User Program and R
esolver
take the Role of "Src", and the Foreign Name Server takes the Role
of "Dst".</t>
<t>Both response time and loss metrics employ a maximum waiting time <t indent="3">Both response time and Loss metrics employ a maximum wai ting time
for received responses, so the count of lost packets to total for received responses, so the count of lost packets to total
packets sent is the basis for the loss determination as per Section packets sent is the basis for the loss determination as per <xref targ
4.3 of <xref target="RFC6673"/>.</t> et="RFC6673" sectionFormat="of" section="4.3"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Fixed Parameters</name>
<dl newline="true" spacing="normal">
<dt>Type-P as defined in <xref target="RFC2330" sectionFormat="of" sec
tion="13"/>:</dt><dd><t/>
<dl newline="true" spacing="normal">
<dt>IPv4 header values:</dt>
<dd><t/>
<dl newline="false" spacing="compact">
<dt>DSCP:</dt><dd>Set to 0</dd>
<dt>TTL:</dt><dd>Set to 255</dd>
<dt>Protocol:</dt><dd>Set to 17 (UDP)</dd>
</dl>
</dd>
</dl>
<dl newline="true" spacing="normal">
<dt>IPv6 header values:</dt>
<dd><t/>
<dl newline="false" spacing="compact">
<dt>DSCP:</dt><dd>Set to 0</dd>
<dt>Hop Count:</dt><dd>Set to 255</dd>
<dt>Next Header:</dt><dd>Set to 17 (UDP)</dd>
<dt>Flow Label:</dt><dd>Set to 0</dd>
<dt>Extension Headers:</dt><dd> None</dd>
</dl>
</dd>
</dl>
<section title="Fixed Parameters"> <dl newline="true" spacing="normal">
<t>Type-P as defined in Section 13 of <xref target="RFC2330"/>: <dt>UDP header values:</dt>
<list style="symbols"> <dd><t/>
<t>IPv4 header values: <list style="symbols"> <dl newline="false" spacing="compact">
<t>DSCP: set to 0</t> <dt>Source port:</dt><dd>53</dd>
<dt>Destination port:</dt><dd>53</dd>
<t>TTL set to 255</t> <dt>Checksum:</dt><dd>The checksum <bcp14>MUST</bcp14> be calculate
d and the
<t>Protocol: set to 17 (UDP)</t> non-zero checksum included in the header</dd>
</list></t> </dl>
</dd>
<t>IPv6 header values:<list style="symbols"> </dl>
<t>DSCP: set to 0</t>
<t>Hop Count: set to 255</t>
<t>Next Header: set to 17 (UDP)</t>
<t>Flow Label: set to zero</t>
<t>Extension Headers: none</t>
</list></t>
<t>UDP header values: <list style="symbols">
<t>Source port: 53</t>
<t>Destination port: 53</t>
<t>Checksum: the checksum must be calculated and the
non-zero checksum included in the header</t>
</list></t>
<t>Payload: The payload contains a DNS message as defined in
<xref target="RFC1035">RFC 1035</xref> with the following
values: <list style="symbols">
<t>The DNS header section contains: <list style="symbols">
<t>Identification (see the Run-time column)</t>
<t>QR: set to 0 (Query)</t>
<t>OPCODE: set to 0 (standard query)</t>
<t>AA: not set</t>
<t>TC: not set</t>
<t>RD: set to one (recursion desired)</t>
<t>RA: not set</t>
<t>RCODE: not set</t>
<t>QDCOUNT: set to one (only one entry)</t>
<t>ANCOUNT: not set</t>
<t>NSCOUNT: not set</t>
<t>ARCOUNT: not set</t> <dl newline="true" spacing="normal">
</list></t> <dt>Payload:</dt>
<dd><t>The payload contains a DNS message as defined in
<xref target="RFC1035" format="default"></xref> with the following
values:</t>
<dl newline="true" spacing="normal">
<dt>The DNS header section contains:</dt>
<dd><t/>
<dl newline="false" spacing="compact">
<dt>Identification (see the Runtime column)</dt><dd/>
<dt>QR:</dt><dd>Set to 0 (Query)</dd>
<dt>OPCODE:</dt><dd>Set to 0 (standard query)</dd>
<dt>AA:</dt><dd>Not set</dd>
<dt>TC:</dt><dd>Not set</dd>
<dt>RD:</dt><dd>Set to 1 (recursion desired)</dd>
<dt>RA:</dt><dd>Not set</dd>
<dt>RCODE:</dt><dd>Not set</dd>
<dt>QDCOUNT:</dt><dd>Set to 1 (only one entry)</dd>
<dt>ANCOUNT:</dt><dd>Not set</dd>
<dt>NSCOUNT:</dt><dd>Not set</dd>
<dt>ARCOUNT:</dt><dd>Not set</dd>
</dl>
</dd>
</dl>
<t>The Question section contains: <list style="symbols"> <dl newline="true" spacing="normal">
<t>QNAME: the Fully Qualified Domain Name (FQDN) <dt>The Question section contains:</dt>
provided as input for the test, see the Run-time <dd><t/>
column</t> <dl newline="false" spacing="normal">
<dt>QNAME:</dt><dd>The Fully Qualified Domain Name (FQDN)
provided as input for the test; see the Runtime
column</dd>
<dt>QTYPE:</dt><dd>The query type provided as input for the test;
see the Runtime column</dd>
<dt>QCLASS:</dt><dd>Set to 1 for IN</dd>
</dl>
</dd>
</dl>
<t>QTYPE: the query type provided as input for the test, <dl newline="false" spacing="normal">
see the Run-time column</t> <dt>The other sections do not contain any Resource
Records (RRs).</dt><dd/>
</dl>
</dd>
</dl>
</dd>
</dl>
<t>QCLASS: set to 1 for IN</t> <dl newline="true" spacing="normal">
</list></t> <dt>Other measurement Parameters:</dt>
<dd><t/>
<t>The other sections do not contain any Resource <dl newline="false" spacing="normal">
Records.</t> <dt>Tmax:</dt><dd>A loss threshold waiting time (and to help disam
</list></t> biguate
</list></t> queries). The value is 5.0, expressed in units of seconds, as a po
sitive value
of type decimal64 with fraction digits = 4 (see <xref target="RFC6
020" sectionFormat="of" section="9.3"/>) and with a resolution of 0.0001
seconds (0.1 ms), with lossless conversion to/from the
32-bit NTP timestamp as per <xref target="RFC5905"
sectionFormat="of" section="6"/>.</dd>
</dl>
</dd>
</dl>
<t>Other measurement parameters:<list style="symbols"> <dl newline="false" spacing="normal">
<t>Tmax: a loss threshold waiting time (and to help disambiguate <dt>Observation:</dt><dd>Reply packets will contain a DNS Response and
queries)<list style="symbols"> may contain RRs.</dd>
<t>5.0, expressed in units of seconds, as a positive value </dl>
of type decimal64 with fraction digits = 4 (see section 9.3
of <xref target="RFC6020"/>) and with resolution of 0.0001
seconds (0.1 ms), with lossless conversion to/from the
32-bit NTP timestamp as per section 6 of <xref
target="RFC5905"/>.</t>
</list></t>
</list>Observation: reply packets will contain a DNS response and
may contain RRs.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Method of Measurement"> <name>Method of Measurement</name>
<t>This category includes columns for references to relevant sections <t>This category includes columns for references to relevant sections
of the RFC(s) and any supplemental information needed to ensure an of the RFC(s) and any supplemental information needed to ensure
unambiguous methods for implementations.</t> an unambiguous method for implementations.</t>
<section numbered="true" toc="default">
<section title="Reference Method"> <name>Reference Methods</name>
<t>The methodology for this metric is defined as <t>The methodology for this metric (equivalent to
Type-P-Round-trip-Delay-Poisson-Stream in section 2.6 of <xref Type-P-Round-trip-Delay-Poisson-Stream) is defined as in <xref target=
target="RFC2681">RFC 2681</xref> and section 3.6 of <xref "RFC2681"
target="RFC2681">RFC 2681</xref> using the Type-P and Timeout sectionFormat="of" section="2.6"/> (for singletons) and <xref target="
defined under Fixed Parameters.</t> RFC2681"
sectionFormat="of" section="3.6"/> (for samples) using the Type-P and
Timeout
defined in the Fixed Parameters column.</t>
<t>The reference method distinguishes between long-delayed packets <t>The reference method distinguishes between long-delayed packets
and lost packets by implementing a maximum waiting time for packet and lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a arrival. Tmax is the waiting time used as the threshold to declare a
response packet lost. Lost packets SHALL be designated as having response packet lost. Lost packets <bcp14>SHALL</bcp14> be designated as having
undefined delay and counted for the RLDNS metric.</t> undefined delay and counted for the RLDNS metric.</t>
<t>The calculations on the delay (RTT) <bcp14>SHALL</bcp14> be perform
<t>The calculations on the delay (RTT) SHALL be performed on the ed on the
conditional distribution, conditioned on successful packet arrival conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process within Tmax. Also, when all packet delays are stored, the process
which calculates the RTT value MUST enforce the Tmax threshold on that calculates the RTT value <bcp14>MUST</bcp14> enforce the Tmax thr
stored values before calculations. See section 4.1 of <xref eshold on
target="RFC3393"/> for details on the conditional distribution to stored values before calculations. See <xref target="RFC3393" sectionF
exclude undefined values of delay, and Section 5 of <xref ormat="of" section="4.1"/> for details on the conditional distribution to
target="RFC6703"/> for background on this analysis choice.</t> exclude undefined values of delay, and see <xref target="RFC6703" sect
ionFormat="of" section="5"/> for background on this analysis choice.</t>
<t>The reference method requires some way to distinguish between <t>The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving sending times and receiving times for each successfully arriving
reply.</t> reply.</t>
<t>DNS messages bearing queries provide for random ID Numbers in the
<t>DNS Messages bearing Queries provide for random ID Numbers in the
Identification header field, so more than one query may be launched Identification header field, so more than one query may be launched
while a previous request is outstanding when the ID Number is used. while a previous request is outstanding when the ID Number is used.
Therefore, the ID Number MUST be retained at the Src and included Therefore, the ID Number <bcp14>MUST</bcp14> be retained at the Src an d included
with each response packet to disambiguate packet reordering if it with each response packet to disambiguate packet reordering if it
occurs.</t> occurs.</t>
<t>If a DNS Response does not arrive within Tmax, the response time
<t>IF a DNS response does not arrive within Tmax, the response time RTDNS is undefined, and RLDNS = 1. The Message ID <bcp14>SHALL</bcp14>
RTDNS is undefined, and RLDNS = 1. The Message ID SHALL be used to be used to
disambiguate the successive queries that are otherwise disambiguate the successive queries that are otherwise
identical.</t> identical.</t>
<t>Since the ID Number field is only 16 bits in length, it places a <t>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 limit on the number of simultaneous outstanding DNS queries during a
stress test from a single Src address.</t> stress test from a single Src address.</t>
<t>Refer to <xref target="RFC6673" sectionFormat="of" section="4.4"/>
<t>Refer to Section 4.4 of <xref target="RFC6673"/> for expanded for an expanded
discussion of the instruction to "send a Type-P packet back to the discussion of the instruction to "send a Type-P packet back to the
Src as quickly as possible" in Section 2.6 of <xref Src as quickly as possible" in <xref target="RFC2681" sectionFormat="o
target="RFC2681">RFC 2681</xref>. However, the DNS Server is f" section="2.6"/>. However, the DNS server is
expected to perform all required functions to prepare and send a expected to perform all required functions to prepare and send a
response, so the response time will include processing time and response, so the response time will include processing time and
network delay. Section 8 of <xref target="RFC6673"/> presents network delay. <xref target="RFC6673" sectionFormat="of" section="8"/>
additional requirements which SHALL be included in the method of presents
measurement for this metric.</t> additional requirements that <bcp14>SHALL</bcp14> be included in the M
ethod of
<t>In addition to operations described in <xref target="RFC2681"/>, Measurement for this metric.</t>
the Src MUST parse the DNS headers of the reply and prepare the <t>In addition to operations described in <xref target="RFC2681" forma
t="default"/>,
the Src <bcp14>MUST</bcp14> parse the DNS headers of the reply and pre
pare the
query response information for subsequent reporting as a measured query response information for subsequent reporting as a measured
result, along with the Round-Trip Delay.</t> result, along with the round-trip delay.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Packet Stream Generation"> <name>Packet Stream Generation</name>
<t>This section gives the details of the packet traffic which is the <t>This section provides details regarding packet traffic, which is
basis for measurement. In IPPM metrics, this is called the Stream, used as the
and can easily be described by providing the list of stream basis for measurement. In IPPM Metrics, this is called the "stream";
parameters.</t> this stream can easily be described by providing the list of stream
Parameters.</t>
<t>Section 11.1.3 of <xref target="RFC2330">RFC 2681</xref> provides <t><xref target="RFC2330" sectionFormat="of" section="11.1.3"/>
provides
three methods to generate Poisson sampling intervals. The reciprocal three methods to generate Poisson sampling intervals. The reciprocal
of lambda is the average packet spacing, thus the Run-time Parameter of lambda is the average packet spacing; thus, the Runtime Parameter
is Reciprocal_lambda = 1/lambda, in seconds.</t> is Reciprocal_lambda&nbsp;=&nbsp;1&wj;/lambda, in seconds.</t>
<t>Method 3 <bcp14>SHALL</bcp14> be used. Where given a start time (Ru
<t>Method 3 is used, where given a start time (Run-time Parameter), ntime Parameter),
the subsequent send times are all computed prior to measurement by the subsequent send times are all computed prior to measurement by
computing the pseudo-random distribution of inter-packet send times, computing the pseudorandom distribution of inter-packet send times
(truncating the distribution as specified in the Run-time (truncating the distribution as specified in the Parameter Trunc),
Parameters), and the Src sends each packet at the computed and the Src sends each packet at the computed times.</t>
times.</t>
<t>Note that Trunc is the upper limit on inter-packet times in the <t>Note that Trunc is the upper limit on inter-packet times in the
Poisson distribution. A random value greater than Trunc is set equal Poisson distribution. A random value greater than Trunc is set equal
to Trunc instead.</t> to Trunc instead.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Traffic Filtering (observation) Details"> <name>Traffic Filtering (Observation) Details</name>
<t>NA</t> <t>N/A</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Sampling Distribution"> <name>Sampling Distribution</name>
<t>NA</t> <t>N/A</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Run-time Parameters and Data Format"> <name>Runtime Parameters and Data Format</name>
<t>Run-time Parameters are input factors that must be determined, <t>Runtime Parameters are input factors that must be determined,
configured into the measurement system, and reported with the configured into the measurement system, and reported with the
results for the context to be complete.</t> results for the context to be complete.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Src:</dt>
<t hangText="Src">the IP address of the host in the Src Role <dd>The IP address of the host in the Src Role
(format ipv4-address-no-zone value for IPv4, or (format ipv4&nbhy;address-no-zone value for IPv4 or
ipv6-address-no-zone value for IPv6, see Section 4 of <xref ipv6-address-no-zone value for IPv6; see <xref target="RFC6991" se
target="RFC6991"/>)</t> ctionFormat="of" section="4"/>).</dd>
<dt>Dst:</dt>
<t hangText="Dst">the IP address of the host in the Dst Role <dd>The IP address of the host in the Dst Role
(format ipv4-address-no-zone value for IPv4, or (format ipv4&nbhy;address-no-zone value for IPv4 or
ipv6-address-no-zone value for IPv6, see section 4 of <xref ipv6-address-no-zone value for IPv6; see <xref target="RFC6991" se
target="RFC6991"/>)</t> ctionFormat="of" section="4"/>).</dd>
<dt>T0:</dt>
<t hangText="T0">a time, the start of a measurement interval, <dd>A time, the start of a measurement interval
(format "date-and-time" as specified in Section 5.6 of <xref (format "date&nbhy;time" as specified in <xref target="RFC3339"
target="RFC3339"/>, see also Section 3 of <xref sectionFormat="of" section="5.6"/>; see also
target="RFC6991"/>). The UTC Time Zone is required by Section "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
6.1 of <xref target="RFC2330"/>. When T0 is "all-zeros", a start "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
time is unspecified and Tf is to be interpreted as the Duration tionFormat="of" section="6.1"/>. 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 of the measurement interval. The start time is controlled
through other means.</t> through other means.</dd>
<dt>Tf:</dt>
<t hangText="Tf">a time, the end of a measurement interval, <dd>A time, the end of a measurement interval
(format "date-and-time" as specified in Section 5.6 of <xref (format "date&nbhy;time" as specified in <xref target="RFC3339"
target="RFC3339"/>, see also Section 3 of <xref sectionFormat="of" section="5.6"/>; see also
target="RFC6991"/>). The UTC Time Zone is required by Section "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
6.1 of <xref target="RFC2330"/>. When T0 is "all-zeros", a end "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
time date is ignored and Tf is interpreted as the Duration of tionFormat="of" section="6.1"/>. When T0 is "all-zeros", an ending
the measurement interval.</t> time and date is ignored and Tf is interpreted as the duration of
the measurement interval.</dd>
<t hangText="Reciprocal_lambda">average packet interval for <dt>Reciprocal_lambda:</dt>
Poisson Streams expressed in units of seconds, as a positive <dd>Average packet interval for
value of type decimal64 with fraction digits = 4 (see section Poisson streams, expressed in units of seconds, as a positive
9.3 of <xref target="RFC6020"/>) with resolution of 0.0001 value of type decimal64 with fraction digits = 4 (see <xref target
="RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.0001
seconds (0.1 ms), and with lossless conversion to/from the seconds (0.1 ms), and with lossless conversion to/from the
32-bit NTP timestamp as per section 6 of <xref 32-bit NTP timestamp as per <xref target="RFC5905" sectionFormat="
target="RFC5905"/>.</t> of" section="6"/>.</dd>
<dt>Trunc:</dt>
<t hangText="Trunc">Upper limit on Poisson distribution <dd>Upper limit on Poisson distribution,
expressed in units of seconds, as a positive value of type expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 4 (see section 9.3 of <xref decimal64 with fraction digits = 4 (see <xref target="RFC6020" sec
target="RFC6020"/>) with resolution of 0.0001 seconds (0.1 ms), tionFormat="of" section="9.3"/>) with a resolution of 0.0001 seconds (0.1 ms),
and with lossless conversion to/from the 32-bit NTP timestamp as and with lossless conversion to/from the 32-bit NTP timestamp as
per section 6 of <xref target="RFC5905"/> (values above this per <xref target="RFC5905" sectionFormat="of" section="6"/> (value
limit will be clipped and set to the limit value).</t> s above this
limit will be clipped and set to the limit value).</dd>
<t hangText="ID">The 16-bit identifier assigned by the program <dt>ID:</dt>
that generates the query, and which must vary in successive <dd>The 16-bit Identifier assigned by the program
queries (a list of IDs is needed), see Section 4.1.1 of <xref that generates the query. The ID value must vary in successive
target="RFC1035"/>. This identifier is copied into the queries (a list of IDs is needed); see <xref target="RFC1035" sect
ionFormat="of" section="4.1.1"/>. This Identifier is copied into the
corresponding reply and can be used by the requester (Src) to corresponding reply and can be used by the requester (Src) to
match-up replies to outstanding queries.</t> match replies with any outstanding queries.</dd>
<dt>QNAME:</dt>
<t hangText="QNAME">The domain name of the Query, formatted as <dd>The domain name of the query, formatted as
specified in section 4 of <xref target="RFC6991"/>.</t> specified in <xref target="RFC6991" sectionFormat="of" section="4"
/>.</dd>
<t hangText="QTYPE">The Query Type, which will correspond to the <dt>QTYPE:</dt>
<dd>The query type, which will correspond to the
IP address family of the query (decimal 1 for IPv4 or 28 for IP address family of the query (decimal 1 for IPv4 or 28 for
IPv6, formatted as a uint16, as per section 9.2 of <xref IPv6), formatted as a uint16, as per <xref target="RFC6020" sectio
target="RFC6020"/>.</t> nFormat="of" section="9.2"/>.</dd>
</list></t> </dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Roles"> <name>Roles</name>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="Src">launches each packet and waits for return <dt>Src:</dt>
transmissions from Dst.</t> <dd>Launches each packet and waits for return
transmissions from the Dst.</dd>
<t hangText="Dst">waits for each packet from Src and sends a <dt>Dst:</dt>
return packet to Src.</t> <dd>Waits for each packet from the Src and sends a
</list></t> return packet to the Src.</dd>
</dl>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Output"> <name>Output</name>
<t>This category specifies all details of the Output of measurements <t>This category specifies all details of the output of measurements
using the metric.</t> using the metric.</t>
<section numbered="true" toc="default">
<section title="Type"> <name>Type</name>
<t>Raw -- for each DNS Query packet sent, sets of values as defined <t>Raw: For each DNS query packet sent, sets of values as defined
in the next column, including the status of the response, only in the next column, including the status of the response, only
assigning delay values to successful query-response pairs.</t> assigning delay values to successful query-response pairs.</t>
</section> </section>
<section title="Reference Definition"> <!-- 6.4.2 -->
<section numbered="true" toc="default">
<name>Reference Definition</name>
<t>For all outputs:</t> <t>For all outputs:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>T:</dt>
<t hangText="T">the time the DNS Query was sent during the <dd>The time the DNS query was sent during the
measurement interval, (format "date-and-time" as specified in measurement interval (format "date&nbhy;time" as specified in
Section 5.6 of <xref target="RFC3339"/>, see also Section 3 of <xref target="RFC3339" sectionFormat="of" section="5.6"/>; see
<xref target="RFC6991"/>). The UTC Time Zone is required by also "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFo
Section 6.1 of <xref target="RFC2330"/>.</t> rmat="of" section="3"/>). The UTC Time Zone is required by
<xref target="RFC2330" sectionFormat="of" section="6.1"/>.</dd>
<t hangText="dT">The time value of the round-trip delay to <dt>dT:</dt>
receive the DNS response, expressed in units of seconds, as a <dd>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 positive value of type decimal64 with fraction digits = 9 (see
section 9.3 of <xref target="RFC6020"/>) with resolution of <xref target="RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of
0.000000001 seconds (1.0 ns), and with lossless conversion 0.000000001 seconds (1.0 ns), and with lossless conversion
to/from the 64-bit NTP timestamp as per section 6 of <xref to/from the 64-bit NTP timestamp as per <xref target="RFC5905" sec
target="RFC5905">RFC</xref>. This value is undefined when the tionFormat="of" section="6"/>. This value is undefined when the
response packet is not received at Src within waiting time Tmax response packet is not received at the Src within a waiting time
seconds.</t> of Tmax&nbsp;seconds.</dd>
<dt>RCODE:</dt>
<t hangText="Rcode">The value of the Rcode field in the DNS <dd>The value of the RCODE field in the DNS
response header, expressed as a uint64 as specified in section Response header, expressed as a uint64 as specified in <xref targe
9.2 of <xref target="RFC6020"/>. Non-zero values convey errors t="RFC6020" sectionFormat="of" section="9.2"/>. Non-zero values convey errors
in the response, and such replies must be analyzed separately in the response, and such replies must be analyzed separately
from successful requests.</t> from successful requests.</dd>
</list></t> <dt>Logical:</dt><dd>The numeric value of the result is expressed a
s a Logical
value, where 1 = Lost and 0 = Received, as a positive value of
type uint8 (represents integer values between 0 and 255, inclusivel
y
(see <xref target="RFC6020" sectionFormat="of" section="9.2"/>). No
te that for queries with outcome 1 = Lost,
dT and RCODE will be set to the maximum for decimal64 and uint64, r
espectively.</dd>
</dl>
</section> </section>
<section title="Metric Units"> <!-- 6.4.3 -->
<t>RTDNS: Round-trip Delay, dT, is expressed in seconds.</t> <section numbered="true" toc="default">
<name>Metric Units</name>
<t>RTLDNS: the Logical value, where 1 = Lost and 0 = Received.</t> <dl newline="false" spacing="normal">
<dt>RTDNS:</dt><dd>Round-trip delay, dT, is expressed in seconds.</dd>
<dt>RLDNS:</dt><dd>The Logical value, where 1 = Lost and 0 =
Received.</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Calibration"> <name>Calibration</name>
<t>Section 3.7.3 of <xref target="RFC7679"/> provides a means to <t><xref target="RFC7679" sectionFormat="of" section="3.7.3"/> provide
s a means to
quantify the systematic and random errors of a time measurement. quantify the systematic and random errors of a time measurement.
In-situ calibration could be enabled with an internal loopback at Calibration in-situ could be enabled with an internal loopback at
the Source host that includes as much of the measurement system as the Source host that includes as much of the measurement system as
possible, performs address and payload manipulation as needed, and possible, performs address and payload manipulation as needed, and
provides some form of isolation (e.g., deterministic delay) to avoid provides some form of isolation (e.g., deterministic delay) to avoid
send-receive interface contention. Some portion of the random and send-receive interface contention. Some portion of the random and
systematic error can be characterized this way.</t> systematic error can be characterized in this way.</t>
<t>When a measurement controller requests a calibration measurement, <t>When a measurement controller requests a calibration measurement,
the loopback is applied and the result is output in the same format the loopback is applied and the result is output in the same format
as a normal measurement with additional indication that it is a as a normal measurement, with an additional indication that it is a
calibration result.</t> calibration result.</t>
<t>Both internal loopback calibration and clock synchronization can <t>Both internal loopback calibration and clock synchronization can
be used to estimate the available accuracy of the Output Metric be used to estimate the available accuracy of the Output Metric
Units. For example, repeated loopback delay measurements will reveal Units. For example, repeated loopback delay measurements will reveal
the portion of the Output result resolution which is the result of the portion of the output result resolution that is the result of
system noise, and thus inaccurate.</t> system noise and is thus inaccurate.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Administrative items"> <name>Administrative Items</name>
<t/> <section numbered="true" toc="default">
<name>Status</name>
<section title="Status">
<t>Current</t> <t>Current</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Requester"> <name>Requester</name>
<t>This RFC number</t> <t>RFC 8912</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Revision"> <name>Revision</name>
<t>1.0</t> <t>1.0</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Revision Date"> <name>Revision Date</name>
<t>YYYY-MM-DD</t> <t>2021-11-17</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Comments and Remarks"> <name>Comments and Remarks</name>
<t>None</t> <t>None</t>
</section> </section>
</section> </section>
<!-- Section 7 -->
<section anchor="udp-poisson-owd-owl-reg" numbered="true" toc="default">
<name>UDP Poisson One-Way Delay and Loss Registry Entries</name>
<t>This section specifies five initial Registry Entries for UDP
Poisson One-Way Delay and one entry for UDP Poisson One-Way Loss.</t>
<section title="UDP Poisson One-way Delay and Loss Registry Entries"> <t>All column entries besides the ID, Name, Description, and Output
<t>This section specifies five initial registry entries for the UDP Reference Method categories are the same; thus, this section defines six
Poisson One-way Delay, and one for UDP Poisson One-way Loss.</t> closely related Registry Entries. As a result, IANA has
assigned corresponding URLs to each of the Named Metrics.</t>
<t>IANA Note: Registry "Name" below specifies multiple registry entries, <section numbered="true" toc="default">
whose output format varies according to the &lt;statistic&gt; element of <!-- section 7 -->
the name that specifies one form of statistical summary. There is an <name>Summary</name>
additional metric name for the Loss metric.</t> <t>This category includes multiple indexes to the Registry Entries:
the element ID and Metric Name.</t>
<t>All column entries beside the ID, Name, Description, and Output <section numbered="true" toc="default">
Reference Method categories are the same, thus this section proposes six <!-- section 7.1.1 -->
closely-related registry entries. As a result, IANA is also asked to <name>ID (Identifier)</name>
assign corresponding URLs to each Named Metric.</t> <t>IANA has allocated the numeric Identifiers 6-11 for the six
Named Metric Entries in <xref target="udp-poisson-owd-owl-reg"/>. See <xref
<section title="Summary"> target="name712"/> for mapping to Names.</t>
<t>This category includes multiple indexes to the registry entries,
the element ID and metric name.</t>
<section title="ID (Identifier)">
<t>IANA is asked to assign different numeric identifiers to each of
the six Metrics.</t>
</section> </section>
<!-- section 7.1.2 -->
<section anchor="name712" numbered="true" toc="default">
<name>Name</name>
<dl spacing="normal" newline="false" indent="5">
<dt>6:</dt><dd>OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8
912sec7_Seconds_95Percentile</dd>
<dt>7:</dt><dd>OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seco
nds_Mean</dd>
<dt>8:</dt><dd>OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_
Seconds_Min</dd>
<dt>9:</dt><dd>OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_
Seconds_Max</dd>
<dt>10:</dt><dd>OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7
_Seconds_StdDev</dd>
<dt>11:</dt><dd>OWLoss_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_
Percent_LossRatio</dd>
</dl>
<section title="Name">
<t>OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsec7_Seconds_&lt;s
tatistic&gt;</t>
<t>where &lt;statistic&gt; is one of:</t>
<t><list style="symbols">
<t>95Percentile</t>
<t>Mean</t>
<t>Min</t>
<t>Max</t>
<t>StdDev</t>
</list></t>
<t>OWLoss_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsec7_Percent_LossRa
tio</t>
</section> </section>
<!-- section 7.1.3 -->
<section title="URI"> <section numbered="true" toc="default">
<t>URL: https://www.iana.org/ ... &lt;name&gt;</t> <name>URI</name>
<t>URL: <eref target="https://www.iana.org/performance-metrics/OWDelay
_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_95Percentile" /></t>
<t>URL: <eref target="https://www.iana.org/performance-metrics/OWDelay_
Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Mean"/></t>
<t>URL: <eref target="https://www.iana.org/performance-metrics/OWDelay_
Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Min"/></t>
<t>URL: <eref target="https://www.iana.org/performance-metrics/OWDelay_
Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Max"/></t>
<t>URL: <eref target="https://www.iana.org/performance-metrics/OWDelay_
Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_StdDev"/></t>
<t>URL: <eref target="https://www.iana.org/performance-metrics/OWLoss_
Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Percent_LossRatio"/></t>
</section> </section>
<section title="Description"> <!-- section 7.1.4 -->
<t>OWDelay: This metric assesses the delay of a stream of packets <section numbered="true" toc="default">
exchanged between two hosts (or measurement points), and reports the <name>Description</name>
&lt;statistic&gt; One-way delay for all successfully exchanged <dl newline="false" spacing="normal">
<dt>OWDelay:</dt><dd><t>This metric assesses the delay of a stream of
packets
exchanged between two hosts (or measurement points) and reports the
&lt;statistic&gt; of one-way delay for all successfully exchanged
packets based on their conditional delay distribution.</t> packets based on their conditional delay distribution.</t>
<t>where &lt;statistic&gt; is one of:</t> <t>where &lt;statistic&gt; is one of:</t>
<ul spacing="normal">
<li>95Percentile</li>
<li>Mean</li>
<li>Min</li>
<li>Max</li>
<li>StdDev</li>
</ul>
</dd>
<dt>OWLoss:</dt><dd>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.</dd>
</dl>
</section>
<t><list style="symbols"> <!-- section 7.1.5 -->
<t>95Percentile</t> <section numbered="true" toc="default">
<name>Change Controller</name>
<t>Mean</t> <t>IETF</t>
</section>
<t>Min</t>
<t>Max</t>
<t>StdDev</t>
</list></t>
<t>OWLoss: This metric assesses the loss ratio of a stream of <!-- section 7.1.6 -->
packets exchanged between two hosts (which are the two measurement <section numbered="true" toc="default">
points), and the Output is the One-way loss ratio for all <name>Version (of Registry Format)</name>
successfully received packets expressed as a percentage.</t> <t>1.0</t>
</section> </section>
</section> </section>
<section title="Metric Definition"> <!-- section 7.2 -->
<section numbered="true" toc="default">
<name>Metric Definition</name>
<t>This category includes columns to prompt the entry of all necessary <t>This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference details related to the metric definition, including the RFC reference
and values of input factors, called fixed parameters.</t> and values of input factors, called "Fixed Parameters".</t>
<section title="Reference Definition">
<t>For Delay:</t>
<t>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,
&lt;http://www.rfc-editor.org/info/rfc7679&gt;.</t>
<t><xref target="RFC7679"/></t>
<t>Morton, A., and Stephan, E., "Spatial Composition of Metrics",
RFC 6049, January 2011.</t>
<t><xref target="RFC6049"/></t>
<t>Section 3.4 of <xref target="RFC7679"/> provides the reference <!-- section 7.2.1 -->
definition of the singleton (single value) One-way delay metric. <section numbered="true" toc="default">
Section 4.4 of <xref target="RFC7679"/> provides the reference <name>Reference Definition</name>
<t>For delay:</t>
<t indent="3">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,
&lt;https://www.rfc-editor.org/info/rfc7679&gt;.
<xref target="RFC7679"/></t>
<t indent="3">Morton, A. and E. Stephan, "Spatial Composition of Metri
cs", RFC
6049, DOI 10.17487/RFC6049, January 2011,
&lt;https://www.rfc-editor.org/info/rfc6049&gt;.
<xref target="RFC6049"/></t>
<t indent="3"><xref target="RFC7679" sectionFormat="of" section="3.4"/
> provides the reference
definition of the singleton (single value) one-way delay metric.
<xref target="RFC7679" sectionFormat="of" section="4.4"/> provides the
reference
definition expanded to cover a multi-value sample. Note that terms definition expanded to cover a multi-value sample. Note that terms
such as singleton and sample are defined in Section 11 of <xref such as "singleton" and "sample" are defined in <xref target="RFC2330"
target="RFC2330"/>.</t> sectionFormat="of" section="11"/>.</t>
<t indent="3">Only successful packet transfers with finite delay are i
<t>Only successful packet transfers with finite delay are included ncluded
in the sample, as prescribed in section 4.1.2 of <xref in the sample, as prescribed in <xref target="RFC6049" sectionFormat="
target="RFC6049"/>.</t> of" section="4.1.2"/>.</t>
<t>For loss:</t> <t>For loss:</t>
<t indent="3">Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
<t>Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A Ed., "A
One-Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, RFC
DOI 10.17487/RFC7680, January 2016, 7680, DOI 10.17487/RFC7680, January 2016,
&lt;http://www.rfc-editor.org/info/rfc7680&gt;.</t> &lt;https://www.rfc-editor.org/info/rfc7680&gt;.
<xref target="RFC7680"/></t>
<t>Section 2.4 of <xref target="RFC7680"/> provides the reference <t indent="3"><xref target="RFC7680" sectionFormat="of" section="2.4"/
definition of the singleton (single value) one-way loss metric. > provides the reference
Section 3.4 of <xref target="RFC7680"/> provides the reference definition of the singleton (single value) one-way Loss metric.
<xref target="RFC7680" sectionFormat="of" section="3.4"/> provides the
reference
definition expanded to cover a multi-singleton sample. Note that definition expanded to cover a multi-singleton sample. Note that
terms such as singleton and sample are defined in Section 11 of terms such as "singleton" and "sample" are defined in <xref target="RF
<xref target="RFC2330"/>.</t> C2330" sectionFormat="of" section="11"/>.</t>
</section> </section>
<section title="Fixed Parameters"> <!-- section 7.2.2 -->
<t>Type-P:<list style="symbols"> <section numbered="true" toc="default">
<t>IPv4 header values: <list style="symbols"> <name>Fixed Parameters</name>
<t>DSCP: set to 0</t> <dl newline="true" spacing ="normal">
<dt>Type-P:</dt>
<t>TTL: set to 255</t> <dd><t/>
<dl newline="true" spacing="normal">
<t>Protocol: Set to 17 (UDP)</t> <dt>IPv4 header values:</dt>
</list></t> <dd><t/>
<dl newline="false" spacing="compact">
<t>IPv6 header values:<list style="symbols"> <dt>DSCP:</dt><dd>Set to 0</dd>
<t>DSCP: set to 0</t> <dt>TTL:</dt><dd>Set to 255</dd>
<dt>Protocol:</dt><dd>Set to 17 (UDP)</dd>
<t>Hop Count: set to 255</t> </dl>
</dd>
<t>Next Header: set to 17 (UDP)</t> </dl>
<t>Flow Label: set to zero</t>
<t>Extension Headers: none</t>
</list></t>
<t>UDP header values: <list style="symbols">
<t>Checksum: the checksum MUST be calculated and the
non-zero checksum included in the header</t>
</list></t>
<t>UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of <dl newline="true" spacing="normal">
<xref target="RFC5357"/> <list style="symbols"> <dt>IPv6 header values:</dt>
<t>Security features in use influence the number of Padding <dd><t/>
octets.</t> <dl newline="false" spacing="compact">
<dt>DSCP:</dt><dd>Set to 0</dd>
<dt>Hop Count:</dt><dd>Set to 255</dd>
<dt>Next Header:</dt><dd>Set to 17 (UDP)</dd>
<dt>Flow Label:</dt><dd> Set to 0</dd>
<dt>Extension Headers:</dt><dd>None</dd>
</dl>
</dd>
</dl>
<t>250 octets total, including the TWAMP format type, which <dl newline="true" spacing="normal">
MUST be reported.</t> <dt>UDP header values:</dt>
</list></t> <dd><t/>
</list></t> <dl newline="false" spacing="compact">
<dt>Checksum:</dt><dd>The checksum <bcp14>MUST</bcp14> be calcul
ated and the
non-zero checksum included in the header</dd>
</dl>
</dd>
</dl>
<t>Other measurement parameters:</t> <dl newline="false" spacing="normal">
<dt>UDP Payload:</dt><dd><t>TWAMP-Test packet formats (<xref targe
t="RFC5357"
sectionFormat="of" section="4.1.2"/>)</t>
<ul empty="true">
<li>Security features in use influence the number of Padding
octets</li>
<li>250 octets total, including the TWAMP format type, which
<bcp14>MUST</bcp14> be reported</li>
</ul>
</dd>
</dl>
</dd>
</dl>
<t><list style="hanging"> <dl newline="true" spacing="normal">
<t hangText="Tmax:">a loss threshold waiting time with value <dt>Other measurement Parameters:</dt>
<dd><t/>
<dl newline="false" spacing="normal">
<dt>Tmax:</dt>
<dd>A loss threshold waiting time with value
3.0, expressed in units of seconds, as a positive value of type 3.0, expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 4 (see section 9.3 of <xref decimal64 with fraction digits = 4 (see <xref target="RFC6020" sec
target="RFC6020"/>) and with resolution of 0.0001 seconds (0.1 tionFormat="of" section="9.3"/>) and with a resolution of 0.0001 seconds (0.1
ms), with lossless conversion to/from the 32-bit NTP timestamp ms), with lossless conversion to/from the 32-bit NTP timestamp
as per section 6 of <xref target="RFC5905"/>.</t> as per <xref target="RFC5905" sectionFormat="of" section="6"/>.</d
</list></t> d>
</dl>
<t>See the Packet Stream generation category for two additional </dd>
</dl>
<t>See the Packet Stream Generation section for two additional
Fixed Parameters.</t> Fixed Parameters.</t>
</section> </section>
</section> </section>
<section title="Method of Measurement"> <!-- section 7.3 -->
<section numbered="true" toc="default">
<name>Method of Measurement</name>
<t>This category includes columns for references to relevant sections <t>This category includes columns for references to relevant sections
of the RFC(s) and any supplemental information needed to ensure an of the RFC(s) and any supplemental information needed to ensure
unambiguous methods for implementations.</t> an unambiguous method for implementations.</t>
<section title="Reference Method">
<t>The methodology for this metric is defined as
Type-P-One-way-Delay-Poisson-Stream in section 3.6 of <xref
target="RFC7679"/> and section 4.6 of <xref target="RFC7679"/> using
the Type-P and Tmax defined under Fixed Parameters.</t>
<!-- section 7.3.1 -->
<section numbered="true" toc="default">
<name>Reference Methods</name>
<t>The methodology for this metric (equivalent to
Type-P-One-way-Delay-Poisson-Stream) is defined as in <xref target="RF
C7679"
sectionFormat="of" section="3.6"/> (for singletons) and <xref
target="RFC7679" sectionFormat="of" section="4.6"/> (for samples) usin
g
the Type-P and Tmax defined in the Fixed Parameters column.</t>
<t>The reference method distinguishes between long-delayed packets <t>The reference method distinguishes between long-delayed packets
and lost packets by implementing a maximum waiting time for packet and lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a arrival. Tmax is the waiting time used as the threshold to declare a
packet lost. Lost packets SHALL be designated as having undefined packet lost. Lost packets <bcp14>SHALL</bcp14> be designated as having
delay, and counted for the OWLoss metric.</t> undefined
delay and counted for the OWLoss metric.</t>
<t>The calculations on the one-way delay SHALL be performed on the <t>The calculations on the one-way delay <bcp14>SHALL</bcp14> be perfo
rmed on the
conditional distribution, conditioned on successful packet arrival conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process within Tmax. Also, when all packet delays are stored, the process
which calculates the one-way delay value MUST enforce the Tmax that calculates the one-way delay value <bcp14>MUST</bcp14> enforce th
threshold on stored values before calculations. See section 4.1 of e Tmax
<xref target="RFC3393"/> for details on the conditional distribution threshold on stored values before calculations. See <xref target="RFC3
to exclude undefined values of delay, and Section 5 of <xref 393" sectionFormat="of" section="4.1"/> for details on the conditional distribut
target="RFC6703"/> for background on this analysis choice.</t> ion
to exclude undefined values of delay, and see <xref target="RFC6703" s
ectionFormat="of" section="5"/> for background on this analysis choice.</t>
<t>The reference method requires some way to distinguish between <t>The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving sending times and receiving times for each successfully arriving
packet.</t> packet.</t>
<t>Since a standard measurement protocol is employed <xref target="RFC
<t>Since a standard measurement protocol is employed <xref 5357" format="default"/>, the measurement process will determine the
target="RFC5357"/>, then the measurement process will determine the
sequence numbers or timestamps applied to test packets after the sequence numbers or timestamps applied to test packets after the
Fixed and Runtime parameters are passed to that process. The Fixed and Runtime Parameters are passed to that process. The
measurement protocol dictates the format of sequence numbers and measurement protocol dictates the format of sequence numbers and
time-stamps conveyed in the TWAMP-Test packet payload.</t> timestamps conveyed in the TWAMP-Test packet payload.</t>
</section> </section>
<section title="Packet Stream Generation"> <!-- section 7.3.2 -->
<t>This section gives the details of the packet traffic which is the <section numbered="true" toc="default">
basis for measurement. In IPPM metrics, this is called the Stream, <name>Packet Stream Generation</name>
and can easily be described by providing the list of stream <t>This section provides details regarding packet traffic, which is
parameters.</t> used as the
basis for measurement. In IPPM Metrics, this is called the "stream";
<t>Section 11.1.3 of <xref target="RFC2330">RFC 2681</xref> provides this stream can easily be described by providing the list of stream
Parameters.</t>
<t><xref target="RFC2330" sectionFormat="of" section="11.1.3"/>
provides
three methods to generate Poisson sampling intervals. The reciprocal three methods to generate Poisson sampling intervals. The reciprocal
of lambda is the average packet spacing, thus the Run-time Parameter of lambda is the average packet spacing; thus, the Runtime Parameter
is Reciprocal_lambda = 1/lambda, in seconds.</t> is Reciprocal_lambda&nbsp;=&nbsp;1&wj;/lambda, in seconds.</t>
<t>Method 3 <bcp14>SHALL</bcp14> be used. Where given a start time (Ru
<t>Method 3 SHALL be used, where given a start time (Run-time ntime
Parameter), the subsequent send times are all computed prior to Parameter), the subsequent send times are all computed prior to
measurement by computing the pseudo-random distribution of measurement by computing the pseudorandom distribution of
inter-packet send times, (truncating the distribution as specified inter-packet send times (truncating the distribution as specified
in the Parameter Trunc), and the Src sends each packet at the in the Parameter Trunc), and the Src sends each packet at the
computed times.</t> computed times.</t>
<t>Note that Trunc is the upper limit on inter-packet times in the <t>Note that Trunc is the upper limit on inter-packet times in the
Poisson distribution. A random value greater than Trunc is set equal Poisson distribution. A random value greater than Trunc is set equal
to Trunc instead.</t> to Trunc instead.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Reciprocal_lambda:</dt>
<t hangText="Reciprocal_lambda">average packet interval for <dd>Average packet interval for
Poisson Streams expressed in units of seconds, as a positive Poisson streams, expressed in units of seconds, as a positive
value of type decimal64 with fraction digits = 4 (see section value of type decimal64 with fraction digits = 4 (see <xref target
9.3 of <xref target="RFC6020"/>) with resolution of 0.0001 ="RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.0001
seconds (0.1 ms), and with lossless conversion to/from the seconds (0.1 ms), and with lossless conversion to/from the
32-bit NTP timestamp as per section 6 of <xref 32-bit NTP timestamp as per <xref target="RFC5905" sectionFormat="
target="RFC5905"/>. Reciprocal_lambda = 1 second.</t> of" section="6"/>. Reciprocal_lambda = 1 second.</dd>
<dt>Trunc:</dt>
<t hangText="Trunc">Upper limit on Poisson distribution <dd>Upper limit on Poisson distribution,
expressed in units of seconds, as a positive value of type expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 4 (see section 9.3 of <xref decimal64 with fraction digits = 4 (see <xref target="RFC6020" sec
target="RFC6020"/>) with resolution of 0.0001 seconds (0.1 ms), tionFormat="of" section="9.3"/>) with a resolution of 0.0001 seconds (0.1 ms),
and with lossless conversion to/from the 32-bit NTP timestamp as and with lossless conversion to/from the 32-bit NTP timestamp as
per section 6 of <xref target="RFC5905"/> (values above this per <xref target="RFC5905" sectionFormat="of" section="6"/> (value
limit will be clipped and set to the limit value). Trunc = s above this
30.0000 seconds.</t> limit will be clipped and set to the limit value).
</list></t> Trunc&nbsp;=&nbsp;30.0000 seconds.</dd>
</dl>
</section> </section>
<!-- section 7.3.3 -->
<section title="Traffic Filtering (observation) Details"> <section numbered="true" toc="default">
<t>NA</t> <name>Traffic Filtering (Observation) Details</name>
<t>N/A</t>
</section> </section>
<section title="Sampling Distribution"> <!-- section 7.3.4 -->
<t>NA</t> <section numbered="true" toc="default">
<name>Sampling Distribution</name>
<t>N/A</t>
</section> </section>
<section title="Run-time Parameters and Data Format"> <!-- section 7.3.5 -->
<t>Run-time Parameters are input factors that must be determined, <section numbered="true" toc="default">
<name>Runtime Parameters and Data Format</name>
<t>Runtime Parameters are input factors that must be determined,
configured into the measurement system, and reported with the configured into the measurement system, and reported with the
results for the context to be complete.</t> results for the context to be complete.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Src:</dt>
<t hangText="Src">the IP address of the host in the Src Role <dd>The IP address of the host in the Src Role
(format ipv4-address-no-zone value for IPv4, or (format ipv4&nbhy;address-no-zone value for IPv4 or
ipv6-address-no-zone value for IPv6, see Section 4 of <xref ipv6-address-no-zone value for IPv6; see <xref target="RFC6991" se
target="RFC6991"/>)</t> ctionFormat="of" section="4"/>).</dd>
<dt>Dst:</dt>
<t hangText="Dst">the IP address of the host in the Dst Role <dd>The IP address of the host in the Dst Role
(format ipv4-address-no-zone value for IPv4, or (format ipv4&nbhy;address-no-zone value for IPv4 or
ipv6-address-no-zone value for IPv6, see section 4 of <xref ipv6-address-no-zone value for IPv6; see <xref target="RFC6991" se
target="RFC6991"/>)</t> ctionFormat="of" section="4"/>).</dd>
<dt>T0:</dt>
<t hangText="T0">a time, the start of a measurement interval, <dd>A time, the start of a measurement interval
(format "date-and-time" as specified in Section 5.6 of <xref (format "date&nbhy;time" as specified in <xref target="RFC3339"
target="RFC3339"/>, see also Section 3 of <xref sectionFormat="of" section="5.6"/>; see also
target="RFC6991"/>). The UTC Time Zone is required by Section "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
6.1 of <xref target="RFC2330"/>. When T0 is "all-zeros", a start "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
time is unspecified and Tf is to be interpreted as the Duration tionFormat="of" section="6.1"/>. 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 of the measurement interval. The start time is controlled
through other means.</t> through other means.</dd>
<dt>Tf:</dt>
<t hangText="Tf">a time, the end of a measurement interval, <dd>A time, the end of a measurement interval
(format "date-and-time" as specified in Section 5.6 of <xref (format "date&nbhy;time" as specified in <xref target="RFC3339"
target="RFC3339"/>, see also Section 3 of <xref sectionFormat="of" section="5.6"/>; see also
target="RFC6991"/>). The UTC Time Zone is required by Section "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
6.1 of <xref target="RFC2330"/>. When T0 is "all-zeros", a end "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
time date is ignored and Tf is interpreted as the Duration of tionFormat="of" section="6.1"/>. When T0 is "all-zeros", an ending
the measurement interval.</t> time and date is ignored and Tf is interpreted as the duration of
</list></t> the measurement interval.</dd>
</dl>
</section> </section>
<section title="Roles"> <!-- section 7.3.6 -->
<t><list style="hanging"> <section numbered="true" toc="default">
<t hangText="Src">launches each packet and waits for return <name>Roles</name>
transmissions from Dst. This is the TWAMP Session-Sender.</t> <dl newline="false" spacing="normal">
<dt>Src:</dt>
<t hangText="Dst">waits for each packet from Src and sends a <!-- updated - 7.3.6 -->
return packet to Src. This is the TWAMP Session-Reflector.</t> <dd>Launches each packet and waits for return transmissions from the
</list></t> Dst. &nbsp;An example is the TWAMP Session-Sender.</dd>
<dt>Dst:</dt>
<dd>Waits for each packet from the Src and sends a return packet to
the Src. &nbsp;An example is the TWAMP Session-Reflector.</dd>
</dl>
</section> </section>
</section> </section>
<section title="Output"> <!-- section 7.4 -->
<t>This category specifies all details of the Output of measurements <section numbered="true" toc="default">
<name>Output</name>
<t>This category specifies all details of the output of measurements
using the metric.</t> using the metric.</t>
<section title="Type"> <!-- section 7.4.1 -->
<t>See subsection titles below for Types.</t> <section numbered="true" toc="default">
<name>Type</name>
<t>Types are discussed in the subsections below.</t>
</section> </section>
<section title="Reference Definition"> <!-- section 7.4.2 -->
<t>For all output types ---<list style="hanging"> <section numbered="true" toc="default">
<t hangText="T0">the start of a measurement interval, (format <name>Reference Definition</name>
"date-and-time" as specified in Section 5.6 of <xref <t>For all output types:</t>
target="RFC3339"/>, see also Section 3 of <xref <dl newline="false" spacing="normal">
target="RFC6991"/>). The UTC Time Zone is required by Section <dt>T0:</dt>
6.1 of <xref target="RFC2330"/>.</t> <dd>The start of a measurement interval (format
"date&nbhy;time" as specified in <xref target="RFC3339"
<t hangText="Tf">the end of a measurement interval, (format sectionFormat="of" section="5.6"/>; see also
"date-and-time" as specified in Section 5.6 of <xref "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
target="RFC3339"/>, see also Section 3 of <xref "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
target="RFC6991"/>). The UTC Time Zone is required by Section tionFormat="of" section="6.1"/>.</dd>
6.1 of <xref target="RFC2330"/>.</t> <dt>Tf:</dt>
</list></t> <dd>The end of a measurement interval (format
"date&nbhy;time" as specified in <xref target="RFC3339"
<t>For LossRatio -- the count of lost packets to total packets sent sectionFormat="of" section="5.6"/>; see also
is the basis for the loss ratio calculation as per Section 4.1 of "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
<xref target="RFC7680"/>.</t> "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
tionFormat="of" section="6.1"/>.</dd>
<t>For each &lt;statistic&gt;, one of the following sub-sections </dl>
apply:</t> <t>For LossRatio, the count of lost packets to total packets sent
is the basis for the loss ratio calculation as per <xref target="RFC76
<section title="Percentile95"> 80" sectionFormat="of" section="4.1"/>.</t>
<t>The 95th percentile SHALL be calculated using the conditional <t>For each &lt;statistic&gt; or Percent_LossRatio, one of the followi
distribution of all packets with a finite value of One-way delay ng subsections
(undefined delays are excluded), a single value as follows:</t> applies.</t>
<!-- section 7.4.2.1 -->
<t>See section 4.1 of <xref target="RFC3393"/> for details on the <section numbered="true" toc="default">
<name>Percentile95</name>
<t>The 95th percentile <bcp14>SHALL</bcp14> 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:</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for
details on the
conditional distribution to exclude undefined values of delay, and conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this see <xref target="RFC6703" sectionFormat="of" section="5"/> for back ground on this
analysis choice.</t> analysis choice.</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.3"/> for
<t>See section 4.3 of <xref target="RFC3393"/> for details on the details on the
percentile statistic (where Round-trip delay should be substituted percentile statistic (where round-trip delay should be substituted
for "ipdv").</t> for "ipdv").</t>
<t>The percentile = 95, meaning that the reported delay, <t>The percentile = 95, meaning that the reported delay,
"95Percentile", is the smallest value of one-way delay for which "95Percentile", is the smallest value of one-way delay for which
the Empirical Distribution Function (EDF), F(95Percentile) &gt;= the Empirical Distribution Function, EDF(95Percentile), is greater
95% of the singleton one-way delay values in the conditional than or equal to 95% of the singleton one-way delay values in the con
distribution. See section 11.3 of <xref target="RFC2330"/> for the ditional
distribution. See <xref target="RFC2330" sectionFormat="of" section=
"11.3"/> for the
definition of the percentile statistic using the EDF.</t> definition of the percentile statistic using the EDF.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>95Percentile:</dt>
<t hangText="95Percentile">The time value of the result is <dd>The time value of the result is
expressed in units of seconds, as a positive value of type expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 9 (see section 9.3 of <xref decimal64 with fraction digits = 9 (see <xref target="RFC6020" s
target="RFC6020"/>) with resolution of 0.000000001 seconds ectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds
(1.0 ns), and with lossless conversion to/from the 64-bit NTP (1.0 ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" secti
target="RFC5905">RFC</xref></t> on="6"/>.</dd>
</list></t> </dl>
</section> </section>
<!-- section 7.4.2.2 -->
<section title="Mean"> <section anchor="mean-sec7422" numbered="true" toc="default">
<t>The mean SHALL be calculated using the conditional distribution <name>Mean</name>
of all packets with a finite value of One-way delay (undefined <t>The mean <bcp14>SHALL</bcp14> be calculated using the conditional
delays are excluded), a single value as follows:</t> distribution
of all packets with a finite value of one-way delay (undefined
<t>See section 4.1 of <xref target="RFC3393"/> for details on the delays are excluded) -- a single value, as follows:</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for
details on the
conditional distribution to exclude undefined values of delay, and conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this see <xref target="RFC6703" sectionFormat="of" section="5"/> for back ground on this
analysis choice.</t> analysis choice.</t>
<t>See <xref target="RFC6049" sectionFormat="of" section="4.2.2"/> f
<t>See section 4.2.2 of <xref target="RFC6049"/> for details on or details on
calculating this statistic, and 4.2.3 of <xref calculating this statistic; see also <xref target="RFC6049"
target="RFC6049"/>.</t> sectionFormat="of" section="4.2.3"/>.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Mean:</dt>
<t hangText="Mean">The time value of the result is expressed <dd>The time value of the result is expressed
in units of seconds, as a positive value of type decimal64 in units of seconds, as a positive value of type decimal64
with fraction digits = 9 (see section 9.3 of <xref with fraction digits = 9 (see <xref target="RFC6020" sectionForm
target="RFC6020"/>) with resolution of 0.000000001 seconds at="of" section="9.3"/>) with a resolution of 0.000000001&nbsp;seconds
(1.0 ns), and with lossless conversion to/from the 64-bit NTP (1.0 ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" secti
target="RFC5905">RFC</xref></t> on="6"/>.</dd>
</list></t> </dl>
</section> </section>
<section title="Min"> <!-- section 7.4.2.3 -->
<t>The minimum SHALL be calculated using the conditional <section numbered="true" toc="default">
distribution of all packets with a finite value of One-way delay <name>Min</name>
(undefined delays are excluded), a single value as follows:</t> <t>The minimum <bcp14>SHALL</bcp14> be calculated using the conditio
nal
<t>See section 4.1 of <xref target="RFC3393"/> for details on the distribution of all packets with a finite value of one-way delay
(undefined delays are excluded) -- a single value, as follows:</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for
details on the
conditional distribution to exclude undefined values of delay, and conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this see <xref target="RFC6703" sectionFormat="of" section="5"/> for back ground on this
analysis choice.</t> analysis choice.</t>
<t>See <xref target="RFC6049" sectionFormat="of" section="4.3.2"/> f
<t>See section 4.3.2 of <xref target="RFC6049"/> for details on or details on
calculating this statistic, and 4.3.3 of <xref calculating this statistic; see also <xref target="RFC6049" sectionF
target="RFC6049"/>.</t> ormat="of" section="4.3.3"/>.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Min:</dt>
<t hangText="Min">The time value of the result is expressed in <dd>The time value of the result is expressed in
units of seconds, as a positive value of type decimal64 with units of seconds, as a positive value of type decimal64 with
fraction digits = 9 (see section 9.3 of <xref fraction digits = 9 (see <xref target="RFC6020" sectionFormat="o
target="RFC6020"/>) with resolution of 0.000000001 seconds f" section="9.3"/>) with a resolution of 0.000000001&nbsp;seconds
(1.0 ns), and with lossless conversion to/from the 64-bit NTP (1.0 ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" secti
target="RFC5905">RFC</xref></t> on="6"/>.</dd>
</list></t> </dl>
</section> </section>
<section title="Max"> <!-- section 7.4.2.4 -->
<t>The maximum SHALL be calculated using the conditional <section numbered="true" toc="default">
distribution of all packets with a finite value of One-way delay <name>Max</name>
(undefined delays are excluded), a single value as follows:</t> <t>The maximum <bcp14>SHALL</bcp14> be calculated using the conditio
nal
<t>See section 4.1 of <xref target="RFC3393"/> for details on the distribution of all packets with a finite value of one-way delay
(undefined delays are excluded) -- a single value, as follows:</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for
details on the
conditional distribution to exclude undefined values of delay, and conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this see <xref target="RFC6703" sectionFormat="of" section="5"/> for back ground on this
analysis choice.</t> analysis choice.</t>
<t>See <xref target="RFC6049" sectionFormat="of" section="4.3.2"/> f
or a closely
related method for calculating this statistic; see also <xref target
="RFC6049" sectionFormat="of" section="4.3.3"/>. The formula is as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Max = (FiniteDelay[j])
]]></artwork>
<t>See section 4.3.2 of <xref target="RFC6049"/> for a closely <ul empty="true">
related method for calculating this statistic, and 4.3.3 of <xref <li>such that for some index, j, where 1 &lt;= j &lt;= N
target="RFC6049"/>. The formula is as follows:</t> FiniteDelay[j]&nbsp;&gt;=&nbsp;FiniteDelay[n] for all n</li>
</ul>
<t><figure> <dl newline="false" spacing="normal">
<artwork><![CDATA[ Max = (FiniteDelay [j]) <dt>Max:</dt>
<dd>The time value of the result is expressed in
such that for some index, j, where 1 <= j <= N
FiniteDelay[j] >= FiniteDelay[n] for all n]]></artwork>
</figure></t>
<t><list style="hanging">
<t hangText="Max">The time value of the result is expressed in
units of seconds, as a positive value of type decimal64 with units of seconds, as a positive value of type decimal64 with
fraction digits = 9 (see section 9.3 of <xref fraction digits = 9 (see <xref target="RFC6020" sectionFormat="o
target="RFC6020"/>) with resolution of 0.000000001 seconds f" section="9.3"/>) with a resolution of 0.000000001&nbsp;seconds
(1.0 ns), and with lossless conversion to/from the 64-bit NTP (1.0 ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" secti
target="RFC5905">RFC</xref></t> on="6"/>.</dd>
</list></t> </dl>
</section> </section>
<section title="Std_Dev"> <!-- section 7.4.2.5 -->
<t>The Std_Dev SHALL be calculated using the conditional <section numbered="true" toc="default">
distribution of all packets with a finite value of One-way delay <name>Std_Dev</name>
(undefined delays are excluded), a single value as follows:</t> <t>The standard deviation (Std_Dev) <bcp14>SHALL</bcp14> be calculat
ed using the conditional
<t>See section 4.1 of <xref target="RFC3393"/> for details on the distribution of all packets with a finite value of one&nbhy;way dela
y
(undefined delays are excluded) -- a single value, as follows:</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for
details on the
conditional distribution to exclude undefined values of delay, and conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this see <xref target="RFC6703" sectionFormat="of" section="5"/> for back ground on this
analysis choice.</t> analysis choice.</t>
<t>See <xref target="RFC6049" sectionFormat="of" section="6.1.4"/> f
<t>See section 6.1.4 of <xref target="RFC6049"/> for a closely or a closely
related method for calculating this statistic. The formula is the related method for calculating this statistic. The formula is the
classic calculation for standard deviation of a population.<figure> classic calculation for the standard deviation of a population.</t>
<artwork><![CDATA[Define Population Std_Dev_Delay as follows:
(where all packets n = 1 through N have a value for Delay[n],
and MeanDelay calculated as in 7.4.2.2), and SQRT[] is the
Square Root function:
_ _
| N |
| --- |
| 1 \ 2 |
Std_Dev = SQRT | ------- > (Delay[n] - MeanDelay) |
| (N) / |
| --- |
| n = 1 |
|_ _|
]]></artwork>
</figure></t>
<t><list style="hanging"> <t>Define Population Std_Dev_Delay as follows:</t>
<t hangText="Std_Dev">The time value of the result is
<artwork name="" type="" align="left" alt=""><![CDATA[
_ _
| N |
| --- |
| 1 \ 2 |
Std_Dev = SQRT | ------- > (Delay[n] - MeanDelay) |
| (N) / |
| --- |
| n = 1 |
|_ _|
]]></artwork>
<t>where all packets n = 1 through N have a value for Delay[n],
MeanDelay is calculated per <xref target="mean-sec7422"/>,
and SQRT[] is the Square Root function:</t>
<dl newline="false" spacing="normal">
<dt>Std_Dev:</dt>
<dd>The time value of the result is
expressed in units of seconds, as a positive value of type expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 9 (see section 9.3 of <xref decimal64 with fraction digits = 9 (see <xref target="RFC6020" s
target="RFC6020"/>) with resolution of 0.000000001 seconds ectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds
(1.0 ns), and with lossless conversion to/from the 64-bit NTP (1.0 ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" secti
target="RFC5905">RFC</xref></t> on="6"/>.</dd>
</list></t> </dl>
</section> </section>
<!-- 7.4.2.6 -->
<section>
<name>Percent_LossRatio</name>
<dl>
<dt>Percent_LossRatio:</dt><dd>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
<xref target="RFC6020" sectionFormat="of" section="9.3"/>) with a
resolution of 0.0000000001.</dd></dl>
</section> </section>
</section>
<section title="Metric Units"> <!-- section 7.4.3 -->
<t>The &lt;statistic&gt; of One-way Delay is expressed in <section numbered="true" toc="default">
seconds.</t> <name>Metric Units</name>
<t>The &lt;statistic&gt; of one-way delay is expressed in
<t>The One-way Loss Ratio is expressed as a percentage of lost seconds, where &lt;statistic&gt; is one of:</t>
<ul>
<li>95Percentile</li>
<li>Mean</li>
<li>Min</li>
<li>Max</li>
<li>StdDev</li>
</ul>
<t>The one-way loss ratio is expressed as a percentage of lost
packets to total packets sent.</t> packets to total packets sent.</t>
</section> </section>
<section title="Calibration"> <!-- 7.4.4 -->
<t>Section 3.7.3 of <xref target="RFC7679"/> provides a means to <section numbered="true" toc="default">
<name>Calibration</name>
<t><xref target="RFC7679" sectionFormat="of" section="3.7.3"/> provide
s a means to
quantify the systematic and random errors of a time measurement. quantify the systematic and random errors of a time measurement.
In-situ calibration could be enabled with an internal loopback that Calibration in-situ could be enabled with an internal loopback that
includes as much of the measurement system as possible, performs includes as much of the measurement system as possible, performs
address manipulation as needed, and provides some form of isolation address manipulation as needed, and provides some form of isolation
(e.g., deterministic delay) to avoid send-receive interface (e.g., deterministic delay) to avoid send-receive interface
contention. Some portion of the random and systematic error can be contention. Some portion of the random and systematic error can be
characterized this way.</t> characterized in this way.</t>
<t>For one-way delay measurements, the error calibration must <t>For one-way delay measurements, the error calibration must
include an assessment of the internal clock synchronization with its include an assessment of the internal clock synchronization with its
external reference (this internal clock is supplying timestamps for external reference (this internal clock is supplying timestamps for
measurement). In practice, the time offsets <xref target="RFC5905"/> measurement). In practice, the time offsets <xref target="RFC5905" for
of clocks at both the source and destination are needed to estimate mat="default"/>
of clocks at both the Source and Destination are needed to estimate
the systematic error due to imperfect clock synchronization (the the systematic error due to imperfect clock synchronization (the
time offsets <xref target="RFC5905"/> are smoothed, thus the random time offsets <xref target="RFC5905" format="default"/> are smoothed; t
variation is not usually represented in the results).<list hus, the random
style="hanging"> variation is not usually represented in the results).</t>
<t hangText="time_offset">The time value of the result is <dl newline="false" spacing="normal">
<dt>time_offset:</dt>
<dd>The time value of the result is
expressed in units of seconds, as a signed value of type expressed in units of seconds, as a signed value of type
decimal64 with fraction digits = 9 (see section 9.3 of <xref decimal64 with fraction digits&nbsp;=&nbsp;9 (see <xref target="RF
target="RFC6020"/>) with resolution of 0.000000001 seconds (1.0 C6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seco
nds (1.0
ns), and with lossless conversion to/from the 64-bit NTP ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" section
target="RFC5905">RFC</xref></t> ="6"/>.</dd>
</list></t> </dl>
<t>When a measurement controller requests a calibration measurement, <t>When a measurement controller requests a calibration measurement,
the loopback is applied and the result is output in the same format the loopback is applied and the result is output in the same format
as a normal measurement with additional indication that it is a as a normal measurement, with an additional indication that it is a
calibration result. In any measurement, the measurement function calibration result. In any measurement, the measurement function
SHOULD report its current estimate of time offset <xref <bcp14>SHOULD</bcp14> report its current estimate of the time offset <
target="RFC5905"/> as an indicator of the degree of xref target="RFC5905" format="default"/> as an indicator of the degree of
synchronization.</t> synchronization.</t>
<t>Both internal loopback calibration and clock synchronization can <t>Both internal loopback calibration and clock synchronization can
be used to estimate the available accuracy of the Output Metric be used to estimate the available accuracy of the Output Metric
Units. For example, repeated loopback delay measurements will reveal Units. For example, repeated loopback delay measurements will reveal
the portion of the Output result resolution which is the result of the portion of the output result resolution that is the result of
system noise, and thus inaccurate.</t> system noise and is thus inaccurate.</t>
<t/>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Administrative items"> <name>Administrative Items</name>
<t/> <section numbered="true" toc="default">
<name>Status</name>
<section title="Status">
<t>Current</t> <t>Current</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Requester"> <name>Requester</name>
<t>This RFC number</t> <t>RFC 8912</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Revision"> <name>Revision</name>
<t>1.0</t> <t>1.0</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Revision Date"> <name>Revision Date</name>
<t>YYYY-MM-DD</t> <t>2021-11-17</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Comments and Remarks"> <name>Comments and Remarks</name>
<t>None</t> <t>None</t>
</section> </section>
</section> </section>
<!-- Section 8 -->
<section anchor="UDP_periodic_owd_and_loss" numbered="true" toc="default">
<name>UDP Periodic One-Way Delay and Loss Registry Entries</name>
<t>This section specifies five initial Registry Entries for UDP
Periodic One-Way Delay and one entry for UDP Periodic One-Way Loss.</t>
<section title="UDP Periodic One-way Delay and Loss Registry Entries"> <t>All column entries besides the ID, Name, Description, and Output
<t>This section specifies five initial registry entries for the UDP Reference Method categories are the same; thus, this section defines six
Periodic One-way Delay, and one for UDP Periodic One-way Loss.</t> closely related Registry Entries. As a result, IANA has
assigned corresponding URLs to each of the six Named Metrics.</t>
<t>IANA Note: Registry "Name" below specifies multiple registry entries, <section numbered="true" toc="default">
whose output format varies according to the &lt;statistic&gt; element of <name>Summary</name>
the name that specifies one form of statistical summary. There is an <t>This category includes multiple indexes to the Registry Entries:
additional metric name for the Loss metric.</t> the element ID and Metric Name.</t>
<section numbered="true" toc="default">
<t>All column entries beside the ID, Name, Description, and Output <name>ID (Identifier)</name>
Reference Method categories are the same, thus this section proposes six <t>IANA has allocated the numeric Identifiers 12-17 for the six
closely-related registry entries. As a result, IANA is also asked to Named Metric Entries in <xref target="UDP_periodic_owd_and_loss"/>. See
assign corresponding URLs to each Named Metric.</t> <xref target="name812"/> for mapping to Names.</t>
<section title="Summary">
<t>This category includes multiple indexes to the registry entries,
the element ID and metric name.</t>
<section title="ID (Identifier)">
<t>IANA is asked to assign a different numeric identifiers to each
of the six Metrics.</t>
</section> </section>
<section anchor="name812" numbered="true" toc="default">
<section title="Name"> <name>Name</name>
<t>OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFCXXXXsec8_Seconds_& <dl spacing="normal" indent="5" newline="false">
lt;statistic&gt;</t> <!-- 8.1.2 --> <dt>12:</dt><dd>OWDelay_Active_IP-UDP-Periodic20m-Payload142B
_RFC8912sec8_Seconds_95Percentile</dd>
<t>where &lt;statistic&gt; is one of:</t> <dt>13:</dt><dd>OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912
sec8_Seconds_Mean</dd>
<t><list style="symbols"> <dt>14:</dt><dd>OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912
<t>95Percentile</t> sec8_Seconds_Min</dd>
<dt>15:</dt><dd>OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912
<t>Mean</t> sec8_Seconds_Max</dd>
<dt>16:</dt><dd>OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912
<t>Min</t> sec8_Seconds_StdDev</dd>
<dt>17:</dt><dd>OWLoss_Active_IP-UDP-Periodic20m-Payload142B_RFC8912
<t>Max</t> sec8_Percent_LossRatio</dd>
</dl>
<t>StdDev</t>
</list></t>
<t>OWLoss_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsec8_Percent_LossR
atio</t>
</section> </section>
<section numbered="true" toc="default">
<section title="URI"> <!-- 8.1.3 -->
<t>URL: https://www.iana.org/ ... &lt;name&gt;</t> <name>URI</name>
<t>URL: <eref target="https://www.iana.org/performance-metrics/OWDelay
_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_95Percentile"/></t>
<t>URL: <eref
target="https://www.iana.org/performance-metrics/OWDelay_Active_IP-UDP-Periodic2
0m-Payload142B_RFC8912sec8_Seconds_Mean"/></t>
<t>URL: <eref target="https://www.iana.org/performance-metrics/OWDelay_
Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Min"/></t>
<t>URL: <eref target="https://www.iana.org/performance-metrics/OWDelay_
Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Max"/></t>
<t>URL: <eref target="https://www.iana.org/performance-metrics/OWDelay_
Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_StdDev"/></t>
<t>URL: <eref target="https://www.iana.org/performance-metrics/OWLoss_A
ctive_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Percent_LossRatio"/></t>
</section> </section>
<section title="Description"> <!-- 8.1.4 -->
<t>OWDelay: This metric assesses the delay of a stream of packets <section numbered="true" toc="default">
exchanged between two hosts (or measurement points), and reports the <name>Description</name>
&lt;statistic&gt; One-way delay for all successfully exchanged <dl newline="false" spacing="normal">
<dt>OWDelay:</dt><dd><t>This metric assesses the delay of a stream of
packets
exchanged between two hosts (or measurement points) and reports the
&lt;statistic&gt; of one-way delay for all successfully exchanged
packets based on their conditional delay distribution.</t> packets based on their conditional delay distribution.</t>
<t>where &lt;statistic&gt; is one of:</t> <t>where &lt;statistic&gt; is one of:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>95Percentile</li>
<t>95Percentile</t> <li>Mean</li>
<li>Min</li>
<t>Mean</t> <li>Max</li>
<li>StdDev</li>
<t>Min</t> </ul>
</dd>
<t>Max</t> <dt>OWLoss:</dt><dd>This metric assesses the loss ratio of a stream of
<t>StdDev</t>
</list></t>
<t>OWLoss: This metric assesses the loss ratio of a stream of
packets exchanged between two hosts (which are the two measurement packets exchanged between two hosts (which are the two measurement
points), and the Output is the One-way loss ratio for all points). The output is the one-way loss ratio for all
successfully received packets expressed as a percentage.</t> transmitted packets expressed as a percentage.</dd>
</dl>
</section>
<!-- 8.1.5 -->
<section numbered="true" toc="default">
<name>Change Controller</name>
<t>IETF</t>
</section>
<section numbered="true" toc="default">
<name>Version (of Registry Format)</name>
<t>1.0</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Metric Definition"> <name>Metric Definition</name>
<t>This category includes columns to prompt the entry of all necessary <t>This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference details related to the metric definition, including the RFC reference
and values of input factors, called fixed parameters.</t> and values of input factors, called "Fixed Parameters".</t>
<section numbered="true" toc="default">
<section title="Reference Definition"> <name>Reference Definition</name>
<t>For Delay:</t> <t>For delay:</t>
<t indent="3">Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
<t>Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A Ed., "A
One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC
7679, DOI 10.17487/RFC7679, January 2016, 7679, DOI 10.17487/RFC7679, January 2016,
&lt;http://www.rfc-editor.org/info/rfc7679&gt;.</t> &lt;https://www.rfc-editor.org/info/rfc7679&gt;.
<xref target="RFC7679"/></t>
<t><xref target="RFC7679"/></t> <t indent="3">Morton, A. and E. Stephan, "Spatial Composition of Metri
cs", RFC
<t>Morton, A., and Stephan, E., "Spatial Composition of Metrics", 6049, DOI 10.17487/RFC6049, January 2011,
RFC 6049, January 2011.</t> &lt;https://www.rfc-editor.org/info/rfc6049&gt;.
<xref target="RFC6049"/></t>
<t><xref target="RFC6049"/></t> <t indent="3"><xref target="RFC7679" sectionFormat="of" section="3.4"/
> provides the reference
<t>Section 3.4 of <xref target="RFC7679"/> provides the reference definition of the singleton (single value) one-way delay metric.
definition of the singleton (single value) One-way delay metric. <xref target="RFC7679" sectionFormat="of" section="4.4"/> provides the
Section 4.4 of <xref target="RFC7679"/> provides the reference reference
definition expanded to cover a multi-value sample. Note that terms definition expanded to cover a multi-value sample. Note that terms
such as singleton and sample are defined in Section 11 of <xref such as "singleton" and "sample" are defined in <xref target="RFC2330"
target="RFC2330"/>.</t> sectionFormat="of" section="11"/>.</t>
<t indent="3">Only successful packet transfers with finite delay are i
<t>Only successful packet transfers with finite delay are included ncluded
in the sample, as prescribed in section 4.1.2 of <xref in the sample, as prescribed in <xref target="RFC6049" sectionFormat="
target="RFC6049"/>.</t> of" section="4.1.2"/>.</t>
<t>For loss:</t> <t>For loss:</t>
<t indent="3">Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
<t>Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A Ed., "A
One-Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, RFC
DOI 10.17487/RFC7680, January 2016, 7680, DOI 10.17487/RFC7680, January 2016,
&lt;http://www.rfc-editor.org/info/rfc7680&gt;.</t> &lt;https://www.rfc-editor.org/info/rfc7680&gt;.
<xref target="RFC7680"/></t>
<t>Section 2.4 of <xref target="RFC7680"/> provides the reference <t indent="3"><xref target="RFC7680" sectionFormat="of" section="2.4"/
definition of the singleton (single value) one-way loss metric. > provides the reference
Section 3.4 of <xref target="RFC7680"/> provides the reference definition of the singleton (single value) one-way Loss metric.
<xref target="RFC7680" sectionFormat="of" section="3.4"/> provides the
reference
definition expanded to cover a multi-singleton sample. Note that definition expanded to cover a multi-singleton sample. Note that
terms such as singleton and sample are defined in Section 11 of terms such as "singleton" and "sample" are defined in <xref target="RF
<xref target="RFC2330"/>.</t> C2330" sectionFormat="of" section="11"/>.</t>
</section> </section>
<!-- 8.2.2 -->
<section numbered="true" toc="default">
<name>Fixed Parameters</name>
<dl newline="true" spacing="normal">
<dt>Type-P:</dt>
<dd><t/>
<dl newline="true" spacing="normal">
<dt>IPv4 header values:</dt>
<dd><t/>
<dl newline="false" spacing="compact">
<dt>DSCP:</dt><dd>Set to 0</dd>
<dt>TTL:</dt><dd>Set to 255</dd>
<dt>Protocol:</dt><dd>Set to 17 (UDP)</dd>
</dl>
</dd>
</dl>
<section title="Fixed Parameters"> <dl newline="true" spacing="normal">
<t>Type-P: <list style="symbols"> <dt>IPv6 header values:</dt>
<t>IPv4 header values: <list style="symbols"> <dd><t/>
<t>DSCP: set to 0</t> <dl newline="false" spacing="compact">
<dt>DSCP:</dt><dd>Set to 0</dd>
<t>TTL: set to 255</t> <dt>Hop Count:</dt><dd>Set to 255</dd>
<dt>Next Header:</dt><dd>Set to 17 (UDP)</dd>
<t>Protocol: Set to 17 (UDP)</t> <dt>Flow Label:</dt><dd>Set to 0</dd>
</list></t> <dt>Extension Headers:</dt><dd>None</dd>
</dl>
<t>IPv6 header values:<list style="symbols"> </dd>
<t>DSCP: set to 0</t> </dl>
<t>Hop Count: set to 255</t>
<t>Next Header: set to 17 (UDP)</t>
<t>Flow Label: set to zero</t>
<t>Extension Headers: none</t>
</list></t>
<t>UDP header values: <list style="symbols">
<t>Checksum: the checksum MUST be calculated and the
non-zero checksum included in the header</t>
</list></t>
<t>UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of
<xref target="RFC5357"/> <list style="symbols">
<t>Security features in use influence the number of Padding
octets.</t>
<t>142 octets total, including the TWAMP format (and format <dl newline="true" spacing="normal">
type MUST be reported, if used)</t> <dt>UDP header values:</dt>
</list></t> <dd><t/>
</list></t> <dl newline="false" spacing="compact">
<dt>Checksum:</dt><dd>The checksum <bcp14>MUST</bcp14> be calculat
ed and the
non-zero checksum included in the header</dd>
</dl>
</dd>
</dl>
<t>Other measurement parameters:</t> <dl newline="false" spacing="normal">
<dt>UDP Payload:</dt><dd><t>TWAMP-Test packet formats (<xref
target="RFC5357" sectionFormat="of" section="4.1.2"/>)</t>
<ul empty="true">
<li>Security features in use influence the number of Padding
octets</li>
<li>142 octets total, including the TWAMP format (and format
type <bcp14>MUST</bcp14> be reported, if used)</li>
</ul>
</dd>
</dl>
</dd>
</dl>
<t><list style="hanging"> <dl newline="true" spacing="normal">
<t hangText="Tmax:">a loss threshold waiting time with value <dt>Other measurement Parameters:</dt>
<dd><t/>
<dl newline="false" spacing="compact">
<dt>Tmax:</dt>
<dd>A loss threshold waiting time with value
3.0, expressed in units of seconds, as a positive value of type 3.0, expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 4 (see section 9.3 of <xref decimal64 with fraction digits = 4 (see <xref target="RFC6020" sec
target="RFC6020"/>) and with resolution of 0.0001 seconds (0.1 tionFormat="of" section="9.3"/>) and with a resolution of 0.0001 seconds (0.1
ms), with lossless conversion to/from the 32-bit NTP timestamp ms), with lossless conversion to/from the 32-bit NTP timestamp
as per section 6 of <xref target="RFC5905"/>.</t> as per <xref target="RFC5905" sectionFormat="of" section="6"/>.</d
</list></t> d>
</dl>
</dd>
</dl>
<t>See the Packet Stream generation category for two additional <t>See the Packet Stream Generation section for three additional
Fixed Parameters.</t> Fixed Parameters.</t>
</section> </section>
</section> </section>
<section title="Method of Measurement"> <!-- 8.3 -->
<section numbered="true" toc="default">
<name>Method of Measurement</name>
<t>This category includes columns for references to relevant sections <t>This category includes columns for references to relevant sections
of the RFC(s) and any supplemental information needed to ensure an of the RFC(s) and any supplemental information needed to ensure
unambiguous methods for implementations.</t> an unambiguous method for implementations.</t>
<section numbered="true" toc="default">
<section title="Reference Method"> <name>Reference Methods</name>
<t>The methodology for this metric is defined as <t>The methodology for this metric (equivalent to
Type-P-One-way-Delay-Poisson-Stream in section 3.6 of <xref Type-P-One-way-Delay-Poisson-Stream) is defined as in <xref target="RF
target="RFC7679"/> and section 4.6 of <xref target="RFC7679"/> using C7679"
the Type-P and Tmax defined under Fixed Parameters. However, a sectionFormat="of" section="3.6"/> (for singletons) and <xref
Periodic stream is used, as defined in <xref target="RFC3432"/>.</t> target="RFC7679" sectionFormat="of" section="4.6"/> (for samples) usin
g
the Type-P and Tmax defined in the Fixed Parameters column. However, a
Periodic stream is used, as defined in <xref target="RFC3432" format="
default"/>.</t>
<t>The reference method distinguishes between long-delayed packets <t>The reference method distinguishes between long-delayed packets
and lost packets by implementing a maximum waiting time for packet and lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a arrival. Tmax is the waiting time used as the threshold to declare a
packet lost. Lost packets SHALL be designated as having undefined packet lost. Lost packets <bcp14>SHALL</bcp14> be designated as having
delay, and counted for the OWLoss metric.</t> undefined
delay and counted for the OWLoss metric.</t>
<t>The calculations on the one-way delay SHALL be performed on the <t>The calculations on the one-way delay <bcp14>SHALL</bcp14> be perfo
rmed on the
conditional distribution, conditioned on successful packet arrival conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process within Tmax. Also, when all packet delays are stored, the process
which calculates the one-way delay value MUST enforce the Tmax that calculates the one-way delay value <bcp14>MUST</bcp14> enforce th
threshold on stored values before calculations. See section 4.1 of e Tmax
<xref target="RFC3393"/> for details on the conditional distribution threshold on stored values before calculations. See <xref target="RFC3
to exclude undefined values of delay, and Section 5 of <xref 393" sectionFormat="of" section="4.1"/> for details on the conditional distribut
target="RFC6703"/> for background on this analysis choice.</t> ion
to exclude undefined values of delay, and see <xref target="RFC6703" s
ectionFormat="of" section="5"/> for background on this analysis choice.</t>
<t>The reference method requires some way to distinguish between <t>The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving sending times and receiving times for each successfully arriving
packet.</t> packet.</t>
<t>Since a standard measurement protocol is employed <xref target="RFC
<t>Since a standard measurement protocol is employed <xref 5357" format="default"/>, the measurement process will determine the
target="RFC5357"/>, then the measurement process will determine the
sequence numbers or timestamps applied to test packets after the sequence numbers or timestamps applied to test packets after the
Fixed and Runtime parameters are passed to that process. The Fixed and Runtime Parameters are passed to that process. The
measurement protocol dictates the format of sequence numbers and measurement protocol dictates the format of sequence numbers and
time-stamps conveyed in the TWAMP-Test packet payload.</t> timestamps conveyed in the TWAMP-Test packet payload.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Packet Stream Generation"> <name>Packet Stream Generation</name>
<t>This section gives the details of the packet traffic which is the <t>This section provides details regarding packet traffic, which is
basis for measurement. In IPPM metrics, this is called the Stream, used as the
and can easily be described by providing the list of stream basis for measurement. In IPPM Metrics, this is called the "stream";
parameters.</t> this stream can easily be described by providing the list of stream
Parameters.</t>
<t>Section 3 of <xref target="RFC3432"/> prescribes the method for <t><xref target="RFC3432" sectionFormat="of" section="3"/> prescribes
generating Periodic streams using associated parameters.</t> the method for
generating Periodic streams using associated Parameters.</t>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="incT">the nominal duration of inter-packet <dt>incT:</dt>
interval, first bit to first bit, with value 0.0200 expressed in <dd>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 units of seconds, as a positive value of type decimal64 with
fraction digits = 4 (see section 9.3 of <xref fraction digits = 4 (see <xref target="RFC6020" sectionFormat="of"
target="RFC6020"/>) and with resolution of 0.0001 seconds (0.1 section="9.3"/>) and with a resolution of 0.0001 seconds (0.1 ms), with lossles
ms), with lossless conversion to/from the 32-bit NTP timestamp s conversion to/from the 32-bit NTP timestamp
as per section 6 of <xref target="RFC5905"/>.</t> as per <xref target="RFC5905" sectionFormat="of" section="6"/>.</d
d>
<t hangText="dT">the duration of the interval for allowed sample <dt>dT:</dt>
<dd>The duration of the interval for allowed sample
start times, with value 1.0000, expressed in units of seconds, start times, with value 1.0000, expressed in units of seconds,
as a positive value of type decimal64 with fraction digits = 4 as a positive value of type decimal64 with fraction digits = 4
(see section 9.3 of <xref target="RFC6020"/>) and with (see <xref target="RFC6020" sectionFormat="of" section="9.3"/>)
resolution of 0.0001 seconds (0.1 ms), with lossless conversion and with a resolution of 0.0001 seconds (0.1 ms), with lossless co
to/from the 32-bit NTP timestamp as per section 6 of <xref nversion
target="RFC5905"/>.</t> to/from the 32-bit NTP timestamp as per <xref target="RFC5905" sec
tionFormat="of" section="6"/>.</dd>
<t hangText="T0">the actual start time of the periodic stream, <dt>T0:</dt>
determined from T0 and dT.</t> <dd>The actual start time of the periodic stream,
</list>NOTE: an initiation process with a number of control determined from T0 and dT.</dd>
</dl>
<t indent="3">Note: An initiation process with a number of control
exchanges resulting in unpredictable start times (within a time exchanges resulting in unpredictable start times (within a time
interval) may be sufficient to avoid synchronization of periodic interval) may be sufficient to avoid synchronization of periodic
streams, and therefore a valid replacement for selecting a start streams and is a valid replacement for selecting a start
time at random from a fixed interval.</t> time at random from a fixed interval.</t>
<t>These stream Parameters will be specified as Runtime
<t>These stream parameters will be specified as Run-time Parameters.</t>
parameters.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Traffic Filtering (observation) Details"> <name>Traffic Filtering (Observation) Details</name>
<t>NA</t> <t>N/A</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Sampling Distribution"> <name>Sampling Distribution</name>
<t>NA</t> <t>N/A</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Run-time Parameters and Data Format"> <name>Runtime Parameters and Data Format</name>
<t>Run-time Parameters are input factors that must be determined, <t>Runtime Parameters are input factors that must be determined,
configured into the measurement system, and reported with the configured into the measurement system, and reported with the
results for the context to be complete.</t> results for the context to be complete.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Src:</dt>
<t hangText="Src">the IP address of the host in the Src Role <dd>The IP address of the host in the Src Role
(format ipv4-address-no-zone value for IPv4, or (format ipv4&nbhy;address-no-zone value for IPv4 or
ipv6-address-no-zone value for IPv6, see Section 4 of <xref ipv6-address-no-zone value for IPv6; see <xref target="RFC6991" se
target="RFC6991"/>)</t> ctionFormat="of" section="4"/>).</dd>
<dt>Dst:</dt>
<t hangText="Dst">the IP address of the host in the Dst Role <dd>The IP address of the host in the Dst Role
(format ipv4-address-no-zone value for IPv4, or (format ipv4&nbhy;address-no-zone value for IPv4 or
ipv6-address-no-zone value for IPv6, see section 4 of <xref ipv6-address-no-zone value for IPv6; see <xref target="RFC6991" se
target="RFC6991"/>)</t> ctionFormat="of" section="4"/>).</dd>
<dt>T0:</dt>
<t hangText="T0">a time, the start of a measurement interval, <dd>A time, the start of a measurement interval
(format "date-and-time" as specified in Section 5.6 of <xref (format "date&nbhy;time" as specified in <xref target="RFC3339"
target="RFC3339"/>, see also Section 3 of <xref sectionFormat="of" section="5.6"/>; see also
target="RFC6991"/>). The UTC Time Zone is required by Section "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
6.1 of <xref target="RFC2330"/>. When T0 is "all-zeros", a start "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
time is unspecified and Tf is to be interpreted as the Duration tionFormat="of" section="6.1"/>. 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 of the measurement interval. The start time is controlled
through other means.</t> through other means.</dd>
<dt>Tf:</dt>
<t hangText="Tf">a time, the end of a measurement interval, <dd>A time, the end of a measurement interval
(format "date-and-time" as specified in Section 5.6 of <xref (format "date&nbhy;time" as specified in <xref target="RFC3339"
target="RFC3339"/>, see also Section 3 of <xref sectionFormat="of" section="5.6"/>; see also
target="RFC6991"/>). The UTC Time Zone is required by Section "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
6.1 of <xref target="RFC2330"/>. When T0 is "all-zeros", a end "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
time date is ignored and Tf is interpreted as the Duration of tionFormat="of" section="6.1"/>. When T0 is "all-zeros", an ending
the measurement interval.</t> time and date is ignored and Tf is interpreted as the duration of
</list></t> the measurement interval.</dd>
</dl>
<t/>
</section> </section>
<section numbered="true" toc="default">
<section title="Roles"> <name>Roles</name>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="Src">launches each packet and waits for return <dt>Src:</dt>
transmissions from Dst. This is the TWAMP Session-Sender.</t> <!-- 8.3.6 -->
<dd>Launches each packet and waits for return transmissions from the
<t hangText="Dst">waits for each packet from Src and sends a Dst. &nbsp;An example is the TWAMP Session-Sender.</dd>
return packet to Src. This is the TWAMP Session-Reflector.</t> <dt>Dst:</dt>
</list></t> <dd>Waits for each packet from the Src and sends a return packet to
the Src. &nbsp;An example is the TWAMP Session-Reflector.</dd>
</dl>
</section> </section>
</section> </section>
<!-- 8.4 -->
<section title="Output"> <section numbered="true" toc="default">
<t>This category specifies all details of the Output of measurements <name>Output</name>
<t>This category specifies all details of the output of measurements
using the metric.</t> using the metric.</t>
<!-- 8.4.1 -->
<section title="Type"> <section numbered="true" toc="default">
<t>See subsection titles in Reference Definition for Latency <name>Type</name>
Types.</t> <t>Latency and Loss Types are discussed in the subsections below.</t>
</section> </section>
<section title="Reference Definition"> <!-- 8.4.2 -->
<t>For all output types ---<list style="hanging"> <section numbered="true" toc="default">
<t hangText="T0">the start of a measurement interval, (format <name>Reference Definition</name>
"date-and-time" as specified in Section 5.6 of <xref <t>For all output types:</t>
target="RFC3339"/>, see also Section 3 of <xref <dl newline="false" spacing="normal">
target="RFC6991"/>). The UTC Time Zone is required by Section <dt>T0:</dt>
6.1 of <xref target="RFC2330"/>.</t> <dd>The start of a measurement interval (format
"date&nbhy;time" as specified in <xref target="RFC3339"
<t hangText="Tf">the end of a measurement interval, (format sectionFormat="of" section="5.6"/>; see also
"date-and-time" as specified in Section 5.6 of <xref "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
target="RFC3339"/>, see also Section 3 of <xref "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
target="RFC6991"/>). The UTC Time Zone is required by Section tionFormat="of" section="6.1"/>.</dd>
6.1 of <xref target="RFC2330"/>.</t> <dt>Tf:</dt>
</list></t> <dd>The end of a measurement interval (format
"date&nbhy;time" as specified in <xref target="RFC3339"
<t>For LossRatio -- the count of lost packets to total packets sent sectionFormat="of" section="5.6"/>; see also
is the basis for the loss ratio calculation as per Section 4.1 of "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
<xref target="RFC7680"/>.</t> "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
tionFormat="of" section="6.1"/>.</dd>
<t>For each &lt;statistic&gt;, one of the following sub-sections </dl>
apply:</t> <t>For LossRatio, the count of lost packets to total packets sent
is the basis for the loss ratio calculation as per <xref target="RFC76
<section title="Percentile95"> 80" sectionFormat="of" section="4.1"/>.</t>
<t>The 95th percentile SHALL be calculated using the conditional <t>For each &lt;statistic&gt; or Percent_LossRatio, one of the followi
distribution of all packets with a finite value of One-way delay ng subsections
(undefined delays are excluded), a single value as follows:</t> applies.</t>
<!-- 8.4.2.1 -->
<t>See section 4.1 of <xref target="RFC3393"/> for details on the <section numbered="true" toc="default">
<name>Percentile95</name>
<t>The 95th percentile <bcp14>SHALL</bcp14> 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:</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for
details on the
conditional distribution to exclude undefined values of delay, and conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this see <xref target="RFC6703" sectionFormat="of" section="5"/> for back ground on this
analysis choice.</t> analysis choice.</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.3"/> for
<t>See section 4.3 of <xref target="RFC3393"/> for details on the details on the
percentile statistic (where Round-trip delay should be substituted percentile statistic (where round-trip delay should be substituted
for "ipdv").</t> for "ipdv").</t>
<t>The percentile = 95, meaning that the reported delay, <t>The percentile = 95, meaning that the reported delay,
"95Percentile", is the smallest value of one-way delay for which "95Percentile", is the smallest value of one-way delay for which
the Empirical Distribution Function (EDF), F(95Percentile) &gt;= the Empirical Distribution Function, EDF(95Percentile), is greater
95% of the singleton one-way delay values in the conditional than or equal to 95% of the singleton one-way delay values in the co
distribution. See section 11.3 of <xref target="RFC2330"/> for the nditional
distribution. See <xref target="RFC2330" sectionFormat="of" section=
"11.3"/> for the
definition of the percentile statistic using the EDF.</t> definition of the percentile statistic using the EDF.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>95Percentile:</dt>
<t hangText="95Percentile">The time value of the result is <dd>The time value of the result is
expressed in units of seconds, as a positive value of type expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 9 (see section 9.3 of <xref decimal64 with fraction digits = 9 (see <xref target="RFC6020" s
target="RFC6020"/>) with resolution of 0.000000001 seconds ectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds
(1.0 ns), and with lossless conversion to/from the 64-bit NTP (1.0 ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" secti
target="RFC5905">RFC</xref></t> on="6"/>.</dd>
</list></t> </dl>
</section> </section>
<section title="Mean"> <!-- 8.4.2.2 -->
<t>The mean SHALL be calculated using the conditional distribution <section anchor="mean-sec8422" numbered="true" toc="default">
of all packets with a finite value of One-way delay (undefined <name>Mean</name>
delays are excluded), a single value as follows:</t> <t>The mean <bcp14>SHALL</bcp14> be calculated using the conditional
distribution
<t>See section 4.1 of <xref target="RFC3393"/> for details on the of all packets with a finite value of one-way delay (undefined
delays are excluded) -- a single value, as follows:</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for
details on the
conditional distribution to exclude undefined values of delay, and conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this see <xref target="RFC6703" sectionFormat="of" section="5"/> for back ground on this
analysis choice.</t> analysis choice.</t>
<t>See <xref target="RFC6049" sectionFormat="of" section="4.2.2"/> f
<t>See section 4.2.2 of <xref target="RFC6049"/> for details on or details on
calculating this statistic, and 4.2.3 of <xref calculating this statistic; see also <xref target="RFC6049" sectionF
target="RFC6049"/>.</t> ormat="of" section="4.2.3"/>.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Mean:</dt>
<t hangText="Mean">The time value of the result is expressed <dd>The time value of the result is expressed
in units of seconds, as a positive value of type decimal64 in units of seconds, as a positive value of type decimal64
with fraction digits = 9 (see section 9.3 of <xref with fraction digits = 9 (see <xref target="RFC6020" sectionForm
target="RFC6020"/>) with resolution of 0.000000001 seconds at="of" section="9.3"/>) with a resolution of 0.000000001&nbsp;seconds
(1.0 ns), and with lossless conversion to/from the 64-bit NTP (1.0 ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" secti
target="RFC5905">RFC</xref></t> on="6"/>.</dd>
</list></t> </dl>
</section> </section>
<section title="Min"> <!-- 8.4.2.3 -->
<t>The minimum SHALL be calculated using the conditional <section numbered="true" toc="default">
distribution of all packets with a finite value of One-way delay <name>Min</name>
(undefined delays are excluded), a single value as follows:</t> <t>The minimum <bcp14>SHALL</bcp14> be calculated using the conditio
nal
<t>See section 4.1 of <xref target="RFC3393"/> for details on the distribution of all packets with a finite value of one-way delay
(undefined delays are excluded) -- a single value, as follows:</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for
details on the
conditional distribution to exclude undefined values of delay, and conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this see <xref target="RFC6703" sectionFormat="of" section="5"/> for back ground on this
analysis choice.</t> analysis choice.</t>
<t>See <xref target="RFC6049" sectionFormat="of" section="4.3.2"/> f
<t>See section 4.3.2 of <xref target="RFC6049"/> for details on or details on
calculating this statistic, and 4.3.3 of <xref calculating this statistic; see also <xref target="RFC6049" sectionF
target="RFC6049"/>.</t> ormat="of" section="4.3.3"/>.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Min:</dt>
<t hangText="Min">The time value of the result is expressed in <dd>The time value of the result is expressed in
units of seconds, as a positive value of type decimal64 with units of seconds, as a positive value of type decimal64 with
fraction digits = 9 (see section 9.3 of <xref fraction digits = 9 (see <xref target="RFC6020" sectionFormat="o
target="RFC6020"/>) with resolution of 0.000000001 seconds f" section="9.3"/>) with a resolution of 0.000000001&nbsp;seconds
(1.0 ns), and with lossless conversion to/from the 64-bit NTP (1.0 ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" secti
target="RFC5905">RFC</xref></t> on="6"/>.</dd>
</list></t> </dl>
</section> </section>
<!-- 8.4.2.4 -->
<section title="Max"> <section numbered="true" toc="default">
<t>The maximum SHALL be calculated using the conditional <name>Max</name>
distribution of all packets with a finite value of One-way delay <t>The maximum <bcp14>SHALL</bcp14> be calculated using the conditio
(undefined delays are excluded), a single value as follows:</t> nal
distribution of all packets with a finite value of one-way delay
<t>See section 4.1 of <xref target="RFC3393"/> for details on the (undefined delays are excluded) -- a single value, as follows:</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for
details on the
conditional distribution to exclude undefined values of delay, and conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this see <xref target="RFC6703" sectionFormat="of" section="5"/> for back ground on this
analysis choice.</t> analysis choice.</t>
<t>See <xref target="RFC6049" sectionFormat="of" section="4.3.2"/> f
or a closely
related method for calculating this statistic; see also <xref target
="RFC6049" sectionFormat="of" section="4.3.3"/>. The formula is as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Max = (FiniteDelay[j])
]]></artwork>
<t>See section 4.3.2 of <xref target="RFC6049"/> for a closely <ul empty="true">
related method for calculating this statistic, and 4.3.3 of <xref <li>such that for some index, j, where 1 &lt;= j &lt;= N
target="RFC6049"/>. The formula is as follows:</t> FiniteDelay[j]&nbsp;&gt;=&nbsp;FiniteDelay[n] for all n</li>
</ul>
<t><figure> <dl newline="false" spacing="normal">
<artwork><![CDATA[ Max = (FiniteDelay [j]) <dt>Max:</dt>
<dd>The time value of the result is expressed in
such that for some index, j, where 1 <= j <= N
FiniteDelay[j] >= FiniteDelay[n] for all n]]></artwork>
</figure></t>
<t><list style="hanging">
<t hangText="Max">The time value of the result is expressed in
units of seconds, as a positive value of type decimal64 with units of seconds, as a positive value of type decimal64 with
fraction digits = 9 (see section 9.3 of <xref fraction digits = 9 (see <xref target="RFC6020" sectionFormat="o
target="RFC6020"/>) with resolution of 0.000000001 seconds f" section="9.3"/>) with a resolution of 0.000000001&nbsp;seconds
(1.0 ns), and with lossless conversion to/from the 64-bit NTP (1.0 ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" secti
target="RFC5905">RFC</xref></t> on="6"/>.</dd>
</list></t> </dl>
</section> </section>
<!-- 8.4.2.5 -->
<section title="Std_Dev"> <section numbered="true" toc="default">
<t>The Std_Dev SHALL be calculated using the conditional <name>Std_Dev</name>
distribution of all packets with a finite value of One-way delay <t>Std_Dev <bcp14>SHALL</bcp14> be calculated using the conditional
(undefined delays are excluded), a single value as follows:</t> distribution of all packets with a finite value of one&nbhy;way dela
y
<t>See section 4.1 of <xref target="RFC3393"/> for details on the (undefined delays are excluded) -- a single value, as follows:</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for
details on the
conditional distribution to exclude undefined values of delay, and conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this see <xref target="RFC6703" sectionFormat="of" section="5"/> for back ground on this
analysis choice.</t> analysis choice.</t>
<t>See <xref target="RFC6049" sectionFormat="of" section="6.1.4"/> f
<t>See section 4.3.2 of <xref target="RFC6049"/> for a closely or a closely
related method for calculating this statistic, and 4.3.3 of <xref related method for calculating this statistic. The formula
target="RFC6049"/>. The formula is the classic calculation for is the classic calculation for the
standard deviation of a population.</t> standard deviation of a population.</t>
<figure> <t>Define Population Std_Dev_Delay as follows:</t>
<artwork><![CDATA[Define Population Std_Dev_Delay as follows:
(where all packets n = 1 through N have a value for Delay[n],
and MeanDelay calculated as in 7.4.2.2), and SQRT[] is the
Square Root function:
_ _
| N |
| --- |
| 1 \ 2 |
Std_Dev = SQRT | ------- > (Delay[n] - MeanDelay) |
| (N) / |
| --- |
| n = 1 |
|_ _|
]]></artwork>
</figure>
<t/> <artwork name="" type="" align="left" alt=""><![CDATA[
_ _
| N |
| --- |
| 1 \ 2 |
Std_Dev = SQRT | ------- > (Delay[n] - MeanDelay) |
| (N) / |
| --- |
| n = 1 |
|_ _|
]]></artwork>
<t><list style="hanging"> <t>where all packets n = 1 through N have a value for Delay[n],
<t hangText="Std_Dev">The time value of the result is MeanDelay is calculated per <xref target="mean-sec8422"/>,
and SQRT[] is the Square Root function:</t>
<dl newline="false" spacing="normal">
<dt>Std_Dev:</dt>
<dd>The time value of the result is
expressed in units of seconds, as a positive value of type expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 9 (see section 9.3 of <xref decimal64 with fraction digits = 9 (see <xref target="RFC6020" s
target="RFC6020"/>) with resolution of 0.000000001 seconds ectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds
(1.0 ns), and with lossless conversion to/from the 64-bit NTP (1.0 ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" secti
target="RFC5905">RFC</xref></t> on="6"/>.</dd>
</list></t> </dl>
</section> </section>
</section> <!-- 8.4.2.6 -->
<section>
<name>Percent_LossRatio</name>
<section title="Metric Units"> <dl>
<t>The &lt;statistic&gt; of One-way Delay is expressed in seconds, <dt>Percent_LossRatio:</dt><dd>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
<xref target="RFC6020" sectionFormat="of" section="9.3"/> with a
resolution of 0.0000000001.</dd></dl>
</section>
</section>
<!-- 8.4.3 -->
<section numbered="true" toc="default">
<name>Metric Units</name>
<t>The &lt;statistic&gt; of one-way delay is expressed in seconds,
where &lt;statistic&gt; is one of:</t> where &lt;statistic&gt; is one of:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>95Percentile</li>
<t>95Percentile</t> <li>Mean</li>
<li>Min</li>
<t>Mean</t> <li>Max</li>
<li>StdDev</li>
<t>Min</t> </ul>
<t>The one-way loss ratio is expressed as a percentage of lost
<t>Max</t>
<t>StdDev</t>
</list></t>
<t>The One-way Loss Ratio is expressed as a percentage of lost
packets to total packets sent.</t> packets to total packets sent.</t>
</section>
<section title="Calibration"> </section>
<t>Section 3.7.3 of <xref target="RFC7679"/> provides a means to <!-- 8.4.4 -->
<section numbered="true" toc="default">
<name>Calibration</name>
<t><xref target="RFC7679" sectionFormat="of" section="3.7.3"/> provide
s a means to
quantify the systematic and random errors of a time measurement. quantify the systematic and random errors of a time measurement.
In-situ calibration could be enabled with an internal loopback that Calibration in-situ could be enabled with an internal loopback that
includes as much of the measurement system as possible, performs includes as much of the measurement system as possible, performs
address manipulation as needed, and provides some form of isolation address manipulation as needed, and provides some form of isolation
(e.g., deterministic delay) to avoid send-receive interface (e.g., deterministic delay) to avoid send-receive interface
contention. Some portion of the random and systematic error can be contention. Some portion of the random and systematic error can be
characterized this way.</t> characterized in this way.</t>
<t>For one-way delay measurements, the error calibration must <t>For one-way delay measurements, the error calibration must
include an assessment of the internal clock synchronization with its include an assessment of the internal clock synchronization with its
external reference (this internal clock is supplying timestamps for external reference (this internal clock is supplying timestamps for
measurement). In practice, the time offsets <xref target="RFC5905"/> measurement). In practice, the time offsets <xref target="RFC5905" for
of clocks at both the source and destination are needed to estimate mat="default"/>
of clocks at both the Source and Destination are needed to estimate
the systematic error due to imperfect clock synchronization (the the systematic error due to imperfect clock synchronization (the
time offsets <xref target="RFC5905"/> are smoothed, thus the random time offsets <xref target="RFC5905" format="default"/> are smoothed; t
variation is not usually represented in the results).<list hus, the random
style="hanging"> variation is not usually represented in the results).</t>
<t hangText="time_offset">The time value of the result is <dl newline="false" spacing="normal">
<dt>time_offset:</dt>
<dd>The time value of the result is
expressed in units of seconds, as a signed value of type expressed in units of seconds, as a signed value of type
decimal64 with fraction digits = 9 (see section 9.3 of <xref decimal64 with fraction digits&nbsp;=&nbsp;9 (see <xref target="RF
target="RFC6020"/>) with resolution of 0.000000001 seconds (1.0 C6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seco
nds (1.0
ns), and with lossless conversion to/from the 64-bit NTP ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" section
target="RFC5905">RFC</xref></t> ="6"/>.</dd>
</list></t> </dl>
<t>When a measurement controller requests a calibration measurement, <t>When a measurement controller requests a calibration measurement,
the loopback is applied and the result is output in the same format the loopback is applied and the result is output in the same format
as a normal measurement with additional indication that it is a as a normal measurement, with an additional indication that it is a
calibration result. In any measurement, the measurement function calibration result. In any measurement, the measurement function
SHOULD report its current estimate of time offset <xref <bcp14>SHOULD</bcp14> report its current estimate of the time offset <
target="RFC5905"/> as an indicator of the degree of xref target="RFC5905" format="default"/> as an indicator of the degree of
synchronization.</t> synchronization.</t>
<t>Both internal loopback calibration and clock synchronization can <t>Both internal loopback calibration and clock synchronization can
be used to estimate the available accuracy of the Output Metric be used to estimate the available accuracy of the Output Metric
Units. For example, repeated loopback delay measurements will reveal Units. For example, repeated loopback delay measurements will reveal
the portion of the Output result resolution which is the result of the portion of the output result resolution that is the result of
system noise, and thus inaccurate.</t> system noise and is thus inaccurate.</t>
<t/>
</section> </section>
</section> </section>
<section title="Administrative items"> <!-- 8.5 -->
<t/> <section numbered="true" toc="default">
<name>Administrative Items</name>
<section title="Status"> <!-- 8.5.1 -->
<section numbered="true" toc="default">
<name>Status</name>
<t>Current</t> <t>Current</t>
</section> </section>
<!-- 8.5.2 -->
<section title="Requester"> <section numbered="true" toc="default">
<t>This RFC number</t> <name>Requester</name>
<t>RFC 8912</t>
</section> </section>
<!-- 8.5.3 -->
<section title="Revision"> <section numbered="true" toc="default">
<name>Revision</name>
<t>1.0</t> <t>1.0</t>
</section> </section>
<!-- 8.5.4 -->
<section title="Revision Date"> <section numbered="true" toc="default">
<t>YYYY-MM-DD</t> <name>Revision Date</name>
<t>2021-11-17</t>
</section> </section>
</section> </section>
<!-- 8.6 -->
<section title="Comments and Remarks"> <section numbered="true" toc="default">
<t>None.</t> <name>Comments and Remarks</name>
<t>None</t>
</section> </section>
</section> </section>
<!-- Section 9 -->
<section title="ICMP Round-trip Latency and Loss Registry Entries"> <section anchor="icmp_roundtrip_latency_and_loss" numbered="true" toc="defau
<t>This section specifies three initial registry entries for the ICMP lt">
Round-trip Latency, and another entry for ICMP Round-trip Loss <name>ICMP Round-Trip Latency and Loss Registry Entries</name>
<t>This section specifies three initial Registry Entries for ICMP
Round&nbhy;Trip Latency and another entry for the ICMP Round-Trip Loss
Ratio.</t> Ratio.</t>
<t>IANA Note: Registry "Name" below specifies multiple registry entries, <t>All column entries besides the ID, Name, Description, and Output
whose output format varies according to the &lt;statistic&gt; element of Reference Method categories are the same; thus, this section defines four
the name that specifies one form of statistical summary. There is an closely related Registry Entries. As a result, IANA has
additional metric name for the Loss metric.</t> assigned corresponding URLs to each of the four Named Metrics.</t>
<t>All column entries beside the ID, Name, Description, and Output
Reference Method categories are the same, thus this section proposes two
closely-related registry entries. As a result, IANA is also asked to
assign corresponding URLs to each Named Metric.</t>
<section title="Summary">
<t>This category includes multiple indexes to the registry entry: the
element ID and metric name.</t>
<section title="ID (Identifier)"> <!-- 9.1 -->
<t>IANA is asked to assign different numeric identifiers to each of <section numbered="true" toc="default">
the four Named Metrics.</t> <name>Summary</name>
<t>This category includes multiple indexes to the Registry Entries: the
element ID and Metric Name.</t>
<!-- 9.1.1 -->
<section numbered="true" toc="default">
<name>ID (Identifier)</name>
<t>IANA has allocated the numeric Identifiers 18-21 for the four
Named Metric Entries in <xref target="icmp_roundtrip_latency_and_loss"/
>.
See <xref target="name912"/> for mapping to Names.</t>
</section> </section>
<section title="Name"> <!-- 9.1.2 -->
<t>RTDelay_Active_IP-ICMP-SendOnRcv_RFCXXXXsec9_Seconds_&lt;statistic& <section anchor="name912" numbered="true" toc="default">
gt;</t> <name>Name</name>
<dl spacing="normal" indent="5" newline="false">
<t>where &lt;statistic&gt; is one of:</t> <dt>18:</dt><dd>RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_
Mean</dd>
<t><list style="symbols"> <dt>19:</dt><dd>RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_
<t>Mean</t> Min</dd>
<dt>20:</dt><dd>RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_
<t>Min</t> Max</dd>
<dt>21:</dt><dd>RTLoss_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Percent_
<t>Max</t> LossRatio</dd>
</list></t> </dl>
<t>RTLoss_Active_IP-ICMP-SendOnRcv_RFCXXXXsec9_Percent_LossRatio</t>
</section> </section>
<!-- 9.1.3 -->
<section title="URI"> <section numbered="true" toc="default">
<t>URL: https://www.iana.org/ ... &lt;name&gt;</t> <name>URI</name>
<t>URL: <eref target="https://www.iana.org/performance-metrics/RTDelay
_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Mean"/></t>
<t>URL: <eref target="https://www.iana.org/performance-metrics/RTDelay_
Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Min"/></t>
<t>URL: <eref target="https://www.iana.org/performance-metrics/RTDelay_
Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Max"/></t>
<t>URL: <eref target="https://www.iana.org/performance-metrics/RTLoss_A
ctive_IP-ICMP-SendOnRcv_RFC8912sec9_Percent_LossRatio"/></t>
</section> </section>
<!-- 9.1.4 -->
<section title="Description"> <section numbered="true" toc="default">
<t>RTDelay: This metric assesses the delay of a stream of ICMP <name>Description</name>
<dl newline="false" spacing="normal">
<dt>RTDelay:</dt><dd><t>This metric assesses the delay of a stream of
ICMP
packets exchanged between two hosts (which are the two measurement packets exchanged between two hosts (which are the two measurement
points), and the Output is the Round-trip delay for all successfully points). The output is the round-trip delay for all successfully
exchanged packets expressed as the &lt;statistic&gt; of their exchanged packets expressed as the &lt;statistic&gt; of their
conditional delay distribution, where &lt;statistic&gt; is one conditional delay distribution, where &lt;statistic&gt; is one
of:</t> of:</t>
<ul spacing="normal">
<li>Mean</li>
<li>Min</li>
<li>Max</li>
</ul>
</dd>
<t><list style="symbols"> <dt>RTLoss:</dt><dd>This metric assesses the loss ratio of a stream of
<t>Mean</t> ICMP
<t>Min</t>
<t>Max</t>
</list></t>
<t>RTLoss: This metric assesses the loss ratio of a stream of ICMP
packets exchanged between two hosts (which are the two measurement packets exchanged between two hosts (which are the two measurement
points), and the Output is the Round-trip loss ratio for all points). The output is the round-trip loss ratio for all
successfully exchanged packets expressed as a percentage.</t> transmitted packets expressed as a percentage.</dd>
</dl>
</section> </section>
<!-- 9.1.5 -->
<section title="Change Controller"> <section numbered="true" toc="default">
<name>Change Controller</name>
<t>IETF</t> <t>IETF</t>
</section> </section>
<section title="Version (of Registry Format)"> <!-- 9.6.1 -->
<section numbered="true" toc="default">
<name>Version (of Registry Format)</name>
<t>1.0</t> <t>1.0</t>
</section> </section>
</section> </section>
<section title="Metric Definition"> <!-- 9.2 -->
<section numbered="true" toc="default">
<name>Metric Definition</name>
<t>This category includes columns to prompt the entry of all necessary <t>This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference details related to the metric definition, including the RFC reference
and values of input factors, called fixed parameters.</t> and values of input factors, called "Fixed Parameters".</t>
<section title="Reference Definition">
<t>Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
Metric for IPPM", RFC 2681, September 1999.</t>
<t><xref target="RFC2681"/></t> <!-- 9.2.1 -->
<section numbered="true" toc="default">
<name>Reference Definition</name>
<t>Section 2.4 of <xref target="RFC2681"/> provides the reference <t>For delay:</t>
definition of the singleton (single value) Round-trip delay metric. <t indent="3">Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-tri
Section 3.4 of <xref target="RFC2681"/> provides the reference p Delay
Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999,
&lt;https://www.rfc-editor.org/info/rfc2681&gt;.
<xref target="RFC2681"/></t>
<t indent="3"><xref target="RFC2681" sectionFormat="of" section="2.4"/
> provides the reference
definition of the singleton (single value) round-trip delay metric.
<xref target="RFC2681" sectionFormat="of" section="3.4"/> provides the
reference
definition expanded to cover a multi-singleton sample. Note that definition expanded to cover a multi-singleton sample. Note that
terms such as singleton and sample are defined in Section 11 of terms such as "singleton" and "sample" are defined in <xref target="RF
<xref target="RFC2330"/>.</t> C2330" sectionFormat="of" section="11"/>.</t>
<t indent="3">Note that although the definition of round-trip delay be
<t>Note that although the <xref target="RFC2681"/> definition of tween the
"Round-trip-Delay between Src and Dst" is directionally ambiguous in Source (Src) and the Destination (Dst) as provided in
the text, this metric tightens the definition further to recognize <xref target="RFC2681" sectionFormat="of" section="2.4"/>
that the host in the "Src" role will send the first packet to "Dst", is directionally ambiguous in the text, this metric
and ultimately receive the corresponding return packet from "Dst" tightens the definition further to recognize that the host in the
(when neither are lost).</t> Src Role will send the first packet to the host in the Dst Role
and will ultimately receive the corresponding return packet from the
<t>Finally, note that the variable "dT" is used in <xref Dst (when neither is lost).</t>
target="RFC2681"/> to refer to the value of Round-trip delay in <t indent="3">Finally, note that the variable "dT" is used in <xref ta
metric definitions and methods. The variable "dT" has been re-used rget="RFC2681" format="default"/> to refer to the value of round-trip delay in
in other IPPM literature to refer to different quantities, and 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.</t> cannot be used as a global variable name.</t>
<t>Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August <t>For loss:</t>
2012.</t>
<t><xref target="RFC6673"/></t>
<t>Both delay and loss metrics employ a maximum waiting time for <t indent="3">Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673,
DOI 10.17487/RFC6673, August 2012,
&lt;https://www.rfc-editor.org/info/rfc6673&gt;.
<xref target="RFC6673"/></t>
<t>Both Delay and Loss metrics employ a maximum waiting time for
received packets, so the count of lost packets to total packets sent received packets, so the count of lost packets to total packets sent
is the basis for the loss ratio calculation as per Section 6.1 of is the basis for the loss ratio calculation as per <xref target="RFC66
<xref target="RFC6673"/>.</t> 73" sectionFormat="of" section="6.1"/>.</t>
</section> </section>
<!-- 9.2.2 -->
<section numbered="true" toc="default">
<name>Fixed Parameters</name>
<dl newline="true" spacing="normal">
<dt>Type-P as defined in <xref target="RFC2330" sectionFormat="of" sec
tion="13"/>:</dt><dd><t/>
<dl newline="true" spacing="normal">
<dt>IPv4 header values:</dt>
<dd><t/>
<dl newline="false" spacing="compact">
<dt>DSCP:</dt><dd>Set to 0</dd>
<dt>TTL:</dt><dd>Set to 255</dd>
<dt>Protocol:</dt><dd>Set to 01 (ICMP)</dd>
</dl>
</dd>
<section title="Fixed Parameters"> <dt>IPv6 header values:</dt>
<t>Type-P as defined in Section 13 of <xref target="RFC2330"/>: <dd><t/>
<list style="symbols"> <dl newline="false" spacing="compact">
<t>IPv4 header values: <list style="symbols"> <dt>DSCP:</dt><dd>Set to 0</dd>
<t>DSCP: set to 0</t> <dt>Hop Count:</dt><dd>Set to 255</dd>
<dt>Next Header:</dt><dd>Set to 128 decimal (ICMP)</dd>
<t>TTL: set to 255</t> <dt>Flow Label:</dt><dd>Set to 0</dd>
<dt>Extension Headers:</dt><dd>None</dd>
<t>Protocol: Set to 01 (ICMP)</t> </dl>
</list></t> </dd>
<t>IPv6 header values:<list style="symbols">
<t>DSCP: set to 0</t>
<t>Hop Count: set to 255</t>
<t>Next Header: set to 128 decimal (ICMP)</t>
<t>Flow Label: set to zero</t>
<t>Extension Headers: none</t>
</list></t>
<t>ICMP header values: <list style="symbols">
<t>Type: 8 (Echo Request)</t>
<t>Code: 0</t>
<t>Checksum: the checksum MUST be calculated and the
non-zero checksum included in the header</t>
<t>(Identifier and Sequence Number set at Run-Time)</t> <dt>ICMP header values:</dt>
</list></t> <dd><t/>
<dl newline="false" spacing="compact">
<dt>Type:</dt><dd>8 (Echo Request)</dd>
<dt>Code:</dt><dd>0</dd>
<dt>Checksum:</dt><dd>The checksum <bcp14>MUST</bcp14> be calculate
d and the
non-zero checksum included in the header</dd>
<dt>(Identifier and sequence number set at runtime)</dt><dd/>
</dl>
</dd>
<t>ICMP Payload <list style="symbols"> <dt>ICMP Payload:</dt>
<t>total of 32 bytes of random info, constant per test.</t> <dd>Total of 32 bytes of random information, constant per test</dd>
</list></t> </dl>
</list></t> </dd>
</dl>
<t>Other measurement parameters:<list style="symbols"> <dl newline="true" spacing="normal">
<t>Tmax: a loss threshold waiting time<list style="symbols"> <dt>Other measurement Parameters:</dt>
<t>3.0, expressed in units of seconds, as a positive value <dd><t/>
of type decimal64 with fraction digits = 4 (see section 9.3 <dl newline="false" spacing="normal">
of <xref target="RFC6020"/>) and with resolution of 0.0001 <dt>Tmax:</dt>
seconds (0.1 ms), with lossless conversion to/from the <dd>A loss threshold waiting time with value 3.0, expressed in un
32-bit NTP timestamp as per section 6 of <xref its of seconds, as a positive value
target="RFC5905"/>.</t> of type decimal64 with fraction digits = 4 (see <xref target="RFC
</list></t> 6020" sectionFormat="of" section="9.3"/>) and with a resolution of 0.0001
</list></t> seconds (0.1 ms), with lossless conversion to/from the
32-bit NTP timestamp as per <xref target="RFC5905"
sectionFormat="of" section="6"/>.</dd>
</dl>
</dd>
</dl>
</section> </section>
</section> </section>
<section title="Method of Measurement"> <!-- 9.3 -->
<section numbered="true" toc="default">
<name>Method of Measurement</name>
<t>This category includes columns for references to relevant sections <t>This category includes columns for references to relevant sections
of the RFC(s) and any supplemental information needed to ensure an of the RFC(s) and any supplemental information needed to ensure
unambiguous methods for implementations.</t> an unambiguous method for implementations.</t>
<section title="Reference Method">
<t>The methodology for this metric is defined as
Type-P-Round-trip-Delay-Poisson-Stream in section 2.6 of <xref
target="RFC2681">RFC 2681</xref> and section 3.6 of <xref
target="RFC2681">RFC 2681</xref> using the Type-P and Tmax defined
under Fixed Parameters.</t>
<!-- 9.3.1 -->
<section numbered="true" toc="default">
<name>Reference Methods</name>
<t>The methodology for this metric (equivalent to
Type-P-Round-trip-Delay-Poisson-Stream) is defined as in <xref target=
"RFC2681"
sectionFormat="of" section="2.6"/> (for singletons) and <xref
target="RFC2681" sectionFormat="of" section="3.6"/> (for samples)
using the Type-P and Tmax defined in the Fixed Parameters column.</t>
<t>The reference method distinguishes between long-delayed packets <t>The reference method distinguishes between long-delayed packets
and lost packets by implementing a maximum waiting time for packet and lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a arrival. Tmax is the waiting time used as the threshold to declare a
packet lost. Lost packets SHALL be designated as having undefined packet lost. Lost packets <bcp14>SHALL</bcp14> be designated as having
delay, and counted for the RTLoss metric.</t> undefined
delay and counted for the RTLoss metric.</t>
<t>The calculations on the delay (RTD) SHALL be performed on the <t>The calculations on the delay (RTD) <bcp14>SHALL</bcp14> be perform
ed on the
conditional distribution, conditioned on successful packet arrival conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process within Tmax. Also, when all packet delays are stored, the process
which calculates the RTD value MUST enforce the Tmax threshold on that calculates the RTD value <bcp14>MUST</bcp14> enforce the Tmax thr
stored values before calculations. See section 4.1 of <xref eshold on
target="RFC3393"/> for details on the conditional distribution to stored values before calculations. See <xref target="RFC3393" sectionF
exclude undefined values of delay, and Section 5 of <xref ormat="of" section="4.1"/> for details on the conditional distribution to
target="RFC6703"/> for background on this analysis choice.</t> exclude undefined values of delay, and see <xref target="RFC6703" sect
ionFormat="of" section="5"/> for background on this analysis choice.</t>
<t>The reference method requires some way to distinguish between <t>The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving sending times and receiving times for each successfully arriving
packet. Sequence numbers or other send-order identification MUST be packet. Sequence numbers or other send-order identification <bcp14>MUS
T</bcp14> be
retained at the Src or included with each packet to disambiguate retained at the Src or included with each packet to disambiguate
packet reordering if it occurs.</t> packet reordering if it occurs.</t>
<t>The measurement process will determine the sequence numbers <t>The measurement process will determine the sequence numbers
applied to test packets after the Fixed and Runtime parameters are applied to test packets after the Fixed and Runtime Parameters are
passed to that process. The ICMP measurement process and protocol passed to that process. The ICMP measurement process and protocol
will dictate the format of sequence numbers and other will dictate the format of sequence numbers and other
identifiers.</t> Identifiers.</t>
<t>Refer to <xref target="RFC6673" sectionFormat="of" section="4.4"/>
<t>Refer to Section 4.4 of <xref target="RFC6673"/> for expanded for an expanded
discussion of the instruction to "send a Type-P packet back to the discussion of the instruction to "send a Type-P packet back to the
Src as quickly as possible" in Section 2.6 of <xref Src as quickly as possible" in <xref target="RFC2681" sectionFormat="o
target="RFC2681">RFC 2681</xref>. Section 8 of <xref f" section="2.6"/>. <xref target="RFC6673" sectionFormat="of" section="8"/> pres
target="RFC6673"/> presents additional requirements which MUST be ents additional requirements that <bcp14>MUST</bcp14> be
included in the method of measurement for this metric.</t> included in the Method of Measurement for this metric.</t>
</section> </section>
<!-- 9.3.2 -->
<section title="Packet Stream Generation"> <section numbered="true" toc="default">
<t>This section gives the details of the packet traffic which is the <name>Packet Stream Generation</name>
basis for measurement. In IPPM metrics, this is called the Stream, <t>This section provides details regarding packet traffic, which is
and can easily be described by providing the list of stream used as the
parameters.</t> basis for measurement. In IPPM Metrics, this is called the "stream";
this stream can easily be described by providing the list of stream
Parameters.</t>
<t>The ICMP metrics use a sending discipline called "SendOnRcv" or <t>The ICMP metrics use a sending discipline called "SendOnRcv" or
Send On Receive. This is a modification of Section 3 of <xref Send On Receive. This is a modification of <xref target="RFC3432" sect
target="RFC3432"/>, which prescribes the method for generating ionFormat="of" section="3"/>, which prescribes the method for generating
Periodic streams using associated parameters as defined below for Periodic streams using associated Parameters as defined below for
this description:</t> this description:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>incT:</dt>
<t hangText="incT">the nominal duration of inter-packet <dd>The nominal duration of the inter-packet
interval, first bit to first bit</t> interval, first bit to first bit.</dd>
<dt>dT:</dt>
<t hangText="dT">the duration of the interval for allowed sample <dd>The duration of the interval for allowed sample
start times</t> start times.</dd>
</list></t> </dl>
<t>The incT stream Parameter will be specified as a Runtime
<t>The incT stream parameter will be specified as a Run-time Parameter, and dT is not used in SendOnRcv.</t>
parameter, and dT is not used in SendOnRcv.</t>
<t>A SendOnRcv sender behaves exactly like a Periodic stream <t>A SendOnRcv sender behaves exactly like a Periodic stream
generator while all reply packets arrive with RTD &lt; incT, and the generator while all reply packets arrive with RTD &lt; incT, and the
inter-packet interval will be constant.</t> inter-packet interval will be constant.</t>
<t>If a reply packet arrives with RTD &gt;= incT, then the <t>If a reply packet arrives with RTD &gt;= incT, then the
inter-packet interval for the next sending time is nominally inter-packet interval for the next sending time is nominally
RTD.</t> RTD.</t>
<t>If a reply packet fails to arrive within Tmax, then the <t>If a reply packet fails to arrive within Tmax, then the
inter-packet interval for the next sending time is nominally inter-packet interval for the next sending time is nominally
Tmax.</t> Tmax.</t>
<t>If an immediate Send On Reply arrival is desired, then set
<t>If an immediate send on reply arrival is desired, then set incT&nbsp;=&nbsp;0.</t>
incT=0.</t>
</section> </section>
<section title="Traffic Filtering (observation) Details"> <!-- 9.3.3 -->
<t>NA</t> <section numbered="true" toc="default">
<name>Traffic Filtering (Observation) Details</name>
<t>N/A</t>
</section> </section>
<section title="Sampling Distribution"> <!-- 9.3.4 -->
<t>NA</t> <section numbered="true" toc="default">
<name>Sampling Distribution</name>
<t>N/A</t>
</section> </section>
<section title="Run-time Parameters and Data Format"> <!-- 9.3.5 -->
<t>Run-time Parameters are input factors that must be determined, <section numbered="true" toc="default">
<name>Runtime Parameters and Data Format</name>
<t>Runtime Parameters are input factors that must be determined,
configured into the measurement system, and reported with the configured into the measurement system, and reported with the
results for the context to be complete.</t> results for the context to be complete.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Src:</dt>
<t hangText="Src">the IP address of the host in the Src Role <dd>The IP address of the host in the Src Role
(format ipv4-address-no-zone value for IPv4, or (format ipv4&nbhy;address-no-zone value for IPv4 or
ipv6-address-no-zone value for IPv6, see Section 4 of <xref ipv6-address-no-zone value for IPv6; see <xref target="RFC6991" se
target="RFC6991"/>)</t> ctionFormat="of" section="4"/>).</dd>
<dt>Dst:</dt>
<t hangText="Dst">the IP address of the host in the Dst Role <dd>The IP address of the host in the Dst Role
(format ipv4-address-no-zone value for IPv4, or (format ipv4&nbhy;address-no-zone value for IPv4 or
ipv6-address-no-zone value for IPv6, see section 4 of <xref ipv6-address-no-zone value for IPv6; see <xref target="RFC6991" se
target="RFC6991"/>)</t> ctionFormat="of" section="4"/>).</dd>
<dt>incT:</dt>
<t hangText="incT">the nominal duration of inter-packet <dd>The nominal duration of the inter-packet
interval, first bit to first bit, expressed in units of seconds, interval, first bit to first bit, expressed in units of seconds,
as a positive value of type decimal64 with fraction digits = 4 as a positive value of type decimal64 with fraction digits = 4
(see section 9.3 of <xref target="RFC6020"/>) and with (see <xref target="RFC6020" sectionFormat="of" section="9.3"/>)
resolution of 0.0001 seconds (0.1 ms).</t> and with a resolution of 0.0001 seconds (0.1 ms).</dd>
<dt>T0:</dt>
<t hangText="T0">a time, the start of a measurement interval, <dd>A time, the start of a measurement interval
(format "date-and-time" as specified in Section 5.6 of <xref (format "date&nbhy;time" as specified in <xref target="RFC3339"
target="RFC3339"/>, see also Section 3 of <xref sectionFormat="of" section="5.6"/>; see also
target="RFC6991"/>). The UTC Time Zone is required by Section "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
6.1 of <xref target="RFC2330"/>. When T0 is "all-zeros", a start "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
time is unspecified and Tf is to be interpreted as the Duration tionFormat="of" section="6.1"/>. 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 of the measurement interval. The start time is controlled
through other means.</t> through other means.</dd>
<dt>Count:</dt>
<t hangText="Count">The total count of ICMP Echo Requests to <dd>The total count of ICMP Echo Requests to
send, formatted as a uint16, as per section 9.2 of <xref send, formatted as a uint16, as per <xref target="RFC6020" section
target="RFC6020"/>.</t> Format="of" section="9.2"/>.</dd>
</list></t> </dl>
<t>See the Packet Stream Generation section for
<t>(see the Packet Stream Generation section for additional Run-time additional Runtime Parameters.</t>
parameters)</t>
</section> </section>
<section title="Roles"> <!-- 9.3.6 -->
<t><list style="hanging"> <section numbered="true" toc="default">
<t hangText="Src">launches each packet and waits for return <name>Roles</name>
transmissions from Dst.</t> <dl newline="false" spacing="normal">
<dt>Src:</dt>
<t hangText="Dst">waits for each packet from Src and sends a <dd>Launches each packet and waits for return
return packet to Src.</t> transmissions from the Dst.</dd>
</list></t> <!-- Section 9.3.6 -->
<dt>Dst:</dt>
<dd>Waits for each packet from the Src and sends a return packet to
the Src (ICMP Echo Reply, Type 0).</dd>
</dl>
</section> </section>
</section> </section>
<section title="Output"> <!-- 9.4 -->
<t>This category specifies all details of the Output of measurements <section numbered="true" toc="default">
<name>Output</name>
<t>This category specifies all details of the output of measurements
using the metric.</t> using the metric.</t>
<section title="Type"> <!-- 9.4.1 -->
<t>See subsection titles in Reference Definition for Latency <section numbered="true" toc="default">
Types.</t> <name>Type</name>
<t>Latency and Loss Types are discussed in the subsections below.</t>
<t>LossRatio -- the count of lost packets to total packets sent is
the basis for the loss ratio calculation as per Section 6.1 of <xref
target="RFC6673"/>.</t>
</section> </section>
<section title="Reference Definition"> <!-- 9.4.2 -->
<t>For all output types ---<list style="hanging"> <section numbered="true" toc="default">
<t hangText="T0">the start of a measurement interval, (format <name>Reference Definition</name>
"date-and-time" as specified in Section 5.6 of <xref <t>For all output types:</t>
target="RFC3339"/>, see also Section 3 of <xref <dl newline="false" spacing="normal">
target="RFC6991"/>). The UTC Time Zone is required by Section <dt>T0:</dt>
6.1 of <xref target="RFC2330"/>.</t> <dd>The start of a measurement interval (format
"date&nbhy;time" as specified in <xref target="RFC3339"
<t hangText="Tf">the end of a measurement interval, (format sectionFormat="of" section="5.6"/>; see also
"date-and-time" as specified in Section 5.6 of <xref "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
target="RFC3339"/>, see also Section 3 of <xref "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
target="RFC6991"/>). The UTC Time Zone is required by Section tionFormat="of" section="6.1"/>.</dd>
6.1 of <xref target="RFC2330"/>.</t> <dt>Tf:</dt>
<dd>The end of a measurement interval (format
<t hangText="TotalCount">the count of packets actually sent by "date&nbhy;time" as specified in <xref target="RFC3339"
the Src to Dst during the measurement interval.</t> sectionFormat="of" section="5.6"/>; see also
</list></t> "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
"of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
<t>For LossRatio -- the count of lost packets to total packets sent tionFormat="of" section="6.1"/>.</dd>
is the basis for the loss ratio calculation as per Section 4.1 of <dt>TotalCount:</dt>
<xref target="RFC7680"/>.</t> <dd>The count of packets actually sent by
the Src to the Dst during the measurement interval.</dd>
<t>For each &lt;statistic&gt;, one of the following sub-sections </dl>
apply:</t> <t>For each &lt;statistic&gt; or Percent_LossRatio, one of the followi
ng subsections
<section title="Mean"> applies.</t>
<t>The mean SHALL be calculated using the conditional distribution <!-- 9.4.2.1 -->
of all packets with a finite value of Round-trip delay (undefined <section numbered="true" toc="default">
delays are excluded), a single value as follows:</t> <name>Mean</name>
<t>The mean <bcp14>SHALL</bcp14> be calculated using the conditional
<t>See section 4.1 of <xref target="RFC3393"/> for details on the distribution
of all packets with a finite value of round-trip delay (undefined
delays are excluded) -- a single value, as follows:</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for
details on the
conditional distribution to exclude undefined values of delay, and conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this see <xref target="RFC6703" sectionFormat="of" section="5"/> for back ground on this
analysis choice.</t> analysis choice.</t>
<t>See <xref target="RFC6049" sectionFormat="of" section="4.2.2"/> f
<t>See section 4.2.2 of <xref target="RFC6049"/> for details on or details on
calculating this statistic, and 4.2.3 of <xref calculating this statistic; see also <xref target="RFC6049" sectionF
target="RFC6049"/>.</t> ormat="of" section="4.2.3"/>.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Mean:</dt>
<t hangText="Mean">The time value of the result is expressed <dd>The time value of the result is expressed
in units of seconds, as a positive value of type decimal64 in units of seconds, as a positive value of type decimal64
with fraction digits = 9 (see section 9.3 of <xref with fraction digits = 9 (see <xref target="RFC6020" sectionForm
target="RFC6020"/>) with resolution of 0.000000001 seconds at="of" section="9.3"/>) with a resolution of 0.000000001&nbsp;seconds
(1.0 ns), and with lossless conversion to/from the 64-bit NTP (1.0 ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" secti
target="RFC5905">RFC</xref></t> on="6"/>.</dd>
</list></t> </dl>
</section> </section>
<section title="Min"> <!-- 9.4.2.2 -->
<t>The minimum SHALL be calculated using the conditional <section numbered="true" toc="default">
distribution of all packets with a finite value of Round-trip <name>Min</name>
delay (undefined delays are excluded), a single value as <t>The minimum <bcp14>SHALL</bcp14> be calculated using the conditio
nal
distribution of all packets with a finite value of round-trip
delay (undefined delays are excluded) -- a single value, as
follows:</t> follows:</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for
<t>See section 4.1 of <xref target="RFC3393"/> for details on the details on the
conditional distribution to exclude undefined values of delay, and conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this see <xref target="RFC6703" sectionFormat="of" section="5"/> for back ground on this
analysis choice.</t> analysis choice.</t>
<t>See <xref target="RFC6049" sectionFormat="of" section="4.3.2"/> f
<t>See section 4.3.2 of <xref target="RFC6049"/> for details on or details on
calculating this statistic, and 4.3.3 of <xref calculating this statistic; see also <xref target="RFC6049" sectionF
target="RFC6049"/>.</t> ormat="of" section="4.3.3"/>.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Min:</dt>
<t hangText="Min">The time value of the result is expressed in <dd>The time value of the result is expressed in
units of seconds, as a positive value of type decimal64 with units of seconds, as a positive value of type decimal64 with
fraction digits = 9 (see section 9.3 of <xref fraction digits = 9 (see <xref target="RFC6020" sectionFormat="o
target="RFC6020"/>) with resolution of 0.000000001 seconds f" section="9.3"/>) with a resolution of 0.000000001&nbsp;seconds
(1.0 ns), and with lossless conversion to/from the 64-bit NTP (1.0 ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" secti
target="RFC5905">RFC</xref></t> on="6"/>.</dd>
</list></t> </dl>
</section> </section>
<section title="Max"> <!-- 9.4.2.3 -->
<t>The maximum SHALL be calculated using the conditional <section numbered="true" toc="default">
distribution of all packets with a finite value of Round-trip <name>Max</name>
delay (undefined delays are excluded), a single value as <t>The maximum <bcp14>SHALL</bcp14> be calculated using the conditio
nal
distribution of all packets with a finite value of round-trip
delay (undefined delays are excluded) -- a single value, as
follows:</t> follows:</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for
<t>See section 4.1 of <xref target="RFC3393"/> for details on the details on the
conditional distribution to exclude undefined values of delay, and conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this see <xref target="RFC6703" sectionFormat="of" section="5"/> for back ground on this
analysis choice.</t> analysis choice.</t>
<t>See <xref target="RFC6049" sectionFormat="of" section="4.3.2"/> f
or a closely
related method for calculating this statistic; see also <xref target
="RFC6049" sectionFormat="of" section="4.3.3"/>. The formula is as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Max = (FiniteDelay[j])
]]></artwork>
<t>See section 4.3.2 of <xref target="RFC6049"/> for a closely <ul empty="true">
related method for calculating this statistic, and 4.3.3 of <xref <li>such that for some index, j, where 1 &lt;= j &lt;= N
target="RFC6049"/>. The formula is as follows:</t> FiniteDelay[j]&nbsp;&gt;=&nbsp;FiniteDelay[n] for all n</li>
</ul>
<t><figure> <dl newline="false" spacing="normal">
<artwork><![CDATA[ Max = (FiniteDelay [j]) <dt>Max:</dt>
<dd>The time value of the result is expressed in
such that for some index, j, where 1 <= j <= N
FiniteDelay[j] >= FiniteDelay[n] for all n]]></artwork>
</figure></t>
<t><list style="hanging">
<t hangText="Max">The time value of the result is expressed in
units of seconds, as a positive value of type decimal64 with units of seconds, as a positive value of type decimal64 with
fraction digits = 9 (see section 9.3 of <xref fraction digits = 9 (see <xref target="RFC6020" sectionFormat="o
target="RFC6020"/>) with resolution of 0.000000001 seconds f" section="9.3"/>) with a resolution of 0.000000001&nbsp;seconds
(1.0 ns), and with lossless conversion to/from the 64-bit NTP (1.0 ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" secti
target="RFC5905">RFC</xref></t> on="6"/>.</dd>
</list></t> </dl>
</section> </section>
</section> <!-- 9.4.2.4 -->
<section>
<name>Percent_LossRatio</name>
<t>For LossRatio, the count of lost packets to total packets sent is
the basis for the loss ratio calculation as per <xref target="RFC7680" sectionFo
rmat="of" section="4.1"/>.</t>
<dl>
<dt>Percent_LossRatio:</dt><dd>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 <xref
target="RFC6020" sectionFormat="of" section="9.3"/>) with a
resolution of 0.0000000001.</dd></dl>
</section>
<section title="Metric Units"> </section>
<t>The &lt;statistic&gt; of Round-trip Delay is expressed in <!-- 9.4.3 -->
<section numbered="true" toc="default">
<name>Metric Units</name>
<t>The &lt;statistic&gt; of round-trip delay is expressed in
seconds, where &lt;statistic&gt; is one of:</t> seconds, where &lt;statistic&gt; is one of:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Mean</li>
<t>Mean</t> <li>Min</li>
<li>Max</li>
<t>Min</t> </ul>
<t>The round-trip loss ratio is expressed as a percentage of lost
<t>Max</t>
</list></t>
<t>The Round-trip Loss Ratio is expressed as a percentage of lost
packets to total packets sent.</t> packets to total packets sent.</t>
</section>
<section title="Calibration"> </section>
<t>Section 3.7.3 of <xref target="RFC7679"/> provides a means to <!-- 9.4.4 -->
<section numbered="true" toc="default">
<name>Calibration</name>
<t><xref target="RFC7679" sectionFormat="of" section="3.7.3"/> provide
s a means to
quantify the systematic and random errors of a time measurement. quantify the systematic and random errors of a time measurement.
In-situ calibration could be enabled with an internal loopback at Calibration in-situ could be enabled with an internal loopback at
the Source host that includes as much of the measurement system as the Source host that includes as much of the measurement system as
possible, performs address manipulation as needed, and provides some possible, performs address manipulation as needed, and provides some
form of isolation (e.g., deterministic delay) to avoid send-receive form of isolation (e.g., deterministic delay) to avoid send-receive
interface contention. Some portion of the random and systematic interface contention. Some portion of the random and systematic
error can be characterized this way.</t> error can be characterized in this way.</t>
<t>When a measurement controller requests a calibration measurement, <t>When a measurement controller requests a calibration measurement,
the loopback is applied and the result is output in the same format the loopback is applied and the result is output in the same format
as a normal measurement with additional indication that it is a as a normal measurement, with an additional indication that it is a
calibration result.</t> calibration result.</t>
<t>Both internal loopback calibration and clock synchronization can <t>Both internal loopback calibration and clock synchronization can
be used to estimate the available accuracy of the Output Metric be used to estimate the available accuracy of the Output Metric
Units. For example, repeated loopback delay measurements will reveal Units. For example, repeated loopback delay measurements will reveal
the portion of the Output result resolution which is the result of the portion of the output result resolution that is the result of
system noise, and thus inaccurate.</t> system noise and is thus inaccurate.</t>
</section> </section>
</section> </section>
<section title="Administrative items"> <!-- 9.5 -->
<t/> <section numbered="true" toc="default">
<name>Administrative Items</name>
<section title="Status"> <!-- 9.5.1 -->
<section numbered="true" toc="default">
<name>Status</name>
<t>Current</t> <t>Current</t>
</section> </section>
<section title="Requester"> <!-- 9.5.2 -->
<t>This RFC number</t> <section numbered="true" toc="default">
<name>Requester</name>
<t>RFC 8912</t>
</section> </section>
<section title="Revision"> <!-- 9.5.3 -->
<section numbered="true" toc="default">
<name>Revision</name>
<t>1.0</t> <t>1.0</t>
</section> </section>
<section title="Revision Date"> <!-- 9.5.4 -->
<t>YYYY-MM-DD</t> <section numbered="true" toc="default">
<name>Revision Date</name>
<t>2021-11-17</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Comments and Remarks"> <name>Comments and Remarks</name>
<t>None</t> <t>None</t>
</section> </section>
</section> </section>
<section anchor="tcp-rt-delay-loss-reg-entries" numbered="true" toc="default
">
<!-- Section 10 -->
<name>TCP Round-Trip Delay and Loss Registry Entries</name>
<section title="TCP Round-Trip Delay and Loss Registry Entries"> <t>This section specifies four initial Registry Entries for the Passive
<t>This section specifies three initial registry entries for the Passive assessment of TCP Round-Trip Delay (RTD) and another entry for the TCP
assessment of TCP Round-Trip Delay (RTD) and another entry for TCP Round-Trip Loss Count.</t>
Round-trip Loss Count.</t>
<t>IANA Note: Registry "Name" below specifies multiple registry entries,
whose output format varies according to the &lt;statistic&gt; element of
the name that specifies one form of statistical summary. There are two
additional metric names for Singleton RT Delay and Packet Count
metrics.</t>
<t>All column entries beside the ID, Name, Description, and Output
Reference Method categories are the same, thus this section proposes
four closely-related registry entries. As a result, IANA is also asked
to assign corresponding URLs to each Named Metric.</t>
<section title="Summary"> <t>All column entries besides the ID, Name, Description, and Output
<t>This category includes multiple indexes to the registry entry: the Reference Method categories are the same; thus, this section defines
element ID and metric name.</t> four closely related Registry Entries. As a result, IANA has
assigned corresponding URLs to each of the four Named Metrics.</t>
<section title="ID (Identifier)"> <section numbered="true" toc="default">
<t>IANA is asked to assign different numeric identifiers to each of <!-- 10.1 -->
the four Named Metrics.</t> <name>Summary</name>
<t>This category includes multiple indexes to the Registry Entries: the
element ID and Metric Name.</t>
<section numbered="true" toc="default">
<!-- 10.1.1 -->
<name>ID (Identifier)</name>
<t>IANA has allocated the numeric Identifiers 22-26 for the five
Named Metric Entries in <xref target="tcp-rt-delay-loss-reg-entries"/>. See
<xref target="name1012"/> for mapping to Names.</t>
</section> </section>
<section title="Name"> <section anchor="name1012" numbered="true" toc="default">
<t>RTDelay_Passive_IP-TCP_RFCXXXXsec10_Seconds_&lt;statistic&gt;</t> <!-- 10.1.2 -->
<name>Name</name>
<t>where &lt;statistic&gt; is one of:</t> <dl spacing="normal" newline="false" indent="5">
<dt>22:</dt><dd>RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Mean</dd>
<t><list style="symbols"> <dt>23:</dt><dd>RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Min</dd>
<t>Mean</t> <dt>24:</dt><dd>RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Max</dd>
<dt>25:</dt><dd>RTDelay_Passive_IP-TCP-HS_RFC8912sec10_Seconds_Singl
<t>Min</t> eton</dd>
</dl>
<t>Max</t> <t>Note that a midpoint observer only has the opportunity to
</list></t> compose a single RTDelay on the TCP handshake.</t>
<dl spacing="normal" newline="false" indent="5">
<t>RTDelay_Passive_IP-TCP-HS_RFCXXXXsec10_Seconds_Singleton</t> <dt>26:</dt><dd>RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count</dd>
</dl>
<t>Note that a mid-point observer only has the opportunity to
compose a single RTDelay on the TCP Hand Shake.</t>
<t>RTLoss_Passive_IP-TCP_RFCXXXXsec10_Packet_Count</t>
</section> </section>
<section numbered="true" toc="default">
<section title="URI"> <!-- 10.1.3 -->
<t>URL: https://www.iana.org/ ... &lt;name&gt;</t> <name>URI</name>
<t>URL: <eref target="https://www.iana.org/performance-metrics/RTDelay
_Passive_IP-TCP_RFC8912sec10_Seconds_Mean" /></t>
<t>URL: <eref target="https://www.iana.org/performance-metrics/RTDelay_
Passive_IP-TCP_RFC8912sec10_Seconds_Min"/></t>
<t>URL: <eref target="https://www.iana.org/performance-metrics/RTDelay_
Passive_IP-TCP_RFC8912sec10_Seconds_Max"/></t>
<t>URL: <eref target="https://www.iana.org/performance-metrics/RTDelay_
Passive_IP-TCP-HS_RFC8912sec10_Seconds_Singleton"/></t>
<t>URL: <eref target="https://www.iana.org/performance-metrics/RTLoss_P
assive_IP-TCP_RFC8912sec10_Packet_Count"/></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Description"> <!-- 10.1.4 -->
<t>RTDelay: This metric assesses the round-trip delay of TCP packets <name>Description</name>
<dl newline="false" spacing="normal">
<dt>RTDelay:</dt><dd><t>This metric assesses the round-trip delay of T
CP packets
constituting a single connection, exchanged between two hosts. We constituting a single connection, exchanged between two hosts. We
consider the measurement of round-trip delay based on a single consider the measurement of round-trip delay based on a single
Observation Point <xref target="RFC7011"/> somewhere in the network. Observation Point (OP) <xref target="RFC7011" format="default"/> somew
The Output is the Round-trip delay for all successfully exchanged here in the network.
The output is the round-trip delay for all successfully exchanged
packets expressed as the &lt;statistic&gt; of their conditional packets expressed as the &lt;statistic&gt; of their conditional
delay distribution, where &lt;statistic&gt; is one of:</t> delay distribution, where &lt;statistic&gt; is one of:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>Mean</t> <li>Mean</li>
<li>Min</li>
<t>Min</t> <li>Max</li>
</ul>
<t>Max</t> </dd>
</list></t> <dt>RTDelay Singleton:</dt><dd><t>This metric assesses the round-trip del
ay of TCP packets
initiating a single connection (or 3-way handshake), exchanged between tw
o hosts. We
consider the measurement of round-trip delay based on a single
Observation Point (OP) <xref target="RFC7011"/> somewhere in the network.
The
output is the single measurement of Round-trip delay, or Singleton.</t></dd
>
<t>RTLoss: This metric assesses the estimated loss count for TCP <dt>RTLoss:</dt><dd>This metric assesses the estimated loss count for TCP
packets constituting a single connection, exchanged between two packets constituting a single connection, exchanged between two
hosts. We consider the measurement of round-trip delay based on a hosts. We consider the measurement of round-trip delay based on a
single Observation Point <xref target="RFC7011"/> somewhere in the single OP <xref target="RFC7011" format="default"/> somewhere in the
network. The Output is the estimated Loss Count for the measurement network. The output is the estimated loss count for the measurement
interval.</t> interval.</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Change Controller"> <!-- 10.1.5 -->
<name>Change Controller</name>
<t>IETF</t> <t>IETF</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Version (of Registry Format)"> <!-- 10.1.6 -->
<name>Version (of Registry Format)</name>
<t>1.0</t> <t>1.0</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Metric Definition"> <!-- 10.2 -->
<name>Metric Definition</name>
<t>This category includes columns to prompt the entry of all necessary <t>This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference details related to the metric definition, including the RFC reference
and values of input factors, called fixed parameters.</t> and values of input factors, called "Fixed Parameters".</t>
<section numbered="true" toc="default" anchor="s10.2.1">
<section title="Reference Definitions"> <!-- 10.2.1 -->
<t>Although there is no RFC that describes passive measurement of <name>Reference Definition</name>
Round-Trip Delay, the parallel definition for Active measurement
is:</t>
<t>Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay <t>Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
Metric for IPPM", RFC 2681, September 1999.</t> Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999,
&lt;https://www.rfc-editor.org/info/rfc2681&gt;.
<t><xref target="RFC2681"/></t> <xref target="RFC2681"/></t>
<t>Although there is no RFC that describes Passive Measurement of
<t>This metric definition uses the terms singleton and sample as round-trip delay, the parallel definition for Active Measurement
defined in Section 11 of <xref target="RFC2330"/>. (Section 2.4 of is provided in <xref target="RFC2681"/>.</t>
<xref target="RFC2681"/> provides the reference definition of the <t>This metric definition uses the term "wire time" as defined in <xre
singleton (single value) Round-trip delay metric. Section 3.4 of f target="RFC2330" sectionFormat="of" section="10.2"/>, and the terms "singleton
<xref target="RFC2681"/> provides the reference definition expanded " and "sample" as
defined in <xref target="RFC2330" sectionFormat="of" section="11"/>.
(<xref target="RFC2681" sectionFormat="of" section="2.4"/>
provides the reference definition of the
singleton (single value) round-trip delay metric. <xref target="RFC268
1" sectionFormat="of" section="3.4"/> provides the reference definition expanded
to cover a multi-singleton sample.)</t> to cover a multi-singleton sample.)</t>
<t>With the OP <xref target="RFC7011" format="default"/>
<t>With the Observation Point <xref target="RFC7011"/> (OP)
typically located between the hosts participating in the TCP typically located between the hosts participating in the TCP
connection, the Round-trip Delay metric requires two individual connection, the round-trip delay metric requires two individual
measurements between the OP and each host, such that the Spatial measurements between the OP and each host, such that the Spatial
Composition <xref target="RFC6049"/>of the measurements yields a Composition <xref target="RFC6049" format="default"/> of the measureme
Round-trip Delay singleton (we are extending the composition of nts yields a
round-trip delay singleton (we are extending the composition of
one-way subpath delays to subpath round-trip delay).</t> one-way subpath delays to subpath round-trip delay).</t>
<t>Using the direction of TCP SYN transmission to anchor the <t>Using the direction of TCP SYN transmission to anchor the
nomenclature, host A sends the SYN and host B replies with SYN-ACK nomenclature, host A sends the SYN, and host B replies with SYN-ACK
during connection establishment. The direction of SYN transfer is during connection establishment. The direction of SYN transfer is
considered the Forward direction of transmission, from A through OP considered the Forward direction of transmission, from A through the O
to B (Reverse is B through OP to A).</t> P
to B (the Reverse direction is B through the OP to A).</t>
<t>Traffic filters reduce the packet stream at the OP to a Qualified <t>Traffic Filters reduce the packet streams at the OP to a Qualified
bidirectional flow of packets.</t> bidirectional flow of packets.</t>
<t>In the definitions below, Corresponding Packets are transferred <t>In the definitions below, Corresponding Packets are transferred
in different directions and convey a common value in a TCP header in different directions and convey a common value in a TCP header
field that establishes correspondence (to the extent possible). field that establishes correspondence (to the extent possible).
Examples may be found in the TCP timestamp fields.</t> Examples may be found in the TCP timestamp fields.</t>
<t>For a real number, RTD_fwd, &gt;&gt; the round-trip delay in the
<t>For a real number, RTD_fwd, &gt;&gt; the Round-trip Delay in the Forward direction from the OP to host B at time T' is RTD_fwd &lt;&lt;
Forward direction from OP to host B at time T' is RTD_fwd &lt;&lt; it is <bcp14>REQUIRED</bcp14> that the OP observed a Qualified Packet
it is REQUIRED that OP observed a Qualified Packet to host B at to host B at
wire-time T', that host B received that packet and sent a wire time T', that host B received that packet and sent a
Corresponding Packet back to host A, and OP observed the Corresponding Packet back to host A, and the OP observed the
Corresponding Packet at wire-time T' + RTD_fwd.</t> Corresponding Packet at wire time T' + RTD_fwd.</t>
<t>For a real number, RTD_rev, &gt;&gt; the round-trip delay in the
<t>For a real number, RTD_rev, &gt;&gt; the Round-trip Delay in the Reverse direction from the OP to host A at time T'' is RTD_rev &lt;&lt
Reverse direction from OP to host A at time T'' is RTD_rev &lt;&lt; ;
it is REQUIRED that OP observed a Qualified Packet to host A at it is <bcp14>REQUIRED</bcp14> that the OP observed a Qualified Packet
wire-time T'', that host A received that packet and sent a to host A at
Corresponding Packet back to host B, and that OP observed the wire time T'', that host A received that packet and sent a
Corresponding Packet at wire-time T'' + RTD_rev.</t> Corresponding Packet back to host B, and that the OP observed the
Corresponding Packet at wire time T'' + RTD_rev.</t>
<t>Ideally, the packet sent from host B to host A in both <t>Ideally, the packet sent from host B to host A in both
definitions above SHOULD be the same packet (or, when measuring definitions above <bcp14>SHOULD</bcp14> be the same packet (or, when m easuring
RTD_rev first, the packet from host A to host B in both definitions RTD_rev first, the packet from host A to host B in both definitions
should be the same).</t> should be the same).</t>
<t>The <bcp14>REQUIRED</bcp14> Composition Function for a singleton of
<t>The REQUIRED Composition Function for a singleton of Round-trip round-trip
Delay at time T (where T is the earliest of T' and T'' above) delay at time T (where T is the earliest of T' and T'' above)
is:</t> is:</t>
<t>RTDelay = RTD_fwd + RTD_rev</t> <t>RTDelay = RTD_fwd + RTD_rev</t>
<t>Note that when the OP is located at host A or host B, one of the
<t>Note that when OP is located at host A or host B, one of the
terms composing RTDelay will be zero or negligible.</t> terms composing RTDelay will be zero or negligible.</t>
<t>Using the abbreviation HS to refer to the TCP handshake: when the Q
<t>When the Qualified and Corresponding Packets are a TCP-SYN and a ualified and Corresponding Packets are a TCP-SYN and a
TCP-SYN-ACK, then RTD_fwd == RTD_HS_fwd.</t> TCP&nbhy;SYN-ACK, RTD_fwd == RTD_HS_fwd.</t>
<t>When the Qualified and Corresponding Packets are a TCP-SYN-ACK <t>When the Qualified and Corresponding Packets are a TCP-SYN-ACK
and a TCP-ACK, then RTD_rev == RTD_HS_rev.</t> and a TCP-ACK, RTD_rev == RTD_HS_rev.</t>
<t>The <bcp14>REQUIRED</bcp14> Composition Function for a singleton of
<t>The REQUIRED Composition Function for a singleton of Round-trip round-trip
Delay for the connection Hand Shake:</t> delay for the connection handshake is:</t>
<t>RTDelay_HS = RTD_HS_fwd + RTD_HS_rev</t> <t>RTDelay_HS = RTD_HS_fwd + RTD_HS_rev</t>
<t>The definition of round-trip loss count uses the nomenclature
<t>The definition of Round-trip Loss Count uses the nomenclature
developed above, based on observation of the TCP header sequence developed above, based on observation of the TCP header sequence
numbers and storing the sequence number gaps observed. Packet Losses numbers and storing the sequence number gaps observed. Packet losses
can be inferred from:<list style="symbols"> can be inferred from:</t>
<t>Out-of-order segments: TCP segments are transmitted with <dl newline="false" spacing="normal">
<dt>Out-of-order segments:</dt><dd>TCP segments are transmitted with
monotonically increasing sequence numbers, but these segments monotonically increasing sequence numbers, but these segments
may be received out of order. Section 3 of <xref may be received out of order. <xref target="RFC4737" sectionFormat
target="RFC4737"/> describes the notion of "next expected" ="of" section="3"/> describes the notion of "next expected"
sequence numbers which can be adapted to TCP segments (for the sequence numbers, which can be adapted to TCP segments (for the
purpose of detecting reordered packets). Observation of purpose of detecting reordered packets). Observation of
out-of-order segments indicates loss on the path prior to the out-of-order segments indicates loss on the path prior to the
OP, and creates a gap.</t> OP and creates a gap.</dd>
<dt>Duplicate segments:</dt><dd><xref target="RFC5560"
<t>Duplicate segments: Section 2 of <xref target="RFC5560"/> sectionFormat="of" section="2"/> defines identical packets and is
defines identical packets and is suitable for evaluation of TCP suitable for evaluation of TCP packets to detect
packets to detect duplication. Observation of duplicate segments duplication. Observation of a segment duplicates a segment
*without a corresponding gap* indicates loss on the path previously observed (and thus no corresponding observed segment
following the OP (because they overlap part of the delivered gap) indicates loss on the path following the OP (e.g., the
sequence numbers already observed at OP).</t> segment overlaps part of the octet stream already observed at the
</list></t> OP).</dd>
</dl>
<t>Each observation of an out-of-order or duplicate infers a <t>Each observation of an out-of-order or duplicate segment infers a
singleton of loss, but composition of Round-trip Loss Counts will be singleton of loss, but the composition of round-trip loss counts will
conducted over a measurement interval which is synonymous with a be
conducted over a measurement interval that is synonymous with a
single TCP connection.</t> single TCP connection.</t>
<t>With the above observations in the Forward direction over a <t>With the above observations in the Forward direction over a
measurement interval, the count of out-of-order and duplicate measurement interval, the count of out-of-order and duplicate
segments is defined as RTL_fwd. Comparable observations in the segments is defined as RTL_fwd. Comparable observations in the
Reverse direction are defined as RTL_rev.</t> Reverse direction are defined as RTL_rev.</t>
<t>For a measurement interval (corresponding to a single TCP <t>For a measurement interval (corresponding to a single TCP
connection), T0 to Tf, the REQUIRED Composition Function for a the connection) T0 to Tf, the <bcp14>REQUIRED</bcp14> Composition Function for the
two single-direction counts of inferred loss is:</t> two single-direction counts of inferred loss is:</t>
<t>RTLoss = RTL_fwd + RTL_rev</t> <t>RTLoss = RTL_fwd + RTL_rev</t>
</section> </section>
<section numbered="true" toc="default">
<!-- 10.2.2 -->
<name>Fixed Parameters</name>
<dl newline="true" spacing="normal">
<dt>Traffic Filters:</dt>
<dd><t/>
<dl newline="true" spacing="normal">
<dt>IPv4 header values:</dt>
<dd><t/>
<dl newline="false" spacing="compact">
<dt>DSCP:</dt><dd>Set to 0</dd>
<dt>Protocol:</dt><dd>Set to 06 (TCP)</dd>
</dl>
</dd>
</dl>
<section title="Fixed Parameters"> <dl newline="true" spacing="normal">
<t/> <dt>IPv6 header values:</dt>
<dd><t/>
<t>Traffic Filters: <list style="symbols"> <dl newline="false" spacing="compact">
<t>IPv4 header values: <list style="symbols"> <dt>DSCP:</dt><dd>Set to 0</dd>
<t>DSCP: set to 0</t> <dt>Hop Count:</dt><dd>Set to 255</dd>
<dt>Next Header:</dt><dd>Set to 6 (TCP)</dd>
<t>Protocol: Set to 06 (TCP)</t> <dt>Flow Label:</dt><dd>Set to 0</dd>
</list></t> <dt>Extension Headers:</dt><dd>None</dd>
</dl>
<t>IPv6 header values:<list style="symbols"> </dd>
<t>DSCP: set to 0</t> </dl>
<t>Hop Count: set to 255</t>
<t>Next Header: set to 6 (TCP)</t>
<t>Flow Label: set to zero</t>
<t>Extension Headers: none</t>
</list></t>
<t>TCP header values: <list style="symbols">
<t>Flags: ACK, SYN, FIN, set as required</t>
<t>Timestamp Option (TSopt): Set <list style="symbols">
<t><xref target="RFC7323">Section 3.2 of </xref></t>
</list></t>
</list></t>
</list></t>
<t/> <dl newline="true" spacing="normal">
<dt>TCP header values:</dt>
<dd><t/>
<dl newline="false" spacing="compact">
<dt>Flags:</dt><dd>ACK, SYN, FIN, set as required</dd>
<dt>Timestamps Option (TSopt):</dt><dd>Set. &nbsp;See <xref
target="RFC7323" sectionFormat="of" section="3.2"/></dd>
</dl>
</dd>
</dl>
</dd>
</dl>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Method of Measurement"> <!-- 10.3 -->
<name>Method of Measurement</name>
<t>This category includes columns for references to relevant sections <t>This category includes columns for references to relevant sections
of the RFC(s) and any supplemental information needed to ensure an of the RFC(s) and any supplemental information needed to ensure
unambiguous methods for implementations.</t> an unambiguous method for implementations.</t>
<section anchor="ref-methods-10.3.1" numbered="true" toc="default">
<section title="Reference Methods"> <!-- 10.3.1 -->
<t>The foundation methodology for this metric is defined in Section <name>Reference Methods</name>
4 of <xref target="RFC7323"/> using the Timestamp Option with <t>The foundational methodology for this metric is defined in <xref ta
modifications that allow application at a mid-path Observation Point rget="RFC7323" sectionFormat="of" section="4"/> using the Timestamps option with
(OP) <xref target="RFC7011"/>. Further details and applicable modifications that allow application at a mid-path OP <xref target="RF
heuristics were derived from <xref target="Strowes"/> and <xref C7011" format="default"/>. Further details and applicable
target="Trammell-14"/>.</t> heuristics were derived from <xref target="Strowes" format="default"/>
and <xref target="Trammell-14" format="default"/>.</t>
<t>The Traffic Filter at the OP is configured to observe a single <t>The Traffic Filter at the OP is configured to observe a single
TCP connection. When the SYN, SYN-ACK, ACK handshake occurs, it TCP connection. When the SYN/SYN-ACK/ACK handshake occurs, it
offers the first opportunity to measure both RTD_fwd (on the SYN to 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 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 singleton of RTDelay as RTDelay_HS (composed using the Forward and
reverse measurement pair). RTDelay_HS SHALL be treated separately Reverse measurement pair). RTDelay_HS <bcp14>SHALL</bcp14> be treated
separately
from other RTDelays on data-bearing packets and their ACKs. The from other RTDelays on data-bearing packets and their ACKs. The
RTDelay_HS value MAY be used as a sanity check on other Composed RTDelay_HS value <bcp14>MAY</bcp14> be used as a consistency check on
values of RTDelay.</t> the composed
values of RTDelay for payload-bearing packets.</t>
<t>For payload bearing packets, the OP measures the time interval <t>For payload-bearing packets, the OP measures the time interval
between observation of a packet with Sequence Number s, and the between observation of a packet with sequence number "s" and the
corresponding ACK with same Sequence number. When the payload is corresponding ACK with the same sequence number. When the payload is
transferred from host A to host B, the observed interval is transferred from host A to host B, the observed interval is RTD_fwd.</
RTD_fwd.</t> t>
<t>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.</t>
<t>Because many data transfers are unidirectional (say, in the <t>Because many data transfers are unidirectional (say, in the
Forward direction from host A to host B), it is necessary to use Forward direction from host A to host B), it is necessary to use
pure ACK packets with Timestamp (TSval) and their Timestamp value pure ACK packets with Timestamp (TSval) and packets with the Timestamp value
echo to perform a RTD_rev measurement. The time interval between echo to perform a RTD_rev measurement. The time interval between
observation of the ACK from B to A, and the corresponding packet observation of the ACK from B to A, and the Corresponding Packet
with Timestamp echo (TSecr) is the RTD_rev.</t> with a Timestamp Echo Reply (TSecr) field <xref target="RFC7323"/>, is
the RTD_rev.</t>
<t>Delay Measurement Filtering Heuristics:</t> <t>Delay Measurement Filtering Heuristics:</t>
<ul spacing="normal">
<t>If Data payloads were transferred in both Forward and Reverse <li>If data payloads were transferred in both Forward and Reverse
directions, then the Round-Trip Time Measurement Rule in Section 4.1 directions, then the Round-Trip Time Measurement rule in <xref target=
of <xref target="RFC7323"/> could be applied. This rule essentially "RFC7323" sectionFormat="of" section="4.1"/> could be applied. This rule essenti
ally
excludes any measurement using a packet unless it makes progress in excludes any measurement using a packet unless it makes progress in
the transfer (advances the left edge of the send window, consistent the transfer (advances the left edge of the send window, consistent
with <xref target="Strowes"/>).</t> with <xref target="Strowes" format="default"/>).</li>
<li>A different heuristic from <xref target="Trammell-14" format="defa
<t>A different heuristic from <xref target="Trammell-14"/> is to ult"/> is to
exclude any RTD_rev that is larger than previously observed values. exclude any RTD_rev that is larger than previously observed values.
This would tend to exclude Reverse measurements taken when the This would tend to exclude Reverse measurements taken when the
Application has no data ready to send, because considerable time application has no data ready to send, because considerable time
could be added to RTD_rev from this source of error.</t> could be added to RTD_rev from this source of error.</li>
<li>Note that the above heuristic assumes that host A is sending
<t>Note that the above Heuristic assumes that host A is sending
data. Host A expecting a download would mean that this heuristic data. Host A expecting a download would mean that this heuristic
should be applied to RTD_fwd.</t> should be applied to RTD_fwd.</li>
<li>The statistic calculations to summarize the delay (RTDelay) <bcp14
<t>The statistic calculations to summarize the delay (RTDelay) SHALL >SHALL</bcp14>
be performed on the conditional distribution, conditioned on be performed on the conditional distribution, conditioned on
successful Forward and Reverse measurements which follow the successful Forward and Reverse measurements that follow the
Heuristics.</t> heuristics.</li>
</ul>
<t>Method for Inferring Loss:</t> <t>Method for Inferring Loss:</t>
<ul spacing="normal">
<t>The OP tracks sequence numbers and stores gaps for each direction <li>The OP tracks sequence numbers and stores gaps for each direction
of transmission, as well as the next-expected sequence number as in of transmission, as well as the next expected sequence number as discu
<xref target="Trammell-14"/> and <xref target="RFC4737"/>. Loss is ssed in
inferred from Out-of-order segments and Duplicate segments.</t> <xref target="Trammell-14" format="default"/> and <xref target="RFC473
7" format="default"/>. Loss is
inferred from out-of-order segments and duplicate segments.</li>
</ul>
<t>Loss Measurement Filtering Heuristics:</t> <t>Loss Measurement Filtering Heuristics:</t>
<ul spacing="normal">
<t><xref target="Trammell-14"/> adds a window of evaluation based on <li><xref target="Trammell-14" format="default"/> adds a window of eva
the RTDelay.</t> luation based on
the RTDelay.</li>
<t>Distinguish Re-ordered from OOO due to loss, because sequence <li>Distinguish reordered packets from out-of-order segments due to
loss, because the sequence
number gap is filled during the same RTDelay window. Segments number gap is filled during the same RTDelay window. Segments
detected as re-ordered according to <xref target="RFC4737"/> MUST detected as reordered according to <xref target="RFC4737" format="defa
reduce the Loss Count inferred from Out-of-order segments.</t> ult"/> <bcp14>MUST</bcp14>
reduce the loss count inferred from out-of-order segments.</li>
<t>Spurious (unneeded) retransmissions (observed as duplicates) can <li>Spurious (unneeded) retransmissions (observed as duplicates) can
also be reduced this way, as described in <xref also be reduced in this way, as described in <xref target="Trammell-14
target="Trammell-14"/>.</t> "
format="default"/>.</li>
</ul>
<t>Sources of Error:</t> <t>Sources of Error:</t>
<ul spacing="normal">
<t>The principal source of RTDelay error is the host processing time <li>The principal source of RTDelay error is the host processing time
to return a packet that defines the termination of a time interval. to return a packet that defines the termination of a time interval.
The heuristics above intend to mitigate these errors by excluding The heuristics above intend to mitigate these errors by excluding
measurements where host processing time is a significant part of measurements where host processing time is a significant part of
RTD_fwd or RTD_rev.</t> RTD_fwd or RTD_rev.</li>
<li>A key source of RTLoss error is observation loss, as described in
<t>A key source of RTLoss error is observation loss, described in Section&nbsp;3 of <xref target="Trammell-14"/>.</li>
section 3 of <xref target="Trammell-14"/>.</t> </ul>
</section> </section>
<section numbered="true" toc="default">
<section title="Packet Stream Generation"> <!-- 10.3.2 -->
<t>NA</t> <name>Packet Stream Generation</name>
<t>N/A</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Traffic Filtering (observation) Details"> <!-- 10.3.3 -->
<name>Traffic Filtering (Observation) Details</name>
<t>The Fixed Parameters above give a portion of the Traffic Filter. <t>The Fixed Parameters above give a portion of the Traffic Filter.
Other aspects will be supplied as Run-time Parameters (below).</t> Other aspects will be supplied as Runtime Parameters (below).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Sampling Distribution"> <!-- 10.3.4 -->
<name>Sampling Distribution</name>
<t>This metric requires a complete sample of all packets that <t>This metric requires a complete sample of all packets that
qualify according to the Traffic Filter criteria.</t> qualify according to the Traffic Filter criteria.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Run-time Parameters and Data Format"> <!-- 10.3.5 -->
<t>Run-time Parameters are input factors that must be determined, <name>Runtime Parameters and Data Format</name>
<t>Runtime Parameters are input factors that must be determined,
configured into the measurement system, and reported with the configured into the measurement system, and reported with the
results for the context to be complete.</t> results for the context to be complete.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Src:</dt>
<t hangText="Src">the IP address of the host in the host A Role <dd>The IP address of the host in the host A Role
(format ipv4-address-no-zone value for IPv4, or (format ipv4&nbhy;address-no-zone value for IPv4 or
ipv6-address-no-zone value for IPv6, see Section 4 of <xref ipv6-address-no-zone value for IPv6; see <xref target="RFC6991" se
target="RFC6991"/>)</t> ctionFormat="of" section="4"/>).</dd>
<dt>Dst:</dt>
<t hangText="Dst">the IP address of the host in the host B <dd>The IP address of the host in the host B Role
(format ipv4-address-no-zone value for IPv4, or (format ipv4&nbhy;address-no-zone value for IPv4 or
ipv6-address-no-zone value for IPv6, see section 4 of <xref ipv6-address-no-zone value for IPv6; see <xref target="RFC6991" se
target="RFC6991"/>)</t> ctionFormat="of" section="4"/>).</dd>
<dt>T0:</dt>
<t hangText="T0">a time, the start of a measurement interval, <dd>A time, the start of a measurement interval
(format "date-and-time" as specified in Section 5.6 of <xref (format "date&nbhy;time" as specified in <xref target="RFC3339"
target="RFC3339"/>, see also Section 3 of <xref sectionFormat="of" section="5.6"/>; see also
target="RFC6991"/>). The UTC Time Zone is required by Section "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
6.1 of <xref target="RFC2330"/>. When T0 is "all-zeros", a start "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
time is unspecified and Td is to be interpreted as the Duration tionFormat="of" section="6.1"/>. 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 of the measurement interval. The start time is controlled
through other means.</t> through other means.</dd>
<dt>Tf:</dt>
<t hangText="Td">Optionally, the end of a measurement interval, <dd>Optionally, the end of a measurement interval
(format "date-and-time" as specified in Section 5.6 of <xref (format "date&nbhy;time" as specified in <xref target="RFC3339"
target="RFC3339"/>, see also Section 3 of <xref sectionFormat="of" section="5.6"/>; see also
target="RFC6991"/>), or the duration (see T0). The UTC Time Zone "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
is required by Section 6.1 of <xref target="RFC2330"/>. "of" section="3"/>), or the duration (see T0). The UTC Time Zone
Alternatively, the end of the measurement interval MAY be is required by <xref target="RFC2330" sectionFormat="of" section="
6.1"/>.
Alternatively, the end of the measurement interval <bcp14>MAY</bcp
14> be
controlled by the measured connection, where the second pair of controlled by the measured connection, where the second pair of
FIN and ACK packets exchanged between host A and B effectively FIN and ACK packets exchanged between host A and host B effectivel
ends the interval.</t> y
ends the interval.</dd>
<t hangText="TTL or Hop Limit">Set at desired value.</t> <dt>TTL or Hop Limit:</dt>
</list></t> <dd>Set at desired value.</dd>
</dl>
<t/>
</section> </section>
<section numbered="true" toc="default">
<section title="Roles"> <!-- 10.3.6 -->
<t><list style="hanging"> <name>Roles</name>
<t hangText="host A">launches the SYN packet to open the <dl newline="false" spacing="normal">
connection, and synonymous with an IP address.</t> <dt>host A:</dt>
<dd>Launches the SYN packet to open the
<t hangText="host B">replies with the SYN-ACK packet to open the connection. The Role of "host A" is synonymous with the IP
connection, and synonymous with an IP address.</t> address used at host A.</dd>
</list></t> <dt>host B:</dt>
<dd>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.</dd>
</dl>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Output"> <!-- 10.4 -->
<t>This category specifies all details of the Output of measurements <name>Output</name>
<t>This category specifies all details of the output of measurements
using the metric.</t> using the metric.</t>
<section numbered="true" toc="default">
<section title="Type"> <!-- 10.4.1 -->
<t>See subsection titles in Reference Definition for RTDelay <name>Type</name>
Types.</t> <t>RTDelay Types are discussed in the subsections below.</t>
<t>For RTLoss: The count of lost packets.</t>
<t>For RTLoss -- the count of lost packets.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Reference Definition"> <!-- 10.4.2 -->
<t>For all output types ---<list style="hanging"> <name>Reference Definition</name>
<t hangText="T0">the start of a measurement interval, (format <t>For all output types:</t>
"date-and-time" as specified in Section 5.6 of <xref <dl newline="false" spacing="normal">
target="RFC3339"/>, see also Section 3 of <xref <dt>T0:</dt>
target="RFC6991"/>). The UTC Time Zone is required by Section <dd>The start of a measurement interval (format
6.1 of <xref target="RFC2330"/>.</t> "date&nbhy;time" as specified in <xref target="RFC3339"
sectionFormat="of" section="5.6"/>; see also
<t hangText="Tf">the end of a measurement interval, (format "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
"date-and-time" as specified in Section 5.6 of <xref "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
target="RFC3339"/>, see also Section 3 of <xref tionFormat="of" section="6.1"/>.</dd>
target="RFC6991"/>). The UTC Time Zone is required by Section <dt>Tf:</dt>
6.1 of <xref target="RFC2330"/>. The end of the measurement <dd>The end of a measurement interval (format
interval MAY be controlled by the measured connection, where the "date&nbhy;time" as specified in <xref target="RFC3339"
sectionFormat="of" section="5.6"/>; see also
"date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
"of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
tionFormat="of" section="6.1"/>. The end of the measurement
interval <bcp14>MAY</bcp14> be controlled by the measured connecti
on, where the
second pair of FIN and ACK packets exchanged between host A and second pair of FIN and ACK packets exchanged between host A and
B effectively ends the interval.</t> host B effectively ends the interval.</dd>
<t hangText="...">...</t>
</list></t>
<t>For RTDelay_HS -- the Round trip delay of the Handshake.</t>
<t>For RTLoss -- the count of lost packets.</t>
<t>For each &lt;statistic&gt;, one of the following sub-sections <dt>RTDelay_Passive_IP-TCP-HS:</dt>
apply:</t> <dd>The round-trip delay of the handshake is a Singleton.</dd>
<dt>RTLoss:</dt><dd>The count of lost packets.</dd>
</dl>
<section title="Mean"> <t>For each &lt;statistic&gt;, Singleton, or Loss Count, one of the fo
<t>The mean SHALL be calculated using the conditional distribution llowing subsections
of all packets with a finite value of Round-trip delay (undefined applies.</t>
delays are excluded), a single value as follows:</t>
<t>See section 4.1 of <xref target="RFC3393"/> for details on the <section numbered="true" toc="default">
<!-- 10.4.2.1 -->
<name>Mean</name>
<t>The mean <bcp14>SHALL</bcp14> 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:</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for
details on the
conditional distribution to exclude undefined values of delay, and conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this see <xref target="RFC6703" sectionFormat="of" section="5"/> for back ground on this
analysis choice.</t> analysis choice.</t>
<t>See <xref target="RFC6049" sectionFormat="of" section="4.2.2"/> f
<t>See section 4.2.2 of <xref target="RFC6049"/> for details on or details on
calculating this statistic, and 4.2.3 of <xref calculating this statistic; see also <xref target="RFC6049" sectionF
target="RFC6049"/>.</t> ormat="of" section="4.2.3"/>.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Mean:</dt>
<t hangText="Mean">The time value of the result is expressed <dd>The time value of the result is expressed
in units of seconds, as a positive value of type decimal64 in units of seconds, as a positive value of type decimal64
with fraction digits = 9 (see section 9.3 of <xref with fraction digits = 9 (see <xref target="RFC6020" sectionForm
target="RFC6020"/>) with resolution of 0.000000001 seconds at="of" section="9.3"/>) with a resolution of 0.000000001&nbsp;seconds
(1.0 ns), and with lossless conversion to/from the 64-bit NTP (1.0 ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" secti
target="RFC5905">RFC</xref></t> on="6"/>.</dd>
</list></t> </dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Min"> <!-- 10.4.2.2 -->
<t>The minimum SHALL be calculated using the conditional <name>Min</name>
distribution of all packets with a finite value of Round-trip <t>The minimum <bcp14>SHALL</bcp14> be calculated using the conditio
delay (undefined delays are excluded), a single value as nal
distribution of all packets with a finite value of round-trip
delay (undefined delays are excluded) -- a single value, as
follows:</t> follows:</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for
<t>See section 4.1 of <xref target="RFC3393"/> for details on the details on the
conditional distribution to exclude undefined values of delay, and conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this see <xref target="RFC6703" sectionFormat="of" section="5"/> for back ground on this
analysis choice.</t> analysis choice.</t>
<t>See <xref target="RFC6049" sectionFormat="of" section="4.3.2"/> f
<t>See section 4.3.2 of <xref target="RFC6049"/> for details on or details on
calculating this statistic, and 4.3.3 of <xref calculating this statistic; see also <xref target="RFC6049" sectionF
target="RFC6049"/>.</t> ormat="of" section="4.3.3"/>.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Min:</dt>
<t hangText="Min">The time value of the result is expressed in <dd>The time value of the result is expressed in
units of seconds, as a positive value of type decimal64 with units of seconds, as a positive value of type decimal64 with
fraction digits = 9 (see section 9.3 of <xref fraction digits = 9 (see <xref target="RFC6020" sectionFormat="o
target="RFC6020"/>) with resolution of 0.000000001 seconds f" section="9.3"/>) with a resolution of 0.000000001&nbsp;seconds
(1.0 ns), and with lossless conversion to/from the 64-bit NTP (1.0 ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" secti
target="RFC5905">RFC</xref></t> on="6"/>.</dd>
</list></t> </dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Max"> <!-- 10.4.2.3 -->
<t>The maximum SHALL be calculated using the conditional <name>Max</name>
distribution of all packets with a finite value of Round-trip <t>The maximum <bcp14>SHALL</bcp14> be calculated using the conditio
delay (undefined delays are excluded), a single value as nal
distribution of all packets with a finite value of round-trip
delay (undefined delays are excluded) -- a single value, as
follows:</t> follows:</t>
<t>See <xref target="RFC3393" sectionFormat="of" section="4.1"/> for
<t>See section 4.1 of <xref target="RFC3393"/> for details on the details on the
conditional distribution to exclude undefined values of delay, and conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this see <xref target="RFC6703" sectionFormat="of" section="5"/> for back ground on this
analysis choice.</t> analysis choice.</t>
<t>See <xref target="RFC6049" sectionFormat="of" section="4.3.2"/> f
or a closely
related method for calculating this statistic; see also <xref target
="RFC6049" sectionFormat="of" section="4.3.3"/>. The formula is as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Max = (FiniteDelay[j])
]]></artwork>
<t>See section 4.3.2 of <xref target="RFC6049"/> for a closely <ul empty="true">
related method for calculating this statistic, and 4.3.3 of <xref <li>such that for some index, j, where 1 &lt;= j &lt;= N
target="RFC6049"/>. The formula is as follows:</t> FiniteDelay[j]&nbsp;&gt;=&nbsp;FiniteDelay[n] for all n</li>
</ul>
<t><figure> <dl newline="false" spacing="normal">
<artwork><![CDATA[ Max = (FiniteDelay [j]) <dt>Max:</dt>
<dd>The time value of the result is expressed in
such that for some index, j, where 1 <= j <= N
FiniteDelay[j] >= FiniteDelay[n] for all n]]></artwork>
</figure></t>
<t><list style="hanging">
<t hangText="Max">The time value of the result is expressed in
units of seconds, as a positive value of type decimal64 with units of seconds, as a positive value of type decimal64 with
fraction digits = 9 (see section 9.3 of <xref fraction digits = 9 (see <xref target="RFC6020" sectionFormat="o
target="RFC6020"/>) with resolution of 0.000000001 seconds f" section="9.3"/>) with a resolution of 0.000000001&nbsp;seconds
(1.0 ns), and with lossless conversion to/from the 64-bit NTP (1.0 ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per section 6 of <xref timestamp as per <xref target="RFC5905" sectionFormat="of" secti
target="RFC5905">RFC</xref></t> on="6"/>.</dd>
</list></t> </dl>
</section> </section>
</section> <!-- 10.4.2.4 -->
<section numbered="true" toc="default">
<name>Singleton</name>
<t>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 <xref target="ref-methods-10.3.1"/>.</t>
<section title="Metric Units"> <!-- <t>For RTDelay_Passive_IP-TCP-HS: The round-trip delay of the handshake
<t>The &lt;statistic&gt; of Round-trip Delay is expressed in .</t>
seconds, where &lt;statistic&gt; is one of:</t> removed because not in ACM's Registry Entry as of 6/27 -->
<t>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 <xref target="RFC6020" sectionFormat="of" section="9.3"/>) with resolu
tion of 0.000000001
seconds (1.0 ns), and with lossless conversion to/from the 64-bit
NTP timestamp as per <xref target="RFC5905" sectionFormat="of" section="6"
/>.</t>
</section>
<t><list style="symbols"> <!-- 10.4.2.5 -->
<t>Mean</t> <section numbered="true" toc="default">
<name>Loss Counts</name>
<t>RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count: The count of lost packets.</
t>
<t>Min</t> <t>Observation of an out-of-order segment or duplicate segment infers a loss cou nt, after application of the Definitions of <xref target="s10.2.1"/> and the Los s Measurement Filtering Heuristics of <xref target="ref-methods-10.3.1"/>. The c omposition of round-trip loss counts will be conducted over a measurement interv al that is synonymous with a single TCP connection.</t>
<t>Max</t> <t>For a measurement interval (corresponding to a single TCP connection)
</list></t> T0 to Tf, the REQUIRED Composition Function for the two single-
direction counts of inferred loss is:</t>
<t>The Round-trip Delay of the Hand Shake is expressed in <t>RTLoss = RTL_fwd + RTL_rev</t>
seconds.</t>
<t>The Round-trip Loss Count is expressed as a number of <dl><dt>Packet count:</dt><dd>The numeric value of the result is expressed in un
its
of lost packets, as a positive value of type uint64 (represents
integer values between 0 and 18446744073709551615, inclusively
(see Section 9.2 of [RFC6020]).</dd>
</dl>
</section>
</section>
<section numbered="true" toc="default">
<!-- 10.4.3 -->
<name>Metric Units</name>
<t>The &lt;statistic&gt; of round-trip delay is expressed in
seconds, where &lt;statistic&gt; is one of:</t>
<ul spacing="normal">
<li>Mean</li>
<li>Min</li>
<li>Max</li>
</ul>
<t>The round-trip delay of the TCP handshake singleton is expressed in
seconds.</t>
<t>The round-trip loss count is expressed as a number of
packets.</t> packets.</t>
</section> <!-- <t>RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count</t>
<dl>
<dt>Packet count:</dt><dd>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 <xref target="RFC6020"
sectionFormat="of" section="9.2"/>).</dd></dl> -->
<section title="Calibration"> </section>
<t>Passive measurements at an OP could be calibrated against an <section numbered="true" toc="default">
active measurement (with loss emulation) at host A or B, where the <!-- 10.4.4 -->
active measurement represents the ground-truth.</t> <name>Calibration</name>
<t>Passive Measurements at an OP could be calibrated against an
Active Measurement (with loss emulation) at host A or host B, where th
e
Active Measurement represents the ground truth.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Administrative items"> <!-- 10.5 -->
<t/> <name>Administrative Items</name>
<section numbered="true" toc="default">
<section title="Status"> <!-- 10.5.1 -->
<name>Status</name>
<t>Current</t> <t>Current</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Requester"> <!-- 10.5.2 -->
<t>This RFC number</t> <name>Requester</name>
<t>RFC 8912</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Revision"> <!-- 10.5.3 -->
<name>Revision</name>
<t>1.0</t> <t>1.0</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Revision Date"> <!-- 10.5.4 -->
<t>YYYY-MM-DD</t> <name>Revision Date</name>
<t>2021-11-17</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Comments and Remarks"> <!-- 10.6 -->
<t>None.</t> <name>Comments and Remarks</name>
<t>None</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t>These registry entries represent no known implications for Internet <t>These Registry Entries represent no known implications for Internet
Security. Each RFC referenced above contains a Security Considerations security. With the exception of <xref target="RFC1035"/>, each RFC referen
section. Further, the LMAP Framework <xref target="RFC7594"/> provides ced above contains a Security Considerations
section. Further, the Large-scale Measurement of Broadband Performance (LM
AP) framework <xref target="RFC7594" format="default"/> provides
both security and privacy considerations for measurements.</t> both security and privacy considerations for measurements.</t>
<t>There are potential privacy considerations for observed traffic, <t>There are potential privacy considerations for observed traffic,
particularly for passive metrics in section 10. An attacker that knows particularly for Passive Metrics as discussed in <xref target="tcp-rt-dela y-loss-reg-entries"/>. An attacker that knows
that its TCP connection is being measured can modify its behavior to that its TCP connection is being measured can modify its behavior to
skew the measurement results.</t> skew the measurement results.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="IANA" title="IANA Considerations"> <t>IANA has populated the Performance Metrics Registry
<!-- <t>Metrics previously defined in IETF were registered in the IANA defined in <xref target="RFC8911" format="default"/> with the
IPPM values defined in Sections&nbsp;<xref target="udp-rt-latency-loss-reg-entr
METRICS REGISTRY, however this process was discontinued when the ies" format="counter"/>
registry structure was found to be inadequate, and the registry was through <xref target="tcp-rt-delay-loss-reg-entries" format="counter"/>.</
declared Obsolete <xref target="RFC6248"/>.</t> t>
<t>The form of metric registration will finalized in this and other
memos, and IANA Action will be requested when the initial contents of
the registry are prepared.</t>-->
<t>IANA is requested to populate The Performance Metrics Registry
defined in <xref target="I-D.ietf-ippm-metric-registry"/> with the
values defined in sections 4 through 10.</t>
<t>See the IANA Considerations section of <xref
target="I-D.ietf-ippm-metric-registry"/> for additional requests and
considerations.</t>
</section>
<section title="Acknowledgements">
<t>The authors thank Brian Trammell for suggesting the term "Run-time
Parameters", which led to the distinction between run-time and fixed
parameters implemented in this memo, for identifying the 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.</t>
<t>The authors also acknowledge the constructive reviews and helpful <t>See the IANA Considerations section of <xref target="RFC8911"
suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, Yaakov format="default"/> for additional considerations.</t>
Stein, and participants in the LMAP working group. Thanks to Michelle
Cotton for her early IANA reviews, and to Amanda Barber for answering
questions related to the presentation of the registry and accessibility
of the complete template via URL.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include="reference.RFC.1035"?> <name>References</name>
<references>
<?rfc include="reference.RFC.2119"?> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.
<?rfc include="reference.RFC.2330"?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<?rfc ?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2330.
<?rfc ?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2681.
<?rfc ?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3339.
<?rfc ?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3393.
<?rfc include='reference.RFC.2681'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3432.
<?rfc include='reference.RFC.3393'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5560.
<?rfc include='reference.RFC.3339'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.
<?rfc include='reference.RFC.3432'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4737.
<?rfc include='reference.RFC.5560'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5357.
<?rfc include='reference.RFC.5905'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5481.
<?rfc include='reference.RFC.4737'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.
<?rfc include='reference.RFC.5357'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6049.
<?rfc include='reference.RFC.5481'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6673.
<?rfc include='reference.RFC.6020'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.
<?rfc include='reference.RFC.6049'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7011.
<?rfc include='reference.RFC.6673'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7323.
<?rfc include='reference.RFC.6991'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7679.
<?rfc include='reference.RFC.7011'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7680.
<?rfc include='reference.RFC.7323'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
<?rfc include='reference.RFC.7679'?> xml"/>
<?rfc include='reference.RFC.7680'?>
<?rfc include='reference.RFC.8174'?>
<reference anchor="I-D.ietf-ippm-metric-registry">
<front>
<title>Registry for Performance Metrics</title>
<author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
<organization/>
</author>
<author fullname="Benoit Claise" initials="B." surname="Claise">
<organization/>
</author>
<author fullname="Phil Eardley" initials="P." surname="Eardley">
<organization/>
</author>
<author fullname="Al Morton" initials="A." surname="Morton">
<organization/>
</author>
<date year="2019"/>
</front>
<seriesInfo name="Internet Draft (work in progress)"
value="draft-ietf-ippm-metric-registry"/>
<format type="TXT"/> <!-- draft-ietf-ippm-metric-registry (RFC 8911) -->
<reference anchor="RFC8911" target="https://www.rfc-editor.org/info/rfc8
911">
<front>
<title>Registry for Performance Metrics</title>
<author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
<organization/>
</author>
<author fullname="Benoit Claise" initials="B." surname="Claise">
<organization/>
</author>
<author fullname="Phil Eardley" initials="P." surname="Eardley">
<organization/>
</author>
<author fullname="Al Morton" initials="A." surname="Morton">
<organization/>
</author>
<author fullname="Aamer Akhter" initials="A." surname="Akhter">
<organization/>
</author>
<date month="November" year="2021"/>
</front>
<seriesInfo name="RFC" value="8911"/>
<seriesInfo name="DOI" value="10.17487/RFC8911"/>
</reference> </reference>
<reference anchor="Strowes"> <reference anchor="Strowes" target="https://dl.acm.org/doi/10.1145/25077
<front> 71.2507781">
<title>Passively Measuring TCP Round Trip Times, Communications of <front>
the ACM, Vol. 56 No. 10, Pages 57-64</title> <title>Passively Measuring TCP Round-Trip Times</title>
<author fullname="Stephen Strowes" initials="S." surname="Strowes">
<author fullname="S.Strowes" initials="S." surname="Strowes"> <organization></organization>
<organization>Communications of the ACM, Vol. 56 No. 10, Pages </author>
57-64.</organization> <date month="October" year="2013"/>
</author> </front>
<refcontent>Communications of the ACM, Vol. 56 No. 10, Pages 57-64</ref
<date month="September" year="2013"/> content>
</front> <seriesInfo name="DOI" value="10.1145/2507771.2507781"/>
</reference> </reference>
<reference anchor="Trammell-14"> <reference anchor="Trammell-14" target="https://link.springer.com/chapte
<front> r/10.1007/978-3-642-54999-1_2">
<title>Inline Data Integrity Signals for Passive Measurement, In: <front>
Dainotti A., Mahanti A., Uhlig S. (eds) Traffic Monitoring and <title>Inline Data Integrity Signals for Passive Measurement</title>
Analysis. TMA 2014. Lecture Notes in Computer Science, vol 8406. <author fullname="Brian Trammell" initials="B." surname="Trammell">
Springer, Berlin, Heidelberg <organization></organization>
https://link.springer.com/chapter/10.1007/978-3-642-54999-1_2</title> </author>
<author fullname="David Gugelmann" initials="D." surname="Gugelmann">
<organization></organization>
</author>
<author fullname="Nevil Brownlee" initials="N." surname="Brownlee">
<organization></organization>
</author>
<date month="March" year="2014"/>
</front>
<refcontent>In: Dainotti A., Mahanti A., Uhlig S. (eds)
Traffic Monitoring and Analysis. TMA 2014. Lecture Notes in
Computer Science, vol 8406. Springer, Berlin, Heidelberg</refcontent>
<seriesInfo name="DOI" value="10.1007/978-3-642-54999-1_2"/>
</reference>
</references>
<author fullname="B.Trammell, et al." initials="B." <references>
surname="Trammell"> <name>Informative References</name>
<organization>TMA 2014 In: Dainotti A., Mahanti A., Uhlig S. (eds) <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1242.
Traffic Monitoring and Analysis. TMA 2014. Lecture Notes in xml"/>
Computer Science, vol 8406. Springer, Berlin, <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6390.
Heidelberg</organization> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6703.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7594.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.
xml"/>
<date month="March" year="2014"/> </references>
</front>
</reference>
</references> </references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors thank <contact fullname="Brian Trammell"/> for suggesting t
he 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. Than
ks to <contact fullname="Peter Koch"/>, who provided several useful suggestions
for
disambiguating successive DNS queries in the DNS Response time
metric.</t>
<t>The authors also acknowledge the constructive reviews and helpful
suggestions from <contact fullname="Barbara Stark"/>, <contact fullname="J
uergen Schoenwaelder"/>, <contact fullname="Tim Carey"/>, <contact fullname="Yaa
kov
Stein"/>, and participants in the LMAP Working Group. Thanks to <contact
fullname="Michelle Cotton"/> for her early IANA reviews, and to <contact f
ullname="Amanda Baber"/> for answering
questions related to the presentation of the Registry and accessibility
of the complete template via URL.</t>
<references title="Informative References"> </section>
<?rfc include='reference.RFC.1242'?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
<?rfc include='reference.RFC.6390'?>
<?rfc include='reference.RFC.6703'?>
<?rfc include='reference.RFC.7594'?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 648 change blocks. 
2926 lines changed or deleted 3449 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/