<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
     docName="draft-ietf-ippm-initial-registry-16"
     ipr="trust200902"> number="8912"
     ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
     consensus="true" xml:lang="en" tocInclude="true" tocDepth="3"
     symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.43.0 -->
  <front>
    <title abbrev="Initial Performance Metrics Registry">Initial Performance Metrics Registry
    Entries</title>

    <seriesInfo name="RFC" value="8912"/>
    <author fullname="Al Morton" initials="A." surname="Morton">
      <organization>AT&amp;T Labs</organization>
      <address>
        <postal>
          <street>200 Laurel Avenue South</street>

          <city>Middletown,</city>
          <city>Middletown</city>
          <region>NJ</region>
          <code>07748</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone>+1 732 420 1571</phone>

        <facsimile>+1 732 368 1192</facsimile>
        <email>acmorton@att.com</email>

        <uri/>
      </address>
    </author>
    <author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
      <organization abbrev="UC3M">Universidad Carlos III de
      Madrid</organization>
      <address>
        <postal>
          <street>Av. Universidad 30</street>
          <city>Leganes</city>
          <region>Madrid</region>
          <code>28911</code>

          <country>SPAIN</country>
          <country>Spain</country>
        </postal>
        <phone>34 91 6249500</phone>
        <email>marcelo@it.uc3m.es</email>
        <uri>http://www.it.uc3m.es</uri>
      </address>
    </author>
    <author fullname="Philip Eardley" initials="P." surname="Eardley">
      <organization abbrev="BT">BT</organization>
      <address>
        <postal>
          <street>Adastral Park, Martlesham Heath</street>
          <city>Ipswich</city>

          <country>ENGLAND</country>
          <country>United Kingdom</country>
        </postal>
        <email>philip.eardley@bt.com</email>
      </address>
    </author>
    <author fullname="Kevin D'Souza" initials="K." surname="D'Souza">
      <organization>AT&amp;T Labs</organization>
      <address>
        <postal>
          <street>200 Laurel Avenue South</street>

          <city>Middletown,</city>
          <city>Middletown</city>
          <region>NJ</region>
          <code>07748</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone>+1 732 420 xxxx</phone>

        <facsimile/> 2514</phone>
        <email>kld@att.com</email>

        <uri/>
      </address>
    </author>

    <date day="9" month="March" 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>
      <t>This memo defines the set of Initial Entries initial entries for the IANA Performance
      Metrics Registry. The set includes: includes UDP Round-trip Round-Trip Latency and Loss,
      Packet Delay Variation, DNS Response Latency and Loss, UDP Poisson
      One-way
      One-Way Delay and Loss, UDP Periodic One-way One-Way Delay and Loss, ICMP
      Round-trip
      Round-Trip Latency and Loss, and TCP round-trip Latency Round-Trip Delay and Loss.</t>
    </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>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>This memo proposes defines an initial set of entries for the Performance
      Metrics Registry.
      It uses terms and definitions from the IPPM IP Performance Metrics (IPPM)
      literature, primarily <xref target="RFC2330"/>.</t> target="RFC2330" format="default"/>.</t>
      <t>Although there are several standard templates for organizing
      specifications of performance metrics Performance Metrics (see <xref target="RFC7679"/> target="RFC7679" format="default"/> for
      an example of the traditional IPPM template, based to a large extent on
      the Benchmarking Methodology Working Group's traditional template in
      <xref target="RFC1242"/>, target="RFC1242" format="default"/>, and see <xref target="RFC6390"/> target="RFC6390" format="default"/> for a similar
      template), none of these templates were intended to become the basis for
      the columns of an IETF-wide registry Registry of metrics. While examining aspects
      of metric specifications which that need to be registered, it became clear
      that none of the existing metric templates fully satisfies satisfy the
      particular needs of a registry.</t> Registry.</t>
      <t>Therefore, <xref target="I-D.ietf-ippm-metric-registry"/> target="RFC8911" format="default"/> defines the
      overall format for a Performance Metrics Registry. Section 5 of <xref
      target="I-D.ietf-ippm-metric-registry"/> target="RFC8911" sectionFormat="of" section="5"/> also gives guidelines for those
      requesting registration of a Metric, Metric -- that is is, the creation of entry(s) one or more entries in
      the Performance Metrics Registry: "In Registry:</t>
<!-- Quoted text is DNE (and updated per author's reply during AUTH
     for draft-ietf-ippm-metric-registry)

Check whether this should be updated to "proposed" based on AQ sent 8911.
-->
      <blockquote>In essence, there needs to be
      evidence that (1) a candidate Registered Performance Metric has significant
      industry interest, interest or has seen deployment, deployment and (2) there is agreement that
      the candidate Registered Performance Metric serves its intended
      purpose." The
      purpose.</blockquote>

<t>The process defined in <xref target="I-D.ietf-ippm-metric-registry"/> target="RFC8911" format="default"/>
      also requires that new entries are be administered by IANA through the
      Specification Required policy, 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 title="Scope"> numbered="true" toc="default">
      <name>Scope</name>
      <t>This document defines a set of initial Performance Metrics Registry
      entries.
      Entries. Most are Active Performance Metrics, which are based on RFCs
      prepared in the IPPM working group Working Group of the IETF, according to their
      framework <xref target="RFC2330"/> target="RFC2330" format="default"/> and its updates.</t>
    </section>
    <section title="Registry numbered="true" toc="default">
      <name>Registry Categories and Columns"> Columns</name>
      <t>This memo uses the terminology defined in <xref
      target="I-D.ietf-ippm-metric-registry"/>.</t> target="RFC8911" format="default"/>.</t>
      <t>This section provides the categories and columns of the registry, Registry, for
      easy reference. An entry (row) therefore gives a complete description of
      a Registered Metric.</t>

      <t><figure>
          <artwork><![CDATA[Legend:
 Registry

      <t>Registry Categories and Columns, Columns are shown as below in this format:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
    Category
                                            ------------------
    ------------------...
    Column |  Column | |...
    ]]></artwork>

      <artwork name="" type="" align="left" alt=""><![CDATA[
Summary
------------------------------------------------------------------------
---------------------------------------------------------------
Identifier | Name | URI | Desc. | Reference | Change Controller     | Ver |
           |      |     |       |           | Controller |

Metric Definition
-----------------------------------------
Reference Definition | Fixed Parameters |

Method of Measurement
---------------------------------------------------------------------
Reference | Packet     | Traffic | Sampling     | Run-time Runtime    | Role |
Method    | Stream     | Filter  | Distribution | Parameters |      |
          | Generation |
Output
-----------------------------------------
Type | Reference  | Units | Calibration |
     | Definition |       |             |

Administrative Information
------------------------------------
-------------------------------------
Status |Requester | Rev | Rev.Date Rev. Date |

Comments and Remarks
--------------------
]]></artwork>
        </figure></t>
    </section>
    <section title="UDP Round-trip anchor="udp-rt-latency-loss-reg-entries" numbered="true" toc="default">
      <name>UDP Round-Trip Latency and Loss Registry Entries"> Entries</name>
      <t>This section specifies an initial registry entry Registry Entry for the UDP
      Round-trip Latency,
      Round-Trip Latency and another entry for the UDP Round-trip Round-Trip Loss Ratio.</t>

      <t>Note:
      <aside><t>Note: Each Registry entry 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 categories can be split split,
      and a single section can specify two or more closely-related closely related metrics.
      For example, this section specifies two Registry entries Entries with many
      common columns. See Section 7 <xref target="udp-poisson-owd-owl-reg"/> for an example specifying multiple
      Registry entries Entries with many common columns.</t> columns.</t></aside>
      <t>All column entries beside besides the ID, Name, Description, and Output
      Reference Method categories are the same, thus same; thus, this section proposes defines two
      closely-related registry entries.
      closely related Registry Entries. As a result, IANA is has also asked to
      assign
      assigned a corresponding URL to each of the two Named Metric.</t> Metrics.</t>
      <section title="Summary"> numbered="true" toc="default">
        <name>Summary</name>
        <t>This category includes multiple indexes to the registry entry: Registry Entries: the
        element ID and metric name.</t> Metric Name.</t>
        <section title="ID (Identifier)"> numbered="true" toc="default">
          <name>ID (Identifier)</name>
          <t>IANA is asked to assign different has allocated the numeric identifiers to each of Identifiers 1 and 2 for the two
   Named Metrics.</t>
        </section>

        <section title="Name">
          <t>RTDelay_Active_IP-UDP-Periodic_RFCXXXXsec4_Seconds_95Percentile</t>

          <t>RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_Percent_LossRatio</t> Metric Entries in <xref
   target="udp-rt-latency-loss-reg-entries"/>. See <xref target="name412"/> for mapping to Names.
</t>
        </section>
        <section title="URI">
          <t>URL: https://www.iana.org/ ... &lt;name&gt;</t> anchor="name412" numbered="true" toc="default">
          <name>Name</name>
	<dl>
          <dt>1:</dt><dd>RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile</dd>
          <dt>2:</dt><dd>RTLoss_Active_IP-UDP-Periodic_RFC8912sec4_Percent_LossRatio</dd>
	</dl>
        </section>
        <section title="Description">
          <t>RTDelay: This metric assesses numbered="true" toc="default">
          <name>URI</name>
<!-- [rfced] Is this section to be updated to include the delay of full URL for each
URI, or is a stream of packets
          exchanged between two hosts (which are link to the two measurement points),
          and main registry
<https://www.iana.org/assignments/performance-metrics> sufficient because the Output is
reader can find all of the Round-trip URIs there?  Note that any updates will be applied
to similar text throughout the document.

4.1.3.  URI

   URL: https://www.iana.org/ ... <Name>

[acm]
The URI section contains a full URL to the HTML-ized Registry Entry text for
each
Registry Entry. So

https://www.iana.org/
... RTDelay_Active_IP-UDP-Periodic_RFCXXXXsec4_Seconds_95Percentile

https://www.iana.org/
... RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_Percent_LossRatio

[SG] update once the IANA entries are avaiable so we can verify the URLs.

-->

          <t>URL: <eref target="https://www.iana.org/" /> ... &lt;Name&gt;</t>
        </section>
        <section numbered="true" toc="default">
          <name>Description</name>
          <dl newline="false" spacing="normal">
	    <dt>RTDelay:</dt>
           <dd>This metric assesses the delay of a stream of packets
          exchanged between two hosts (which are the two measurement points).
          The output is the round-trip delay for all successfully
          exchanged packets expressed as the 95th percentile of their
          conditional delay distribution.</t>

          <t>RTLoss: This distribution.</dd>
          <dt>RTLoss:</dt>
           <dd>This metric assesses the loss ratio of a stream of
          packets exchanged between two hosts (which are the two measurement
          points), and the Output
          points). The output is the Round-trip round-trip loss ratio for all
          successfully exchanged packets expressed as a percentage.</t> percentage.</dd>
       </dl>
        </section>
        <section title="Change Controller"> numbered="true" toc="default">
          <name>Change Controller</name>
          <t>IETF</t>
        </section>
        <section title="Version numbered="true" toc="default">
          <name>Version (of Registry Format)"> Format)</name>
          <t>1.0</t>
        </section>
      </section>
      <section title="Metric Definition"> numbered="true" toc="default">
        <name>Metric Definition</name>
        <t>This category includes columns to prompt the entry of all necessary
        details related to the metric definition, including the RFC reference
        and values of input factors, called fixed parameters.</t> "Fixed Parameters".</t>
        <section title="Reference Definition">
          <t>Almes, numbered="true" toc="default">
          <name>Reference Definition</name>
	  <t>For delay:</t>
          <t indent="3">Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
	  Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999.</t>

          <t><xref target="RFC2681"/></t>

          <t>Section 2.4 of 1999,
	  &lt;https://www.rfc-editor.org/info/rfc2681&gt;.
          <xref target="RFC2681"/> 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 round-trip delay metric.
          Section 3.4 of
          <xref target="RFC2681"/> target="RFC2681" sectionFormat="of" section="3.4"/>
 provides the reference
          definition expanded to cover a multi-singleton sample. Note that
          terms such as singleton "singleton" and sample "sample" are defined in Section 11 of <xref target="RFC2330"/>.</t>

          <t>Note target="RFC2330" sectionFormat="of" section="11"/>.</t>
          <t indent="3">Note that although the <xref target="RFC2681"/> definition of
          "Round-trip-Delay round-trip delay between Src the
          Source (Src) and Dst" the Destination (Dst) 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
          Src Role will send the first packet to "Dst", the host in the Dst Role
          and will ultimately receive the corresponding return packet from "Dst" the
          Dst (when neither are is lost).</t>

          <t>Finally,
          <t indent="3">Finally, note that the variable "dT" is used in <xref
          target="RFC2681"/> target="RFC2681" format="default"/> to refer to the value of Round-trip round-trip delay in
          metric definitions and methods. The variable "dT" has been re-used reused
          in other IPPM literature to refer to different quantities, quantities and
          cannot be used as a global variable name.</t>

          <t>Morton,
	<t>For loss:</t>
          <t indent="3">Morton, A., "Round-trip "Round-Trip Packet Loss Metrics", RFC 6673,
          DOI 10.17487/RFC6673, August
          2012.</t>

          <t><xref 2012,
	  &lt;https://www.rfc-editor.org/info/rfc6673&gt;.
          <xref target="RFC6673"/></t>
          <t>Both delay Delay and loss Loss metrics employ a maximum waiting time for
          received packets, so the count of lost packets to total packets sent
          is the basis for the loss ratio calculation as per Section 6.1 of <xref target="RFC6673"/>.</t> target="RFC6673" sectionFormat="of" section="6.1"/>.</t>
        </section>
        <section title="Fixed Parameters">
          <t>Type-P as numbered="true" toc="default">
          <name>Fixed Parameters</name>
        <dl newline="false" spacing="normal">
          <dt>Type-P:</dt><dd><t>As defined in Section 13 of <xref target="RFC2330"/>:
          <list style="symbols">
              <t>IPv4 target="RFC2330" sectionFormat="of" section="13"/>:</t>
          <dl newline="true" spacing="normal">
            <dt>IPv4 header values: <list style="symbols">
                  <t>DSCP: set values:</dt>
	    <dd><t/>
 	    <dl newline="false" spacing="compact">
            <dt>DSCP:</dt><dd>Set to 0</t>

                  <t>TTL: set 0</dd>
            <dt>TTL:</dt><dd>Set to 255</t>

                  <t>Protocol: set 255</dd>
            <dt>Protocol:</dt><dd>Set to 17 (UDP)</t>
                </list></t>

              <t>IPv6 (UDP)</dd>
	    </dl>
	    </dd>
	  </dl>
	  <dl newline="true" spacing="normal">
            <dt>IPv6 header values:<list style="symbols">
                  <t>DSCP: set to 0</t>

                  <t>Hop Count: set to 255</t>

                  <t>Next Header: set 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)</t>

                  <t>Flow Label: set to zero</t>

                  <t>Extension Headers: none</t>
                </list></t>

              <t>UDP (UDP)</dd>
             <dt>Flow Label:</dt><dd>Set to 0</dd>
             <dt>Extension Headers:</dt><dd>None</dd>
	   </dl></dd>
	  </dl>

	  <dl newline="true" spacing="normal">
             <dt>UDP header values: <list style="symbols">
                  <t>Checksum: the values:</dt>
	     <dd><t/><dl newline="false" spacing="compact">
             <dt>Checksum:</dt><dd>The checksum MUST <bcp14>MUST</bcp14> be calculated and the
                  non-zero checksum included in the header</t>
                </list></t>

              <t>UDP Payload <list style="symbols">
                  <t>total header</dd>
		</dl></dd>
	  </dl>

	  <dl newline="true" spacing="normal">
            <dt>UDP Payload:</dt>
	    <dd><t/><dl newline="false" spacing="compact">
            <dt>Total of 100 bytes</t>
                </list></t>
            </list></t>

          <t>Other measurement parameters:<list style="symbols">
              <t>Tmax: a bytes</dt><dd/>
	  </dl></dd>
          </dl>
        </dd>
      </dl>

      <dl newline="true" spacing="normal">
	<dt>Other measurement Parameters:</dt>
	<dd><t/>
         <dl newline="false" spacing="normal">
              <dt>Tmax:</dt><dd>A loss threshold waiting time<list style="symbols">
                  <t>3.0, time with value 3.0, expressed in units of seconds, as a positive value
               of type decimal64 with fraction digits = 4 (see section 9.3
                  of <xref target="RFC6020"/>) target="RFC6020" 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 section 6 of <xref
                  target="RFC5905"/>.</t>
                </list></t>
            </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
          </dl>
	</dd>
      </dl>
        </section>
      </section>
      <section title="Method numbered="true" toc="default">
        <name>Method of Measurement"> Measurement</name>
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure
        an unambiguous methods method for implementations.</t>
        <section title="Reference Method"> 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
          Type-P-Round-trip-Delay-Poisson-Stream in section 2.6 of <xref
          target="RFC2681">RFC 2681</xref> target="RFC2681"
          sectionFormat="of" section="2.6"/> (for singletons) and section 3.6 of <xref
          target="RFC2681">RFC 2681</xref> target="RFC2681"
          sectionFormat="of" section="3.6"/> (for samples) using the Type-P
          and Tmax defined
          under in the Fixed Parameters. Parameters column.

<!-- [rfced] We are revisiting this question from the AUTH state.

Sections 4.3.1, 6.3.1, 7.3.1, 8.3.1, and 9.3.1:

