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 SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
<?rfc tocompact="yes"?> docName="draft-ietf-ippm-initial-registry-16" number="8912"
<?rfc tocdepth="3"?> ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
<?rfc tocindent="yes"?> consensus="true" xml:lang="en" tocInclude="true" tocDepth="3"
<?rfc symrefs="yes"?> symRefs="true" sortRefs="true" version="3">
<?rfc sortrefs="yes"?> <!-- xml2rfc v2v3 conversion 2.43.0 -->
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-ippm-initial-registry-16"
ipr="trust200902">
<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="October" year="2020"/>
<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 Performance
Metrics Registry. The set includes: UDP Round-trip Latency and Loss, Metrics Registry. 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>
<!-- Quoted text is DNE (and updated per author's reply during AUTH
for draft-ietf-ippm-metric-registry)
<t>Therefore, <xref target="I-D.ietf-ippm-metric-registry"/> defines the Check whether this should be updated to "proposed" based on AQ sent 8911.
overall format for a Performance Metrics Registry. Section 5 of <xref -->
target="I-D.ietf-ippm-metric-registry"/> also gives guidelines for those <blockquote>In essence, there needs to be
requesting registration of a Metric, that is the creation of entry(s) in evidence that (1) a candidate Registered Performance Metric has significan
the Performance Metrics Registry: "In essence, there needs to be t
evidence that a candidate Registered Performance Metric has significant industry interest or has seen deployment and (2) there is agreement that
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 numbered="true" toc="default">
<section title="Registry Categories and Columns"> <name>Registry Categories and Columns</name>
<t>This memo uses the terminology defined in <xref <t>This memo uses the terminology defined in <xref target="RFC8911" format
target="I-D.ietf-ippm-metric-registry"/>.</t> ="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 anchor="udp-rt-latency-loss-reg-entries" numbered="true" toc="defau
lt">
<name>UDP Round-Trip Latency and Loss Registry Entries</name>
<t>This section specifies an initial Registry Entry for UDP
Round-Trip Latency and another entry for the UDP Round-Trip Loss Ratio.</t
>
<aside><t>Note: Each Registry Entry only produces a "raw" output or a
statistical summary. To describe both "raw" and one or more statistics
efficiently, the Identifier, Name, and Output categories can be split,
and a single section can specify two or more closely related metrics.
For example, this section specifies two Registry Entries with many
common columns. See <xref target="udp-poisson-owd-owl-reg"/> for an exampl
e specifying multiple
Registry Entries with many common columns.</t></aside>
<t>All column entries besides the ID, Name, Description, and Output
Reference Method categories are the same; thus, this section defines two
closely related Registry Entries. As a result, IANA has also
assigned a corresponding URL to each of the two Named Metrics.</t>
<section numbered="true" toc="default">
<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">
<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 anchor="name412" numbered="true" toc="default">
<name>Name</name>
<dl>
<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 numbered="true" toc="default">
<name>URI</name>
<!-- [rfced] Is this section to be updated to include the full URL for each
URI, or is a link to the main registry
<https://www.iana.org/assignments/performance-metrics> sufficient because the
reader can find all of the URIs there? Note that any updates will be applied
to similar text throughout the document.
<section title="UDP Round-trip Latency and Loss Registry Entries"> 4.1.3. URI
<t>This section specifies an initial registry entry for the UDP
Round-trip Latency, and another entry for UDP Round-trip Loss Ratio.</t>
<t>Note: Each Registry entry only produces a "raw" output or a URL: https://www.iana.org/ ... <Name>
statistical summary. To describe both "raw" and one or more statistics
efficiently, the Identifier, Name, and Output Categories can be split
and a single section can specify two or more closely-related metrics.
For example, this section specifies two Registry entries with many
common columns. See Section 7 for an example specifying multiple
Registry entries with many common columns.</t>
<t>All column entries beside the ID, Name, Description, and Output [acm]
Reference Method categories are the same, thus this section proposes two The URI section contains a full URL to the HTML-ized Registry Entry text for
closely-related registry entries. As a result, IANA is also asked to each
assign a corresponding URL to each Named Metric.</t> Registry Entry. So
<section title="Summary"> https://www.iana.org/
<t>This category includes multiple indexes to the registry entry: the ... RTDelay_Active_IP-UDP-Periodic_RFCXXXXsec4_Seconds_95Percentile
element ID and metric name.</t>
<section title="ID (Identifier)"> https://www.iana.org/
<t>IANA is asked to assign different numeric identifiers to each of ... RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_Percent_LossRatio
the two Named Metrics.</t>
</section>
<section title="Name"> [SG] update once the IANA entries are avaiable so we can verify the URLs.
<t>RTDelay_Active_IP-UDP-Periodic_RFCXXXXsec4_Seconds_95Percentile</t>
<t>RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_Percent_LossRatio</t> -->
</section>
<section title="URI"> <t>URL: <eref target="https://www.iana.org/" /> ... &lt;Name&gt;</t>
<t>URL: https://www.iana.org/ ... &lt;name&gt;</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Description"> <name>Description</name>
<t>RTDelay: This metric assesses the delay of a stream of packets <dl newline="false" spacing="normal">
exchanged between two hosts (which are the two measurement points), <dt>RTDelay:</dt>
and the Output is the Round-trip delay for all successfully <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> successfully exchanged packets expressed as a percentage.</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 numbered="true" toc="default">
<section title="Reference Definition"> <name>Reference Definition</name>
<t>Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay <t>For delay:</t>
Metric for IPPM", RFC 2681, September 1999.</t> <t indent="3">Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-tri
p Delay
<t><xref target="RFC2681"/></t> 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>
<section numbered="true" toc="default">
<name>Fixed Parameters</name>
<dl newline="false" spacing="normal">
<dt>Type-P:</dt><dd><t>As defined in <xref target="RFC2330" sectionFor
mat="of" section="13"/>:</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>
<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">
<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.
<section title="Reference Method"> <!-- [rfced] We are revisiting this question from the AUTH state.
<t>The methodology for this metric is defined as
Type-P-Round-trip-Delay-Poisson-Stream in section 2.6 of <xref Sections 4.3.1, 6.3.1, 7.3.1, 8.3.1, and 9.3.1:
target="RFC2681">RFC 2681</xref> and section 3.6 of <xref
target="RFC2681">RFC 2681</xref> using the Type-P and Tmax defined Please review all updates to the five "The methodology for this
under Fixed Parameters. However, the Periodic stream will be metric is defined as ..." sentences, and let us know any objections
generated according to <xref target="RFC3432"/>.</t> regarding our addition of "(for singletons)" and "(for samples)". -->
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.</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>
<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 basis for measurement. In IPPM Metrics, this is called
and can easily be described by providing the list of stream the "stream"; this stream can easily be described by providing the
parameters.</t> list of stream Parameters.</t>
<t><xref target="RFC3432" sectionFormat="of" section="3"/> prescribes
<t>Section 3 of <xref target="RFC3432"/> prescribes the method for the method for
generating Periodic streams using associated parameters.</t> generating Periodic streams using associated Parameters.</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, 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>
<aside><t>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></aside>
<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>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"/>, 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>
<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>Percentile -- for the conditional distribution of all packets <t>Percentile: For the conditional distribution of all packets
with a valid value of Round-trip delay (undefined delays are with a valid value of round-trip delay (undefined delays are
excluded), a single value corresponding to the 95th percentile, as 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>
<section numbered="true" toc="default">
<section title="Reference Definition"> <name>Reference Definition</name>
<t>For all outputs ---</t> <t>For all outputs:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>T0:</dt>
<t hangText="T0">the start of a measurement interval, (format <dd>The start of a measurement interval (format
"date-and-time" as specified in Section 5.6 of <xref "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"/>.</t> "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
tionFormat="of" section="6.1"/>.</dd>
<t hangText="Tf">the end of a measurement interval, (format <dt>Tf:</dt>
"date-and-time" as specified in Section 5.6 of <xref <dd>The end 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="TotalPkts">the count of packets sent by the Src to tionFormat="of" section="6.1"/>.</dd>
Dst during the measurement interval.</t> <dt>TotalPkts:</dt>
</list></t> <dd>The count of packets sent by the Src to the
Dst during the measurement interval.</dd>
<t/> </dl>
<t>For RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile
<t>For</t> :</t>
<dl newline="false" spacing="normal">
<t>RTDelay_Active_IP-UDP-Periodic_RFCXXXXsec4_Seconds_95Percentile:</t <dt>95Percentile:</dt>
> <dd>The time value of the result is
<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 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" sec
target="RFC6020"/>) with resolution of 0.000000001 seconds (1.0 tionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds (1.0
ns).</t> ns).</dd>
</list></t> </dl>
<t>For RTLoss_Active_IP-UDP-Periodic_RFC8912sec4_Percent_LossRatio:</t
<t>For</t> >
<dl newline="false" spacing="normal">
<t>RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_Percent_LossRatio:</t> <dt>Percentile:</dt>
<dd>The numeric value of the result is
<t><list style="hanging">
<t hangText="Percentile">The numeric value of the result is
expressed in units of lost packets to total packets times 100%, expressed in units of lost packets to total packets times 100%,
as a positive value of type decimal64 with fraction digits = 9 as a positive value of type decimal64 with fraction digits = 9
(see section 9.3 of <xref target="RFC6020"/>) with resolution of (see <xref target="RFC6020" sectionFormat="of" section="9.3"/>) wi
0.0000000001.</t> th a resolution of
</list></t> 0.0000000001.</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Metric Units"> <name>Metric Units</name>
<t>The 95th Percentile of Round-trip Delay is expressed in <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>
<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&nbsp;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 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">
<!-- [rfced] Note that we will update the various "Revision Dates" to align
with the IANA registries, once the URIs are available.
<section title="Revision Date"> Example:
4.5.4. Revision Date
YYYY-MM-DD
[acm]
Yes, thank you.
[SG] update once IANA info is available
-->
<name>Revision Date</name>
<t>YYYY-MM-DD</t> <t>YYYY-MM-DD</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="packet_delay_variation" numbered="true" toc="default">
<section title="Packet Delay Variation Registry Entry"> <name>Packet Delay Variation Registry Entry</name>
<t>This section gives an initial registry entry for a Packet Delay <t>This section gives an initial Registry Entry for a Packet Delay
Variation metric.</t> Variation (PDV) metric.</t>
<section numbered="true" toc="default">
<section title="Summary"> <name>Summary</name>
<t>This category includes multiple indexes to the registry entries, <t>This category includes multiple indexes to the Registry Entry:
the element ID and metric name.</t> the element ID and Metric Name.</t>
<section numbered="true" toc="default">
<section title="ID (Identifier)"> <name>ID (Identifier)</name>
<t>&lt;insert numeric identifier, an integer&gt;</t> <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/"/> ... &lt;Name&gt;</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 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 &lt;section or column&gt; 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>
<aside><t>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></aside>
<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
</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>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&nbsp;situ could be enabled with an internal loopback th at
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>YYYY-MM-DD</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 anchor="dns_response_latency_and_loss" numbered="true" toc="default
<section title="DNS Response Latency and Loss Registry Entries"> ">
<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 using different names.
<xref target="RFC2681">RFC 2681</xref> defines a Round-trip delay <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>
<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>
<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/"/> ... &lt;Name&gt;</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 numbered="true" toc="default">
<section title="Reference Definition"> <name>Reference Definition</name>
<t>Mockapetris, P., "Domain names - implementation and <!-- [rfced] Section 6.2.1: We added "For Delay" and "For Loss" tags here.
specification", STD 13, RFC 1035, November 1987. (and updates)</t> Please review.
-->
<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 <t>For Delay:</t>
definition of the singleton (single value) Round-trip delay metric. <t indent="3">Mockapetris, P., "Domain names - implementation and
Section 3.4 of <xref target="RFC2681"/> provides the reference 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
tween the
Source (Src) and the Destination (Dst) at T as provided in
<xref target="RFC2681" sectionFormat="of" section="2.4"/>
is directionally ambiguous in the text, this metric
tightens the definition further to recognize that the host in the
Src Role will send the first packet to the host in the Dst Role
and will ultimately receive the corresponding return packet from the
Dst (when neither is lost).</t>
<t>Note that although the <xref target="RFC2681"/> definition of <t>For Loss:</t>
"Round-trip-Delay between Src and Dst at T" is directionally <t indent="3">Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673,
ambiguous in the text, this metric tightens the definition further DOI 10.17487/RFC6673, August 2012,
to recognize that the host in the "Src" role will send the first &lt;https://www.rfc-editor.org/info/rfc6673&gt;.
packet to "Dst", and ultimately receive the corresponding return <xref target="RFC6673"/></t>
packet from "Dst" (when neither are lost).</t> <t indent="3">Both response time and Loss metrics employ a maximum wai
ting time
<t>Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August
2012.</t>
<t><xref target="RFC6673"/></t>
<t>Both response time and loss metrics employ a maximum waiting time
for received responses, so the count of lost packets to total for received responses, so the count of lost packets to total
packets sent is the basis for the loss determination as per 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="false" spacing="normal">
<dt>Type-P:</dt><dd><t>As defined in <xref target="RFC2330" sectionFor
mat="of" section="13"/>:</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>
<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>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> <!-- [rfced] [AD*]: Because of the use of "RFC 2119" language,
we will need your approval of the following update.
<t>RA: not set</t> Original question (from the AUTH state):
Section 6.2.2: This is the only "Checksum:" entry that
uses "must" instead of "MUST". Please confirm that this is
intentional.
<t>RCODE: not set</t> Original:
* Checksum: the checksum must be calculated and the non-zero
checksum included in the header
<t>QDCOUNT: set to one (only one entry)</t> Author reply:
[acm] Good catch, change to MUST in 6.2.2
<t>ANCOUNT: not set</t> Currently:
Checksum: The checksum MUST be calculated and the non-zero
checksum included in the header -->
<t>NSCOUNT: not set</t> </dl>
</dd>
</dl>
<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">
<name>Packet Stream Generation</name>
<t>This section provides details regarding packet traffic, which is
used as the
basis for measurement. In IPPM Metrics, this is called the "stream";
this stream can easily be described by providing the list of stream
Parameters.</t>
<t><xref target="RFC2330" sectionFormat="of" section="11.1.3"/>
provides
three methods to generate Poisson sampling intervals. The reciprocal
of lambda is the average packet spacing; thus, the Runtime Parameter
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
ntime Parameter),
the subsequent send times are all computed prior to measurement by
computing the pseudorandom distribution of inter-packet send times
(truncating the distribution as specified in the Parameter Trunc),
and the Src sends each packet at the computed times.
<section title="Packet Stream Generation"> <!-- [rfced] [AD*]: Because of the use of "RFC 2119" language,
<t>This section gives the details of the packet traffic which is the we will need your approval of the following update.
basis for measurement. In IPPM metrics, this is called the Stream,
and 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 Original question (from the AUTH state):
three methods to generate Poisson sampling intervals. The reciprocal Sections 6.3.2 and 7.3.2: These sentences are difficult
of lambda is the average packet spacing, thus the Run-time Parameter to follow. Please confirm that it is correct to (1) have the "SHALL"
is Reciprocal_lambda = 1/lambda, in seconds.</t> in Section 7.3.2 but not in Section 6.3.2 and (2) say "as specified
in the Run-time Parameters" in Section 6.3.2 but "as specified in the
Parameter Trunc" in Section 7.3.2.
<t>Method 3 is used, where given a start time (Run-time Parameter), Original (the next paragraph is included for context):
the subsequent send times are all computed prior to measurement by Method 3 is used, where given a start time (Run-time Parameter), the
computing the pseudo-random distribution of inter-packet send times, subsequent send times are all computed prior to measurement by
(truncating the distribution as specified in the Run-time computing the pseudo-random distribution of inter-packet send times,
Parameters), and the Src sends each packet at the computed (truncating the distribution as specified in the Run-time
times.</t> Parameters), and the Src sends each packet at the computed times.
Note that Trunc is the upper limit on inter-packet times in the
Poisson distribution. A random value greater than Trunc is set equal
to Trunc instead.
...
Method 3 SHALL be used, where given a start time (Run-time
Parameter), the subsequent send times are all computed prior to
measurement by computing the pseudo-random distribution of inter-
packet send times, (truncating the distribution as specified in the
Parameter Trunc), and the Src sends each packet at the computed
times.
Note that Trunc is the upper limit on inter-packet times in the
Poisson distribution. A random value greater than Trunc is set equal
to Trunc instead.
Possibly (for the "Method 3" paragraph, assuming that "SHALL" and
"Parameter Trunc" are correct):
Method 3 SHALL be used. Where given a start time (Runtime
Parameter), the subsequent send times are all computed prior to
measurement by computing the pseudorandom distribution of
inter-packet send times (truncating the distribution as specified in
the Parameter Trunc), and the Src sends each packet at the computed
times.
Author reply:
[acm] This looks right, thanks.
Currently:
Method 3 SHALL be used. Where given a start time (Runtime
Parameter), the subsequent send times are all computed prior to
measurement by computing the pseudorandom distribution of inter-
packet send times (truncating the distribution as specified in the
Parameter Trunc), and the Src sends each packet at the computed
times. -->
</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 numbered="true" toc="default">
<section title="Reference Definition"> <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> </dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Metric Units"> <name>Metric Units</name>
<t>RTDNS: Round-trip Delay, dT, is expressed in seconds.</t> <dl newline="false" spacing="normal">
<dt>RTDNS:</dt><dd>Round-trip delay, dT, is expressed in seconds.</dd>
<t>RTLDNS: the Logical value, where 1 = Lost and 0 = Received.</t> <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&nbsp;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>YYYY-MM-DD</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="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 <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 6-11 for the six
closely-related registry entries. As a result, IANA is also asked to Named Metric Entries in <xref target="udp-poisson-owd-owl-reg"/> See <xref
assign corresponding URLs to each Named Metric.</t> target="name712"/> 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 different numeric identifiers to each of
the six Metrics.</t>
</section> </section>
<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_RFC8912sec7_
Seconds_95Percentile</dd>
<dt>7:</dt><dd>OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_
Seconds_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 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/" /> ... &lt;Name&gt;</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Description"> <name>Description</name>
<t>OWDelay: This metric assesses the delay of a stream of packets <dl newline="false" spacing="normal">
exchanged between two hosts (or measurement points), and reports the <dt>OWDelay:</dt><dd><t>This metric assesses the delay of a stream of
&lt;statistic&gt; One-way delay for all successfully exchanged packets
exchanged between two hosts (or measurement points) and reports the
&lt;statistic&gt; 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> successfully received packets expressed as a percentage.</dd>
</dl>
</section>
<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>
<section numbered="true" toc="default">
<section title="Fixed Parameters"> <name>Fixed Parameters</name>
<t>Type-P:<list style="symbols"> <dl newline="true" spacing ="normal">
<t>IPv4 header values: <list style="symbols"> <dt>Type-P:</dt>
<t>DSCP: set to 0</t> <dd><t/>
<dl newline="true" spacing="normal">
<t>TTL: set to 255</t> <dt>IPv4 header values:</dt>
<dd><t/>
<t>Protocol: Set to 17 (UDP)</t> <dl newline="false" spacing="compact">
</list></t> <dt>DSCP:</dt><dd>Set to 0</dd>
<dt>TTL:</dt><dd>Set to 255</dd>
<t>IPv6 header values:<list style="symbols"> <dt>Protocol:</dt><dd>Set to 17 (UDP)</dd>
<t>DSCP: set to 0</t> </dl>
</dd>
<t>Hop Count: set to 255</t> </dl>
<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 <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 &lt;section or column&gt; for two
additional
Fixed Parameters.</t> 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>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.</t> 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 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 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 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>
</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> <dd>Launches each packet and waits for return
transmissions from the Dst. &nbsp;This is the TWAMP Session-Sender
<t hangText="Dst">waits for each packet from Src and sends a .</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;This is the TWAMP Session-Reflecto
r.</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>See subsection titles below for Types.</t> <t>Types are discussed in the subsections below.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Reference Definition"> <name>Reference Definition</name>
<t>For all output types ---<list style="hanging"> <t>For all output types:</t>
<t hangText="T0">the start of a measurement interval, (format <dl newline="false" spacing="normal">
"date-and-time" as specified in Section 5.6 of <xref <dt>T0:</dt>
target="RFC3339"/>, see also Section 3 of <xref <dd>The start 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
"date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
<t hangText="Tf">the end of a measurement interval, (format "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
"date-and-time" as specified in Section 5.6 of <xref tionFormat="of" section="6.1"/>.</dd>
target="RFC3339"/>, see also Section 3 of <xref <dt>Tf:</dt>
target="RFC6991"/>). The UTC Time Zone is required by Section <dd>The end of a measurement interval (format
6.1 of <xref target="RFC2330"/>.</t> "date&nbhy;time" as specified in <xref target="RFC3339"
</list></t> sectionFormat="of" section="5.6"/>; see also
"date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
<t>For LossRatio -- the count of lost packets to total packets sent "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
is the basis for the loss ratio calculation as per Section 4.1 of tionFormat="of" section="6.1"/>.</dd>
<xref target="RFC7680"/>.</t> </dl>
<t>For LossRatio, the count of lost packets to total packets sent
<t>For each &lt;statistic&gt;, one of the following sub-sections is the basis for the loss ratio calculation as per <xref target="RFC76
apply:</t> 80" sectionFormat="of" section="4.1"/>.</t>
<t>For each &lt;statistic&gt;, one of the following subsections
<section title="Percentile95"> applies.</t>
<t>The 95th percentile SHALL be calculated using the conditional <section numbered="true" toc="default">
distribution of all packets with a finite value of One-way delay <name>Percentile95</name>
(undefined delays are excluded), a single value as follows:</t> <t>The 95th percentile <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 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 anchor="mean-sec7422" numbered="true" toc="default">
<section title="Mean"> <name>Mean</name>
<t>The mean SHALL be calculated using the conditional distribution <t>The mean <bcp14>SHALL</bcp14> be calculated using the conditional
of all packets with a finite value of One-way delay (undefined distribution
delays are excluded), a single value as follows:</t> of all packets with a finite value of one-way delay (undefined
delays are excluded) -- a single value, as follows:</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
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 numbered="true" toc="default">
<section title="Min"> <name>Min</name>
<t>The minimum SHALL be calculated using the conditional <t>The minimum <bcp14>SHALL</bcp14> be calculated using the conditio
distribution of all packets with a finite value of One-way delay nal
(undefined delays are excluded), a single value as follows:</t> distribution of all packets with a finite value of one-way delay
(undefined delays are excluded) -- a single value, as follows:</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
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"> <name>Max</name>
<t>The maximum SHALL be calculated using the conditional <t>The maximum <bcp14>SHALL</bcp14> be calculated using the conditio
distribution of all packets with a finite value of One-way delay nal
(undefined delays are excluded), a single value as follows:</t> distribution of all packets with a finite value of one-way delay
(undefined delays are excluded) -- a single value, as follows:</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
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 numbered="true" toc="default">
<section title="Std_Dev"> <name>Std_Dev</name>
<t>The Std_Dev SHALL be calculated using the conditional <t>The standard deviation (Std_Dev) <bcp14>SHALL</bcp14> be calculat
distribution of all packets with a finite value of One-way delay ed 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 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>
</section> </section>
<section numbered="true" toc="default">
<section title="Metric Units"> <name>Metric Units</name>
<t>The &lt;statistic&gt; of One-way Delay is expressed in <t>The &lt;statistic&gt; of one-way delay is expressed in
seconds.</t> seconds.</t>
<t>The one-way loss ratio is expressed as a percentage of lost
<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 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&nbsp;situ could be enabled with an internal loopback th at
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>YYYY-MM-DD</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="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> <dt>12:</dt><dd>OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912
sec8_Seconds_95Percentile</dd>
<t>where &lt;statistic&gt; is one of:</t> <dt>13:</dt><dd>OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912
sec8_Mean</dd>
<t><list style="symbols"> <dt>14:</dt><dd>OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912
<t>95Percentile</t> sec8_Min</dd>
<dt>15:</dt><dd>OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912
<t>Mean</t> sec8_Max</dd>
<dt>16:</dt><dd>OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912
<t>Min</t> sec8_StdDev</dd>
<dt>17:</dt><dd>OWLoss_Active_IP-UDP-Periodic-Payload142B_RFC8912sec
<t>Max</t> 8_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"> <name>URI</name>
<t>URL: https://www.iana.org/ ... &lt;name&gt;</t> <t>URL: <eref target="https://www.iana.org/"/> ... &lt;Name&gt;</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Description"> <name>Description</name>
<t>OWDelay: This metric assesses the delay of a stream of packets <dl newline="false" spacing="normal">
exchanged between two hosts (or measurement points), and reports the <dt>OWDelay:</dt><dd><t>This metric assesses the delay of a stream of
&lt;statistic&gt; One-way delay for all successfully exchanged packets
exchanged between two hosts (or measurement points) and reports the
&lt;statistic&gt; 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> successfully received packets expressed as a percentage.</dd>
</dl>
</section>
<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>
<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 &lt;section or column&gt; for thre e additional
Fixed Parameters.</t> 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>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>
<aside><t>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></aside>
<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> <dd>Launches each packet and waits for return
transmissions from the Dst. &nbsp;This is the TWAMP Session-Sender
<t hangText="Dst">waits for each packet from Src and sends a .</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;This is the TWAMP Session-Reflecto
r.</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>See subsection titles in Reference Definition for Latency <t>Latency Types are discussed in the subsections below.</t>
Types.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Reference Definition"> <name>Reference Definition</name>
<t>For all output types ---<list style="hanging"> <t>For all output types:</t>
<t hangText="T0">the start of a measurement interval, (format <dl newline="false" spacing="normal">
"date-and-time" as specified in Section 5.6 of <xref <dt>T0:</dt>
target="RFC3339"/>, see also Section 3 of <xref <dd>The start 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
"date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
<t hangText="Tf">the end of a measurement interval, (format "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
"date-and-time" as specified in Section 5.6 of <xref tionFormat="of" section="6.1"/>.</dd>
target="RFC3339"/>, see also Section 3 of <xref <dt>Tf:</dt>
target="RFC6991"/>). The UTC Time Zone is required by Section <dd>The end of a measurement interval (format
6.1 of <xref target="RFC2330"/>.</t> "date&nbhy;time" as specified in <xref target="RFC3339"
</list></t> sectionFormat="of" section="5.6"/>; see also
"date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
<t>For LossRatio -- the count of lost packets to total packets sent "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
is the basis for the loss ratio calculation as per Section 4.1 of tionFormat="of" section="6.1"/>.</dd>
<xref target="RFC7680"/>.</t> </dl>
<t>For LossRatio, the count of lost packets to total packets sent
<t>For each &lt;statistic&gt;, one of the following sub-sections is the basis for the loss ratio calculation as per <xref target="RFC76
apply:</t> 80" sectionFormat="of" section="4.1"/>.</t>
<t>For each &lt;statistic&gt;, one of the following subsections
<section title="Percentile95"> applies.</t>
<t>The 95th percentile SHALL be calculated using the conditional <section numbered="true" toc="default">
distribution of all packets with a finite value of One-way delay <name>Percentile95</name>
(undefined delays are excluded), a single value as follows:</t> <t>The 95th percentile <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 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 anchor="mean-sec8422" numbered="true" toc="default">
<section title="Mean"> <name>Mean</name>
<t>The mean SHALL be calculated using the conditional distribution <t>The mean <bcp14>SHALL</bcp14> be calculated using the conditional
of all packets with a finite value of One-way delay (undefined distribution
delays are excluded), a single value as follows:</t> of all packets with a finite value of one-way delay (undefined
delays are excluded) -- a single value, as follows:</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
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"> <name>Min</name>
<t>The minimum SHALL be calculated using the conditional <t>The minimum <bcp14>SHALL</bcp14> be calculated using the conditio
distribution of all packets with a finite value of One-way delay nal
(undefined delays are excluded), a single value as follows:</t> distribution of all packets with a finite value of one-way delay
(undefined delays are excluded) -- a single value, as follows:</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
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"> <name>Max</name>
<t>The maximum SHALL be calculated using the conditional <t>The maximum <bcp14>SHALL</bcp14> be calculated using the conditio
distribution of all packets with a finite value of One-way delay nal
(undefined delays are excluded), a single value as follows:</t> distribution of all packets with a finite value of one-way delay
(undefined delays are excluded) -- a single value, as follows:</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
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 numbered="true" toc="default">
<section title="Std_Dev"> <name>Std_Dev</name>
<t>The Std_Dev SHALL be calculated using the conditional <t>Std_Dev <bcp14>SHALL</bcp14> be calculated using the conditional
distribution of all packets with a finite value of One-way delay distribution of all packets with a finite value of one&nbhy;way dela
(undefined delays are excluded), a single value as follows:</t> y
(undefined delays are excluded) -- a single value, as follows:</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
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> </section>
<section numbered="true" toc="default">
<section title="Metric Units"> <name>Metric Units</name>
<t>The &lt;statistic&gt; of One-way Delay is expressed in seconds, <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>
<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&nbsp;situ could be enabled with an internal loopback th at
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>YYYY-MM-DD</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="icmp_roundtrip_latency_and_loss" numbered="true" toc="defau
<section title="ICMP Round-trip Latency and Loss Registry Entries"> lt">
<t>This section specifies three initial registry entries for the ICMP <name>ICMP Round-Trip Latency and Loss Registry Entries</name>
Round-trip Latency, and another entry for ICMP Round-trip Loss <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>
<section numbered="true" toc="default">
<t>All column entries beside the ID, Name, Description, and Output <name>Summary</name>
Reference Method categories are the same, thus this section proposes two <t>This category includes multiple indexes to the Registry Entries: the
closely-related registry entries. As a result, IANA is also asked to element ID and Metric Name.</t>
assign corresponding URLs to each Named Metric.</t> <section numbered="true" toc="default">
<name>ID (Identifier)</name>
<section title="Summary"> <t>IANA has allocated the numeric Identifiers 18-21 for the four
<t>This category includes multiple indexes to the registry entry: the Named Metric Entries in <xref target="icmp_roundtrip_latency_and_loss"/
element ID and metric name.</t> >.
See <xref target="name912"/> for mapping to Names.</t>
<section title="ID (Identifier)">
<t>IANA is asked to assign different numeric identifiers to each of
the four Named Metrics.</t>
</section> </section>
<section title="Name"> <section anchor="name912" numbered="true" toc="default">
<t>RTDelay_Active_IP-ICMP-SendOnRcv_RFCXXXXsec9_Seconds_&lt;statistic& <name>Name</name>
gt;</t> <dl spacing="normal" indent="5" newline="false">
<dt>18:</dt><dd>RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_
<t>where &lt;statistic&gt; is one of:</t> Mean</dd>
<dt>19:</dt><dd>RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_
<t><list style="symbols"> Min</dd>
<t>Mean</t> <dt>20:</dt><dd>RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_
Max</dd>
<t>Min</t> <dt>21:</dt><dd>RTLoss_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Percent_
LossRatio</dd>
<t>Max</t> </dl>
</list></t>
<t>RTLoss_Active_IP-ICMP-SendOnRcv_RFCXXXXsec9_Percent_LossRatio</t>
</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/"/> ... &lt;Name&gt;</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Description"> <name>Description</name>
<t>RTDelay: This metric assesses the delay of a stream of ICMP <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> successfully exchanged packets expressed as a percentage.</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 numbered="true" toc="default">
<section title="Reference Definition"> <name>Reference Definition</name>
<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><xref target="RFC2681" sectionFormat="of" section="2.4"/> provides
<t>Section 2.4 of <xref target="RFC2681"/> provides the reference the reference
definition of the singleton (single value) Round-trip delay metric. definition of the singleton (single value) round-trip delay metric.
Section 3.4 of <xref target="RFC2681"/> provides the reference <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>Note that although the definition of round-trip delay between the
<t>Note that although the <xref target="RFC2681"/> definition of Source (Src) and the Destination (Dst) as provided in
"Round-trip-Delay between Src and Dst" is directionally ambiguous in <xref target="RFC2681" sectionFormat="of" section="2.4"/>
the text, this metric tightens the definition further to recognize is directionally ambiguous in the text, this metric
that the host in the "Src" role will send the first packet to "Dst", tightens the definition further to recognize that the host in the
and ultimately receive the corresponding return packet from "Dst" Src Role will send the first packet to the host in the Dst Role
(when neither are lost).</t> and will ultimately receive the corresponding return packet from the
Dst (when neither is lost).</t>
<t>Finally, note that the variable "dT" is used in <xref <t>Finally, note that the variable "dT" is used in <xref target="RFC26
target="RFC2681"/> to refer to the value of Round-trip delay in 81" format="default"/> to refer to the value of round-trip delay in
metric definitions and methods. The variable "dT" has been re-used metric definitions and methods. The variable "dT" has been reused
in other IPPM literature to refer to different quantities, and 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,
<t>Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August DOI 10.17487/RFC6673, August 2012,
2012.</t> &lt;https://www.rfc-editor.org/info/rfc6673&gt;.
<xref target="RFC6673"/></t>
<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>
<section numbered="true" toc="default">
<name>Fixed Parameters</name>
<dl newline="true" spacing="normal">
<dt>Type-P:</dt><dd><t>As defined in <xref target="RFC2330" sectionFor
mat="of" section="13"/>:</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 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 Tmax defined sectionFormat="of" section="2.6"/> (for singletons) and <xref
under Fixed Parameters.</t> 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>
<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>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 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>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 &lt;section or column&gt; for
<t>(see the Packet Stream Generation section for additional Run-time additional Runtime Parameters.</t>
parameters)</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
</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>See subsection titles in Reference Definition for Latency <t>Latency Types are discussed in the subsections below.</t>
Types.</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="RFC6673"
<t>LossRatio -- the count of lost packets to total packets sent is sectionFormat="of" section="6.1"/>.</t>
the basis for the loss ratio calculation as per Section 6.1 of <xref
target="RFC6673"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Reference Definition"> <name>Reference Definition</name>
<t>For all output types ---<list style="hanging"> <t>For all output types:</t>
<t hangText="T0">the start of a measurement interval, (format <dl newline="false" spacing="normal">
"date-and-time" as specified in Section 5.6 of <xref <dt>T0:</dt>
target="RFC3339"/>, see also Section 3 of <xref <dd>The start 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
"date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
<t hangText="Tf">the end of a measurement interval, (format "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
"date-and-time" as specified in Section 5.6 of <xref tionFormat="of" section="6.1"/>.</dd>
target="RFC3339"/>, see also Section 3 of <xref <dt>Tf:</dt>
target="RFC6991"/>). The UTC Time Zone is required by Section <dd>The end 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="TotalCount">the count of packets actually sent by "date&nbhy;and&nbhy;time" in <xref target="RFC6991" sectionFormat=
the Src to Dst during the measurement interval.</t> "of" section="3"/>). The UTC Time Zone is required by <xref target="RFC2330" sec
</list></t> tionFormat="of" section="6.1"/>.</dd>
<dt>TotalCount:</dt>
<t>For LossRatio -- the count of lost packets to total packets sent <dd>The count of packets actually sent by
is the basis for the loss ratio calculation as per Section 4.1 of the Src to the Dst during the measurement interval.</dd>
<xref target="RFC7680"/>.</t> </dl>
<t>For LossRatio, the count of lost packets to total packets sent
<t>For each &lt;statistic&gt;, one of the following sub-sections is the basis for the loss ratio calculation as per <xref target="RFC76
apply:</t> 80" sectionFormat="of" section="4.1"/>.</t>
<t>For each &lt;statistic&gt;, one of the following subsections
<section title="Mean"> applies.</t>
<t>The mean SHALL be calculated using the conditional distribution <section numbered="true" toc="default">
of all packets with a finite value of Round-trip 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 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"> <name>Min</name>
<t>The minimum SHALL be calculated using the conditional <t>The minimum <bcp14>SHALL</bcp14> be calculated using the conditio
distribution of all packets with a finite value of Round-trip nal
delay (undefined delays are excluded), a single value as 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"> <name>Max</name>
<t>The maximum SHALL be calculated using the conditional <t>The maximum <bcp14>SHALL</bcp14> be calculated using the conditio
distribution of all packets with a finite value of Round-trip nal
delay (undefined delays are excluded), a single value as 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> </section>
<section numbered="true" toc="default">
<section title="Metric Units"> <name>Metric Units</name>
<t>The &lt;statistic&gt; of Round-trip Delay is expressed in <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>
<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&nbsp;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 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>YYYY-MM-DD</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
">
<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 <name>Summary</name>
the four Named Metrics.</t> <t>This category includes multiple indexes to the Registry Entries: the
element ID and Metric Name.</t>
<section numbered="true" toc="default">
<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> <name>Name</name>
<dl spacing="normal" newline="false" indent="5">
<t>where &lt;statistic&gt; is one of:</t> <dt>22:</dt><dd>RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Mean</dd>
<dt>23:</dt><dd>RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Min</dd>
<t><list style="symbols"> <dt>24:</dt><dd>RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Max</dd>
<t>Mean</t> <dt>25:</dt><dd>RTDelay_Passive_IP-TCP-HS_RFC8912sec10_Seconds_Singl
eton</dd>
<t>Min</t> </dl>
<t>Note that a midpoint observer only has the opportunity to
<t>Max</t> compose a single RTDelay on the TCP handshake.</t>
</list></t> <dl spacing="normal" newline="false" indent="5">
<dt>26:</dt><dd>RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count</dd>
<t>RTDelay_Passive_IP-TCP-HS_RFCXXXXsec10_Seconds_Singleton</t> </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"> <name>URI</name>
<t>URL: https://www.iana.org/ ... &lt;name&gt;</t> <t>URL: <eref target="https://www.iana.org/" /> ... &lt;Name&gt;</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Description"> <name>Description</name>
<t>RTDelay: This metric assesses the round-trip delay of TCP packets <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>
<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"> <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 Definitions"> <name>Reference Definition</name>
<t>Although there is no RFC that describes passive measurement of
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 terms "singleton" and "sample" as
singleton (single value) Round-trip delay metric. Section 3.4 of defined in <xref target="RFC2330" sectionFormat="of" section="11"/>.
<xref target="RFC2681"/> provides the reference definition expanded (<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 measuremen
Round-trip Delay singleton (we are extending the composition of ts 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 stream 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&nbhy;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&nbhy;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 i