Please review all updates to the five "The methodology for this
metric is defined as ..." sentences, and let us know any objections
regarding our addition of "(for singletons)" and "(for samples)". -->

 However, the Periodic stream will be
          generated according to <xref target="RFC3432"/>.</t> target="RFC3432" format="default"/>.</t>
          <t>The reference method distinguishes between long-delayed packets
          and lost packets by implementing a maximum waiting time for packet
          arrival. Tmax is the waiting time used as the threshold to declare a
          packet lost. Lost packets SHALL <bcp14>SHALL</bcp14> be designated as having undefined
          delay,
          delay and counted for the RTLoss metric.</t>
          <t>The calculations on the delay (RTT) SHALL <bcp14>SHALL</bcp14> be performed on the
          conditional distribution, conditioned on successful packet arrival
          within Tmax. Also, when all packet delays are stored, the process
          which
          that calculates the RTT value MUST <bcp14>MUST</bcp14> enforce the Tmax threshold on
          stored values before calculations. See section 4.1 of <xref
          target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the conditional distribution to
          exclude undefined values of delay, and Section 5 of see <xref
          target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this analysis choice.</t>
          <t>The reference method requires some way to distinguish between
          different packets in a stream to establish correspondence between
          sending times and receiving times for each successfully-arriving successfully arriving
          packet. Sequence numbers or other send-order identification MUST <bcp14>MUST</bcp14> be
          retained at the Src or included with each packet to disambiguate
          packet reordering if it occurs.</t>
          <t>If a standard measurement protocol is employed, then the
          measurement process will determine the sequence numbers or
          timestamps applied to test packets after the Fixed and Runtime
          parameters
          Parameters are passed to that process. The chosen measurement
          protocol will dictate the format of sequence numbers and
          time-stamps,
          timestamps, if they are conveyed in the packet payload.</t>
          <t>Refer to Section 4.4 of <xref target="RFC6673"/> target="RFC6673" sectionFormat="of" section="4.4"/>
 for an expanded
          discussion of the instruction to "send a Type-P packet back to the
          Src as quickly as possible" in Section 2.6 of <xref
          target="RFC2681">RFC 2681</xref>. Section 8 of <xref
          target="RFC6673"/> target="RFC2681" sectionFormat="of" section="2.6"/>. <xref target="RFC6673" sectionFormat="of" section="8"/>
 presents additional requirements which MUST that <bcp14>MUST</bcp14> be
          included in the method Method of measurement Measurement for this metric.</t>
        </section>
        <section title="Packet numbered="true" toc="default">
          <name>Packet Stream Generation"> Generation</name>
          <t>This section gives the provides details of the regarding packet traffic traffic, which is
          used as the basis for measurement. In IPPM metrics, Metrics, this is called
          the Stream,
          and "stream"; this stream can easily be described by providing the
          list of stream
          parameters.</t>

          <t>Section 3 of <xref target="RFC3432"/> Parameters.</t>
          <t><xref target="RFC3432" sectionFormat="of" section="3"/> prescribes the method for
          generating Periodic streams using associated parameters.</t>

          <t><list style="hanging">
              <t hangText="incT">the Parameters.</t>
          <dl newline="false" spacing="normal">
            <dt>incT:</dt>
            <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
              fraction digits = 4 (see section 9.3 of <xref
              target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) and with a resolution of 0.0001 seconds (0.1
              ms).</t>

              <t hangText="dT">the
              ms).</dd>
            <dt>dT:</dt>
            <dd>The duration of the interval for allowed sample
              start times, with value 1.0, expressed in units of seconds, as a
              positive value of type decimal64 with fraction digits = 4 (see
              section 9.3 of
              <xref target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) and with a resolution of
              0.0001 seconds (0.1 ms).</t>
            </list>NOTE: an ms).</dd>
          </dl>
          <aside><t>Note: An initiation process with a number of control
          exchanges resulting in unpredictable start times (within a time
          interval) may be sufficient to avoid synchronization of periodic
          streams,
          streams and therefore is a valid replacement for selecting a start time
          at random from a fixed interval.</t> interval.</t></aside>
          <t>The T0 parameter Parameter will be reported as a measured parameter. Parameter.
          Parameters incT and dT are Fixed Parameters.</t>
        </section>
        <section title="Traffic numbered="true" toc="default">
          <name>Traffic Filtering (observation) Details">
          <t>NA</t> (Observation) Details</name>
          <t>N/A</t>
        </section>
        <section title="Sampling Distribution">
          <t>NA</t> numbered="true" toc="default">
          <name>Sampling Distribution</name>
          <t>N/A</t>
        </section>
        <section title="Run-time numbered="true" toc="default">
          <name>Runtime Parameters and Data Format">
          <t>Run-time Format</name>
          <t>Runtime Parameters are input factors that must be determined,
          configured into the measurement system, and reported with the
          results for the context to be complete.</t>

          <t><list style="hanging">
              <t hangText="Src">the
          <dl newline="false" spacing="normal">
            <dt>Src:</dt>
            <dd>The IP address of the host in the Src Role
              (format ipv4-address-no-zone ipv4&nbhy;address-no-zone value for IPv4, IPv4 or
              ipv6-address-no-zone value for IPv6, IPv6; see Section 4 of <xref
              target="RFC6991"/>)</t>

              <t hangText="Dst">the target="RFC6991" sectionFormat="of" section="4"/>).</dd>
            <dt>Dst:</dt>
            <dd>The IP address of the host in the Dst Role
              (format ipv4-address-no-zone ipv4&nbhy;address-no-zone value for IPv4, IPv4 or
              ipv6-address-no-zone value for IPv6, IPv6; see section 4 of <xref
              target="RFC6991"/>)</t>

              <t hangText="T0">a target="RFC6991" sectionFormat="of" section="4"/>).</dd>
            <dt>T0:</dt>
            <dd>A time, the start of a measurement interval, interval
              (format "date-and-time" "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>,
              target="RFC3339" sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The
              UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>. target="RFC2330"
              sectionFormat="of" section="6.1"/>. When T0 is "all-zeros", a start
              time is unspecified and Tf is to be interpreted as the Duration duration
              of the measurement interval. The start time is controlled
              through other means.</t>

              <t hangText="Tf">a means.</dd>
            <dt>Tf:</dt>
            <dd>A time, the end of a measurement interval, interval
              (format "date-and-time" "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>. target="RFC2330" sectionFormat="of" section="6.1"/>. When T0 is "all-zeros", a end an ending
              time and date is ignored and Tf is interpreted as the Duration duration of
              the measurement interval.</t>
            </list></t>

          <t/> interval.</dd>
          </dl>
        </section>
        <section title="Roles">
          <t><list style="hanging">
              <t hangText="Src">launches numbered="true" toc="default">
          <name>Roles</name>
          <dl newline="false" spacing="normal">
            <dt>Src:</dt>
            <dd>Launches each packet and waits for return
              transmissions from Dst.</t>

              <t hangText="Dst">waits the Dst.</dd>
            <dt>Dst:</dt>
            <dd>Waits for each packet from the Src and sends a
              return packet to Src.</t>
            </list></t> the Src.</dd>
          </dl>
        </section>
      </section>
      <section title="Output"> numbered="true" toc="default">
        <name>Output</name>
        <t>This category specifies all details of the Output output of measurements
        using the metric.</t>
        <section title="Type">
          <t>Percentile -- for numbered="true" toc="default">
          <name>Type</name>
          <t>Percentile: For the conditional distribution of all packets
          with a valid value of Round-trip round-trip delay (undefined delays are
          excluded), this is a single value corresponding to the 95th percentile, as
          follows:</t>
          <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
          conditional distribution to exclude undefined values of delay, and
          Section 5 of see
          <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
          analysis choice.</t>
          <t>The percentile = 95, meaning that the reported delay,
          "95Percentile", is the smallest value of Round-trip round-trip delay for which
          the Empirical Distribution Function (EDF), F(95Percentile) &gt;= Function, EDF(95Percentile), is greater
	  than or equal to 95% of the singleton Round-trip round-trip delay values in the conditional
          distribution. See section 11.3 of <xref target="RFC2330"/> target="RFC2330" sectionFormat="of" section="11.3"/> for the
          definition of the percentile statistic using the EDF.</t>

          <t>LossRatio --
          <t>For LossRatio, the count of lost packets to total packets sent is
          the basis for the loss ratio calculation as per Section 6.1 of <xref
          target="RFC6673"/>.</t> target="RFC6673" sectionFormat="of" section="6.1"/>.</t>
        </section>
        <section title="Reference Definition"> numbered="true" toc="default">
          <name>Reference Definition</name>
          <t>For all outputs ---</t>

          <t><list style="hanging">
              <t hangText="T0">the outputs:</t>
          <dl newline="false" spacing="normal">
            <dt>T0:</dt>
            <dd>The start of a measurement interval, interval (format
              "date-and-time"
              "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>.</t>

              <t hangText="Tf">the target="RFC2330" sectionFormat="of" section="6.1"/>.</dd>
            <dt>Tf:</dt>
            <dd>The end of a measurement interval, interval (format
              "date-and-time"
              "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>.</t>

              <t hangText="TotalPkts">the target="RFC2330" sectionFormat="of" section="6.1"/>.</dd>
            <dt>TotalPkts:</dt>
            <dd>The count of packets sent by the Src to the
              Dst during the measurement interval.</t>
            </list></t>

          <t/>

          <t>For</t>

          <t>RTDelay_Active_IP-UDP-Periodic_RFCXXXXsec4_Seconds_95Percentile:</t>

          <t><list style="hanging">
              <t hangText="95Percentile">The interval.</dd>
          </dl>
          <t>For RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile:</t>
          <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
              decimal64 with fraction digits = 9 (see section 9.3 of <xref
              target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds (1.0
              ns).</t>
            </list></t>

          <t>For</t>

          <t>RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_Percent_LossRatio:</t>

          <t><list style="hanging">
              <t hangText="Percentile">The
              ns).</dd>
          </dl>
          <t>For RTLoss_Active_IP-UDP-Periodic_RFC8912sec4_Percent_LossRatio:</t>
          <dl newline="false" spacing="normal">
            <dt>Percentile:</dt>
            <dd>The numeric value of the result is
              expressed in units of lost packets to total packets times 100%,
              as a positive value of type decimal64 with fraction digits = 9
              (see section 9.3 of <xref target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of
              0.0000000001.</t>
            </list></t>
              0.0000000001.</dd>
          </dl>
        </section>
        <section title="Metric Units"> numbered="true" toc="default">
          <name>Metric Units</name>
          <t>The 95th Percentile percentile of Round-trip Delay round-trip delay is expressed in
          seconds.</t>
          <t>The Round-trip Loss Ratio round-trip loss ratio is expressed as a percentage of lost
          packets to total packets sent.</t>
        </section>
        <section title="Calibration">
          <t>Section 3.7.3 of <xref target="RFC7679"/> numbered="true" toc="default">
          <name>Calibration</name>
          <t><xref target="RFC7679" sectionFormat="of" section="3.7.3"/> provides a means to
          quantify the systematic and random errors of a time measurement.
          In-situ calibration
          Calibration in&nbsp;situ could be enabled with an internal loopback at
          the Source host that includes as much of the measurement system as
          possible, performs address manipulation as needed, and provides some
          form of isolation (e.g., deterministic delay) to avoid send-receive
          interface contention. Some portion of the random and systematic
          error can be characterized in this way.</t>
          <t>When a measurement controller requests a calibration measurement,
          the loopback is applied and the result is output in the same format
          as a normal measurement measurement, with an additional indication that it is a
          calibration result.</t>
          <t>Both internal loopback calibration and clock synchronization can
          be used to estimate the available accuracy of the Output Metric
          Units. For example, repeated loopback delay measurements will reveal
          the portion of the Output output result resolution which that is the result of
          system noise, noise and is thus inaccurate.</t>
        </section>
      </section>
      <section title="Administrative items">
        <t/>

        <section title="Status"> numbered="true" toc="default">
        <name>Administrative Items</name>
        <section numbered="true" toc="default">
          <name>Status</name>
          <t>Current</t>
        </section>
        <section title="Requester">
          <t>This RFC number</t> numbered="true" toc="default">
          <name>Requester</name>
          <t>RFC 8912</t>
        </section>
        <section title="Revision"> numbered="true" toc="default">
          <name>Revision</name>
          <t>1.0</t>
        </section>
        <section title="Revision Date"> 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.

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>
        </section>
      </section>
      <section title="Comments numbered="true" toc="default">
        <name>Comments and Remarks">
        <t>None.</t> Remarks</name>
        <t>None</t>
      </section>
    </section>
    <section title="Packet anchor="packet_delay_variation" numbered="true" toc="default">
      <name>Packet Delay Variation Registry Entry"> Entry</name>
      <t>This section gives an initial registry entry Registry Entry for a Packet Delay
      Variation (PDV) metric.</t>
      <section title="Summary"> numbered="true" toc="default">
        <name>Summary</name>
        <t>This category includes multiple indexes to the registry entries, Registry Entry:
        the element ID and metric name.</t> Metric Name.</t>
        <section title="ID (Identifier)">
          <t>&lt;insert numbered="true" toc="default">
          <name>ID (Identifier)</name>
   <t>IANA has allocated the numeric identifier, an integer&gt;</t> Identifier 3 for the
   Named Metric Entry in <xref target="packet_delay_variation"/>. See <xref
   target="name512"/> for mapping to Name.</t>
        </section>

        <section title="Name">
          <t>OWPDV_Active_IP-UDP-Periodic_RFCXXXXsec5_Seconds_95Percentile</t> anchor="name512" numbered="true" toc="default">
          <name>Name</name>
	  <dl>
	    <dt>3:</dt><dd>OWPDV_Active_IP-UDP-Periodic_RFC8912sec5_Seconds_95Percentile</dd>
	  </dl>
        </section>
        <section title="URI"> numbered="true" toc="default">
          <name>URI</name>
          <t>URL: https://www.iana.org/ <eref target="https://www.iana.org/"/> ... &lt;name&gt;</t> &lt;Name&gt;</t>
        </section>
        <section title="Description">
          <t>An assessment of numbered="true" toc="default">
          <name>Description</name>
          <t>This metric assesses packet delay variation with respect to the
          minimum delay observed on the periodic stream, and the Output stream. The output is
          expressed as the 95th percentile of the packet delay variation
          distribution.</t>
        </section>
        <section title="Change Controller"> numbered="true" toc="default">
          <name>Change Controller</name>
          <t>IETF</t>
        </section>
        <section title="Version numbered="true" toc="default">
          <name>Version (of Registry Format)"> Format)</name>
          <t>1.0</t>
        </section>
      </section>
      <section title="Metric Definition"> numbered="true" toc="default">
        <name>Metric Definition</name>
        <t>This category includes columns to prompt the entry of all necessary
        details related to the metric definition, including the RFC reference
        and values of input factors, called fixed parameters.</t> "Fixed Parameters".</t>
        <section title="Reference Definition"> numbered="true" toc="default">
          <name>Reference Definition</name>
          <t>Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for
	  IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998. 1998,
	  &lt;https://www.rfc-editor.org/info/rfc2330&gt;. <xref
	  target="RFC2330"/></t>
          <t>Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric
	  for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393,
	  November 2002. 2002,
	  &lt;https://www.rfc-editor.org/info/rfc3393&gt;. <xref
	  target="RFC3393"/></t>
          <t>Morton, A. and B. Claise, "Packet Delay Variation Applicability
	  Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009. 2009,
	  &lt;https://www.rfc-editor.org/info/rfc5481&gt;. <xref
	  target="RFC5481"/></t>
          <t>Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network
	  Time Protocol Version 4: Protocol and Algorithms Specification", RFC
	  5905, DOI 10.17487/RFC5905, June 2010.<xref target="RFC5905"> </xref></t> 2010,
	  &lt;https://www.rfc-editor.org/info/rfc5905&gt;.
          <xref target="RFC5905"/></t>
          <t>See sections 2.4 Sections&nbsp;<xref target="RFC3393" section="2.4"
 sectionFormat="bare"/> and 3.4 <xref target="RFC3393" section="3.4"
 sectionFormat="bare"/> of <xref target="RFC3393"/>. Singleton The measured singleton
          delay differences measured are referred to by the variable name
          "ddT" (applicable to all forms of delay variation). However, this
          metric entry
          Metric Entry specifies the PDV form defined in section 4.2 of <xref
          target="RFC5481"/>, target="RFC5481" sectionFormat="of" section="4.2"/>, where the singleton PDV for packet i is referred
          to by the variable name "PDV(i)".</t>
        </section>
        <section title="Fixed Parameters">
          <t><list style="symbols">
              <t>IPv4 numbered="true" toc="default">
          <name>Fixed Parameters</name>
          <dl newline="true" spacing="normal">
              <dt>IPv4 header values: <list style="symbols">
                  <t>DSCP: set values:</dt>
	      <dd><t/>
	      <dl newline="false" spacing="compact">
                <dt>DSCP:</dt><dd>Set to 0</t>

                  <t>TTL: set 0</dd>
                <dt>TTL:</dt><dd>Set to 255</t>

                  <t>Protocol: set 255</dd>
                <dt>Protocol:</dt><dd>Set to 17 (UDP)</t>
                </list></t>

              <t>IPv6 (UDP)</dd>
	      </dl>
	      </dd>

              <dt>IPv6 header values:<list style="symbols">
                  <t>DSCP: set to 0</t>

                  <t>Hop Count: set to 255</t>

                  <t>Next Header: set 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)</t>

                  <t>Flow Label: set to zero</t>

                  <t>Extension Headers: none</t>
                </list></t>

              <t>UDP (UDP)</dd>
                <dt>Flow Label:</dt><dd>Set to 0</dd>
                <dt>Extension Headers:</dt><dd>None</dd>
	      </dl>
	      </dd>

              <dt>UDP header values: <list style="symbols">
                  <t>Checksum: the values:</dt>
	      <dd><t/>
	      <dl newline="false" spacing="compact">
                <dt>Checksum:</dt><dd>The checksum MUST <bcp14>MUST</bcp14> be calculated and the
                  non-zero checksum included in the header</t>
                </list></t>

              <t>UDP Payload <list style="symbols">
                  <t>total header</dd>
		</dl>
	      </dd>

              <dt>UDP Payload:</dt>
	      <dd><t/><dl newline="false" spacing="compact">
              <dt>Total of 200 bytes</t>
                </list></t>
            </list></t>

          <t>Other measurement parameters:</t>

          <t><list style="hanging">
              <t hangText="Tmax:">a bytes</dt><dd/>
          </dl>
	      </dd>
	  </dl>

        <dl newline="true" spacing="normal">
	  <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
              decimal64 with fraction digits = 4 (see section 9.3 of <xref
              target="RFC6020"/>) target="RFC6020" 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 section 6 of <xref target="RFC5905"/>.</t>

              <t hangText="F">a target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            <dt>F:</dt>
            <dd>A selection function unambiguously defining the
              packets from the stream selected for the metric. See section 4.2
              of <xref target="RFC5481"/> target="RFC5481" sectionFormat="of" section="4.2"/> for the PDV form.</t>
            </list>See form.</dd>
          </dl>
	  </dd>
	</dl>
          <t>See the Packet Stream generation category Generation &lt;section or column&gt; for two
          additional Fixed Parameters.</t>
        </section>
      </section>
      <section title="Method numbered="true" toc="default">
        <name>Method of Measurement"> Measurement</name>
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure
        an unambiguous methods method for implementations.</t>
        <section title="Reference Method"> numbered="true" toc="default">
          <name>Reference Methods</name>
          <t>See section 2.6 Sections&nbsp;<xref target="RFC3393" section="2.6"
 sectionFormat="bare"/> and 3.6 <xref target="RFC3393" section="3.6"
 sectionFormat="bare"/> of <xref target="RFC3393"/> for general
          singleton element calculations. This metric entry Metric Entry requires
          implementation of the PDV form defined in section 4.2 of <xref
          target="RFC5481"/>. target="RFC5481" sectionFormat="of" section="4.2"/>. Also see measurement considerations in section 8
          of <xref target="RFC5481"/>.</t> target="RFC5481" sectionFormat="of" section="8"/>.</t>
          <t>The reference method distinguishes between long-delayed packets
          and lost packets by implementing a maximum waiting time for packet
          arrival. Tmax is the waiting time used as the threshold to declare a
          packet lost. Lost packets SHALL <bcp14>SHALL</bcp14> be designated as having undefined
          delay.</t>
          <t>The calculations on the one-way delay SHALL <bcp14>SHALL</bcp14> be performed on the
          conditional distribution, conditioned on successful packet arrival
          within Tmax. Also, when all packet delays are stored, the process
          which
          that calculates the one-way delay value MUST <bcp14>MUST</bcp14> enforce the Tmax
          threshold on stored values before calculations. See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the conditional distribution
          to exclude undefined values of delay, and Section 5 of see <xref
          target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this analysis choice.</t>
          <t>The reference method requires some way to distinguish between
          different packets in a stream to establish correspondence between
          sending times and receiving times for each successfully-arriving successfully arriving
          packet. Sequence numbers or other send-order identification MUST <bcp14>MUST</bcp14> be
          retained at the Src or included with each packet to disambiguate
          packet reordering if it occurs.</t>
          <t>If a standard measurement protocol is employed, then the
          measurement process will determine the sequence numbers or
          timestamps applied to test packets after the Fixed and Runtime
          parameters
          Parameters are passed to that process. The chosen measurement
          protocol will dictate the format of sequence numbers and
          time-stamps,
          timestamps, if they are conveyed in the packet payload.</t>
        </section>
        <section title="Packet numbered="true" toc="default">
          <name>Packet Stream Generation"> Generation</name>
          <t>This section gives the provides details of the regarding packet traffic traffic, which is
	  used as the
          basis for measurement. In IPPM metrics, Metrics, this is called the Stream,
          and "stream";
	  this stream can easily be described by providing the list of stream
          parameters.</t>

          <t>Section 3 of <xref target="RFC3432"/>
          Parameters.</t>
          <t><xref target="RFC3432" sectionFormat="of" section="3"/> prescribes the method for
          generating Periodic streams using associated parameters.</t>

          <t><list style="hanging">
              <t hangText="incT">the Parameters.</t>
          <dl newline="false" spacing="normal">
            <dt>incT:</dt>
            <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
              fraction digits = 4 (see section 9.3 of <xref
              target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) and with a resolution of 0.0001 seconds (0.1
              ms).</t>

              <t hangText="dT">the
              ms).</dd>
            <dt>dT:</dt>
            <dd>The duration of the interval for allowed sample
              start times, with value 1.0, expressed in units of seconds, as a
              positive value of type decimal64 with fraction digits = 4 (see
              section 9.3 of
              <xref target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) and with a resolution of
              0.0001 seconds (0.1 ms).</t>
            </list>NOTE: an ms).</dd>
          </dl>
          <aside><t>Note: An initiation process with a number of control
          exchanges resulting in unpredictable start times (within a time
          interval) may be sufficient to avoid synchronization of periodic
          streams,
          streams and therefore is a valid replacement for selecting a start
          time at random from a fixed interval.</t> interval.</t></aside>
          <t>The T0 parameter Parameter will be reported as a measured parameter. Parameter.
          Parameters incT and dT are Fixed Parameters.</t>
        </section>
        <section title="Traffic numbered="true" toc="default">
          <name>Traffic Filtering (observation) Details">
          <t>NA</t> (Observation) Details</name>
          <t>N/A</t>
        </section>
        <section title="Sampling Distribution">
          <t>NA</t> numbered="true" toc="default">
          <name>Sampling Distribution</name>
          <t>N/A</t>
        </section>
        <section title="Run-time numbered="true" toc="default">
          <name>Runtime Parameters and Data Format">
          <t><list style="hanging">
              <t hangText="Src">the Format</name>
          <dl newline="false" spacing="normal">
            <dt>Src:</dt>
            <dd>The IP address of the host in the Src Role
              (format ipv4-address-no-zone ipv4&nbhy;address-no-zone value for IPv4, IPv4 or
              ipv6-address-no-zone value for IPv6, IPv6; see Section 4 of <xref
              target="RFC6991"/>)</t>

              <t hangText="Dst">the target="RFC6991" sectionFormat="of" section="4"/>).</dd>
            <dt>Dst:</dt>
            <dd>The IP address of the host in the Dst Role
              (format ipv4-address-no-zone ipv4&nbhy;address-no-zone value for IPv4, IPv4 or
              ipv6-address-no-zone value for IPv6, IPv6; see section 4 of <xref
              target="RFC6991"/>)</t>

              <t hangText="T0">a target="RFC6991" sectionFormat="of" section="4"/>).</dd>
            <dt>T0:</dt>
            <dd>A time, the start of a measurement interval, interval
              (format "date-and-time" "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>. target="RFC2330" sectionFormat="of" section="6.1"/>. When T0 is "all-zeros", a start
              time is unspecified and Tf is to be interpreted as the Duration duration
              of the measurement interval. The start time is controlled
              through other means.</t>

              <t hangText="Tf">a means.</dd>
            <dt>Tf:</dt>
            <dd>A time, the end of a measurement interval, interval
              (format "date-and-time" "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>. target="RFC2330" sectionFormat="of" section="6.1"/>. When T0 is "all-zeros", a end an ending
              time and date is ignored and Tf is interpreted as the Duration duration of
              the measurement interval.</t>
            </list></t>

          <t/> interval.</dd>
          </dl>
        </section>
        <section title="Roles">
          <t><list style="hanging">
              <t hangText="Src">launches numbered="true" toc="default">
          <name>Roles</name>
          <dl newline="false" spacing="normal">
            <dt>Src:</dt>
            <dd>Launches each packet and waits for return
              transmissions from Dst.</t>

              <t hangText="Dst">waits the Dst.</dd>
            <dt>Dst:</dt>
            <dd>Waits for each packet from the Src and sends a
              return packet to Src.</t>
            </list></t> the Src.</dd>
          </dl>
        </section>
      </section>
      <section title="Output"> numbered="true" toc="default">
        <name>Output</name>
        <t>This category specifies all details of the Output output of measurements
        using the metric.</t>
        <section title="Type">
          <t>Percentile -- for numbered="true" toc="default">
          <name>Type</name>
          <t>Percentile: For the conditional distribution of all packets
          with a valid value of one-way delay (undefined delays are excluded),
          this is a single value corresponding to the 95th percentile, as follows:</t>
          <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
          conditional distribution to exclude undefined values of delay, and
          Section 5 of see
          <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
          analysis choice.</t>
          <t>The percentile = 95, meaning that the reported delay,
          "95Percentile", is the smallest value of one-way PDV for which the
          Empirical Distribution Function (EDF), F(95Percentile) &gt;= Function, EDF(95Percentile), is greater than
	  or equal to 95% of
          the singleton one-way PDV values in the conditional distribution.
          See section 11.3 of <xref target="RFC2330"/> target="RFC2330" sectionFormat="of" section="11.3"/> for the definition of
          the percentile statistic using the EDF.</t>
        </section>
        <section title="Reference Definition">
          <t><list style="hanging">
              <t hangText="T0">the numbered="true" toc="default">
          <name>Reference Definition</name>
          <dl newline="false" spacing="normal">
            <dt>T0:</dt>
            <dd>The start of a measurement interval, interval (format
              "date-and-time"
              "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>.</t>

              <t hangText="Tf">the target="RFC2330" sectionFormat="of" section="6.1"/>.</dd>
            <dt>Tf:</dt>
            <dd>The end of a measurement interval, interval (format
              "date-and-time"
              "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>.</t>
            </list></t>

          <t><list style="hanging">
              <t hangText="95Percentile">The target="RFC2330" sectionFormat="of" section="6.1"/>.</dd>
          </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
              decimal64 with fraction digits = 9 =&nbsp;9 (see section 9.3 of <xref
              target="RFC6020"/>) target="RFC6020" 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
              timestamp as per section 6 of <xref
              target="RFC5905">RFC</xref></t>
            </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
          </dl>
        </section>
        <section title="Metric Units"> numbered="true" toc="default">
          <name>Metric Units</name>
          <t>The 95th Percentile percentile of one-way PDV is expressed in seconds.</t>
        </section>
        <section title="Calibration">
          <t>Section 3.7.3 of <xref target="RFC7679"/> numbered="true" toc="default">
          <name>Calibration</name>
          <t><xref target="RFC7679" sectionFormat="of" section="3.7.3"/> provides a means to
          quantify the systematic and random errors of a time measurement.
          In-situ calibration
          Calibration in&nbsp;situ could be enabled with an internal loopback that
          includes as much of the measurement system as possible, performs
          address manipulation as needed, and provides some form of isolation
          (e.g., deterministic delay) to avoid send-receive interface
          contention. Some portion of the random and systematic error can be
          characterized in this way.</t>
          <t>For one-way delay measurements, the error calibration must
          include an assessment of the internal clock synchronization with its
          external reference (this internal clock is supplying timestamps for
          measurement). In practice, the time offsets <xref target="RFC5905"/> target="RFC5905" format="default"/>
          of clocks at both the source Source and destination Destination are needed to estimate
          the systematic error due to imperfect clock synchronization (the
          time offsets are smoothed, thus smoothed; thus, the random variation is not usually
          represented in the results).<list style="hanging">
              <t hangText="time_offset">The results).</t>
          <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
              decimal64 with fraction digits = 9 digits&nbsp;=&nbsp;9 (see section 9.3 of <xref
              target="RFC6020"/>) target="RFC6020" 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
              timestamp as per section 6 of <xref
              target="RFC5905">RFC</xref></t>
            </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
          </dl>
          <t>When a measurement controller requests a calibration measurement,
          the loopback is applied and the result is output in the same format
          as a normal measurement measurement, with an additional indication that it is a
          calibration result. In any measurement, the measurement function
          SHOULD
          <bcp14>SHOULD</bcp14> report its current estimate of the time offset <xref
          target="RFC5905"/> target="RFC5905" format="default"/> as an indicator of the degree of
          synchronization.</t>
          <t>Both internal loopback calibration and clock synchronization can
          be used to estimate the available accuracy of the Output Metric
          Units. For example, repeated loopback delay measurements will reveal
          the portion of the Output output result resolution which that is the result of
          system noise, noise and is thus inaccurate.</t>
        </section>
      </section>
      <section title="Administrative items">
        <t/>

        <section title="Status"> numbered="true" toc="default">
        <name>Administrative Items</name>
        <section numbered="true" toc="default">
          <name>Status</name>
          <t>Current</t>
        </section>
        <section title="Requester">
          <t>This RFC number</t> numbered="true" toc="default">
          <name>Requester</name>
          <t>RFC 8912</t>
        </section>
        <section title="Revision"> numbered="true" toc="default">
          <name>Revision</name>
          <t>1.0</t>
        </section>
        <section title="Revision Date"> numbered="true" toc="default">
          <name>Revision Date</name>
          <t>YYYY-MM-DD</t>
        </section>
      </section>
      <section title="Comments numbered="true" toc="default">
        <name>Comments and Remarks"> Remarks</name>
        <t>Lost packets represent a challenge for delay variation metrics. See
        section 4.1 of
        <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> and the delay variation
        applicability statement<xref target="RFC5481"/> statement <xref target="RFC5481" format="default"/> for extensive analysis
        and comparison of PDV and an alternate metric, IPDV.</t> IPDV (Inter-Packet
        Delay Variation).</t>
      </section>
    </section>
    <section title="DNS anchor="dns_response_latency_and_loss" numbered="true" toc="default">
      <name>DNS Response Latency and Loss Registry Entries"> Entries</name>
      <t>This section gives initial registry entries Registry Entries for DNS Response Latency
      and Loss from a network user's perspective, for a specific named
      resource. The metric can be measured repeatedly using different names.
      <xref target="RFC2681">RFC 2681</xref> target="RFC2681" format="default"></xref> defines a Round-trip round-trip delay
      metric. We build on that metric by specifying several of the input
      parameters
      Parameters to precisely define two metrics for measuring DNS latency and
      loss.</t>

      <t>Note to IANA: Each Registry "Name" below specifies a single registry
      entry, whose output format varies in accordance with the name.</t>

      <t>All column entries beside besides the ID, Name, Description, and Output
      Reference Method categories are the same, thus same; thus, this section proposes defines two
      closely-related registry entries.
      closely related Registry Entries. As a result, IANA is also asked to
      assign has
      assigned corresponding URLs to each of the two Named Metric.</t> Metrics.</t>
      <section title="Summary"> numbered="true" toc="default">
        <name>Summary</name>
        <t>This category includes multiple indexes to the registry entries, Registry Entries:
        the element ID and metric name.</t> Name.</t>
        <section title="ID (Identifier)">
          <t>&lt;insert numeric identifier, an integer&gt;</t> numbered="true" toc="default">
          <name>ID (Identifier)</name>
	  <t>IANA is asked to assign different has allocated the numeric identifiers to each of Identifiers 4 and 5 for the two
          Named Metrics.</t> Metric Entries in <xref
	  target="dns_response_latency_and_loss"/>. See
	  <xref target="name612"/> for mapping to Names.</t>
        </section>

        <section title="Name">
          <t>RTDNS_Active_IP-UDP-Poisson_RFCXXXXsec6_Seconds_Raw</t>

          <t>RLDNS_Active_IP-UDP-Poisson_RFCXXXXsec6_Logical_Raw</t> anchor="name612" numbered="true" toc="default">
          <name>Name</name>
	  <dl>
	    <dt>4:</dt><dd>RTDNS_Active_IP-UDP-Poisson_RFC8912sec6_Seconds_Raw</dd>
            <dt>5:</dt><dd>RLDNS_Active_IP-UDP-Poisson_RFC8912sec6_Logical_Raw</dd>
	  </dl>
        </section>
        <section title="URI"> numbered="true" toc="default">
          <name>URI</name>
          <t>URL: https://www.iana.org/ <eref target="https://www.iana.org/"/> ... &lt;name&gt;</t> &lt;Name&gt;</t>
        </section>
        <section title="Description"> numbered="true" toc="default">
          <name>Description</name>
          <t>This is a metric for DNS Response performance from a network
          user's perspective, for a specific named resource. The metric can be
          measured repeatedly using different resource names.</t>

          <t>RTDNS: This
          <dl newline="false" spacing="normal">
          <dt>RTDNS:</dt><dd>This metric assesses the response time, the interval from
          the query transmission to the response.</t>

          <t>RLDNS: This response.</dd>
          <dt>RLDNS:</dt><dd>This metric indicates that the response was deemed lost.
          In other words, the response time exceeded the maximum waiting
          time.</t>
          time.</dd>
          </dl>
        </section>
        <section title="Change Controller"> numbered="true" toc="default">
          <name>Change Controller</name>
          <t>IETF</t>
        </section>
        <section title="Version numbered="true" toc="default">
          <name>Version (of Registry Format)"> Format)</name>
          <t>1.0</t>
        </section>
      </section>
      <section title="Metric Definition"> numbered="true" toc="default">
        <name>Metric Definition</name>
        <t>This category includes columns to prompt the entry of all necessary
        details related to the metric definition, including the RFC reference
        and values of input factors, called fixed parameters.</t> "Fixed Parameters".</t>
        <section title="Reference Definition">
          <t>Mockapetris, numbered="true" toc="default">
          <name>Reference Definition</name>
<!-- [rfced] Section 6.2.1: We added "For Delay" and "For Loss" tags here.
Please review.
-->

          <t>For Delay:</t>
          <t indent="3">Mockapetris, P., "Domain names - implementation and
	  specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987.
	  1987, &lt;https://www.rfc-editor.org/info/rfc1035&gt; (and updates)</t>

          <t><xref updates).
          <xref target="RFC1035"/></t>

          <t>Almes,
          <t indent="3">Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
	  Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999.</t>

          <t><xref target="RFC2681"/></t>

          <t>Section 2.4 of 1999,
	  &lt;https://www.rfc-editor.org/info/rfc2681&gt;.
          <xref target="RFC2681"/> 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 round-trip delay metric.
          Section 3.4 of
          <xref target="RFC2681"/> target="RFC2681" sectionFormat="of" section="3.4"/> provides the reference
          definition expanded to cover a multi-singleton sample. Note that
          terms such as singleton "singleton" and sample "sample" are defined in Section 11 of <xref target="RFC2330"/>.</t>

          <t>For target="RFC2330" sectionFormat="of" section="11"/>.</t>
          <t indent="3">For DNS Response Latency, the entities in <xref
          target="RFC1035"/> target="RFC1035" format="default"/> must be mapped to <xref target="RFC2681"/>. target="RFC2681" format="default"/>. The
          Local Host with its User Program and Resolver take the role of
          "Src", and the Foreign Name Server takes the role of "Dst".</t>

          <t>Note
          <t indent="3">Note that although the <xref target="RFC2681"/> definition of
          "Round-trip-Delay round-trip delay between Src the
          Source (Src) and Dst the Destination (Dst) at T" 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
          Src Role will send the first packet to "Dst", the host in the Dst Role
          and will ultimately receive the corresponding return packet from "Dst" the
          Dst (when neither are is lost).</t>

          <t>Morton,

	  <t>For Loss:</t>
          <t indent="3">Morton, A., "Round-trip "Round-Trip Packet Loss Metrics", RFC 6673,
          DOI 10.17487/RFC6673, August
          2012.</t>

          <t><xref 2012,
	  &lt;https://www.rfc-editor.org/info/rfc6673&gt;.
          <xref target="RFC6673"/></t>

          <t>Both
          <t indent="3">Both response time and loss Loss metrics employ a maximum waiting time
          for received responses, so the count of lost packets to total
          packets sent is the basis for the loss determination as per Section
          4.3 of <xref target="RFC6673"/>.</t> target="RFC6673" sectionFormat="of" section="4.3"/>.</t>
        </section>
        <section title="Fixed Parameters">
          <t>Type-P as numbered="true" toc="default">
          <name>Fixed Parameters</name>
         <dl newline="false" spacing="normal">
          <dt>Type-P:</dt><dd><t>As defined in Section 13 of <xref target="RFC2330"/>:
          <list style="symbols">
              <t>IPv4 target="RFC2330" sectionFormat="of" section="13"/>:</t>
           <dl newline="true" spacing="normal">
            <dt>IPv4 header values: <list style="symbols">
                  <t>DSCP: set values:</dt>
	    <dd><t/>
	    <dl newline="false" spacing="compact">
             <dt>DSCP:</dt><dd>Set to 0</t>

                  <t>TTL set 0</dd>
             <dt>TTL:</dt><dd>Set to 255</t>

                  <t>Protocol: set 255</dd>
             <dt>Protocol:</dt><dd>Set to 17 (UDP)</t>
                </list></t>

              <t>IPv6 (UDP)</dd>
	    </dl>
	    </dd>
	   </dl>
         <dl newline="true" spacing="normal">
            <dt>IPv6 header values:<list style="symbols">
                  <t>DSCP: set to 0</t>

                  <t>Hop Count: set to 255</t>

                  <t>Next Header: set 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)</t>

                  <t>Flow Label: set to zero</t>

                  <t>Extension Headers: none</t>
                </list></t>

              <t>UDP (UDP)</dd>
             <dt>Flow Label:</dt><dd>Set to 0</dd>
             <dt>Extension Headers:</dt><dd> None</dd>
	    </dl>
	    </dd>
	 </dl>

	  <dl newline="true" spacing="normal">
            <dt>UDP header values: <list style="symbols">
                  <t>Source port: 53</t>

                  <t>Destination port: 53</t>

                  <t>Checksum: values:</dt>
	    <dd><t/>
	    <dl newline="false" spacing="compact">
             <dt>Source port:</dt><dd>53</dd>
             <dt>Destination port:</dt><dd>53</dd>
             <dt>Checksum:</dt><dd>The checksum <bcp14>MUST</bcp14> be calculated and the
                  non-zero checksum included in the header</dd>

<!-- [rfced] [AD*]:  Because of the use of "RFC 2119" language,
we will need your approval of the following update.

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.

Original:
 *  Checksum: the checksum must be calculated and the non-zero
    checksum included in the header</t>
                </list></t>

              <t>Payload: header

Author reply:
[acm]  Good catch, change to MUST in 6.2.2

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

	    </dl>
	    </dd>
	  </dl>

          <dl newline="true" spacing="normal">
          <dt>Payload:</dt>
          <dd><t>The payload contains a DNS message as defined in
              <xref target="RFC1035">RFC 1035</xref> target="RFC1035" format="default"></xref> with the following
              values: <list style="symbols">
                  <t>The
              values:</t>
            <dl newline="true" spacing="normal">
             <dt>The DNS header section contains: <list style="symbols">
                      <t>Identification contains:</dt>
	     <dd><t/>
            <dl newline="false" spacing="compact">
             <dt>Identification (see the Run-time column)</t>

                      <t>QR: set Runtime column)</dt><dd/>
             <dt>QR:</dt><dd>Set to 0 (Query)</t>

                      <t>OPCODE: set (Query)</dd>
             <dt>OPCODE:</dt><dd>Set to 0 (standard query)</t>

                      <t>AA: not set</t>

                      <t>TC: not set</t>

                      <t>RD: set query)</dd>
             <dt>AA:</dt><dd>Not set</dd>
             <dt>TC:</dt><dd>Not set</dd>
             <dt>RD:</dt><dd>Set to one 1 (recursion desired)</t>

                      <t>RA: not set</t>

                      <t>RCODE: not set</t>

                      <t>QDCOUNT: set desired)</dd>
             <dt>RA:</dt><dd>Not set</dd>
             <dt>RCODE:</dt><dd>Not set</dd>
             <dt>QDCOUNT:</dt><dd>Set to one 1 (only one entry)</t>

                      <t>ANCOUNT: not set</t>

                      <t>NSCOUNT: not set</t>

                      <t>ARCOUNT: not set</t>
                    </list></t>

                  <t>The 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>

            <dl newline="true" spacing="normal">
            <dt>The Question section contains: <list style="symbols">
                      <t>QNAME: the contains:</dt>
	    <dd><t/>
	    <dl newline="false" spacing="normal">
             <dt>QNAME:</dt><dd>The Fully Qualified Domain Name (FQDN)
               provided as input for the test, test; see the Run-time
                      column</t>

                      <t>QTYPE: the Runtime
               column</dd>
             <dt>QTYPE:</dt><dd>The query type provided as input for the test, test;
               see the Run-time column</t>

                      <t>QCLASS: set Runtime column</dd>
             <dt>QCLASS:</dt><dd>Set to 1 for IN</t>
                    </list></t>

                  <t>The IN</dd>
            </dl>
	    </dd>
	    </dl>

            <dl newline="false" spacing="normal">
         <dt>The other sections do not contain any Resource
                  Records.</t>
                </list></t>
            </list></t>

          <t>Other measurement parameters:<list style="symbols">
              <t>Tmax: a
           Records (RRs).</dt><dd/>
         </dl>
        </dd>
       </dl>
     </dd>
   </dl>

   <dl newline="true" spacing="normal">
     <dt>Other measurement Parameters:</dt>
     <dd><t/>

       <dl newline="false" spacing="normal">
              <dt>Tmax:</dt><dd>A loss threshold waiting time (and to help disambiguate
              queries)<list style="symbols">
                  <t>5.0,
              queries). The value is 5.0, expressed in units of seconds, as a positive value
              of type decimal64 with fraction digits = 4 (see section 9.3
                  of <xref target="RFC6020"/>) target="RFC6020" 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 section 6 of <xref
                  target="RFC5905"/>.</t>
                </list></t>
            </list>Observation: reply target="RFC5905"
              sectionFormat="of" section="6"/>.</dd>
       </dl>
     </dd>
   </dl>

         <dl newline="false" spacing="normal">
          <dt>Observation:</dt><dd>Reply packets will contain a DNS response Response and
          may contain RRs.</t> RRs.</dd>
         </dl>
        </section>
      </section>
      <section title="Method numbered="true" toc="default">
        <name>Method of Measurement"> Measurement</name>
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure
        an unambiguous methods method for implementations.</t>
        <section title="Reference Method"> 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
          Type-P-Round-trip-Delay-Poisson-Stream in section 2.6 of <xref
          target="RFC2681">RFC 2681</xref> target="RFC2681"
          sectionFormat="of" section="2.6"/> (for singletons) and section 3.6 of <xref
          target="RFC2681">RFC 2681</xref> target="RFC2681"
          sectionFormat="of" section="3.6"/> (for samples) using the Type-P and Timeout
          defined under in the Fixed Parameters.</t> Parameters column.</t>
          <t>The reference method distinguishes between long-delayed packets
          and lost packets by implementing a maximum waiting time for packet
          arrival. Tmax is the waiting time used as the threshold to declare a
          response packet lost. Lost packets SHALL <bcp14>SHALL</bcp14> be designated as having
          undefined delay and counted for the RLDNS metric.</t>
          <t>The calculations on the delay (RTT) SHALL <bcp14>SHALL</bcp14> be performed on the
          conditional distribution, conditioned on successful packet arrival
          within Tmax. Also, when all packet delays are stored, the process
          which
          that calculates the RTT value MUST <bcp14>MUST</bcp14> enforce the Tmax threshold on
          stored values before calculations. See section 4.1 of <xref
          target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the conditional distribution to
          exclude undefined values of delay, and Section 5 of see <xref
          target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this analysis choice.</t>
          <t>The reference method requires some way to distinguish between
          different packets in a stream to establish correspondence between
          sending times and receiving times for each successfully-arriving successfully arriving
          reply.</t>
          <t>DNS Messages messages bearing Queries queries provide for random ID Numbers in the
          Identification header field, so more than one query may be launched
          while a previous request is outstanding when the ID Number is used.
          Therefore, the ID Number MUST <bcp14>MUST</bcp14> be retained at the Src and included
          with each response packet to disambiguate packet reordering if it
          occurs.</t>

          <t>IF
          <t>If a DNS response Response does not arrive within Tmax, the response time
          RTDNS is undefined, and RLDNS = 1. The Message ID SHALL <bcp14>SHALL</bcp14> be used to
          disambiguate the successive queries that are otherwise
          identical.</t>
          <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
          stress test from a single Src address.</t>
          <t>Refer to Section 4.4 of <xref target="RFC6673"/> target="RFC6673" sectionFormat="of" section="4.4"/> for an expanded
          discussion of the instruction to "send a Type-P packet back to the
          Src as quickly as possible" in Section 2.6 of <xref
          target="RFC2681">RFC 2681</xref>. target="RFC2681" sectionFormat="of" section="2.6"/>. However, the DNS Server server is
          expected to perform all required functions to prepare and send a
          response, so the response time will include processing time and
          network delay. Section 8 of <xref target="RFC6673"/> target="RFC6673" sectionFormat="of" section="8"/> presents
          additional requirements which SHALL that <bcp14>SHALL</bcp14> be included in the method Method of
          measurement
          Measurement for this metric.</t>
          <t>In addition to operations described in <xref target="RFC2681"/>, target="RFC2681" format="default"/>,
          the Src MUST <bcp14>MUST</bcp14> parse the DNS headers of the reply and prepare the
          query response information for subsequent reporting as a measured
          result, along with the Round-Trip Delay.</t> round-trip delay.</t>
        </section>
        <section title="Packet numbered="true" toc="default">
          <name>Packet Stream Generation"> Generation</name>
          <t>This section gives the provides details of the regarding packet traffic traffic, which is
	  used as the
          basis for measurement. In IPPM metrics, Metrics, this is called the Stream,
          and "stream";
	  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>
          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 spacing; thus, the Run-time Runtime Parameter
          is Reciprocal_lambda = 1/lambda, Reciprocal_lambda&nbsp;=&nbsp;1&wj;/lambda, in seconds.</t>
          <t>Method 3 is used, where <bcp14>SHALL</bcp14> be used. Where given a start time (Run-time (Runtime Parameter),
          the subsequent send times are all computed prior to measurement by
          computing the pseudo-random pseudorandom distribution of inter-packet send times, times
          (truncating the distribution as specified in the Run-time
          Parameters), Parameter Trunc),
          and the Src sends each packet at the computed
          times.</t>

          <t>Note that Trunc is the times.

<!-- [rfced] [AD*]:  Because of the use of "RFC 2119" language,
we will need your approval of the following update.

Original question (from the AUTH state):
Sections 6.3.2 and 7.3.2:  These sentences are difficult
to follow.  Please confirm that it is correct to (1) have the "SHALL"
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.

Original (the next paragraph is included for context):
 Method 3 is 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 Run-time
 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
          Poisson distribution. A random value greater than Trunc is set equal
          to Trunc instead.</t>
        </section>
        <section title="Traffic numbered="true" toc="default">
          <name>Traffic Filtering (observation) Details">
          <t>NA</t> (Observation) Details</name>
          <t>N/A</t>
        </section>
        <section title="Sampling Distribution">
          <t>NA</t> numbered="true" toc="default">
          <name>Sampling Distribution</name>
          <t>N/A</t>
        </section>
        <section title="Run-time numbered="true" toc="default">
          <name>Runtime Parameters and Data Format">
          <t>Run-time Format</name>
          <t>Runtime Parameters are input factors that must be determined,
          configured into the measurement system, and reported with the
          results for the context to be complete.</t>

          <t><list style="hanging">
              <t hangText="Src">the
          <dl newline="false" spacing="normal">
            <dt>Src:</dt>
            <dd>The IP address of the host in the Src Role
              (format ipv4-address-no-zone ipv4&nbhy;address-no-zone value for IPv4, IPv4 or
              ipv6-address-no-zone value for IPv6, IPv6; see Section 4 of <xref
              target="RFC6991"/>)</t>

              <t hangText="Dst">the target="RFC6991" sectionFormat="of" section="4"/>).</dd>
            <dt>Dst:</dt>
            <dd>The IP address of the host in the Dst Role
              (format ipv4-address-no-zone ipv4&nbhy;address-no-zone value for IPv4, IPv4 or
              ipv6-address-no-zone value for IPv6, IPv6; see section 4 of <xref
              target="RFC6991"/>)</t>

              <t hangText="T0">a target="RFC6991" sectionFormat="of" section="4"/>).</dd>
            <dt>T0:</dt>
            <dd>A time, the start of a measurement interval, interval
              (format "date-and-time" "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>. target="RFC2330" sectionFormat="of" section="6.1"/>. When T0 is "all-zeros", a start
              time is unspecified and Tf is to be interpreted as the Duration duration
              of the measurement interval. The start time is controlled
              through other means.</t>

              <t hangText="Tf">a means.</dd>
            <dt>Tf:</dt>
            <dd>A time, the end of a measurement interval, interval
              (format "date-and-time" "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>. target="RFC2330" sectionFormat="of" section="6.1"/>. When T0 is "all-zeros", a end an ending
              time and date is ignored and Tf is interpreted as the Duration duration of
              the measurement interval.</t>

              <t hangText="Reciprocal_lambda">average interval.</dd>
            <dt>Reciprocal_lambda:</dt>
            <dd>Average packet interval for
              Poisson Streams streams, expressed in units of seconds, as a positive
              value of type decimal64 with fraction digits = 4 (see section
              9.3 of <xref target="RFC6020"/>) target="RFC6020" sectionFormat="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 per section 6 of <xref
              target="RFC5905"/>.</t>

              <t hangText="Trunc">Upper target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            <dt>Trunc:</dt>
            <dd>Upper limit on Poisson distribution distribution,
              expressed in units of seconds, as a positive value of type
              decimal64 with fraction digits = 4 (see section 9.3 of <xref
              target="RFC6020"/>) target="RFC6020" sectionFormat="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
              per section 6 of <xref target="RFC5905"/> target="RFC5905" sectionFormat="of" section="6"/> (values above this
              limit will be clipped and set to the limit value).</t>

              <t hangText="ID">The value).</dd>
            <dt>ID:</dt>
            <dd>The 16-bit identifier Identifier assigned by the program
              that generates the query, and which query.  The ID value must vary in successive
              queries (a list of IDs is needed), needed); see Section 4.1.1 of <xref
              target="RFC1035"/>. target="RFC1035" sectionFormat="of" section="4.1.1"/>. This identifier Identifier is copied into the
              corresponding reply and can be used by the requester (Src) to
              match-up
              match replies to with any outstanding queries.</t>

              <t hangText="QNAME">The queries.</dd>
            <dt>QNAME:</dt>
            <dd>The domain name of the Query, query, formatted as
              specified in section 4 of <xref target="RFC6991"/>.</t>

              <t hangText="QTYPE">The Query Type, target="RFC6991" sectionFormat="of" section="4"/>.</dd>
            <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
              IPv6,
              IPv6), formatted as a uint16, as per section 9.2 of <xref
              target="RFC6020"/>.</t>
            </list></t> target="RFC6020" sectionFormat="of" section="9.2"/>.</dd>
          </dl>
        </section>
        <section title="Roles">
          <t><list style="hanging">
              <t hangText="Src">launches numbered="true" toc="default">
          <name>Roles</name>
          <dl newline="false" spacing="normal">
            <dt>Src:</dt>
            <dd>Launches each packet and waits for return
              transmissions from Dst.</t>

              <t hangText="Dst">waits the Dst.</dd>
            <dt>Dst:</dt>
            <dd>Waits for each packet from the Src and sends a
              return packet to Src.</t>
            </list></t> the Src.</dd>
          </dl>
        </section>
      </section>
      <section title="Output"> numbered="true" toc="default">
        <name>Output</name>
        <t>This category specifies all details of the Output output of measurements
        using the metric.</t>
        <section title="Type">
          <t>Raw -- for numbered="true" toc="default">
          <name>Type</name>
          <t>Raw: For each DNS Query query packet sent, sets of values as defined
          in the next column, including the status of the response, only
          assigning delay values to successful query-response pairs.</t>
        </section>
        <section title="Reference Definition"> numbered="true" toc="default">
          <name>Reference Definition</name>
          <t>For all outputs:</t>

          <t><list style="hanging">
              <t hangText="T">the
          <dl newline="false" spacing="normal">
            <dt>T:</dt>
            <dd>The time the DNS Query query was sent during the
              measurement interval, interval (format "date-and-time" "date&nbhy;time" as specified in
              Section 5.6 of
              <xref target="RFC3339"/>, target="RFC3339" sectionFormat="of" section="5.6"/>; see
              also Section 3 of "date&nbhy;and&nbhy;time" in <xref target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by
              Section 6.1 of
              <xref target="RFC2330"/>.</t>

              <t hangText="dT">The target="RFC2330" sectionFormat="of" section="6.1"/>.</dd>
            <dt>dT:</dt>
            <dd>The time value of the round-trip delay to
              receive the DNS response, Response, expressed in units of seconds, as a
              positive value of type decimal64 with fraction digits = 9 (see
              section 9.3 of
              <xref target="RFC6020"/>) target="RFC6020" 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 timestamp as per section 6 of <xref
              target="RFC5905">RFC</xref>. target="RFC5905" sectionFormat="of" section="6"/>. This value is undefined when the
              response packet is not received at the Src within a waiting time Tmax
              seconds.</t>

              <t hangText="Rcode">The
              of Tmax&nbsp;seconds.</dd>
            <dt>RCODE:</dt>
            <dd>The value of the Rcode RCODE field in the DNS
              response
              Response header, expressed as a uint64 as specified in section
              9.2 of <xref target="RFC6020"/>. target="RFC6020" sectionFormat="of" section="9.2"/>. Non-zero values convey errors
              in the response, and such replies must be analyzed separately
              from successful requests.</t>
            </list></t> requests.</dd>
          </dl>
        </section>
        <section title="Metric Units">
          <t>RTDNS: Round-trip Delay, numbered="true" toc="default">
          <name>Metric Units</name>
          <dl newline="false" spacing="normal">
          <dt>RTDNS:</dt><dd>Round-trip delay, dT, is expressed in seconds.</t>

          <t>RTLDNS: the seconds.</dd>
          <dt>RLDNS:</dt><dd>The Logical value, where 1 = Lost and 0 = Received.</t>
          Received.</dd>
          </dl>
        </section>
        <section title="Calibration">
          <t>Section 3.7.3 of <xref target="RFC7679"/> numbered="true" toc="default">
          <name>Calibration</name>
          <t><xref target="RFC7679" sectionFormat="of" section="3.7.3"/> provides a means to
          quantify the systematic and random errors of a time measurement.
          In-situ calibration
          Calibration in&nbsp;situ could be enabled with an internal loopback at
          the Source host that includes as much of the measurement system as
          possible, performs address and payload manipulation as needed, and
          provides some form of isolation (e.g., deterministic delay) to avoid
          send-receive interface contention. Some portion of the random and
          systematic error can be characterized in this way.</t>
          <t>When a measurement controller requests a calibration measurement,
          the loopback is applied and the result is output in the same format
          as a normal measurement measurement, with an additional indication that it is a
          calibration result.</t>
          <t>Both internal loopback calibration and clock synchronization can
          be used to estimate the available accuracy of the Output Metric
          Units. For example, repeated loopback delay measurements will reveal
          the portion of the Output output result resolution which that is the result of
          system noise, noise and is thus inaccurate.</t>
        </section>
      </section>
      <section title="Administrative items">
        <t/>

        <section title="Status"> numbered="true" toc="default">
        <name>Administrative Items</name>
        <section numbered="true" toc="default">
          <name>Status</name>
          <t>Current</t>
        </section>
        <section title="Requester">
          <t>This RFC number</t> numbered="true" toc="default">
          <name>Requester</name>
          <t>RFC 8912</t>
        </section>
        <section title="Revision"> numbered="true" toc="default">
          <name>Revision</name>
          <t>1.0</t>
        </section>
        <section title="Revision Date"> numbered="true" toc="default">
          <name>Revision Date</name>
          <t>YYYY-MM-DD</t>
        </section>
      </section>
      <section title="Comments numbered="true" toc="default">
        <name>Comments and Remarks"> Remarks</name>
        <t>None</t>
      </section>
    </section>
    <section title="UDP anchor="udp-poisson-owd-owl-reg" numbered="true" toc="default">
      <name>UDP Poisson One-way One-Way Delay and Loss Registry Entries"> Entries</name>
      <t>This section specifies five initial registry entries Registry Entries for the UDP
      Poisson One-way Delay, One-Way Delay and one entry for UDP Poisson One-way One-Way Loss.</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 is an
      additional metric name for the Loss metric.</t>

      <t>All column entries beside besides the ID, Name, Description, and Output
      Reference Method categories are the same, thus same; thus, this section proposes defines six
      closely-related registry entries.
      closely related Registry Entries. As a result, IANA is also asked to
      assign has
      assigned corresponding URLs to each of the Named Metric.</t> Metrics.</t>
      <section title="Summary"> numbered="true" toc="default">
        <name>Summary</name>
        <t>This category includes multiple indexes to the registry entries, Registry Entries:
        the element ID and metric name.</t> Metric Name.</t>
        <section title="ID (Identifier)"> numbered="true" toc="default">
          <name>ID (Identifier)</name>
	  <t>IANA is asked to assign different has allocated the numeric identifiers to each of Identifiers 6-11 for the six Metrics.</t>
        </section>

        <section title="Name">
          <t>OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsec7_Seconds_&lt;statistic&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_LossRatio</t>
   Named Metric Entries in <xref target="udp-poisson-owd-owl-reg"/> See <xref
   target="name712"/> for mapping to Names.</t>
        </section>
        <section title="URI"> 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>

        <section numbered="true" toc="default">
          <name>URI</name>
          <t>URL: https://www.iana.org/ <eref target="https://www.iana.org/" /> ... &lt;name&gt;</t> &lt;Name&gt;</t>
        </section>
        <section title="Description">
          <t>OWDelay: This numbered="true" toc="default">
          <name>Description</name>
          <dl newline="false" spacing="normal">
          <dt>OWDelay:</dt><dd><t>This metric assesses the delay of a stream of packets
          exchanged between two hosts (or measurement points), points) and reports the
          &lt;statistic&gt; One-way one-way delay for all successfully exchanged
          packets based on their conditional delay distribution.</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: This
          <ul spacing="normal">
            <li>95Percentile</li>
            <li>Mean</li>
            <li>Min</li>
            <li>Max</li>
            <li>StdDev</li>
          </ul>
	</dd>
          <dt>OWLoss:</dt><dd>This metric assesses the loss ratio of a stream of
          packets exchanged between two hosts (which are the two measurement
          points), and the Output
          points). The output is the One-way one-way loss ratio for all
          successfully received packets expressed as a percentage.</t> 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 title="Metric Definition"> numbered="true" toc="default">
        <name>Metric Definition</name>
        <t>This category includes columns to prompt the entry of all necessary
        details related to the metric definition, including the RFC reference
        and values of input factors, called fixed parameters.</t> "Fixed Parameters".</t>
        <section title="Reference Definition"> numbered="true" toc="default">
          <name>Reference Definition</name>
          <t>For Delay:</t>

          <t>Almes, delay:</t>
          <t indent="3">Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A
	  One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC
	  7679, DOI 10.17487/RFC7679, January 2016,
          &lt;http://www.rfc-editor.org/info/rfc7679&gt;.</t>

          <t><xref
	  &lt;https://www.rfc-editor.org/info/rfc7679&gt;.
          <xref target="RFC7679"/></t>

          <t>Morton, A.,
          <t indent="3">Morton, A. and E. Stephan, E., "Spatial Composition of Metrics", RFC
	  6049, DOI 10.17487/RFC6049, January 2011.</t>

          <t><xref target="RFC6049"/></t>

          <t>Section 3.4 of 2011,
	  &lt;https://www.rfc-editor.org/info/rfc6049&gt;.
          <xref target="RFC7679"/> target="RFC6049"/></t>
          <t indent="3"><xref target="RFC7679" sectionFormat="of" section="3.4"/> provides the reference
          definition of the singleton (single value) One-way one-way delay metric.
          Section 4.4 of
          <xref target="RFC7679"/> target="RFC7679" sectionFormat="of" section="4.4"/> provides the reference
          definition expanded to cover a multi-value sample. Note that terms
          such as singleton "singleton" and sample "sample" are defined in Section 11 of <xref
          target="RFC2330"/>.</t>

          <t>Only target="RFC2330" sectionFormat="of" section="11"/>.</t>
          <t indent="3">Only successful packet transfers with finite delay are included
          in the sample, as prescribed in section 4.1.2 of <xref
          target="RFC6049"/>.</t> target="RFC6049" sectionFormat="of" section="4.1.2"/>.</t>
          <t>For loss:</t>

          <t>Almes,
          <t indent="3">Almes, G., Kalidini, Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A
	  One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, RFC
	  7680, DOI 10.17487/RFC7680, January 2016,
          &lt;http://www.rfc-editor.org/info/rfc7680&gt;.</t>

          <t>Section 2.4 of
	  &lt;https://www.rfc-editor.org/info/rfc7680&gt;.
          <xref target="RFC7680"/> target="RFC7680"/></t>
          <t indent="3"><xref target="RFC7680" sectionFormat="of" section="2.4"/> provides the reference
          definition of the singleton (single value) one-way loss Loss metric.
          Section 3.4 of
          <xref target="RFC7680"/> target="RFC7680" sectionFormat="of" section="3.4"/> provides the reference
          definition expanded to cover a multi-singleton sample. Note that
          terms such as singleton "singleton" and sample "sample" are defined in Section 11 of <xref target="RFC2330"/>.</t>
        </section>

        <section title="Fixed Parameters">
          <t>Type-P:<list style="symbols">
              <t>IPv4 target="RFC2330" sectionFormat="of" section="11"/>.</t>
        </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: <list style="symbols">
                  <t>DSCP: set values:</dt>
	      <dd><t/>
	      <dl newline="false" spacing="compact">
                <dt>DSCP:</dt><dd>Set to 0</t>

                  <t>TTL: set 0</dd>
                <dt>TTL:</dt><dd>Set to 255</t>

                  <t>Protocol: Set 255</dd>
                <dt>Protocol:</dt><dd>Set to 17 (UDP)</t>
                </list></t>

              <t>IPv6 (UDP)</dd>
	      </dl>
	      </dd>
	    </dl>

	    <dl newline="true" spacing="normal">
              <dt>IPv6 header values:<list style="symbols">
                  <t>DSCP: set to 0</t>

                  <t>Hop Count: set to 255</t>

                  <t>Next Header: set 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)</t>

                  <t>Flow Label: set (UDP)</dd>
                <dt>Flow Label:</dt><dd> Set to zero</t>

                  <t>Extension Headers: none</t>
                </list></t>

              <t>UDP 0</dd>
                <dt>Extension Headers:</dt><dd>None</dd>
	      </dl>
	      </dd>
	    </dl>

	    <dl newline="true" spacing="normal">
              <dt>UDP header values: <list style="symbols">
                  <t>Checksum: the values:</dt>
	      <dd><t/>
	      <dl newline="false" spacing="compact">
                <dt>Checksum:</dt><dd>The checksum MUST <bcp14>MUST</bcp14> 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 header</dd>
	      </dl>
	      </dd>
	    </dl>

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

                  <t>250
                  octets</li>
                <li>250 octets total, including the TWAMP format type, which
                  MUST
                  <bcp14>MUST</bcp14> be reported.</t>
                </list></t>
            </list></t>

          <t>Other measurement parameters:</t>

          <t><list style="hanging">
              <t hangText="Tmax:">a reported</li>
	    </ul>
	    </dd>
          </dl>
	    </dd>
	  </dl>

	  <dl newline="true" spacing="normal">
         <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
              decimal64 with fraction digits = 4 (see section 9.3 of <xref
              target="RFC6020"/>) target="RFC6020" 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 section 6 of <xref target="RFC5905"/>.</t>
            </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
          </dl>
	 </dd>
	  </dl>
          <t>See the Packet Stream generation category Generation &lt;section or column&gt; for two additional
          Fixed Parameters.</t>
        </section>
      </section>
      <section title="Method numbered="true" toc="default">
        <name>Method of Measurement"> Measurement</name>
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure
        an unambiguous methods method for implementations.</t>
        <section title="Reference Method"> numbered="true" toc="default">
          <name>Reference Methods</name>
          <t>The methodology for this metric (equivalent to
          Type-P-One-way-Delay-Poisson-Stream) is defined as
          Type-P-One-way-Delay-Poisson-Stream in section 3.6 of <xref
          target="RFC7679"/> target="RFC7679"
          sectionFormat="of" section="3.6"/> (for singletons) and section 4.6 of <xref target="RFC7679"/>
          target="RFC7679" sectionFormat="of" section="4.6"/> (for samples) using
          the Type-P and Tmax defined under in the Fixed Parameters.</t> Parameters column.</t>
          <t>The reference method distinguishes between long-delayed packets
          and lost packets by implementing a maximum waiting time for packet
          arrival. Tmax is the waiting time used as the threshold to declare a
          packet lost. Lost packets SHALL <bcp14>SHALL</bcp14> be designated as having undefined
          delay,
          delay and counted for the OWLoss metric.</t>
          <t>The calculations on the one-way delay SHALL <bcp14>SHALL</bcp14> be performed on the
          conditional distribution, conditioned on successful packet arrival
          within Tmax. Also, when all packet delays are stored, the process
          which
          that calculates the one-way delay value MUST <bcp14>MUST</bcp14> enforce the Tmax
          threshold on stored values before calculations. See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the conditional distribution
          to exclude undefined values of delay, and Section 5 of see <xref
          target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this analysis choice.</t>
          <t>The reference method requires some way to distinguish between
          different packets in a stream to establish correspondence between
          sending times and receiving times for each successfully-arriving successfully arriving
          packet.</t>
          <t>Since a standard measurement protocol is employed <xref
          target="RFC5357"/>, then target="RFC5357" format="default"/>, the measurement process will determine the
          sequence numbers or timestamps applied to test packets after the
          Fixed and Runtime parameters Parameters are passed to that process. The
          measurement protocol dictates the format of sequence numbers and
          time-stamps
          timestamps conveyed in the TWAMP-Test packet payload.</t>
        </section>
        <section title="Packet numbered="true" toc="default">
          <name>Packet Stream Generation"> Generation</name>
          <t>This section gives the provides details of the regarding packet traffic traffic, which is
	  used as the
          basis for measurement. In IPPM metrics, Metrics, this is called the Stream,
          and "stream";
	  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>
          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 spacing; thus, the Run-time Runtime Parameter
          is Reciprocal_lambda = 1/lambda, Reciprocal_lambda&nbsp;=&nbsp;1&wj;/lambda, in seconds.</t>
          <t>Method 3 SHALL <bcp14>SHALL</bcp14> be used, where used. Where given a start time (Run-time (Runtime
          Parameter), the subsequent send times are all computed prior to
          measurement by computing the pseudo-random pseudorandom distribution of
          inter-packet send times, 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
          Poisson distribution. A random value greater than Trunc is set equal
          to Trunc instead.</t>

          <t><list style="hanging">
              <t hangText="Reciprocal_lambda">average
          <dl newline="false" spacing="normal">
            <dt>Reciprocal_lambda:</dt>
            <dd>Average packet interval for
              Poisson Streams streams, expressed in units of seconds, as a positive
              value of type decimal64 with fraction digits = 4 (see section
              9.3 of <xref target="RFC6020"/>) target="RFC6020" sectionFormat="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 per section 6 of <xref
              target="RFC5905"/>. target="RFC5905" sectionFormat="of" section="6"/>. Reciprocal_lambda = 1 second.</t>

              <t hangText="Trunc">Upper second.</dd>
            <dt>Trunc:</dt>
            <dd>Upper limit on Poisson distribution distribution,
              expressed in units of seconds, as a positive value of type
              decimal64 with fraction digits = 4 (see section 9.3 of (see <xref
              target="RFC6020"/>) target="RFC6020" sectionFormat="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
              per section 6 of <xref target="RFC5905"/> target="RFC5905" sectionFormat="of" section="6"/> (values above this
              limit will be clipped and set to the limit value). Trunc =
              30.0000 seconds.</t>
            </list></t>
              Trunc&nbsp;=&nbsp;30.0000 seconds.</dd>
          </dl>
        </section>
        <section title="Traffic numbered="true" toc="default">
          <name>Traffic Filtering (observation) Details">
          <t>NA</t> (Observation) Details</name>
          <t>N/A</t>
        </section>
        <section title="Sampling Distribution">
          <t>NA</t> numbered="true" toc="default">
          <name>Sampling Distribution</name>
          <t>N/A</t>
        </section>
        <section title="Run-time numbered="true" toc="default">
          <name>Runtime Parameters and Data Format">
          <t>Run-time Format</name>
          <t>Runtime Parameters are input factors that must be determined,
          configured into the measurement system, and reported with the
          results for the context to be complete.</t>

          <t><list style="hanging">
              <t hangText="Src">the
          <dl newline="false" spacing="normal">
            <dt>Src:</dt>
            <dd>The IP address of the host in the Src Role
              (format ipv4-address-no-zone ipv4&nbhy;address-no-zone value for IPv4, IPv4 or
              ipv6-address-no-zone value for IPv6, IPv6; see Section 4 of <xref
              target="RFC6991"/>)</t>

              <t hangText="Dst">the target="RFC6991" sectionFormat="of" section="4"/>).</dd>
            <dt>Dst:</dt>
            <dd>The IP address of the host in the Dst Role
              (format ipv4-address-no-zone ipv4&nbhy;address-no-zone value for IPv4, IPv4 or
              ipv6-address-no-zone value for IPv6, IPv6; see section 4 of <xref
              target="RFC6991"/>)</t>

              <t hangText="T0">a target="RFC6991" sectionFormat="of" section="4"/>).</dd>
            <dt>T0:</dt>
            <dd>A time, the start of a measurement interval, interval
              (format "date-and-time" "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>. target="RFC2330" sectionFormat="of" section="6.1"/>. When T0 is "all-zeros", a start
              time is unspecified and Tf is to be interpreted as the Duration duration
              of the measurement interval. The start time is controlled
              through other means.</t>

              <t hangText="Tf">a means.</dd>
            <dt>Tf:</dt>
            <dd>A time, the end of a measurement interval, interval
              (format "date-and-time" "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>. target="RFC2330" sectionFormat="of" section="6.1"/>. When T0 is "all-zeros", a end an ending
              time and date is ignored and Tf is interpreted as the Duration duration of
              the measurement interval.</t>
            </list></t> interval.</dd>
          </dl>
        </section>
        <section title="Roles">
          <t><list style="hanging">
              <t hangText="Src">launches numbered="true" toc="default">
          <name>Roles</name>
          <dl newline="false" spacing="normal">
            <dt>Src:</dt>
            <dd>Launches each packet and waits for return
              transmissions from the Dst. This &nbsp;This is the TWAMP Session-Sender.</t>

              <t hangText="Dst">waits Session-Sender.</dd>
            <dt>Dst:</dt>
            <dd>Waits for each packet from the Src and sends a
              return packet to the Src. This &nbsp;This is the TWAMP Session-Reflector.</t>
            </list></t> Session-Reflector.</dd>
          </dl>
        </section>
      </section>
      <section title="Output"> numbered="true" toc="default">
        <name>Output</name>
        <t>This category specifies all details of the Output output of measurements
        using the metric.</t>
        <section title="Type">
          <t>See subsection titles below for Types.</t> numbered="true" toc="default">
          <name>Type</name>
          <t>Types are discussed in the subsections below.</t>
        </section>
        <section title="Reference Definition"> numbered="true" toc="default">
          <name>Reference Definition</name>
          <t>For all output types ---<list style="hanging">
              <t hangText="T0">the types:</t>
          <dl newline="false" spacing="normal">
            <dt>T0:</dt>
            <dd>The start of a measurement interval, interval (format
              "date-and-time"
              "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>.</t>

              <t hangText="Tf">the target="RFC2330" sectionFormat="of" section="6.1"/>.</dd>
            <dt>Tf:</dt>
            <dd>The end of a measurement interval, interval (format
              "date-and-time"
              "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>.</t>
            </list></t> target="RFC2330" sectionFormat="of" section="6.1"/>.</dd>
          </dl>
          <t>For LossRatio -- LossRatio, the count of lost packets to total packets sent
          is the basis for the loss ratio calculation as per Section 4.1 of <xref target="RFC7680"/>.</t> target="RFC7680" sectionFormat="of" section="4.1"/>.</t>
          <t>For each &lt;statistic&gt;, one of the following sub-sections
          apply:</t> subsections
          applies.</t>
          <section title="Percentile95"> numbered="true" toc="default">
            <name>Percentile95</name>
            <t>The 95th percentile SHALL <bcp14>SHALL</bcp14> be calculated using the conditional
            distribution of all packets with a finite value of One-way one-way delay
            (undefined delays are excluded), excluded) -- a single value value, as follows:</t>
            <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            Section 5 of
            see <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
            analysis choice.</t>
            <t>See section 4.3 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.3"/> for details on the
            percentile statistic (where Round-trip round-trip delay should be substituted
            for "ipdv").</t>
            <t>The percentile = 95, meaning that the reported delay,
            "95Percentile", is the smallest value of one-way delay for which
            the Empirical Distribution Function (EDF), F(95Percentile) &gt;= Function, EDF(95Percentile), is greater
	    than or equal to 95% of the singleton one-way delay values in the conditional
            distribution. See section 11.3 of <xref target="RFC2330"/> target="RFC2330" sectionFormat="of" section="11.3"/> for the
            definition of the percentile statistic using the EDF.</t>

            <t><list style="hanging">
                <t hangText="95Percentile">The
            <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
                decimal64 with fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) target="RFC6020" 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
                timestamp as per section 6 of <xref
                target="RFC5905">RFC</xref></t>
              </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            </dl>
          </section>
          <section title="Mean"> anchor="mean-sec7422" numbered="true" toc="default">
            <name>Mean</name>
            <t>The mean SHALL <bcp14>SHALL</bcp14> be calculated using the conditional distribution
            of all packets with a finite value of One-way one-way delay (undefined
            delays are excluded), excluded) -- a single value value, as follows:</t>
            <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            Section 5 of
            see <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
            analysis choice.</t>
            <t>See section 4.2.2 of <xref target="RFC6049"/> target="RFC6049" sectionFormat="of" section="4.2.2"/> for details on
            calculating this statistic, and 4.2.3 of statistic; see also <xref
            target="RFC6049"/>.</t>

            <t><list style="hanging">
                <t hangText="Mean">The target="RFC6049"
            sectionFormat="of" section="4.2.3"/>.</t>
            <dl newline="false" spacing="normal">
              <dt>Mean:</dt>
              <dd>The time value of the result is expressed
                in units of seconds, as a positive value of type decimal64
                with fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds 0.000000001&nbsp;seconds
                (1.0 ns), and with lossless conversion to/from the 64-bit NTP
                timestamp as per section 6 of <xref
                target="RFC5905">RFC</xref></t>
              </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            </dl>
          </section>
          <section title="Min"> numbered="true" toc="default">
            <name>Min</name>
            <t>The minimum SHALL <bcp14>SHALL</bcp14> be calculated using the conditional
            distribution of all packets with a finite value of One-way one-way delay
            (undefined delays are excluded), excluded) -- a single value value, as follows:</t>
            <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            Section 5 of
            see <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
            analysis choice.</t>
            <t>See section 4.3.2 of <xref target="RFC6049"/> target="RFC6049" sectionFormat="of" section="4.3.2"/> for details on
            calculating this statistic, and 4.3.3 of statistic; see also <xref
            target="RFC6049"/>.</t>

            <t><list style="hanging">
                <t hangText="Min">The target="RFC6049" sectionFormat="of" section="4.3.3"/>.</t>
            <dl newline="false" spacing="normal">
              <dt>Min:</dt>
              <dd>The time value of the result is expressed in
                units of seconds, as a positive value of type decimal64 with
                fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds 0.000000001&nbsp;seconds
                (1.0 ns), and with lossless conversion to/from the 64-bit NTP
                timestamp as per section 6 of <xref
                target="RFC5905">RFC</xref></t>
              </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            </dl>
          </section>
          <section title="Max"> numbered="true" toc="default">
            <name>Max</name>
            <t>The maximum SHALL <bcp14>SHALL</bcp14> be calculated using the conditional
            distribution of all packets with a finite value of One-way one-way delay
            (undefined delays are excluded), excluded) -- a single value value, as follows:</t>
            <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            Section 5 of
            see <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
            analysis choice.</t>
            <t>See section 4.3.2 of <xref target="RFC6049"/> target="RFC6049" sectionFormat="of" section="4.3.2"/> for a closely
            related method for calculating this statistic, and 4.3.3 of statistic; see also <xref
            target="RFC6049"/>. target="RFC6049" sectionFormat="of" section="4.3.3"/>. The formula is as follows:</t>

            <t><figure>
                <artwork><![CDATA[
            <artwork name="" type="" align="left" alt=""><![CDATA[
   Max = (FiniteDelay [j])

               such (FiniteDelay[j])
]]></artwork>

       <ul empty="true">
         <li>such that for some index, j, where 1 <= &lt;= j <= &lt;= N
               FiniteDelay[j] >= FiniteDelay[n]
         FiniteDelay[j]&nbsp;&gt;=&nbsp;FiniteDelay[n] for all n]]></artwork>
              </figure></t>

            <t><list style="hanging">
                <t hangText="Max">The n</li>
       </ul>
            <dl newline="false" spacing="normal">
              <dt>Max:</dt>
              <dd>The time value of the result is expressed in
                units of seconds, as a positive value of type decimal64 with
                fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds 0.000000001&nbsp;seconds
                (1.0 ns), and with lossless conversion to/from the 64-bit NTP
                timestamp as per section 6 of <xref
                target="RFC5905">RFC</xref></t>
              </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            </dl>
          </section>
          <section title="Std_Dev"> numbered="true" toc="default">
            <name>Std_Dev</name>
            <t>The Std_Dev SHALL standard deviation (Std_Dev) <bcp14>SHALL</bcp14> be calculated using the conditional
            distribution of all packets with a finite value of One-way one&nbhy;way delay
            (undefined delays are excluded), excluded) -- a single value value, as follows:</t>
            <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            Section 5 of
            see <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
            analysis choice.</t>
            <t>See section 6.1.4 of <xref target="RFC6049"/> target="RFC6049" sectionFormat="of" section="6.1.4"/> for a closely
            related method for calculating this statistic. The formula is the
            classic calculation for standard deviation of a population.<figure>
                <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:
            classic calculation for the standard deviation of a population.</t>

<t>Define Population Std_Dev_Delay as follows:</t>

            <artwork name="" type="" align="left" alt=""><![CDATA[
                     _                                       _
                    |            N                            |
                    |           ---                           |
                    |     1     \                          2  |
    Std_Dev = SQRT  |  -------   >   (Delay[n] - MeanDelay)   |
                    |    (N)    /                             |
                    |           ---                           |
                    |          n = 1                          |
                    |_                                       _|
]]></artwork>
              </figure></t>

            <t><list style="hanging">
                <t hangText="Std_Dev">The

     <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
                decimal64 with fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) target="RFC6020" 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
                timestamp as per section 6 of <xref
                target="RFC5905">RFC</xref></t>
              </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            </dl>
          </section>
        </section>
        <section title="Metric Units"> numbered="true" toc="default">
          <name>Metric Units</name>
          <t>The &lt;statistic&gt; of One-way Delay one-way delay is expressed in
          seconds.</t>
          <t>The One-way Loss Ratio one-way loss ratio is expressed as a percentage of lost
          packets to total packets sent.</t>
        </section>
        <section title="Calibration">
          <t>Section 3.7.3 of <xref target="RFC7679"/> numbered="true" toc="default">
          <name>Calibration</name>
          <t><xref target="RFC7679" sectionFormat="of" section="3.7.3"/> provides a means to
          quantify the systematic and random errors of a time measurement.
          In-situ calibration
          Calibration in&nbsp;situ could be enabled with an internal loopback that
          includes as much of the measurement system as possible, performs
          address manipulation as needed, and provides some form of isolation
          (e.g., deterministic delay) to avoid send-receive interface
          contention. Some portion of the random and systematic error can be
          characterized in this way.</t>
          <t>For one-way delay measurements, the error calibration must
          include an assessment of the internal clock synchronization with its
          external reference (this internal clock is supplying timestamps for
          measurement). In practice, the time offsets <xref target="RFC5905"/> target="RFC5905" format="default"/>
          of clocks at both the source Source and destination Destination are needed to estimate
          the systematic error due to imperfect clock synchronization (the
          time offsets <xref target="RFC5905"/> target="RFC5905" format="default"/> are smoothed, thus smoothed; thus, the random
          variation is not usually represented in the results).<list
              style="hanging">
              <t hangText="time_offset">The results).</t>
          <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
              decimal64 with fraction digits = 9 digits&nbsp;=&nbsp;9 (see section 9.3 of <xref
              target="RFC6020"/>) target="RFC6020" 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
              timestamp as per section 6 of <xref
              target="RFC5905">RFC</xref></t>
            </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
          </dl>
          <t>When a measurement controller requests a calibration measurement,
          the loopback is applied and the result is output in the same format
          as a normal measurement measurement, with an additional indication that it is a
          calibration result. In any measurement, the measurement function
          SHOULD
          <bcp14>SHOULD</bcp14> report its current estimate of the time offset <xref
          target="RFC5905"/> target="RFC5905" format="default"/> as an indicator of the degree of
          synchronization.</t>
          <t>Both internal loopback calibration and clock synchronization can
          be used to estimate the available accuracy of the Output Metric
          Units. For example, repeated loopback delay measurements will reveal
          the portion of the Output output result resolution which that is the result of
          system noise, noise and is thus inaccurate.</t>

          <t/>
        </section>
      </section>
      <section title="Administrative items">
        <t/>

        <section title="Status"> numbered="true" toc="default">
        <name>Administrative Items</name>
        <section numbered="true" toc="default">
          <name>Status</name>
          <t>Current</t>
        </section>
        <section title="Requester">
          <t>This RFC number</t> numbered="true" toc="default">
          <name>Requester</name>
          <t>RFC 8912</t>
        </section>
        <section title="Revision"> numbered="true" toc="default">
          <name>Revision</name>
          <t>1.0</t>
        </section>
        <section title="Revision Date"> numbered="true" toc="default">
          <name>Revision Date</name>
          <t>YYYY-MM-DD</t>
        </section>
      </section>
      <section title="Comments numbered="true" toc="default">
        <name>Comments and Remarks"> Remarks</name>
        <t>None</t>
      </section>
    </section>
    <section title="UDP anchor="UDP_periodic_owd_and_loss" numbered="true" toc="default">
      <name>UDP Periodic One-way One-Way Delay and Loss Registry Entries"> Entries</name>
      <t>This section specifies five initial registry entries Registry Entries for the UDP
      Periodic One-way Delay, One-Way Delay and one entry for UDP Periodic One-way One-Way Loss.</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 is an
      additional metric name for the Loss metric.</t>

      <t>All column entries beside besides the ID, Name, Description, and Output
      Reference Method categories are the same, thus same; thus, this section proposes defines six
      closely-related registry entries.
      closely related Registry Entries. As a result, IANA is also asked to
      assign has
      assigned corresponding URLs to each of the six Named Metric.</t> Metrics.</t>
      <section title="Summary"> numbered="true" toc="default">
        <name>Summary</name>
        <t>This category includes multiple indexes to the registry entries, Registry Entries:
        the element ID and metric name.</t> Metric Name.</t>
        <section title="ID (Identifier)"> numbered="true" toc="default">
          <name>ID (Identifier)</name>
	  <t>IANA is asked to assign a different has allocated the numeric identifiers to each
          of Identifiers 12-17 for the six Metrics.</t>
        </section>

        <section title="Name">
          <t>OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFCXXXXsec8_Seconds_&lt;statistic&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-Periodic-Payload142B_RFCXXXXsec8_Percent_LossRatio</t>
   Named Metric Entries in <xref target="UDP_periodic_owd_and_loss"/>. See
   <xref target="name812"/> for mapping to Names.</t>
        </section>
        <section title="URI"> anchor="name812" numbered="true" toc="default">
          <name>Name</name>
	  <dl spacing="normal" indent="5" newline="false">
	    <dt>12:</dt><dd>OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_95Percentile</dd>
	    <dt>13:</dt><dd>OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Mean</dd>
   	    <dt>14:</dt><dd>OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Min</dd>
   	    <dt>15:</dt><dd>OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Max</dd>
   	    <dt>16:</dt><dd>OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_StdDev</dd>
            <dt>17:</dt><dd>OWLoss_Active_IP-UDP-Periodic-Payload142B_RFC8912sec8_Percent_LossRatio</dd>
	  </dl>
        </section>
        <section numbered="true" toc="default">
          <name>URI</name>
          <t>URL: https://www.iana.org/ <eref target="https://www.iana.org/"/> ... &lt;name&gt;</t> &lt;Name&gt;</t>
        </section>
        <section title="Description">
          <t>OWDelay: This numbered="true" toc="default">
          <name>Description</name>
          <dl newline="false" spacing="normal">
          <dt>OWDelay:</dt><dd><t>This metric assesses the delay of a stream of packets
          exchanged between two hosts (or measurement points), points) and reports the
          &lt;statistic&gt; One-way one-way delay for all successfully exchanged
          packets based on their conditional delay distribution.</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: This
          <ul spacing="normal">
            <li>95Percentile</li>
            <li>Mean</li>
            <li>Min</li>
            <li>Max</li>
            <li>StdDev</li>
          </ul>
	</dd>
          <dt>OWLoss:</dt><dd>This metric assesses the loss ratio of a stream of
          packets exchanged between two hosts (which are the two measurement
          points), and the Output
          points). The output is the One-way one-way loss ratio for all
          successfully received packets expressed as a percentage.</t> 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 title="Metric Definition"> numbered="true" toc="default">
        <name>Metric Definition</name>
        <t>This category includes columns to prompt the entry of all necessary
        details related to the metric definition, including the RFC reference
        and values of input factors, called fixed parameters.</t> "Fixed Parameters".</t>
        <section title="Reference Definition"> numbered="true" toc="default">
          <name>Reference Definition</name>
          <t>For Delay:</t>

          <t>Almes, delay:</t>
          <t indent="3">Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A
	  One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC
	  7679, DOI 10.17487/RFC7679, January 2016,
          &lt;http://www.rfc-editor.org/info/rfc7679&gt;.</t>

          <t><xref
	  &lt;https://www.rfc-editor.org/info/rfc7679&gt;.
          <xref target="RFC7679"/></t>

          <t>Morton, A.,
          <t indent="3">Morton, A. and E. Stephan, E., "Spatial Composition of Metrics", RFC
	  6049, DOI 10.17487/RFC6049, January 2011.</t>

          <t><xref target="RFC6049"/></t>

          <t>Section 3.4 of 2011,
	  &lt;https://www.rfc-editor.org/info/rfc6049&gt;.
          <xref target="RFC7679"/> target="RFC6049"/></t>
          <t indent="3"><xref target="RFC7679" sectionFormat="of" section="3.4"/> provides the reference
          definition of the singleton (single value) One-way one-way delay metric.
          Section 4.4 of
          <xref target="RFC7679"/> target="RFC7679" sectionFormat="of" section="4.4"/> provides the reference
          definition expanded to cover a multi-value sample. Note that terms
          such as singleton "singleton" and sample "sample" are defined in Section 11 of <xref
          target="RFC2330"/>.</t>

          <t>Only target="RFC2330" sectionFormat="of" section="11"/>.</t>
          <t indent="3">Only successful packet transfers with finite delay are included
          in the sample, as prescribed in section 4.1.2 of <xref
          target="RFC6049"/>.</t> target="RFC6049" sectionFormat="of" section="4.1.2"/>.</t>
          <t>For loss:</t>

          <t>Almes,
          <t indent="3">Almes, G., Kalidini, Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A
	  One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, RFC
	  7680, DOI 10.17487/RFC7680, January 2016,
          &lt;http://www.rfc-editor.org/info/rfc7680&gt;.</t>

          <t>Section 2.4 of
	  &lt;https://www.rfc-editor.org/info/rfc7680&gt;.
          <xref target="RFC7680"/> target="RFC7680"/></t>
          <t indent="3"><xref target="RFC7680" sectionFormat="of" section="2.4"/> provides the reference
          definition of the singleton (single value) one-way loss Loss metric.
          Section 3.4 of
          <xref target="RFC7680"/> target="RFC7680" sectionFormat="of" section="3.4"/> provides the reference
          definition expanded to cover a multi-singleton sample. Note that
          terms such as singleton "singleton" and sample "sample" are defined in Section 11 of <xref target="RFC2330"/>.</t>
        </section>

        <section title="Fixed Parameters">
          <t>Type-P: <list style="symbols">
              <t>IPv4 target="RFC2330" sectionFormat="of" section="11"/>.</t>
        </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: <list style="symbols">
                  <t>DSCP: set values:</dt>
 	    <dd><t/>
 	     <dl newline="false" spacing="compact">
             <dt>DSCP:</dt><dd>Set to 0</t>

                  <t>TTL: set 0</dd>
             <dt>TTL:</dt><dd>Set to 255</t>

                  <t>Protocol: Set 255</dd>
             <dt>Protocol:</dt><dd>Set to 17 (UDP)</t>
                </list></t>

              <t>IPv6 (UDP)</dd>
	     </dl>
	    </dd>
	    </dl>

	    <dl newline="true" spacing="normal">
             <dt>IPv6 header values:<list style="symbols">
                  <t>DSCP: set to 0</t>

                  <t>Hop Count: set to 255</t>

                  <t>Next Header: set 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)</t>

                  <t>Flow Label: set to zero</t>

                  <t>Extension Headers: none</t>
                </list></t>

              <t>UDP (UDP)</dd>
              <dt>Flow Label:</dt><dd>Set to 0</dd>
              <dt>Extension Headers:</dt><dd>None</dd>
	      </dl>
	     </dd>
	    </dl>

	    <dl newline="true" spacing="normal">
              <dt>UDP header values: <list style="symbols">
                  <t>Checksum: the values:</dt>
	      <dd><t/>
	      <dl newline="false" spacing="compact">
	       <dt>Checksum:</dt><dd>The checksum MUST <bcp14>MUST</bcp14> 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 header</dd>
	      </dl>
	      </dd>
	    </dl>

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

                  <t>142
              octets</li>
            <li>142 octets total, including the TWAMP format (and format
              type MUST <bcp14>MUST</bcp14> be reported, if used)</t>
                </list></t>
            </list></t>

          <t>Other measurement parameters:</t>

          <t><list style="hanging">
              <t hangText="Tmax:">a used)</li>
            </ul>
	  </dd>
	    </dl>
	    </dd>
	  </dl>

	    <dl newline="true" spacing="normal">
	      <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
              decimal64 with fraction digits = 4 (see section 9.3 of (see <xref
              target="RFC6020"/>) target="RFC6020" 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 section 6 of <xref target="RFC5905"/>.</t>
            </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
              </dl>
	      </dd>
	    </dl>

          <t>See the Packet Stream generation category Generation &lt;section or column&gt; for two three additional
          Fixed Parameters.</t>
        </section>
      </section>
      <section title="Method numbered="true" toc="default">
        <name>Method of Measurement"> Measurement</name>
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure
        an unambiguous methods method for implementations.</t>
        <section title="Reference Method"> numbered="true" toc="default">
          <name>Reference Methods</name>
          <t>The methodology for this metric (equivalent to
          Type-P-One-way-Delay-Poisson-Stream) is defined as
          Type-P-One-way-Delay-Poisson-Stream in section 3.6 of <xref
          target="RFC7679"/> target="RFC7679"
          sectionFormat="of" section="3.6"/> (for singletons) and section 4.6 of <xref target="RFC7679"/>
          target="RFC7679" sectionFormat="of" section="4.6"/> (for samples) using
          the Type-P and Tmax defined under in the Fixed Parameters. Parameters column. However, a
          Periodic stream is used, as defined in <xref target="RFC3432"/>.</t> target="RFC3432" format="default"/>.</t>
          <t>The reference method distinguishes between long-delayed packets
          and lost packets by implementing a maximum waiting time for packet
          arrival. Tmax is the waiting time used as the threshold to declare a
          packet lost. Lost packets SHALL <bcp14>SHALL</bcp14> be designated as having undefined
          delay,
          delay and counted for the OWLoss metric.</t>
          <t>The calculations on the one-way delay SHALL <bcp14>SHALL</bcp14> be performed on the
          conditional distribution, conditioned on successful packet arrival
          within Tmax. Also, when all packet delays are stored, the process
          which
          that calculates the one-way delay value MUST <bcp14>MUST</bcp14> enforce the Tmax
          threshold on stored values before calculations. See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the conditional distribution
          to exclude undefined values of delay, and Section 5 of see <xref
          target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this analysis choice.</t>
          <t>The reference method requires some way to distinguish between
          different packets in a stream to establish correspondence between
          sending times and receiving times for each successfully-arriving successfully arriving
          packet.</t>
          <t>Since a standard measurement protocol is employed <xref
          target="RFC5357"/>, then target="RFC5357" format="default"/>, the measurement process will determine the
          sequence numbers or timestamps applied to test packets after the
          Fixed and Runtime parameters Parameters are passed to that process. The
          measurement protocol dictates the format of sequence numbers and
          time-stamps
          timestamps conveyed in the TWAMP-Test packet payload.</t>
        </section>
        <section title="Packet numbered="true" toc="default">
          <name>Packet Stream Generation"> Generation</name>
          <t>This section gives the provides details of the regarding packet traffic traffic, which is
	  used as the
          basis for measurement. In IPPM metrics, Metrics, this is called the Stream,
          and "stream";
	  this stream can easily be described by providing the list of stream
          parameters.</t>

          <t>Section 3 of <xref target="RFC3432"/>
          Parameters.</t>
          <t><xref target="RFC3432" sectionFormat="of" section="3"/> prescribes the method for
          generating Periodic streams using associated parameters.</t>

          <t><list style="hanging">
              <t hangText="incT">the Parameters.</t>
          <dl newline="false" spacing="normal">
            <dt>incT:</dt>
            <dd>The nominal duration of the inter-packet
              interval, first bit to first bit, with value 0.0200 0.0200, expressed in
              units of seconds, as a positive value of type decimal64 with
              fraction digits = 4 (see section 9.3 of <xref
              target="RFC6020"/>) target="RFC6020" 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 section 6 of <xref target="RFC5905"/>.</t>

              <t hangText="dT">the target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            <dt>dT:</dt>
            <dd>The duration of the interval for allowed sample
              start times, with value 1.0000, expressed in units of seconds,
              as a positive value of type decimal64 with fraction digits = 4
              (see section 9.3 of <xref target="RFC6020"/>) target="RFC6020" 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 section 6 of <xref
              target="RFC5905"/>.</t>

              <t hangText="T0">the target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            <dt>T0:</dt>
            <dd>The actual start time of the periodic stream,
              determined from T0 and dT.</t>
            </list>NOTE: an dT.</dd>
          </dl>
          <aside><t>Note: An initiation process with a number of control
          exchanges resulting in unpredictable start times (within a time
          interval) may be sufficient to avoid synchronization of periodic
          streams,
          streams and therefore is a valid replacement for selecting a start
          time at random from a fixed interval.</t> interval.</t></aside>
          <t>These stream parameters Parameters will be specified as Run-time
          parameters.</t> Runtime
          Parameters.</t>
        </section>
        <section title="Traffic numbered="true" toc="default">
          <name>Traffic Filtering (observation) Details">
          <t>NA</t> (Observation) Details</name>
          <t>N/A</t>
        </section>
        <section title="Sampling Distribution">
          <t>NA</t> numbered="true" toc="default">
          <name>Sampling Distribution</name>
          <t>N/A</t>
        </section>
        <section title="Run-time numbered="true" toc="default">
          <name>Runtime Parameters and Data Format">
          <t>Run-time Format</name>
          <t>Runtime Parameters are input factors that must be determined,
          configured into the measurement system, and reported with the
          results for the context to be complete.</t>

          <t><list style="hanging">
              <t hangText="Src">the
          <dl newline="false" spacing="normal">
            <dt>Src:</dt>
            <dd>The IP address of the host in the Src Role
              (format ipv4-address-no-zone ipv4&nbhy;address-no-zone value for IPv4, IPv4 or
              ipv6-address-no-zone value for IPv6, IPv6; see Section 4 of <xref
              target="RFC6991"/>)</t>

              <t hangText="Dst">the target="RFC6991" sectionFormat="of" section="4"/>).</dd>
            <dt>Dst:</dt>
            <dd>The IP address of the host in the Dst Role
              (format ipv4-address-no-zone ipv4&nbhy;address-no-zone value for IPv4, IPv4 or
              ipv6-address-no-zone value for IPv6, IPv6; see section 4 of <xref
              target="RFC6991"/>)</t>

              <t hangText="T0">a target="RFC6991" sectionFormat="of" section="4"/>).</dd>
            <dt>T0:</dt>
            <dd>A time, the start of a measurement interval, interval
              (format "date-and-time" "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>. target="RFC2330" sectionFormat="of" section="6.1"/>. When T0 is "all-zeros", a start
              time is unspecified and Tf is to be interpreted as the Duration duration
              of the measurement interval. The start time is controlled
              through other means.</t>

              <t hangText="Tf">a means.</dd>
            <dt>Tf:</dt>
            <dd>A time, the end of a measurement interval, interval
              (format "date-and-time" "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>. target="RFC2330" sectionFormat="of" section="6.1"/>. When T0 is "all-zeros", a end an ending
              time and date is ignored and Tf is interpreted as the Duration duration of
              the measurement interval.</t>
            </list></t>

          <t/> interval.</dd>
          </dl>
        </section>
        <section title="Roles">
          <t><list style="hanging">
              <t hangText="Src">launches numbered="true" toc="default">
          <name>Roles</name>
          <dl newline="false" spacing="normal">
            <dt>Src:</dt>
            <dd>Launches each packet and waits for return
              transmissions from the Dst. This &nbsp;This is the TWAMP Session-Sender.</t>

              <t hangText="Dst">waits Session-Sender.</dd>
            <dt>Dst:</dt>
            <dd>Waits for each packet from the Src and sends a
              return packet to the Src. This &nbsp;This is the TWAMP Session-Reflector.</t>
            </list></t> Session-Reflector.</dd>
          </dl>
        </section>
      </section>
      <section title="Output"> numbered="true" toc="default">
        <name>Output</name>
        <t>This category specifies all details of the Output output of measurements
        using the metric.</t>
        <section title="Type">
          <t>See subsection titles numbered="true" toc="default">
          <name>Type</name>
          <t>Latency Types are discussed in Reference Definition for Latency
          Types.</t> the subsections below.</t>
        </section>
        <section title="Reference Definition"> numbered="true" toc="default">
          <name>Reference Definition</name>
          <t>For all output types ---<list style="hanging">
              <t hangText="T0">the types:</t>
          <dl newline="false" spacing="normal">
            <dt>T0:</dt>
            <dd>The start of a measurement interval, interval (format
              "date-and-time"
              "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>.</t>

              <t hangText="Tf">the target="RFC2330" sectionFormat="of" section="6.1"/>.</dd>
            <dt>Tf:</dt>
            <dd>The end of a measurement interval, interval (format
              "date-and-time"
              "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>.</t>
            </list></t> target="RFC2330" sectionFormat="of" section="6.1"/>.</dd>
          </dl>
          <t>For LossRatio -- LossRatio, the count of lost packets to total packets sent
          is the basis for the loss ratio calculation as per Section 4.1 of <xref target="RFC7680"/>.</t> target="RFC7680" sectionFormat="of" section="4.1"/>.</t>
          <t>For each &lt;statistic&gt;, one of the following sub-sections
          apply:</t> subsections
          applies.</t>
          <section title="Percentile95"> numbered="true" toc="default">
            <name>Percentile95</name>
            <t>The 95th percentile SHALL <bcp14>SHALL</bcp14> be calculated using the conditional
            distribution of all packets with a finite value of One-way one-way delay
            (undefined delays are excluded), excluded) -- a single value value, as follows:</t>
            <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            Section 5 of
            see <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
            analysis choice.</t>
            <t>See section 4.3 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.3"/> for details on the
            percentile statistic (where Round-trip round-trip delay should be substituted
            for "ipdv").</t>
            <t>The percentile = 95, meaning that the reported delay,
            "95Percentile", is the smallest value of one-way delay for which
            the Empirical Distribution Function (EDF), F(95Percentile) &gt;= Function, EDF(95Percentile), is greater
	    than or equal to 95%  of the singleton one-way delay values in the conditional
            distribution. See section 11.3 of <xref target="RFC2330"/> target="RFC2330" sectionFormat="of" section="11.3"/> for the
            definition of the percentile statistic using the EDF.</t>

            <t><list style="hanging">
                <t hangText="95Percentile">The
            <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
                decimal64 with fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) target="RFC6020" 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
                timestamp as per section 6 of <xref
                target="RFC5905">RFC</xref></t>
              </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            </dl>
          </section>
          <section title="Mean"> anchor="mean-sec8422" numbered="true" toc="default">
            <name>Mean</name>
            <t>The mean SHALL <bcp14>SHALL</bcp14> be calculated using the conditional distribution
            of all packets with a finite value of One-way one-way delay (undefined
            delays are excluded), excluded) -- a single value value, as follows:</t>
            <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            Section 5 of
            see <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
            analysis choice.</t>
            <t>See section 4.2.2 of <xref target="RFC6049"/> target="RFC6049" sectionFormat="of" section="4.2.2"/> for details on
            calculating this statistic, and 4.2.3 of statistic; see also <xref
            target="RFC6049"/>.</t>

            <t><list style="hanging">
                <t hangText="Mean">The target="RFC6049" sectionFormat="of" section="4.2.3"/>.</t>
            <dl newline="false" spacing="normal">
              <dt>Mean:</dt>
              <dd>The time value of the result is expressed
                in units of seconds, as a positive value of type decimal64
                with fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds 0.000000001&nbsp;seconds
                (1.0 ns), and with lossless conversion to/from the 64-bit NTP
                timestamp as per section 6 of <xref
                target="RFC5905">RFC</xref></t>
              </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            </dl>
          </section>
          <section title="Min"> numbered="true" toc="default">
            <name>Min</name>
            <t>The minimum SHALL <bcp14>SHALL</bcp14> be calculated using the conditional
            distribution of all packets with a finite value of One-way one-way delay
            (undefined delays are excluded), excluded) -- a single value value, as follows:</t>
            <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            Section 5 of
            see <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
            analysis choice.</t>
            <t>See section 4.3.2 of <xref target="RFC6049"/> target="RFC6049" sectionFormat="of" section="4.3.2"/> for details on
            calculating this statistic, and 4.3.3 of statistic; see also <xref
            target="RFC6049"/>.</t>

            <t><list style="hanging">
                <t hangText="Min">The target="RFC6049" sectionFormat="of" section="4.3.3"/>.</t>
            <dl newline="false" spacing="normal">
              <dt>Min:</dt>
              <dd>The time value of the result is expressed in
                units of seconds, as a positive value of type decimal64 with
                fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds 0.000000001&nbsp;seconds
                (1.0 ns), and with lossless conversion to/from the 64-bit NTP
                timestamp as per section 6 of per <xref
                target="RFC5905">RFC</xref></t>
              </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            </dl>
          </section>
          <section title="Max"> numbered="true" toc="default">
            <name>Max</name>
            <t>The maximum SHALL <bcp14>SHALL</bcp14> be calculated using the conditional
            distribution of all packets with a finite value of One-way one-way delay
            (undefined delays are excluded), excluded) -- a single value value, as follows:</t>
            <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            Section 5 of
            see <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
            analysis choice.</t>
            <t>See section 4.3.2 of <xref target="RFC6049"/> target="RFC6049" sectionFormat="of" section="4.3.2"/> for a closely
            related method for calculating this statistic, and 4.3.3 of statistic; see also <xref
            target="RFC6049"/>. target="RFC6049" sectionFormat="of" section="4.3.3"/>. The formula is as follows:</t>

            <t><figure>
                <artwork><![CDATA[
            <artwork name="" type="" align="left" alt=""><![CDATA[
   Max = (FiniteDelay [j])

               such (FiniteDelay[j])
]]></artwork>

       <ul empty="true">
        <li>such that for some index, j, where 1 <= &lt;= j <= &lt;= N
               FiniteDelay[j] >= FiniteDelay[n]
        FiniteDelay[j]&nbsp;&gt;=&nbsp;FiniteDelay[n] for all n]]></artwork>
              </figure></t>

            <t><list style="hanging">
                <t hangText="Max">The n</li>
       </ul>
            <dl newline="false" spacing="normal">
              <dt>Max:</dt>
              <dd>The time value of the result is expressed in
                units of seconds, as a positive value of type decimal64 with
                fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds 0.000000001&nbsp;seconds
                (1.0 ns), and with lossless conversion to/from the 64-bit NTP
                timestamp as per section 6 of <xref
                target="RFC5905">RFC</xref></t>
              </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            </dl>
          </section>
          <section title="Std_Dev">
            <t>The Std_Dev SHALL numbered="true" toc="default">
            <name>Std_Dev</name>
            <t>Std_Dev <bcp14>SHALL</bcp14> be calculated using the conditional
            distribution of all packets with a finite value of One-way one&nbhy;way delay
            (undefined delays are excluded), excluded) -- a single value value, as follows:</t>
            <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            Section 5 of
            see <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
            analysis choice.</t>
            <t>See section 4.3.2 of <xref target="RFC6049"/> target="RFC6049" sectionFormat="of" section="6.1.4"/> for a closely
            related method for calculating this statistic, and 4.3.3 of <xref
            target="RFC6049"/>. statistic. The formula
            is the classic calculation for the
            standard deviation of a population.</t>

            <figure>
              <artwork><![CDATA[Define

<t>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: follows:</t>

<artwork name="" type="" align="left" alt=""><![CDATA[
                     _                                       _
                    |            N                            |
                    |           ---                           |
                    |     1     \                          2  |
    Std_Dev = SQRT  |  -------   >   (Delay[n] - MeanDelay)   |
                    |    (N)    /                             |
                    |           ---                           |
                    |          n = 1                          |
                    |_                                       _|
]]></artwork>
            </figure>

            <t/>

            <t><list style="hanging">
                <t hangText="Std_Dev">The

     <t>where all packets n = 1 through N have a value for Delay[n],
     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
                decimal64 with fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) target="RFC6020" 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
                timestamp as per section 6 of <xref
                target="RFC5905">RFC</xref></t>
              </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            </dl>
          </section>
        </section>
        <section title="Metric Units"> numbered="true" toc="default">
          <name>Metric Units</name>
          <t>The &lt;statistic&gt; of One-way Delay one-way delay is expressed in seconds,
          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>
          <ul spacing="normal">
            <li>95Percentile</li>
            <li>Mean</li>
            <li>Min</li>
            <li>Max</li>
            <li>StdDev</li>
          </ul>
          <t>The One-way Loss Ratio one-way loss ratio is expressed as a percentage of lost
          packets to total packets sent.</t>
        </section>
        <section title="Calibration">
          <t>Section 3.7.3 of <xref target="RFC7679"/> numbered="true" toc="default">
          <name>Calibration</name>
          <t><xref target="RFC7679" sectionFormat="of" section="3.7.3"/> provides a means to
          quantify the systematic and random errors of a time measurement.
          In-situ calibration
          Calibration in&nbsp;situ could be enabled with an internal loopback that
          includes as much of the measurement system as possible, performs
          address manipulation as needed, and provides some form of isolation
          (e.g., deterministic delay) to avoid send-receive interface
          contention. Some portion of the random and systematic error can be
          characterized in this way.</t>
          <t>For one-way delay measurements, the error calibration must
          include an assessment of the internal clock synchronization with its
          external reference (this internal clock is supplying timestamps for
          measurement). In practice, the time offsets <xref target="RFC5905"/> target="RFC5905" format="default"/>
          of clocks at both the source Source and destination Destination are needed to estimate
          the systematic error due to imperfect clock synchronization (the
          time offsets <xref target="RFC5905"/> target="RFC5905" format="default"/> are smoothed, thus smoothed; thus, the random
          variation is not usually represented in the results).<list
              style="hanging">
              <t hangText="time_offset">The results).</t>
          <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
              decimal64 with fraction digits = 9 digits&nbsp;=&nbsp;9 (see section 9.3 of <xref
              target="RFC6020"/>) target="RFC6020" 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
              timestamp as per section 6 of <xref
              target="RFC5905">RFC</xref></t>
            </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
          </dl>
          <t>When a measurement controller requests a calibration measurement,
          the loopback is applied and the result is output in the same format
          as a normal measurement measurement, with an additional indication that it is a
          calibration result. In any measurement, the measurement function
          SHOULD
          <bcp14>SHOULD</bcp14> report its current estimate of the time offset <xref
          target="RFC5905"/> target="RFC5905" format="default"/> as an indicator of the degree of
          synchronization.</t>
          <t>Both internal loopback calibration and clock synchronization can
          be used to estimate the available accuracy of the Output Metric
          Units. For example, repeated loopback delay measurements will reveal
          the portion of the Output output result resolution which that is the result of
          system noise, noise and is thus inaccurate.</t>

          <t/>
        </section>
      </section>
      <section title="Administrative items">
        <t/>

        <section title="Status"> numbered="true" toc="default">
        <name>Administrative Items</name>
        <section numbered="true" toc="default">
          <name>Status</name>
          <t>Current</t>
        </section>
        <section title="Requester">
          <t>This RFC number</t> numbered="true" toc="default">
          <name>Requester</name>
          <t>RFC 8912</t>
        </section>
        <section title="Revision"> numbered="true" toc="default">
          <name>Revision</name>
          <t>1.0</t>
        </section>
        <section title="Revision Date"> numbered="true" toc="default">
          <name>Revision Date</name>
          <t>YYYY-MM-DD</t>
        </section>
      </section>
      <section title="Comments numbered="true" toc="default">
        <name>Comments and Remarks">
        <t>None.</t> Remarks</name>
        <t>None</t>
      </section>
    </section>
    <section title="ICMP Round-trip anchor="icmp_roundtrip_latency_and_loss" numbered="true" toc="default">
      <name>ICMP Round-Trip Latency and Loss Registry Entries"> Entries</name>
      <t>This section specifies three initial registry entries Registry Entries for the ICMP
      Round-trip Latency,
      Round&nbhy;Trip Latency and another entry for the ICMP Round-trip Round-Trip Loss
      Ratio.</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 is an
      additional metric name for the Loss metric.</t>

      <t>All column entries beside besides the ID, Name, Description, and Output
      Reference Method categories are the same, thus same; thus, this section proposes two
      closely-related registry entries. defines four
      closely related Registry Entries. As a result, IANA is also asked to
      assign has
      assigned corresponding URLs to each of the four Named Metric.</t> Metrics.</t>
      <section title="Summary"> numbered="true" toc="default">
        <name>Summary</name>
        <t>This category includes multiple indexes to the registry entry: Registry Entries: the
        element ID and metric name.</t> Metric Name.</t>
        <section title="ID (Identifier)"> numbered="true" toc="default">
          <name>ID (Identifier)</name>
          <t>IANA is asked to assign different has allocated the numeric identifiers to each of Identifiers 18-21 for the four
	  Named Metrics.</t>
        </section>

        <section title="Name">
          <t>RTDelay_Active_IP-ICMP-SendOnRcv_RFCXXXXsec9_Seconds_&lt;statistic&gt;</t>

          <t>where &lt;statistic&gt; is one of:</t>

          <t><list style="symbols">
              <t>Mean</t>

              <t>Min</t>

              <t>Max</t>
            </list></t>

          <t>RTLoss_Active_IP-ICMP-SendOnRcv_RFCXXXXsec9_Percent_LossRatio</t> Metric Entries in <xref target="icmp_roundtrip_latency_and_loss"/>.
	  See <xref target="name912"/> for mapping to Names.</t>
        </section>

        <section title="URI"> anchor="name912" numbered="true" toc="default">
          <name>Name</name>
	  <dl spacing="normal" indent="5" newline="false">
	    <dt>18:</dt><dd>RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Mean</dd>
	    <dt>19:</dt><dd>RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Min</dd>
	    <dt>20:</dt><dd>RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Max</dd>
            <dt>21:</dt><dd>RTLoss_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Percent_LossRatio</dd>
	  </dl>
        </section>
        <section numbered="true" toc="default">
          <name>URI</name>
          <t>URL: https://www.iana.org/ <eref target="https://www.iana.org/"/> ... &lt;name&gt;</t> &lt;Name&gt;</t>
        </section>
        <section title="Description">
          <t>RTDelay: This numbered="true" toc="default">
          <name>Description</name>
          <dl newline="false" spacing="normal">
          <dt>RTDelay:</dt><dd><t>This metric assesses the delay of a stream of ICMP
          packets exchanged between two hosts (which are the two measurement
          points), and the Output
          points). The output is the Round-trip round-trip delay for all successfully
          exchanged packets expressed as the &lt;statistic&gt; of their
          conditional delay distribution, where &lt;statistic&gt; is one
          of:</t>

          <t><list style="symbols">
              <t>Mean</t>

              <t>Min</t>

              <t>Max</t>
            </list></t>

          <t>RTLoss: This
          <ul spacing="normal">
            <li>Mean</li>
            <li>Min</li>
            <li>Max</li>
          </ul>
	</dd>

          <dt>RTLoss:</dt><dd>This metric assesses the loss ratio of a stream of ICMP
          packets exchanged between two hosts (which are the two measurement
          points), and the Output
          points). The output is the Round-trip round-trip loss ratio for all
          successfully exchanged packets expressed as a percentage.</t> percentage.</dd>
          </dl>
        </section>
        <section title="Change Controller"> numbered="true" toc="default">
          <name>Change Controller</name>
          <t>IETF</t>
        </section>
        <section title="Version numbered="true" toc="default">
          <name>Version (of Registry Format)"> Format)</name>
          <t>1.0</t>
        </section>
      </section>
      <section title="Metric Definition"> numbered="true" toc="default">
        <name>Metric Definition</name>
        <t>This category includes columns to prompt the entry of all necessary
        details related to the metric definition, including the RFC reference
        and values of input factors, called fixed parameters.</t> "Fixed Parameters".</t>
        <section title="Reference Definition"> numbered="true" toc="default">
          <name>Reference Definition</name>
          <t>Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
	  Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999.</t>

          <t><xref target="RFC2681"/></t>

          <t>Section 2.4 of 1999,
	  &lt;https://www.rfc-editor.org/info/rfc2681&gt;.
          <xref target="RFC2681"/> target="RFC2681"/></t>
          <t><xref target="RFC2681" sectionFormat="of" section="2.4"/> provides the reference
          definition of the singleton (single value) Round-trip round-trip delay metric.
          Section 3.4 of
          <xref target="RFC2681"/> target="RFC2681" sectionFormat="of" section="3.4"/> provides the reference
          definition expanded to cover a multi-singleton sample. Note that
          terms such as singleton "singleton" and sample "sample" are defined in Section 11 of <xref target="RFC2330"/>.</t> target="RFC2330" sectionFormat="of" section="11"/>.</t>
          <t>Note that although the <xref target="RFC2681"/> definition of
          "Round-trip-Delay round-trip delay between Src the
          Source (Src) and Dst" the Destination (Dst) 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
          Src Role will send the first packet to "Dst", the host in the Dst Role
          and will ultimately receive the corresponding return packet from "Dst" the
          Dst (when neither are is lost).</t>
          <t>Finally, note that the variable "dT" is used in <xref
          target="RFC2681"/> target="RFC2681" format="default"/> to refer to the value of Round-trip round-trip delay in
          metric definitions and methods. The variable "dT" has been re-used reused
          in other IPPM literature to refer to different quantities, quantities and
          cannot be used as a global variable name.</t>
          <t>Morton, A., "Round-trip "Round-Trip Packet Loss Metrics", RFC 6673,
          DOI 10.17487/RFC6673, August
          2012.</t>

          <t><xref 2012,
	  &lt;https://www.rfc-editor.org/info/rfc6673&gt;.
          <xref target="RFC6673"/></t>
          <t>Both delay Delay and loss Loss metrics employ a maximum waiting time for
          received packets, so the count of lost packets to total packets sent
          is the basis for the loss ratio calculation as per Section 6.1 of <xref target="RFC6673"/>.</t> target="RFC6673" sectionFormat="of" section="6.1"/>.</t>
        </section>
        <section title="Fixed Parameters">
          <t>Type-P as numbered="true" toc="default">
          <name>Fixed Parameters</name>
         <dl newline="true" spacing="normal">
          <dt>Type-P:</dt><dd><t>As defined in Section 13 of <xref target="RFC2330"/>:
          <list style="symbols">
              <t>IPv4 target="RFC2330" sectionFormat="of" section="13"/>:</t>
           <dl newline="true" spacing="normal">
            <dt>IPv4 header values: <list style="symbols">
                  <t>DSCP: set values:</dt>
	    <dd><t/>
	      <dl newline="false" spacing="compact">
              <dt>DSCP:</dt><dd>Set to 0</t>

                  <t>TTL: set 0</dd>
              <dt>TTL:</dt><dd>Set to 255</t>

                  <t>Protocol: Set 255</dd>
              <dt>Protocol:</dt><dd>Set to 01 (ICMP)</t>
                </list></t>

              <t>IPv6 (ICMP)</dd>
	      </dl>
	    </dd>

            <dt>IPv6 header values:<list style="symbols">
                  <t>DSCP: set to 0</t>

                  <t>Hop Count: set to 255</t>

                  <t>Next Header: set 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 128 decimal (ICMP)</t>

                  <t>Flow Label: set to zero</t>

                  <t>Extension Headers: none</t>
                </list></t>

              <t>ICMP (ICMP)</dd>
             <dt>Flow Label:</dt><dd>Set to 0</dd>
             <dt>Extension Headers:</dt><dd>None</dd>
	     </dl>
	    </dd>

            <dt>ICMP header values: <list style="symbols">
                  <t>Type: 8 values:</dt>
	    <dd><t/>
             <dl newline="false" spacing="compact">
             <dt>Type:</dt><dd>8 (Echo Request)</t>

                  <t>Code: 0</t>

                  <t>Checksum: the Request)</dd>
             <dt>Code:</dt><dd>0</dd>
             <dt>Checksum:</dt><dd>The checksum MUST <bcp14>MUST</bcp14> be calculated and the
                 non-zero checksum included in the header</t>

                  <t>(Identifier header</dd>
             <dt>(Identifier and Sequence Number sequence number set at Run-Time)</t>
                </list></t>

              <t>ICMP Payload <list style="symbols">
                  <t>total runtime)</dt><dd/>
	     </dl>
	    </dd>

             <dt>ICMP Payload:</dt>
	     <dd>Total of 32 bytes of random info, information, constant per test.</t>
                </list></t>
            </list></t>

          <t>Other measurement parameters:<list style="symbols">
              <t>Tmax: a test</dd>
           </dl>
         </dd>
       </dl>

      <dl newline="true" spacing="normal">
       <dt>Other measurement Parameters:</dt>
       <dd><t/>
         <dl newline="false" spacing="normal">
              <dt>Tmax:</dt>
               <dd>A loss threshold waiting time<list style="symbols">
                  <t>3.0, time with value 3.0, expressed in units of seconds, as a positive value
               of type decimal64 with fraction digits = 4 (see section 9.3
                  of <xref target="RFC6020"/>) target="RFC6020" 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 section 6 of <xref
                  target="RFC5905"/>.</t>
                </list></t>
            </list></t> target="RFC5905"
	       sectionFormat="of" section="6"/>.</dd>
	 </dl>
       </dd>
         </dl>
        </section>
      </section>
      <section title="Method numbered="true" toc="default">
        <name>Method of Measurement"> Measurement</name>
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure
        an unambiguous methods method for implementations.</t>
        <section title="Reference Method"> 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
          Type-P-Round-trip-Delay-Poisson-Stream in section 2.6 of <xref
          target="RFC2681">RFC 2681</xref> target="RFC2681"
          sectionFormat="of" section="2.6"/> (for singletons) and section 3.6 of <xref
          target="RFC2681">RFC 2681</xref>
          target="RFC2681" sectionFormat="of" section="3.6"/> (for samples)
          using the Type-P and Tmax defined
          under in the Fixed Parameters.</t> Parameters column.</t>
          <t>The reference method distinguishes between long-delayed packets
          and lost packets by implementing a maximum waiting time for packet
          arrival. Tmax is the waiting time used as the threshold to declare a
          packet lost. Lost packets SHALL <bcp14>SHALL</bcp14> be designated as having undefined
          delay,
          delay and counted for the RTLoss metric.</t>
          <t>The calculations on the delay (RTD) SHALL <bcp14>SHALL</bcp14> be performed on the
          conditional distribution, conditioned on successful packet arrival
          within Tmax. Also, when all packet delays are stored, the process
          which
          that calculates the RTD value MUST <bcp14>MUST</bcp14> enforce the Tmax threshold on
          stored values before calculations. See section 4.1 of <xref
          target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the conditional distribution to
          exclude undefined values of delay, and Section 5 of see <xref
          target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this analysis choice.</t>
          <t>The reference method requires some way to distinguish between
          different packets in a stream to establish correspondence between
          sending times and receiving times for each successfully-arriving successfully arriving
          packet. Sequence numbers or other send-order identification MUST <bcp14>MUST</bcp14> be
          retained at the Src or included with each packet to disambiguate
          packet reordering if it occurs.</t>
          <t>The measurement process will determine the sequence numbers
          applied to test packets after the Fixed and Runtime parameters Parameters are
          passed to that process. The ICMP measurement process and protocol
          will dictate the format of sequence numbers and other
          identifiers.</t>
          Identifiers.</t>
          <t>Refer to Section 4.4 of <xref target="RFC6673"/> target="RFC6673" sectionFormat="of" section="4.4"/> for an expanded
          discussion of the instruction to "send a Type-P packet back to the
          Src as quickly as possible" in Section 2.6 of <xref
          target="RFC2681">RFC 2681</xref>. Section 8 of <xref
          target="RFC6673"/> target="RFC2681" sectionFormat="of" section="2.6"/>. <xref target="RFC6673" sectionFormat="of" section="8"/> presents additional requirements which MUST that <bcp14>MUST</bcp14> be
          included in the method Method of measurement Measurement for this metric.</t>
        </section>
        <section title="Packet numbered="true" toc="default">
          <name>Packet Stream Generation"> Generation</name>
          <t>This section gives the provides details of the regarding packet traffic traffic, which is
	  used as the
          basis for measurement. In IPPM metrics, Metrics, this is called the Stream,
          and "stream";
	  this stream can easily be described by providing the list of stream
          parameters.</t>
          Parameters.</t>
          <t>The ICMP metrics use a sending discipline called "SendOnRcv" or
          Send On Receive. This is a modification of Section 3 of <xref
          target="RFC3432"/>, target="RFC3432" sectionFormat="of" section="3"/>, which prescribes the method for generating
          Periodic streams using associated parameters Parameters as defined below for
          this description:</t>

          <t><list style="hanging">
              <t hangText="incT">the
          <dl newline="false" spacing="normal">
            <dt>incT:</dt>
            <dd>The nominal duration of the inter-packet
              interval, first bit to first bit</t>

              <t hangText="dT">the bit.</dd>
            <dt>dT:</dt>
            <dd>The duration of the interval for allowed sample
              start times</t>
            </list></t> times.</dd>
          </dl>
          <t>The incT stream parameter Parameter will be specified as a Run-time
          parameter, Runtime
          Parameter, and dT is not used in SendOnRcv.</t>
          <t>A SendOnRcv sender behaves exactly like a Periodic stream
          generator while all reply packets arrive with RTD &lt; incT, and the
          inter-packet interval will be constant.</t>
          <t>If a reply packet arrives with RTD &gt;= incT, then the
          inter-packet interval for the next sending time is nominally
          RTD.</t>
          <t>If a reply packet fails to arrive within Tmax, then the
          inter-packet interval for the next sending time is nominally
          Tmax.</t>
          <t>If an immediate send on reply Send On Reply arrival is desired, then set
          incT=0.</t>
          incT&nbsp;=&nbsp;0.</t>
        </section>
        <section title="Traffic numbered="true" toc="default">
          <name>Traffic Filtering (observation) Details">
          <t>NA</t> (Observation) Details</name>
          <t>N/A</t>
        </section>
        <section title="Sampling Distribution">
          <t>NA</t> numbered="true" toc="default">
          <name>Sampling Distribution</name>
          <t>N/A</t>
        </section>
        <section title="Run-time numbered="true" toc="default">
          <name>Runtime Parameters and Data Format">
          <t>Run-time Format</name>
          <t>Runtime Parameters are input factors that must be determined,
          configured into the measurement system, and reported with the
          results for the context to be complete.</t>

          <t><list style="hanging">
              <t hangText="Src">the
          <dl newline="false" spacing="normal">
            <dt>Src:</dt>
            <dd>The IP address of the host in the Src Role
              (format ipv4-address-no-zone ipv4&nbhy;address-no-zone value for IPv4, IPv4 or
              ipv6-address-no-zone value for IPv6, IPv6; see Section 4 of <xref
              target="RFC6991"/>)</t>

              <t hangText="Dst">the target="RFC6991" sectionFormat="of" section="4"/>).</dd>
            <dt>Dst:</dt>
            <dd>The IP address of the host in the Dst Role
              (format ipv4-address-no-zone ipv4&nbhy;address-no-zone value for IPv4, IPv4 or
              ipv6-address-no-zone value for IPv6, IPv6; see section 4 of <xref
              target="RFC6991"/>)</t>

              <t hangText="incT">the target="RFC6991" sectionFormat="of" section="4"/>).</dd>
            <dt>incT:</dt>
            <dd>The nominal duration of the inter-packet
              interval, first bit to first bit, expressed in units of seconds,
              as a positive value of type decimal64 with fraction digits = 4
              (see section 9.3 of <xref target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>)
              and with a resolution of 0.0001 seconds (0.1 ms).</t>

              <t hangText="T0">a ms).</dd>
            <dt>T0:</dt>
            <dd>A time, the start of a measurement interval, interval
              (format "date-and-time" "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>. target="RFC2330" sectionFormat="of" section="6.1"/>. When T0 is "all-zeros", a start
              time is unspecified and Tf is to be interpreted as the Duration duration
              of the measurement interval. The start time is controlled
              through other means.</t>

              <t hangText="Count">The means.</dd>
            <dt>Count:</dt>
            <dd>The total count of ICMP Echo Requests to
              send, formatted as a uint16, as per section 9.2 of <xref
              target="RFC6020"/>.</t>
            </list></t>

          <t>(see target="RFC6020" sectionFormat="of" section="9.2"/>.</dd>
          </dl>
          <t>See the Packet Stream Generation section &lt;section or column&gt; for
	  additional Run-time
          parameters)</t> Runtime Parameters.</t>
        </section>
        <section title="Roles">
          <t><list style="hanging">
              <t hangText="Src">launches numbered="true" toc="default">
          <name>Roles</name>
          <dl newline="false" spacing="normal">
            <dt>Src:</dt>
            <dd>Launches each packet and waits for return
              transmissions from Dst.</t>

              <t hangText="Dst">waits the Dst.</dd>
            <dt>Dst:</dt>
            <dd>Waits for each packet from the Src and sends a
              return packet to Src.</t>
            </list></t> the Src.</dd>
          </dl>
        </section>
      </section>
      <section title="Output"> numbered="true" toc="default">
        <name>Output</name>
        <t>This category specifies all details of the Output output of measurements
        using the metric.</t>
        <section title="Type">
          <t>See subsection titles numbered="true" toc="default">
          <name>Type</name>
          <t>Latency Types are discussed in Reference Definition for Latency
          Types.</t>

          <t>LossRatio -- the subsections below.</t>
          <t>For LossRatio, the count of lost packets to total packets sent is
          the basis for the loss ratio calculation as per Section 6.1 of <xref
          target="RFC6673"/>.</t> target="RFC6673" sectionFormat="of" section="6.1"/>.</t>
        </section>
        <section title="Reference Definition"> numbered="true" toc="default">
          <name>Reference Definition</name>
          <t>For all output types ---<list style="hanging">
              <t hangText="T0">the types:</t>
          <dl newline="false" spacing="normal">
            <dt>T0:</dt>
            <dd>The start of a measurement interval, interval (format
              "date-and-time"
              "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>.</t>

              <t hangText="Tf">the target="RFC2330" sectionFormat="of" section="6.1"/>.</dd>
            <dt>Tf:</dt>
            <dd>The end of a measurement interval, interval (format
              "date-and-time"
              "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>.</t>

              <t hangText="TotalCount">the target="RFC2330" sectionFormat="of" section="6.1"/>.</dd>
            <dt>TotalCount:</dt>
            <dd>The count of packets actually sent by
              the Src to the Dst during the measurement interval.</t>
            </list></t> interval.</dd>
          </dl>
          <t>For LossRatio -- LossRatio, the count of lost packets to total packets sent
          is the basis for the loss ratio calculation as per Section 4.1 of <xref target="RFC7680"/>.</t> target="RFC7680" sectionFormat="of" section="4.1"/>.</t>
          <t>For each &lt;statistic&gt;, one of the following sub-sections
          apply:</t> subsections
          applies.</t>
          <section title="Mean"> numbered="true" toc="default">
            <name>Mean</name>
            <t>The mean SHALL <bcp14>SHALL</bcp14> be calculated using the conditional distribution
            of all packets with a finite value of Round-trip round-trip delay (undefined
            delays are excluded), excluded) -- a single value value, as follows:</t>
            <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            Section 5 of
            see <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
            analysis choice.</t>
            <t>See section 4.2.2 of <xref target="RFC6049"/> target="RFC6049" sectionFormat="of" section="4.2.2"/> for details on
            calculating this statistic, and 4.2.3 of statistic; see also <xref
            target="RFC6049"/>.</t>

            <t><list style="hanging">
                <t hangText="Mean">The target="RFC6049" sectionFormat="of" section="4.2.3"/>.</t>
            <dl newline="false" spacing="normal">
              <dt>Mean:</dt>
              <dd>The time value of the result is expressed
                in units of seconds, as a positive value of type decimal64
                with fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds 0.000000001&nbsp;seconds
                (1.0 ns), and with lossless conversion to/from the 64-bit NTP
                timestamp as per section 6 of <xref
                target="RFC5905">RFC</xref></t>
              </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            </dl>
          </section>
          <section title="Min"> numbered="true" toc="default">
            <name>Min</name>
            <t>The minimum SHALL <bcp14>SHALL</bcp14> be calculated using the conditional
            distribution of all packets with a finite value of Round-trip round-trip
            delay (undefined delays are excluded), excluded) -- a single value value, as
            follows:</t>
            <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            Section 5 of
            see <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
            analysis choice.</t>
            <t>See section 4.3.2 of <xref target="RFC6049"/> target="RFC6049" sectionFormat="of" section="4.3.2"/> for details on
            calculating this statistic, and 4.3.3 of statistic; see also <xref
            target="RFC6049"/>.</t>

            <t><list style="hanging">
                <t hangText="Min">The target="RFC6049" sectionFormat="of" section="4.3.3"/>.</t>
            <dl newline="false" spacing="normal">
              <dt>Min:</dt>
              <dd>The time value of the result is expressed in
                units of seconds, as a positive value of type decimal64 with
                fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds 0.000000001&nbsp;seconds
                (1.0 ns), and with lossless conversion to/from the 64-bit NTP
                timestamp as per section 6 of <xref
                target="RFC5905">RFC</xref></t>
              </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            </dl>
          </section>
          <section title="Max"> numbered="true" toc="default">
            <name>Max</name>
            <t>The maximum SHALL <bcp14>SHALL</bcp14> be calculated using the conditional
            distribution of all packets with a finite value of Round-trip round-trip
            delay (undefined delays are excluded), excluded) -- a single value value, as
            follows:</t>
            <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            Section 5 of
            see <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
            analysis choice.</t>
            <t>See section 4.3.2 of <xref target="RFC6049"/> target="RFC6049" sectionFormat="of" section="4.3.2"/> for a closely
            related method for calculating this statistic, and 4.3.3 of statistic; see also <xref
            target="RFC6049"/>. target="RFC6049" sectionFormat="of" section="4.3.3"/>. The formula is as follows:</t>

            <t><figure>
                <artwork><![CDATA[
            <artwork name="" type="" align="left" alt=""><![CDATA[
   Max = (FiniteDelay [j])

               such (FiniteDelay[j])
]]></artwork>

       <ul empty="true">
        <li>such that for some index, j, where 1 <= &lt;= j <= &lt;= N
               FiniteDelay[j] >= FiniteDelay[n]
        FiniteDelay[j]&nbsp;&gt;=&nbsp;FiniteDelay[n] for all n]]></artwork>
              </figure></t>

            <t><list style="hanging">
                <t hangText="Max">The n</li>
       </ul>
            <dl newline="false" spacing="normal">
              <dt>Max:</dt>
              <dd>The time value of the result is expressed in
                units of seconds, as a positive value of type decimal64 with
                fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds 0.000000001&nbsp;seconds
                (1.0 ns), and with lossless conversion to/from the 64-bit NTP
                timestamp as per section 6 of <xref
                target="RFC5905">RFC</xref></t>
              </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            </dl>
          </section>
        </section>
        <section title="Metric Units"> numbered="true" toc="default">
          <name>Metric Units</name>
          <t>The &lt;statistic&gt; of Round-trip Delay round-trip delay is expressed in
          seconds, where &lt;statistic&gt; is one of:</t>

          <t><list style="symbols">
              <t>Mean</t>

              <t>Min</t>

              <t>Max</t>
            </list></t>
          <ul spacing="normal">
            <li>Mean</li>
            <li>Min</li>
            <li>Max</li>
          </ul>
          <t>The Round-trip Loss Ratio round-trip loss ratio is expressed as a percentage of lost
          packets to total packets sent.</t>
        </section>
        <section title="Calibration">
          <t>Section 3.7.3 of <xref target="RFC7679"/> numbered="true" toc="default">
          <name>Calibration</name>
          <t><xref target="RFC7679" sectionFormat="of" section="3.7.3"/> provides a means to
          quantify the systematic and random errors of a time measurement.
          In-situ calibration
          Calibration in&nbsp;situ could be enabled with an internal loopback at
          the Source host that includes as much of the measurement system as
          possible, performs address manipulation as needed, and provides some
          form of isolation (e.g., deterministic delay) to avoid send-receive
          interface contention. Some portion of the random and systematic
          error can be characterized in this way.</t>
          <t>When a measurement controller requests a calibration measurement,
          the loopback is applied and the result is output in the same format
          as a normal measurement measurement, with an additional indication that it is a
          calibration result.</t>
          <t>Both internal loopback calibration and clock synchronization can
          be used to estimate the available accuracy of the Output Metric
          Units. For example, repeated loopback delay measurements will reveal
          the portion of the Output output result resolution which that is the result of
          system noise, noise and is thus inaccurate.</t>
        </section>
      </section>
      <section title="Administrative items">
        <t/>

        <section title="Status"> numbered="true" toc="default">
        <name>Administrative Items</name>
        <section numbered="true" toc="default">
          <name>Status</name>
          <t>Current</t>
        </section>
        <section title="Requester">
          <t>This RFC number</t> numbered="true" toc="default">
          <name>Requester</name>
          <t>RFC 8912</t>
        </section>
        <section title="Revision"> numbered="true" toc="default">
          <name>Revision</name>
          <t>1.0</t>
        </section>
        <section title="Revision Date"> numbered="true" toc="default">
          <name>Revision Date</name>
          <t>YYYY-MM-DD</t>
        </section>
      </section>
      <section title="Comments numbered="true" toc="default">
        <name>Comments and Remarks"> Remarks</name>
        <t>None</t>
      </section>
    </section>
    <section title="TCP anchor="tcp-rt-delay-loss-reg-entries" numbered="true" toc="default">
      <name>TCP Round-Trip Delay and Loss Registry Entries"> Entries</name>

      <t>This section specifies three four initial registry entries Registry Entries for the Passive
      assessment of TCP Round-Trip Delay (RTD) and another entry for the TCP
      Round-trip
      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 besides the ID, Name, Description, and Output
      Reference Method categories are the same, thus same; thus, this section proposes defines
      four closely-related registry entries. closely related Registry Entries. As a result, IANA is also asked
      to assign has
      assigned corresponding URLs to each of the four Named Metric.</t> Metrics.</t>

      <section title="Summary"> numbered="true" toc="default">
        <name>Summary</name>
        <t>This category includes multiple indexes to the registry entry: Registry Entries: the
        element ID and metric name.</t> Metric Name.</t>
        <section title="ID (Identifier)"> numbered="true" toc="default">
          <name>ID (Identifier)</name>
          <t>IANA is asked to assign different has allocated the numeric identifiers to each of Identifiers 22-26 for the four five
   Named Metrics.</t> Metric Entries in <xref target="tcp-rt-delay-loss-reg-entries"/>. See
   <xref target="name1012"/> for mapping to Names.</t>
        </section>

        <section title="Name">
          <t>RTDelay_Passive_IP-TCP_RFCXXXXsec10_Seconds_&lt;statistic&gt;</t>

          <t>where &lt;statistic&gt; is one of:</t>

          <t><list style="symbols">
              <t>Mean</t>

              <t>Min</t>

              <t>Max</t>
            </list></t>

          <t>RTDelay_Passive_IP-TCP-HS_RFCXXXXsec10_Seconds_Singleton</t> anchor="name1012" numbered="true" toc="default">
          <name>Name</name>
	  <dl spacing="normal" newline="false" indent="5">
	    <dt>22:</dt><dd>RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Mean</dd>
	    <dt>23:</dt><dd>RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Min</dd>
	    <dt>24:</dt><dd>RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Max</dd>
            <dt>25:</dt><dd>RTDelay_Passive_IP-TCP-HS_RFC8912sec10_Seconds_Singleton</dd>
	  </dl>
          <t>Note that a mid-point midpoint 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> handshake.</t>
	<dl spacing="normal" newline="false" indent="5">
          <dt>26:</dt><dd>RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count</dd>
	</dl>
        </section>
        <section title="URI"> numbered="true" toc="default">
          <name>URI</name>
          <t>URL: https://www.iana.org/ <eref target="https://www.iana.org/" /> ... &lt;name&gt;</t> &lt;Name&gt;</t>
        </section>
        <section title="Description">
          <t>RTDelay: This numbered="true" toc="default">
          <name>Description</name>
          <dl newline="false" spacing="normal">
          <dt>RTDelay:</dt><dd><t>This metric assesses the round-trip delay of TCP packets
          constituting a single connection, exchanged between two hosts. We
          consider the measurement of round-trip delay based on a single
          Observation Point (OP) <xref target="RFC7011"/> target="RFC7011" format="default"/> somewhere in the network.
          The Output output is the Round-trip round-trip delay for all successfully exchanged
          packets expressed as the &lt;statistic&gt; of their conditional
          delay distribution, where &lt;statistic&gt; is one of:</t>

          <t><list style="symbols">
              <t>Mean</t>

              <t>Min</t>

              <t>Max</t>
            </list></t>

          <t>RTLoss: This

          <ul spacing="normal">
            <li>Mean</li>
            <li>Min</li>
            <li>Max</li>
          </ul>
	</dd>

          <dt>RTLoss:</dt><dd>This metric assesses the estimated loss count for TCP
          packets constituting a single connection, exchanged between two
          hosts. We consider the measurement of round-trip delay based on a
          single Observation Point OP <xref target="RFC7011"/> target="RFC7011" format="default"/> somewhere in the
          network. The Output output is the estimated Loss Count loss count for the measurement
          interval.</t>
          interval.</dd>
          </dl>
        </section>
        <section title="Change Controller"> numbered="true" toc="default">
          <name>Change Controller</name>
          <t>IETF</t>
        </section>
        <section title="Version numbered="true" toc="default">
          <name>Version (of Registry Format)"> Format)</name>
          <t>1.0</t>
        </section>
      </section>
      <section title="Metric Definition"> numbered="true" toc="default">
        <name>Metric Definition</name>
        <t>This category includes columns to prompt the entry of all necessary
        details related to the metric definition, including the RFC reference
        and values of input factors, called fixed parameters.</t> "Fixed Parameters".</t>
        <section title="Reference Definitions">
          <t>Although there is no RFC that describes passive measurement of
          Round-Trip Delay, the parallel definition for Active measurement
          is:</t> numbered="true" toc="default">
          <name>Reference Definition</name>
          <t>Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
	  Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999.</t>

          <t><xref 1999,
	  &lt;https://www.rfc-editor.org/info/rfc2681&gt;.
          <xref target="RFC2681"/></t>
          <t>Although there is no RFC that describes Passive Measurement of
          round-trip delay, the parallel definition for Active Measurement
          is provided in <xref target="RFC2681"/>.</t>
          <t>This metric definition uses the terms singleton "singleton" and sample "sample" as
          defined in Section 11 of <xref target="RFC2330"/>. (Section 2.4 of <xref target="RFC2681"/> target="RFC2330" sectionFormat="of" section="11"/>.
 (<xref target="RFC2681" sectionFormat="of" section="2.4"/>
 provides the reference definition of the
          singleton (single value) Round-trip round-trip delay metric. Section 3.4 of <xref target="RFC2681"/> target="RFC2681" sectionFormat="of" section="3.4"/> provides the reference definition expanded
          to cover a multi-singleton sample.)</t>
          <t>With the Observation Point OP <xref target="RFC7011"/> (OP) target="RFC7011" format="default"/>
          typically located between the hosts participating in the TCP
          connection, the Round-trip Delay round-trip delay metric requires two individual
          measurements between the OP and each host, such that the Spatial
          Composition <xref target="RFC6049"/>of target="RFC6049" format="default"/>of the measurements yields a
          Round-trip Delay
          round-trip delay singleton (we are extending the composition of
          one-way subpath delays to subpath round-trip delay).</t>
          <t>Using the direction of TCP SYN transmission to anchor the
          nomenclature, host A sends the SYN SYN, and host B replies with SYN-ACK
          during connection establishment. The direction of SYN transfer is
          considered the Forward direction of transmission, from A through the OP
          to B (Reverse (the Reverse direction is B through the OP to A).</t>
          <t>Traffic filters Filters reduce the packet stream at the OP to a Qualified
          bidirectional flow of packets.</t>
          <t>In the definitions below, Corresponding Packets are transferred
          in different directions and convey a common value in a TCP header
          field that establishes correspondence (to the extent possible).
          Examples may be found in the TCP timestamp fields.</t>
          <t>For a real number, RTD_fwd, &gt;&gt; the Round-trip Delay round-trip delay in the
          Forward direction from the OP to host B at time T' is RTD_fwd &lt;&lt;
          it is REQUIRED <bcp14>REQUIRED</bcp14> that the OP observed a Qualified Packet to host B at
          wire-time
          wire&nbhy;time T', that host B received that packet and sent a
          Corresponding Packet back to host A, and the OP observed the
          Corresponding Packet at wire-time wire&nbhy;time T' + RTD_fwd.</t>
          <t>For a real number, RTD_rev, &gt;&gt; the Round-trip Delay round-trip delay in the
          Reverse direction from the OP to host A at time T'' is RTD_rev &lt;&lt;
          it is REQUIRED <bcp14>REQUIRED</bcp14> that the OP observed a Qualified Packet to host A at
          wire-time
          wire&nbhy;time T'', that host A received that packet and sent a
          Corresponding Packet back to host B, and that the OP observed the
          Corresponding Packet at wire-time wire&nbhy;time T'' + RTD_rev.</t>
          <t>Ideally, the packet sent from host B to host A in both
          definitions above SHOULD <bcp14>SHOULD</bcp14> be the same packet (or, when measuring
          RTD_rev first, the packet from host A to host B in both definitions
          should be the same).</t>
          <t>The REQUIRED <bcp14>REQUIRED</bcp14> Composition Function for a singleton of Round-trip
          Delay round-trip
          delay at time T (where T is the earliest of T' and T'' above)
          is:</t>
          <t>RTDelay = RTD_fwd + RTD_rev</t>
          <t>Note that when the OP is located at host A or host B, one of the
          terms composing RTDelay will be zero or negligible.</t>
          <t>When the Qualified and Corresponding Packets are a TCP-SYN and a
          TCP-SYN-ACK, then
          TCP&nbhy;SYN-ACK, RTD_fwd == RTD_HS_fwd.</t>
          <t>When the Qualified and Corresponding Packets are a TCP-SYN-ACK
          and a TCP-ACK, then RTD_rev == RTD_HS_rev.</t>
          <t>The REQUIRED <bcp14>REQUIRED</bcp14> Composition Function for a singleton of Round-trip
          Delay round-trip
          delay for the connection Hand Shake:</t> handshake is:</t>
          <t>RTDelay_HS = RTD_HS_fwd + RTD_HS_rev</t>
          <t>The definition of Round-trip Loss Count round-trip loss count uses the nomenclature
          developed above, based on observation of the TCP header sequence
          numbers and storing the sequence number gaps observed. Packet Losses losses
          can be inferred from:<list style="symbols">
              <t>Out-of-order segments: TCP from:</t>
          <dl newline="false" spacing="normal">
            <dt>Out-of-order segments:</dt><dd>TCP segments are transmitted with
              monotonically increasing sequence numbers, but these segments
              may be received out of order. Section 3 of <xref
              target="RFC4737"/> target="RFC4737" sectionFormat="of" section="3"/> describes the notion of "next expected"
              sequence numbers numbers, which can be adapted to TCP segments (for the
              purpose of detecting reordered packets). Observation of
              out-of-order segments indicates loss on the path prior to the
              OP,
              OP and creates a gap.</t>

              <t>Duplicate segments: Section 2 of <xref target="RFC5560"/> gap.</dd>
            <dt>Duplicate segments:</dt><dd><xref target="RFC5560" sectionFormat="of" section="2"/> defines identical packets and is suitable for evaluation of TCP
              packets to detect duplication. Observation of duplicate segments
              *without a corresponding gap* indicates loss on the path
              following the OP (because they overlap part of the delivered
              sequence numbers already observed at OP).</t>
            </list></t> the OP).</dd>
          </dl>
          <t>Each observation of an out-of-order or duplicate segment infers a
          singleton of loss, but the composition of Round-trip Loss Counts round-trip loss counts will be
          conducted over a measurement interval which that is synonymous with a
          single TCP connection.</t>
          <t>With the above observations in the Forward direction over a
          measurement interval, the count of out-of-order and duplicate
          segments is defined as RTL_fwd. Comparable observations in the
          Reverse direction are defined as RTL_rev.</t>
          <t>For a measurement interval (corresponding to a single TCP
          connection),
          connection) T0 to Tf, the REQUIRED <bcp14>REQUIRED</bcp14> Composition Function for a the
          two single-direction counts of inferred loss is:</t>
          <t>RTLoss = RTL_fwd + RTL_rev</t>
        </section>
        <section title="Fixed Parameters">
          <t/>

          <t>Traffic Filters: <list style="symbols">
              <t>IPv4 numbered="true" toc="default">
          <name>Fixed Parameters</name>
	  <dl>
	    <dt>Traffic Filters:</dt>
	    <dd><t/>
            <dl newline="true" spacing="normal">
              <dt>IPv4 header values: <list style="symbols">
                  <t>DSCP: set values:</dt>
	      <dd><t/>
	       <dl newline="false" spacing="compact">
                <dt>DSCP:</dt><dd>Set to 0</t>

                  <t>Protocol: Set 0</dd>
                <dt>Protocol:</dt><dd>Set to 06 (TCP)</t>
                </list></t>

              <t>IPv6 (TCP)</dd>
	       </dl>
	       </dd>
	    </dl>

            <dl newline="true" spacing="normal">
              <dt>IPv6 header values:<list style="symbols">
                  <t>DSCP: set to 0</t>

                  <t>Hop Count: set to 255</t>

                  <t>Next Header: set 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 6 (TCP)</t>

                  <t>Flow Label: set to zero</t>

                  <t>Extension Headers: none</t>
                </list></t>

              <t>TCP (TCP)</dd>
                <dt>Flow Label:</dt><dd>Set to 0</dd>
                <dt>Extension Headers:</dt><dd>None</dd>
	      </dl>
	      </dd>
	    </dl>

	    <dl newline="true" spacing="normal">
              <dt>TCP header values: <list style="symbols">
                  <t>Flags: ACK, values:</dt>
	      <dd><t/>
	      <dl newline="false" spacing="compact">
                <dt>Flags:</dt><dd>ACK, SYN, FIN, set as required</t>

                  <t>Timestamp required</dd>
                <dt>Timestamps Option (TSopt): Set <list style="symbols">
                      <t><xref target="RFC7323">Section 3.2 of </xref></t>
                    </list></t>
                </list></t>
            </list></t>

          <t/> (TSopt):</dt><dd>Set. &nbsp;See <xref
		target="RFC7323" sectionFormat="of" section="3.2"/></dd>
	      </dl>
	      </dd>
            </dl>
	    </dd>
	  </dl>
        </section>
      </section>
      <section title="Method numbered="true" toc="default">
        <name>Method of Measurement"> Measurement</name>
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure
        an unambiguous methods method for implementations.</t>
        <section title="Reference Methods"> numbered="true" toc="default">
          <name>Reference Methods</name>
          <t>The foundation foundational methodology for this metric is defined in Section
          4 of <xref target="RFC7323"/> target="RFC7323" sectionFormat="of" section="4"/> using the Timestamp Option Timestamps option with
          modifications that allow application at a mid-path Observation Point
          (OP) OP <xref target="RFC7011"/>. target="RFC7011" format="default"/>. Further details and applicable
          heuristics were derived from <xref target="Strowes"/> target="Strowes" format="default"/> and <xref
          target="Trammell-14"/>.</t> target="Trammell-14" format="default"/>.</t>
          <t>The Traffic Filter at the OP is configured to observe a single
          TCP connection. When the SYN, SYN-ACK, ACK SYN/SYN-ACK/ACK handshake occurs, it
          offers the first opportunity to measure both RTD_fwd (on the SYN to
          SYN-ACK pair) and RTD_rev (on the SYN-ACK to ACK pair). Label this
          singleton of RTDelay as RTDelay_HS (composed using the forward Forward and
          reverse
          Reverse measurement pair). RTDelay_HS SHALL <bcp14>SHALL</bcp14> be treated separately
          from other RTDelays on data-bearing packets and their ACKs. The
          RTDelay_HS value MAY <bcp14>MAY</bcp14> be used as a sanity check on other Composed the composed
          values of RTDelay.</t> RTDelay for payload-bearing packets.</t>
          <t>For payload bearing payload-bearing packets, the OP measures the time interval
          between observation of a packet with Sequence Number s, sequence number "s" and the
          corresponding ACK with the same Sequence sequence number. When the payload is
          transferred from host A to host B, the observed interval is
          RTD_fwd.</t>
          <t>Because many data transfers are unidirectional (say, in the
          Forward direction from host A to host B), it is necessary to use
          pure ACK packets with Timestamp (TSval) and their packets with the Timestamp value
          echo to perform a RTD_rev measurement. The time interval between
          observation of the ACK from B to A, and the corresponding packet Corresponding Packet
          with a Timestamp echo Echo Reply (TSecr) field <xref target="RFC7323"/>, is the RTD_rev.</t>
          <t>Delay Measurement Filtering Heuristics:</t>

          <t>If Data
          <ul spacing="normal">
          <li>If data payloads were transferred in both Forward and Reverse
          directions, then the Round-Trip Time Measurement Rule rule in Section 4.1
          of <xref target="RFC7323"/> target="RFC7323" sectionFormat="of" section="4.1"/> could be applied. This rule essentially
          excludes any measurement using a packet unless it makes progress in
          the transfer (advances the left edge of the send window, consistent
          with <xref target="Strowes"/>).</t>

          <t>A target="Strowes" format="default"/>).</li>
          <li>A different heuristic from <xref target="Trammell-14"/> target="Trammell-14" format="default"/> is to
          exclude any RTD_rev that is larger than previously observed values.
          This would tend to exclude Reverse measurements taken when the
          Application
          application has no data ready to send, because considerable time
          could be added to RTD_rev from this source of error.</t>

          <t>Note error.</li>
          <li>Note that the above Heuristic heuristic assumes that host A is sending
          data. Host A expecting a download would mean that this heuristic
          should be applied to RTD_fwd.</t>

          <t>The RTD_fwd.</li>
          <li>The statistic calculations to summarize the delay (RTDelay) SHALL <bcp14>SHALL</bcp14>
          be performed on the conditional distribution, conditioned on
          successful Forward and Reverse measurements which that follow the
          Heuristics.</t>
          heuristics.</li>
          </ul>
          <t>Method for Inferring Loss:</t>

          <t>The
          <ul spacing="normal">
          <li>The OP tracks sequence numbers and stores gaps for each direction
          of transmission, as well as the next-expected next expected sequence number as discussed in
          <xref target="Trammell-14"/> target="Trammell-14" format="default"/> and <xref target="RFC4737"/>. target="RFC4737" format="default"/>. Loss is
          inferred from Out-of-order out-of-order segments and Duplicate segments.</t> duplicate segments.</li>
          </ul>
          <t>Loss Measurement Filtering Heuristics:</t>

          <t><xref target="Trammell-14"/>
          <ul spacing="normal">
          <li><xref target="Trammell-14" format="default"/> adds a window of evaluation based on
          the RTDelay.</t>

          <t>Distinguish Re-ordered RTDelay.</li>
          <li>Distinguish reordered packets from OOO out-of-order segments due to
          loss, because the sequence
          number gap is filled during the same RTDelay window. Segments
          detected as re-ordered reordered according to <xref target="RFC4737"/> MUST target="RFC4737" format="default"/> <bcp14>MUST</bcp14>
          reduce the Loss Count loss count inferred from Out-of-order segments.</t>

          <t>Spurious out-of-order segments.</li>
          <li>Spurious (unneeded) retransmissions (observed as duplicates) can
          also be reduced in this way, as described in <xref
          target="Trammell-14"/>.</t> target="Trammell-14"
          format="default"/>.</li>
          </ul>
          <t>Sources of Error:</t>

          <t>The
          <ul spacing="normal">
          <li>The principal source of RTDelay error is the host processing time
          to return a packet that defines the termination of a time interval.
          The heuristics above intend to mitigate these errors by excluding
          measurements where host processing time is a significant part of
          RTD_fwd or RTD_rev.</t>

          <t>A RTD_rev.</li>
          <li>A key source of RTLoss error is observation loss, as described in
          section 3
          Section&nbsp;3 of <xref target="Trammell-14"/>.</t> target="Trammell-14"/>.</li>
          </ul>
        </section>
        <section title="Packet numbered="true" toc="default">
          <name>Packet Stream Generation">
          <t>NA</t> Generation</name>
          <t>N/A</t>
        </section>
        <section title="Traffic numbered="true" toc="default">
          <name>Traffic Filtering (observation) Details"> (Observation) Details</name>
          <t>The Fixed Parameters above give a portion of the Traffic Filter.
          Other aspects will be supplied as Run-time Runtime Parameters (below).</t>
        </section>
        <section title="Sampling Distribution"> numbered="true" toc="default">
          <name>Sampling Distribution</name>
          <t>This metric requires a complete sample of all packets that
          qualify according to the Traffic Filter criteria.</t>
        </section>
        <section title="Run-time numbered="true" toc="default">
          <name>Runtime Parameters and Data Format">
          <t>Run-time Format</name>
          <t>Runtime Parameters are input factors that must be determined,
          configured into the measurement system, and reported with the
          results for the context to be complete.</t>

          <t><list style="hanging">
              <t hangText="Src">the
          <dl newline="false" spacing="normal">
            <dt>Src:</dt>
            <dd>The IP address of the host in the host A Role
              (format ipv4-address-no-zone ipv4&nbhy;address-no-zone value for IPv4, IPv4 or
              ipv6-address-no-zone value for IPv6, IPv6; see Section 4 of <xref
              target="RFC6991"/>)</t>

              <t hangText="Dst">the target="RFC6991" sectionFormat="of" section="4"/>).</dd>
            <dt>Dst:</dt>
            <dd>The IP address of the host in the host B Role
              (format ipv4-address-no-zone ipv4&nbhy;address-no-zone value for IPv4, IPv4 or
              ipv6-address-no-zone value for IPv6, IPv6; see section 4 of <xref
              target="RFC6991"/>)</t>

              <t hangText="T0">a target="RFC6991" sectionFormat="of" section="4"/>).</dd>
            <dt>T0:</dt>
            <dd>A time, the start of a measurement interval, interval
              (format "date-and-time" "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>. target="RFC2330" sectionFormat="of" section="6.1"/>. When T0 is "all-zeros", a start
              time is unspecified and Td Tf is to be interpreted as the Duration duration
              of the measurement interval. The start time is controlled
              through other means.</t>

              <t hangText="Td">Optionally, means.</dd>
            <dt>Tf:</dt>
            <dd>Optionally, the end of a measurement interval, interval
              (format "date-and-time" "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>), target="RFC6991" sectionFormat="of" section="3"/>), or the duration (see T0). The UTC Time Zone
              is required by Section 6.1 of <xref target="RFC2330"/>. target="RFC2330" sectionFormat="of" section="6.1"/>.
              Alternatively, the end of the measurement interval MAY <bcp14>MAY</bcp14> be
              controlled by the measured connection, where the second pair of
              FIN and ACK packets exchanged between host A and host B effectively
              ends the interval.</t>

              <t hangText="TTL interval.</dd>
            <dt>TTL or Hop Limit">Set Limit:</dt>
            <dd>Set at desired value.</t>
            </list></t>

          <t/> value.</dd>
          </dl>
        </section>
        <section title="Roles">
          <t><list style="hanging">
              <t hangText="host A">launches numbered="true" toc="default">
          <name>Roles</name>
          <dl newline="false" spacing="normal">
            <dt>host A:</dt>
            <dd>Launches the SYN packet to open the
              connection, and
              connection. The role of "host A" is synonymous with an the IP address.</t>

              <t hangText="host B">replies
	    address used at host A.</dd>
            <dt>host B:</dt>
            <dd>Replies with the SYN-ACK packet to open the
              connection, and
              connection. The role of "host B" is synonymous with an the IP address.</t>
            </list></t>
	    address used at host B.</dd>
          </dl>
        </section>
      </section>
      <section title="Output"> numbered="true" toc="default">
        <name>Output</name>
        <t>This category specifies all details of the Output output of measurements
        using the metric.</t>
        <section title="Type">
          <t>See subsection titles numbered="true" toc="default">
          <name>Type</name>
          <t>RTDelay Types are discussed in Reference Definition for RTDelay
          Types.</t>

          <t>For RTLoss -- the subsections below.</t>
          <t>For RTLoss: The count of lost packets.</t>
        </section>
        <section title="Reference Definition"> numbered="true" toc="default">
          <name>Reference Definition</name>
          <t>For all output types ---<list style="hanging">
              <t hangText="T0">the types:</t>
          <dl newline="false" spacing="normal">
            <dt>T0:</dt>
            <dd>The start of a measurement interval, interval (format
              "date-and-time"
              "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of also
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>.</t>

              <t hangText="Tf">the target="RFC2330" sectionFormat="of" section="6.1"/>.</dd>
            <dt>Tf:</dt>
            <dd>The end of a measurement interval, interval (format
              "date-and-time"
              "date&nbhy;time" as specified in Section 5.6 of <xref
              target="RFC3339"/>, target="RFC3339"
              sectionFormat="of" section="5.6"/>; see also Section 3 of
              "date&nbhy;and&nbhy;time" in <xref
              target="RFC6991"/>). target="RFC6991" sectionFormat="of" section="3"/>). The UTC Time Zone is required by Section
              6.1 of <xref target="RFC2330"/>. target="RFC2330" sectionFormat="of" section="6.1"/>. The end of the measurement
              interval MAY <bcp14>MAY</bcp14> be controlled by the measured connection, where the
              second pair of FIN and ACK packets exchanged between host A and
              host B effectively ends the interval.</t>

              <t hangText="...">...</t>
            </list></t> interval.</dd>
          </dl>
          <t>For RTDelay_HS -- the Round trip RTDelay_HS: The round-trip delay of the Handshake.</t> handshake.</t>
          <t>For RTLoss -- the RTLoss: The count of lost packets.</t>
          <t>For each &lt;statistic&gt;, one of the following sub-sections
          apply:</t> subsections
          applies.</t>
          <section title="Mean"> numbered="true" toc="default">
            <name>Mean</name>
            <t>The mean SHALL <bcp14>SHALL</bcp14> be calculated using the conditional distribution
            of all packets with a finite value of Round-trip round-trip delay (undefined
            delays are excluded), excluded) -- a single value value, as follows:</t>
            <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            Section 5 of
            see <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
            analysis choice.</t>
            <t>See section 4.2.2 of <xref target="RFC6049"/> target="RFC6049" sectionFormat="of" section="4.2.2"/> for details on
            calculating this statistic, and 4.2.3 of statistic; see also <xref
            target="RFC6049"/>.</t>

            <t><list style="hanging">
                <t hangText="Mean">The target="RFC6049" sectionFormat="of" section="4.2.3"/>.</t>
            <dl newline="false" spacing="normal">
              <dt>Mean:</dt>
              <dd>The time value of the result is expressed
                in units of seconds, as a positive value of type decimal64
                with fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds 0.000000001&nbsp;seconds
                (1.0 ns), and with lossless conversion to/from the 64-bit NTP
                timestamp as per section 6 of <xref
                target="RFC5905">RFC</xref></t>
              </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            </dl>
          </section>
          <section title="Min"> numbered="true" toc="default">
            <name>Min</name>
            <t>The minimum SHALL <bcp14>SHALL</bcp14> be calculated using the conditional
            distribution of all packets with a finite value of Round-trip round-trip
            delay (undefined delays are excluded), excluded) -- a single value value, as
            follows:</t>
            <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            Section 5 of
            see <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
            analysis choice.</t>
            <t>See section 4.3.2 of <xref target="RFC6049"/> target="RFC6049" sectionFormat="of" section="4.3.2"/> for details on
            calculating this statistic, and 4.3.3 of statistic; see also <xref
            target="RFC6049"/>.</t>

            <t><list style="hanging">
                <t hangText="Min">The target="RFC6049" sectionFormat="of" section="4.3.3"/>.</t>
            <dl newline="false" spacing="normal">
              <dt>Min:</dt>
              <dd>The time value of the result is expressed in
                units of seconds, as a positive value of type decimal64 with
                fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds 0.000000001&nbsp;seconds
                (1.0 ns), and with lossless conversion to/from the 64-bit NTP
                timestamp as per section 6 of <xref
                target="RFC5905">RFC</xref></t>
              </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            </dl>
          </section>
          <section title="Max"> numbered="true" toc="default">
            <name>Max</name>
            <t>The maximum SHALL <bcp14>SHALL</bcp14> be calculated using the conditional
            distribution of all packets with a finite value of Round-trip round-trip
            delay (undefined delays are excluded), excluded) -- a single value value, as
            follows:</t>
            <t>See section 4.1 of <xref target="RFC3393"/> target="RFC3393" sectionFormat="of" section="4.1"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            Section 5 of
            see <xref target="RFC6703"/> target="RFC6703" sectionFormat="of" section="5"/> for background on this
            analysis choice.</t>
            <t>See section 4.3.2 of <xref target="RFC6049"/> target="RFC6049" sectionFormat="of" section="4.3.2"/> for a closely
            related method for calculating this statistic, and 4.3.3 of statistic; see also <xref
            target="RFC6049"/>. target="RFC6049" sectionFormat="of" section="4.3.3"/>. The formula is as follows:</t>

            <t><figure>
                <artwork><![CDATA[
            <artwork name="" type="" align="left" alt=""><![CDATA[
   Max = (FiniteDelay [j])

               such (FiniteDelay[j])
]]></artwork>

       <ul empty="true">
        <li>such that for some index, j, where 1 <= &lt;= j <= &lt;= N
               FiniteDelay[j] >= FiniteDelay[n]
        FiniteDelay[j]&nbsp;&gt;=&nbsp;FiniteDelay[n] for all n]]></artwork>
              </figure></t>

            <t><list style="hanging">
                <t hangText="Max">The n</li>
       </ul>
            <dl newline="false" spacing="normal">
              <dt>Max:</dt>
              <dd>The time value of the result is expressed in
                units of seconds, as a positive value of type decimal64 with
                fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) target="RFC6020" sectionFormat="of" section="9.3"/>) with a resolution of 0.000000001 seconds 0.000000001&nbsp;seconds
                (1.0 ns), and with lossless conversion to/from the 64-bit NTP
                timestamp as per section 6 of <xref
                target="RFC5905">RFC</xref></t>
              </list></t> target="RFC5905" sectionFormat="of" section="6"/>.</dd>
            </dl>
          </section>
        </section>
        <section title="Metric Units"> numbered="true" toc="default">
          <name>Metric Units</name>
          <t>The &lt;statistic&gt; of Round-trip Delay round-trip delay is expressed in
          seconds, where &lt;statistic&gt; is one of:</t>

          <t><list style="symbols">
              <t>Mean</t>

              <t>Min</t>

              <t>Max</t>
            </list></t>
          <ul spacing="normal">
            <li>Mean</li>
            <li>Min</li>
            <li>Max</li>
          </ul>
          <t>The Round-trip Delay round-trip delay of the Hand Shake handshake is expressed in
          seconds.</t>
          <t>The Round-trip Loss Count round-trip loss count is expressed as a number of
          packets.</t>
        </section>
        <section title="Calibration"> numbered="true" toc="default">
          <name>Calibration</name>
          <t>Passive measurements Measurements at an OP could be calibrated against an
          active measurement
          Active Measurement (with loss emulation) at host A or host B, where the
          active measurement
          Active Measurement represents the ground-truth.</t> ground truth.</t>
        </section>
      </section>
      <section title="Administrative items">
        <t/> numbered="true" toc="default">
        <name>Administrative Items</name>
        <section title="Status"> numbered="true" toc="default">
          <name>Status</name>
          <t>Current</t>
        </section>
        <section title="Requester">
          <t>This RFC number</t> numbered="true" toc="default">
          <name>Requester</name>
          <t>RFC 8912</t>
        </section>
        <section title="Revision"> numbered="true" toc="default">
          <name>Revision</name>
          <t>1.0</t>
        </section>
        <section title="Revision Date"> numbered="true" toc="default">
          <name>Revision Date</name>
          <t>YYYY-MM-DD</t>
        </section>
      </section>
      <section title="Comments numbered="true" toc="default">
        <name>Comments and Remarks">
        <t>None.</t> Remarks</name>
        <t>None</t>
      </section>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>These registry entries Registry Entries represent no known implications for Internet
      Security. Each
      security. With the exception of <xref target="RFC1035"/>, each RFC referenced above contains a Security Considerations
      section. Further, the LMAP Framework Large-scale Measurement of Broadband Performance (LMAP) framework <xref target="RFC7594"/> target="RFC7594" format="default"/> provides
      both security and privacy considerations for measurements.</t>
      <t>There are potential privacy considerations for observed traffic,
      particularly for passive metrics Passive Metrics as discussed in section 10. <xref target="tcp-rt-delay-loss-reg-entries"/>. An attacker that knows
      that its TCP connection is being measured can modify its behavior to
      skew the measurement results.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <!--     <t>Metrics previously numbered="true" toc="default">
      <name>IANA Considerations</name>

      <t>IANA has populated the Performance Metrics Registry
      defined in IETF were registered in the IANA IPPM
      METRICS REGISTRY, however this process was discontinued when the
      registry structure was found to be inadequate, and the registry was
      declared Obsolete <xref target="RFC6248"/>.</t>

      <t>The form of metric registration will finalized target="RFC8911" format="default"/> with the
      values defined in this and other
      memos, Sections&nbsp;<xref target="udp-rt-latency-loss-reg-entries" format="counter"/>
      through <xref target="tcp-rt-delay-loss-reg-entries" format="counter"/>.</t>

<!-- [IANA FLAG] Should "additional requests and IANA Action will considerations" be requested when
     changed to "additional considerations"? -->

      <t>See the initial contents IANA Considerations section of <xref target="RFC8911"
      format="default"/> for additional requests and considerations.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2330.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2681.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3339.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3393.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3432.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5560.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4737.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5357.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5481.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6049.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6673.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7011.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7323.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7679.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7680.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

<!-- draft-ietf-ippm-metric-registry (RFC 8911) -->
        <reference anchor="RFC8911" target="https://www.rfc-editor.org/info/rfc8911">
          <front>
            <title>Registry for Performance Metrics</title>
            <author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
              <organization/>
            </author>
            <author fullname="Benoit Claise" initials="B." surname="Claise">
              <organization/>
            </author>
            <author fullname="Phil Eardley" initials="P." surname="Eardley">
              <organization/>
            </author>
            <author fullname="Al Morton" initials="A." surname="Morton">
              <organization/>
            </author>
            <author fullname="Aamer Akhter" initials="A." surname="Akhter">
              <organization/>
            </author>
            <date month="September" year="2020"/>
          </front>
          <seriesInfo name="RFC" value="8911"/>
          <seriesInfo name="DOI" value="10.17487/RFC8911"/>
      </reference>

        <reference anchor="Strowes" target="https://dl.acm.org/doi/10.1145/2507771.2507781">
          <front>
            <title>Passively Measuring TCP Round-Trip Times</title>
            <author fullname="Stephen Strowes" initials="S." surname="Strowes">
              <organization></organization>
            </author>
            <date month="October" year="2013"/>
          </front>
         <refcontent>Communications of the registry are prepared.</t>-->

      <t>IANA is requested to populate The Performance Metrics Registry
      defined in <xref target="I-D.ietf-ippm-metric-registry"/> with the
      values defined in sections 4 through 10.</t>

      <t>See the IANA Considerations section of <xref
      target="I-D.ietf-ippm-metric-registry"/> ACM, Vol. 56 No. 10, Pages 57-64</refcontent>
        <seriesInfo name="DOI" value="10.1145/2507771.2507781"/>
        </reference>

        <reference anchor="Trammell-14" target="https://link.springer.com/chapter/10.1007/978-3-642-54999-1_2">
         <front>
          <title>Inline Data Integrity Signals for additional requests Passive Measurement</title>
           <author fullname="Brian Trammell" initials="B." surname="Trammell">
             <organization></organization>
           </author>
           <author fullname="David Gugelmann" initials="D." surname="Gugelmann">
             <organization></organization>
           </author>
           <author fullname="Nevil Brownlee" initials="N." surname="Brownlee">
             <organization></organization>
           </author>
            <date month="March" year="2014"/>
          </front>
         <refcontent>In: Dainotti A., Mahanti A., Uhlig S. (eds)
         Traffic Monitoring and
      considerations.</t>
    </section> Analysis.  TMA 2014.  Lecture Notes in
         Computer Science, vol 8406.  Springer, Berlin, Heidelberg</refcontent>
         <seriesInfo name="DOI" value="10.1007/978-3-642-54999-1_2"/>
        </reference>
      </references>

      <references>
        <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1242.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6390.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6703.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7594.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>

      </references>
    </references>
    <section title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors thank Brian Trammell <contact fullname="Brian Trammell"/> for suggesting the term "Run-time "Runtime
      Parameters", which led to the distinction between run-time Runtime and fixed
      parameters Fixed
      Parameters implemented in this memo, for identifying the IPFIX IP Flow
      Information Export (IPFIX) metric
      with Flow Key as an example, for suggesting the Passive TCP RTD metric Metric
      and supporting references, and for many other productive suggestions. Thanks to Peter Koch, <contact fullname="Peter Koch"/>, who provided several useful suggestions for
      disambiguating successive DNS Queries queries in the DNS Response time
      metric.</t>
      <t>The authors also acknowledge the constructive reviews and helpful
      suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, Yaakov
      Stein, <contact fullname="Barbara Stark"/>, <contact fullname="Juergen Schoenwaelder"/>, <contact fullname="Tim Carey"/>, <contact fullname="Yaakov
      Stein"/>, and participants in the LMAP working group. Working Group. Thanks to Michelle
      Cotton <contact
      fullname="Michelle Cotton"/> for her early IANA reviews, and to Amanda Barber <contact fullname="Amanda Baber"/> for answering
      questions related to the presentation of the registry Registry and accessibility
      of the complete template via URL.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.1035"?>

      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.2330"?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc include='reference.RFC.2681'?>

      <?rfc include='reference.RFC.3393'?>

      <?rfc include='reference.RFC.3339'?>

      <?rfc include='reference.RFC.3432'?>

      <?rfc include='reference.RFC.5560'?>

      <?rfc include='reference.RFC.5905'?>

      <?rfc include='reference.RFC.4737'?>

      <?rfc include='reference.RFC.5357'?>

      <?rfc include='reference.RFC.5481'?>

      <?rfc include='reference.RFC.6020'?>

      <?rfc include='reference.RFC.6049'?>

      <?rfc include='reference.RFC.6673'?>

      <?rfc include='reference.RFC.6991'?>

      <?rfc include='reference.RFC.7011'?>

      <?rfc include='reference.RFC.7323'?>

      <?rfc include='reference.RFC.7679'?>

      <?rfc include='reference.RFC.7680'?>

      <?rfc include='reference.RFC.8174'?>

      <reference anchor="I-D.ietf-ippm-metric-registry">
        <front>
          <title>Registry for Performance Metrics</title>

          <author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
            <organization/>
          </author>

          <author fullname="Benoit Claise" initials="B." surname="Claise">
            <organization/>
          </author>

          <author fullname="Phil Eardley" initials="P." surname="Eardley">
            <organization/>
          </author>

          <author fullname="Al Morton" initials="A." surname="Morton">
            <organization/>
          </author>

          <date year="2019"/>
        </front>

        <seriesInfo name="Internet Draft (work in progress)"
                    value="draft-ietf-ippm-metric-registry"/>

        <format type="TXT"/>
      </reference>

      <reference anchor="Strowes">
        <front>
          <title>Passively Measuring TCP Round Trip Times, Communications of
          the ACM, Vol. 56 No. 10, Pages 57-64</title>

          <author fullname="S.Strowes" initials="S." surname="Strowes">
            <organization>Communications of the ACM, Vol. 56 No. 10, Pages
            57-64.</organization>
          </author>

          <date month="September" year="2013"/>
        </front>
      </reference>

      <reference anchor="Trammell-14">
        <front>
          <title>Inline Data Integrity Signals for Passive Measurement, In:
          Dainotti A., Mahanti A., Uhlig S. (eds) Traffic Monitoring and
          Analysis. TMA 2014. Lecture Notes in Computer Science, vol 8406.
          Springer, Berlin, Heidelberg
          https://link.springer.com/chapter/10.1007/978-3-642-54999-1_2</title>

          <author fullname="B.Trammell, et al." initials="B."
                  surname="Trammell">
            <organization>TMA 2014 In: Dainotti A., Mahanti A., Uhlig S. (eds)
            Traffic Monitoring and Analysis. TMA 2014. Lecture Notes in
            Computer Science, vol 8406. Springer, Berlin,
            Heidelberg</organization>
          </author>

          <date month="March" year="2014"/>
        </front>
      </reference>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.1242'?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc include='reference.RFC.6390'?>

      <?rfc include='reference.RFC.6703'?>

      <?rfc include='reference.RFC.7594'?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>
    </references>
  </back>
</rfc>