<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE fc 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"?> rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" consensus="true" category="std" docName="draft-ietf-ippm-capacity-protocol-25" number="9946" ipr="trust200902" updates=""> updates="" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="Test Protocol: IP Capacity Measurement">UDP Measurement">The UDP Speed Test
    Protocol for One-way One-Way IP Capacity Metric Measurement</title>
    <seriesInfo name="RFC" value="9946"/>

<!--[rfced] *AD, per your request and the request of the WG, we have
added Al Morton as an author of this document. We have also added
the role of "editor" for Geib Ruediger. Please let us know if Al
should have an affiliation listed.

Note that when this document has completed AUTH48, we will ask you
to approve it on behalf of Al.

Current Authors (header):
   A. Morton

   L. Ciavattone
   AT&T Labs

   R. Geib, Ed.
   Deutsche Telekom
-->

<author fullname="Al Morton" initials="A." surname="Morton">
      <organization></organization>
      <address>
        <postal>
          <city></city>
          <region></region>
          <country></country>
        </postal>
        <email></email>
      </address>
    </author>

    <author fullname="Len Ciavattone" initials="L." surname="Ciavattone">
      <organization>AT&amp;T Labs</organization>
      <address>
        <postal>
          <street/>
          <city>Middletown</city>
          <region>NJ</region>

          <code/>

          <country>USA</country>
          <country>United States of America</country>
        </postal>

        <phone/>

        <facsimile/>
        <email>lenciavattone@gmail.com</email>

        <uri/>
      </address>
    </author>
    <author fullname="Ruediger Geib" initials="R." surname="Geib"> surname="Geib" role="editor">
      <organization>Deutsche Telekom</organization>
      <address>
        <postal>
          <street>Deutsche Telekom Allee 9</street>

          <!-- Reorder these if your country does things differently -->
          <code>64295</code>
          <city>Darmstadt</city>

          <region/>
          <country>Germany</country>
        </postal>
        <phone>+49 6151 5812747</phone>
        <email>Ruediger.Geib@telekom.de</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date year="2026" month="March"/>

    <area>OPS</area>
    <workgroup>ippm</workgroup>

<!--   <author fullname="Al Morton" initials="A." surname="Morton">
      <organization>AT&amp;T Labs</organization>

      <address>
        <postal>
          <street/>

          <city>Chicago</city>

          <region>IL</region>

          <code>60660</code>

          <country>USA</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>acmorton@att.com</email>

        <uri/>
      </address>
    </author> [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->

    <date year="2025"/>

    <abstract>
      <t>This document addresses the problem of protocol support for measuring
      One-Way IP Capacity metrics specified by RFC 9097. The Method of
      Measurement discussed there in that RFC requires a feedback channel from the
      receiver to control the sender's transmission rate in near-real-time. near real-time.

<!--[rfced] Does "conducting RFC 9097 and other related measurements"
mean "conducting measurements as described in RFC 9097 and other
related measurements"? Please let us know how we may update for
clarity.

Original:
   This document defines the UDP Speed Test Protocol (UDPSTP) for
   conducting RFC 9097 and other related measurements.

Perhaps:
   This document defines the UDP Speed Test Protocol (UDPSTP) for
   conducting measurements as described in RFC 9097 and other
   related measurements.
-->

      This document defines the UDP Speed Test Protocol (UDPSTP) for conducting RFC
      9097 and other related measurements.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
      <t>The numbered="true" toc="default">
      <name>Introduction</name>

<!-- [rfced] We are unsure if the quoted text was intended to be the
titles of or concepts in the RFCs listed. Since quote marks were
present, we updated the text to reflect the exact titles of the
RFCs. Please let us know if this is agreeable or if you prefer
otherwise.

Original:
   The performance community has seen development of Informative Bulk
   Transport Capacity definitions in the "Framework for Bulk Transport
   Capacity" (BTC, see <xref target="RFC3148"/>) [RFC3148]) and for "Network Capacity and Maximum
   IP-layer Capacity" <xref target="RFC5136"/>. [RFC5136]. "Model-Based Metrics for BTC" add
   experimental metric definitions and methods in [RFC8337].

Current:
   The performance community has seen the development of Informative
   Bulk Transport Capacity (BTC) definitions in "A Framework for
   Defining Empirical Bulk Transfer Capacity Metrics" [RFC3148] and
   "Defining Network Capacity" [RFC5136] as well as experimental
   metric definitions and methods in "Model-Based Metrics for Bulk
   Transport Capacity" [RFC8337].
-->
      <t>The performance community has seen the development of Informative Bulk
      Transport Capacity (BTC) definitions in "A Framework for Defining Empirical Bulk Transfer
      Capacity Metrics" <xref target="RFC3148" format="default"/> and "Defining Network Capacity" <xref target="RFC5136" format="default"/> as well as experimental metric definitions and methods in "Model-Based Metrics for Bulk Transport Capacity" <xref target="RFC8337"/>.</t> target="RFC8337" format="default"/>.</t>
      <t>This document specifies the UDP Speed Test Protocol (UDPSTP) enabling to enable
      the measurement of One-Way IP Capacity metrics as defined by <xref
      target="RFC9097"/>. target="RFC9097" format="default"/>. The Method of Measurement discussed there in that RFC deploys a
      feedback channel from the receiver to control the sender's transmission
      rate in near-real-time. Section 8.1 of near real-time. <xref target="RFC9097"/> target="RFC9097" section="8.1"/>
      specifies requirements for this method.</t>

      <t>This protocol

      <t>UDPSTP supports measurement features which that weren't available
      by TCP based
      via TCP-based speed tests and standard measurement protocols like One Way protocols, such as the One-Way
      Active Measurement Protocol (OWAMP) <xref target="RFC4656"/>, target="RFC4656" format="default"/>, Two-Way
      Active Measurement Protocol (TWAMP) <xref target="RFC5357"/> target="RFC5357" format="default"/>, and Simple
      Two-Way Active Measurement Protocol (STAMP) <xref target="RFC8762"/> target="RFC8762" format="default"/>,
      prior to this work. The controlled Bulk Capacity measurement or Speed
      Test, respectively, is based on UDP rather than TCP. The bulk
      measurement load is unidirectional. These specifications did support
      the creation of asymmetric traffic in combination with some two-way
      communication, as supported by TWAMP and STAMP, when work on UDPSTP
      started. Further, two-way communications of TWAMP and STAMP are limited
      to reflection or unidirectional load properties, but they lack support for
      closed loop feedback operation. The latter enables limiting congestion
      of a bottleneck, whose capacity is measured, to a short time range.
      Support of such a control loop is the main purpose of UDPSTP.</t>
      <t>Apart from measurement functionality, a Key Derivation Function (KDF) has
      been added providing to provide cryptographic separation of key material for
      authentication of protocol messages in a standardized and
      cryptographically secure manner. This is a secondary improvement reached
      by UDPSTP and may simplify its reuse for other measurement purposes.
      Additionally, because the protocol uses synthetic payload data and
      contains no direct user information, a decision was made to forgo
      encryption support. Secondarily, this is also expected to increase the
      number of low-end devices that can support the test methodology.</t>
      <section title="Terminology">
        <t>Downstream numbered="true" toc="default">
        <name>Terminology</name>

	<dl spacing="normal" newline="false">
        <dt>Downstream UDP Speed Test: A client initiated Test:</dt><dd>A client-initiated Network Capacity
        measurement between a server acting as sender and a client acting as
        receiver.</t>

        <t>Upstream
        receiver.</dd>
        <dt>Upstream UDP Speed Test: A client initiated Test:</dt><dd>A client-initiated Network Capacity
        measurement between a client acting as sender and a server acting as
        receiver.</t>
        receiver.</dd>
	</dl>
      </section>

      <!--  This statement may be removed by the RFC editor -->

      <section title="Requirements Language">
        <t>The numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
        14 BCP&nbsp;14 <xref target="RFC2119"/>, target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

      </section>
    </section>
    <section anchor="applicablity" title="Scope, numbered="true" toc="default">
      <name>Scope, Goals, and Applicability"> Applicability</name>
      <t>The scope of this document is to define a protocol to measure the
      Maximum IP-Layer Capacity metric Metric according to the Method of Measurement
      standardized by Section 8 of <xref target="RFC9097"/>. target="RFC9097" section="8"/>. As such, this
      document adheres to the applicability scope defined in Section 2 of
      <xref target="RFC9097"/>.</t> target="RFC9097" section="2"/>.</t>
      <t>Some aspects of this protocol and end-host configuration can lead to
      support of additional forms of measurement, such as application
      emulation enabled by creative use of the load rate adjustment algorithm.
      Per <xref target="RFC9097"/>, target="RFC9097" format="default"/>, that algorithm must not be used as a
      general Congestion Control Algorithm (CCA). Instead, the load rate
      adjustment algorithm's goal is to help determine the Maximum IP-Layer
      Capacity in the context of an infrequent, diagnostic, short-term
      measurement.</t>
      <t>The goal is to harmonize the specified IP-Layer Capacity metric Metric and
      method
      Method across the industry, and this protocol supports the
      specifications of IETF (<xref target="RFC9097"/>) (see <xref target="RFC9097" format="default"/>) and other Standards
      Development Organizations (SDO's; see, (SDOs) (see, e.g., <xref
      target="TR-471"/>).</t> target="TR-471" format="default"/>).</t>
      <t>The primary application of the protocol described here is the same as
      in Section 2 of <xref target="RFC7497"/> target="RFC7497" section="2"/> where:</t>

      <t><list style="symbols">

<blockquote>
          <t>The access portion of the network is the focus of this problem
          statement. The user typically subscribes to a service with
          bidirectional access partly described by rates in bits per
          second.</t>
        </list></t>
</blockquote>
      <t>UDPSTP is a client-based protocol. It may be applied by consumers to
      measure their own access bandwidth. Consumers may prefer an independent
      3rd party
      third-party domain hosting the measurement server for this purpose.

<!--[rfced] FYI - We made "LMAP environments" singular to agree with
"another independent third-party domain measurement server
deployment" as shown below. Please let us know of any objections.

Original:
   UDPSTP may be deployed in Large-Scale Measurement of Broadband
   Performance environments (LMAP, see <xref target="RFC7497"/>), [RFC7497]), another independent
   3rd party domain measurement server deployment.

Current:
   UDPSTP may be deployed in a Large-scale Measurement of Broadband
   Performance (LMAP) environment (see [RFC7497]), another independent
   third-party domain measurement server deployment.
-->

      UDPSTP
      may be deployed in a Large-scale Measurement of Broadband Performance (LMAP)
      environment (see <xref target="RFC7497" format="default"/>), another independent
      third-party domain measurement server deployment. A network operator may
      support operation and maintenance by UDPSTP, a typical intra-domain
      deployment.

<!--[rfced] Please clarify "benefit from trust into the results". Is
the intended meaning perhaps "benefit from trusting the results"?

Original:
   All these deployments require or benefit from trust into the
   results, which are ensured by authenticated communication.

Perhaps:
   All these deployments require or benefit from trusting the
   results, which are ensured by authenticated communication.
-->

      All these deployments require or benefit from trust into the
      results, which are ensured by authenticated communication.</t>
    </section>
    <section title="Protocol Overview"> numbered="true" toc="default">
      <name>Protocol Overview</name>
      <t>All messages defined by this document SHALL <bcp14>SHALL</bcp14> use UDP transport.</t>
      <t>The remainder of this section gives an informative overview of the
      communication protocol between two test endpoints (without expressing
      requirements or elaborating on the authentication aspects).</t>
      <t>One endpoint takes the role of server, listening for connection
      requests on a standard UDP Speed Test Protocol port number from the
      other endpoint, the client.</t>
      <t>The client requires configuration of a test direction parameter
      (upstream or downstream test, where the client performs the role of
      sender or receiver, respectively) as well as the hostname or IP
      address(es) of the server(s) in order to begin the setup and
      configuration exchanges with the server(s). By default, the client uses
      the single, standard UDPSTP port number per connection (see <xref
      target="Test-Setup"/>). target="Test-Setup" format="default"/>). If the default port number is not used, the
      client may require configuration of the control port number used by each
      server. This would be the case if multiple server instances (processes)
      operate on one or more machines.</t>
      <t>Additionally, multi-connection (multi-flow) testing is supported by
      the protocol. Each connection is independent and attempts to maximize
      its own individual traffic rate. For multi-connection tests, a single
      client process would replicate the connection setup and test procedure
      multiple times (once for each flow) to one or more server instances. The
      server instance(s) would process each connection independently, as if
      they were coming from separate clients. It shall be the responsibility
      of the client process to manage the inter-related connections: connections such as handling
      the individual connection setup successes and failures, cleaning up
      connections during a test (should some fail) as well as aggregate fail), and aggregating the
      individual test results into an overall set of performance statistics.

<!--[rfced] We don't see the terms "mcIndex", "mcCount", and "mcIdent" in
Section 6.1. Was Section 5.1 perhaps intended?

Original:
   Fields in the Setup Request (mcIndex, mcCount, and mcIdent, see
   Section 6.1) are used to both differentiate and associate the
   multiple connections that comprise a single test.

Perhaps:
   Fields in the Setup Request (i.e., mcIndex, mcCount, and mcIdent;
   see Section 5.1) are used to both differentiate and associate the
   multiple connections that comprise a single test.
-->

      Fields in the Setup Request (i.e., mcIndex, mcCount, and mcIdent; see <xref
      target="Client-Gen-Activation"/>) target="Client-Gen-Activation" format="default"/>) are used to both differentiate and
      associate the multiple connections that comprise a single test.</t>
      <t>The protocol uses UDP transport <xref target="RFC0768"/> target="RFC0768" format="default"/> with two
      connection phases (Control and Data). The As shown below, exchanges 1 and 2 (see below)
      constitute the Control phase, while exchanges 3 and 4 constitute the
      Data phase. In this document, the term message "message" and the term Protocol "Protocol
      Data Unit, Unit", or PDU (<xref target="RFC5044"/>) "PDU" <xref target="RFC5044" format="default"/>, are used
      interchangeably.</t>

      <t><list style="numbers">
      <ol spacing="normal" type="1"><li>
          <t>Test Setup Request and Response: If a server instance is
          identified with a host name that resolves to both IPv4/IPv6
          addresses, it is recommended to use the first address returned in
          the name resolution response - regardless, response, regardless of whether it's IPv4 or
          IPv6. Thus, the decision on the preferred IP address family is left
          to the name resolver's default behavior. Support for separate IPv4
          and IPv6 measurements or an IPv4 and IPv6 multi connection multi-connection setup are
          left for future improvement. The client then requests to begin a
          test by communicating its UDPSTP protocol version, intended security
          mode, and datagram size support. The server either confirms matching
          a configuration or rejects the connection request. If the request is
          accepted, the server provides a unique ephemeral port number for
          each test connection, allowing further communication. In a
          multi-connection setup, distinct UDP port numbers may be assigned
          with each Setup Response from a server instance. Distinct UDP port
          numbers will be assigned if all Setup Response messages originate
          from the same server in that case.</t>
        </li>
        <li>
          <t>Test Activation Request and Response: After having received a
          confirmation of the configuration by a server, the client composes a
          request conveying parameters such as the testing direction, the
          duration of the test interval and test sub-intervals, and various
          thresholds (for a detailed discussion, see <xref target="RFC9097"/> target="RFC9097" format="default"/>
          and <xref target="TR-471"/>). target="TR-471" format="default"/>). The server then chooses to accept,
          ignore
          ignore, or modify any of the test parameters, parameters and communicates the
          set that will be used unless the client rejects the modifications.
          Note that the client assumes that the Test Activation exchange has
          opened any co-located firewalls and network address/port translators
          for the test connection (in response to the Request packet on the
          ephemeral port number) and the traffic that follows. See <xref
          target="RFC9097"/> target="RFC9097" format="default"/> for a more detailed discussion of firewall and
          NAT related
          NAT-related features. If the Test Activation Request is rejected or
          fails, the client assumes that the firewall will close the
          address/port number pinhole entry after the firewall's configured
          idle traffic timeout.</t>
        </li>
        <li>
          <t>Test Stream Transmission and Measurement Feedback Messages:
          Testing proceeds with one endpoint sending the Load PDUs and the other
          endpoint receiving the Load PDUs and sending frequent status
          messages to communicate the status and reception conditions there. conditions. The
          data in the feedback messages, whether received from the client or
          when being sent to the client, is input to a load rate adjustment
          algorithm at the server server, which controls future sending rates at
          either end. The choice to locate the load rate adjustment algorithm
          at the server, regardless of transmission direction, means that the
          algorithm can be updated more easily at a host within the network, network
          and at a fewer number of hosts than the number of clients. Note that
          the status messages also help keep the pinhole (or mapping,
          respecitvely)
          respectively) active at on-path stateful devices. UDPSTP is at least
          partially compliant to section 3.1 of <xref target="RFC8085"/>: target="RFC8085" section="3.1"/> if
          the bottleneck is congested, but pending congestion is avoided by
          limiting the duration of that congestion to the minimum required to
          determine the bottleneck capacity.</t>
        </li>
        <li>
          <t>Stopping the Test: When the specified test duration has been
          reached, the server initiates the exchange to stop the test by
          setting a STOP indication in its outgoing Load PDUs or Status
          Feedback messages. After being received, the client acknowledges it
          by also setting a STOP indication in its outgoing Load PDUs or
          Status Feedback messages. A graceful connection termination at each
          end then follows. Since the Load PDUs and Status Feedback messages
          are used, this exchange is considered a sub-exchange of 3. 3 above. If the
          Test
          test traffic stops or the communication path fails, the client
          assumes that the firewall will close the address/port number
          combination after the firewall's configured idle traffic
          timeout.</t>
        </li>
        <li>
          <t>Both the client and server react to unexpected interruptions in
          the Control or Data phase, respectively. Watchdog timers limit the
          time a server or client will wait before stopping all traffic and
          terminating a test.</t>
        </list></t>
        </li>
      </ol>
      <t><xref target="MessageExchange"/> target="MessageExchange" format="default"/> provides an example exchange of
      control and measurement PDUs for both a downstream and upstream UDP
      Speed Tests (always client initiated):</t>

      <t><figure anchor="MessageExchange"
          title="Successful
      <figure anchor="MessageExchange">
        <name>Successful UDPSTP Message Exchanges">
          <artwork> Exchanges</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
             =========== Downstream Test ===========
+---------+                                           +---------+
| Client  |          Test Setup Request -----&gt; ----->        |  Server |
+---------+                                           +---------+
            &lt;-----
            <----- Test Setup Response (Accept)
            &lt;-----
            <----- Null Request PDU

                   Test Activation Request -----&gt;

            &lt;----- ----->

            <----- Test Activation Response (Accept)

            &lt;-----

            <----- Load PDUs

                      Status Feedback PDUs -----&gt; ----->

          After expiry of server's test duration timer...

            &lt;-----

            <----- Load PDU (TEST_ACT_STOP)

           Status Feedback PDU (TEST_ACT_STOP) -----&gt; ----->

             ============ Upstream Test ============
+---------+                                           +---------+
| Client  |          Test Setup Request -----&gt; ----->        |  Server |
+---------+                                           +---------+
            &lt;-----
            <----- Test Setup Response (Accept)
            &lt;-----
            <----- Null Request PDU

                   Test Activation Request -----&gt;

            &lt;----- ----->

            <----- Test Activation Response (Accept)

                      Load PDUs -----&gt;

            &lt;----- ----->

            <----- Status Feedback PDUs

          After expiry of server's test duration timer...

            &lt;-----

            <----- Status Feedback PDU (TEST_ACT_STOP)

                    Load PDU (TEST_ACT_STOP) -----&gt;
        </artwork>

          <postamble/>
        </figure></t> ----->]]></artwork>
      </figure>

      <section anchor="Fixed-Rate" title="Fixed-Rate Testing"> numbered="true" toc="default">
        <name>Fixed-Rate Testing</name>
        <t>A network operator who is certain of the IP-Layer Capacity to be
        validated,
        validated can execute a fixed-rate test of the IP-Layer Capacity and
        avoid activating the measurement load rate adjustment algorithm (see
        section 8.1 of
        <xref target="RFC9097"/>). target="RFC9097" section="8.1"/>). Fixed-rate testing SHOULD <bcp14>SHOULD</bcp14>
        only be activated for operation and maintenance purposes by operators
        within their local network domain.</t>
        <t>If a subscriber requests a diagnostic test from the network
        operator, this it strongly implies that there is no certainty on the
        bottleneck capacity and initiating a UDP Speed Test based on the load
        adjustment algorithm is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>. To protect against misuse, a
        client (and in general, a consumer) MUST NOT <bcp14>MUST NOT</bcp14> be able to initiate a
        fixed-rate test. A network operator may conduct a fixed-rate test for
        a stable measurement at or near the maximum determined by the load
        rate adjustment algorithm for debugging purposes. This may be valuable
        for post-installation or post-repair verification.</t>
      </section>
      <section anchor="Congestion"
               title="Handling numbered="true" toc="default">
        <name>Handling of and Safeguards required Required by Self-Induced Congestion"> Congestion</name>
        <t>Active capacity measurement requires inducing intentional
        congestion. On paths where the capacity bottleneck is not shared with
        other flows, this self-congestion will be observed as loss and/or
        delay. However, when a path is shared by other flows, the measurment measurement
        traffic can congest the bottleneck on the path and therefore can
        degrade the performance of other flows. Unrestricted use of the tool
        could lead to traffic starvation and significant issues.</t>
        <t>Measurements that generate traffic on shared paths (including WiFi Wi-Fi
        and Internet paths) need to consider the impact on other traffic.
        Fixed-rate testing operates without congestion control and therefore
        must not be executed over other operators operators' network segments. Fixed-rate
        testing therefore
        testing, therefore, is limited to paths within a domain entirely managed
        and operated section-wise and end-to-end by the network operator
        performing the measurement. When the risks of disruption to other
        flows has been considered, testing could be extended to include
        adjacent operational domains for which there is also a testing
        agreement.</t>
        <t>Concurrent tests that congest a common bottleneck will impair the
        measurement and result in additional congestion. Concurrent
        measurements to measure the maximum capacity on a single path are
        counterproductive. The number of concurrent independent tests of a
        path SHALL <bcp14>SHALL</bcp14> be limited to one, regardless of the number of flows.</t>
        <t>A load rate adjustment algorithm (see section 4.1) <xref target="LoadRateAlgoReqs"/>) is required to
        mitigate the impact of this congestion and to limit the duration of
        any congestion by terminating the test when sudden impairments or a
        loss of connectivity is detected.</t>
      </section>
</section>

<!--[rfced] Is there only one optional checksum or would it be correct
to make checksum plural in the title of Section 4 (for
consistency with "Requirements" and "Security Operations") as well
as in one sentence in Section 4?

Original:
   Section 4.  Requirements, Security Operations, and Optional Checksum

   This section adds the operational specification related to security
   and optional checksum.

Perhaps:
   Section 4.  Requirements, Security Operations, and Optional Checksums

   This section adds the operational specification related to security
   and optional checksums.
-->

    <section anchor="Security-Checksum"
             title="Requirements, numbered="true" toc="default">
      <name>Requirements, Security Operations, and Optional Checksum"> Checksum</name>
      <t>Security and checksum operation operations aren't covered by <xref
      target="RFC9097"/>, target="RFC9097" format="default"/>, which only defines the Method of Measurement. This
      section adds the operational specification related to security and
      optional checksum.

<!--[rfced] In order to avoid hyphenating "Layer-3-to-Layer-4 mapping",
may we rephrase this sentence as shown below?

Original:
   Due to the additional complexities, and loss of the direct
   Layer 3 to Layer 4 mapping of packets to datagrams, it is
   recommended that Layer 3 fragmentation be avoided.

Perhaps:
   Due to the additional complexities, and loss of the direct
   mapping of packets to datagrams between Layer 3 and Layer 4,
   it is recommended that Layer 3 fragmentation be avoided.
-->

      Due to the additional complexities, and loss of the
      direct Layer 3 to Layer 4 mapping of packets to datagrams, it is
      recommended that Layer 3 fragmentation be avoided. A simplified approach
      is to choose the default datagram size that is small enough to prevent
      fragmentation. This version of the specification does not support
      Datagram Packetization Layer Path MTU Discovery for Datagram Transports
      (DPLPMTUD) <xref target="RFC8899"/>. target="RFC8899" format="default"/>. A future version could specify how
      to support this. DPLPMTUD support will require a carefully adapted
      protocol design to ensure interoperability. Unless IP fragmentation is
      expected, and is one of the attributes being measured, the IPv4 DF Don't Fragment (DF) bit
      SHOULD
      <bcp14>SHOULD</bcp14> be set for all tests.</t>
      <t>Note: When this specification is used for network debugging, it may
      be useful for fragmentation to be under the control of the test
      administrator.</t>
      <t>This section specifies generic requirements requirements, which a measurement load
      rate adjustment algorithm conforming to this specification MUST <bcp14>MUST</bcp14>
      fulfill.</t>
      <section anchor="LoadRateAlgoReqs"
               title="Load numbered="true" toc="default">
        <name>Load Rate Adjustment Algorithm Requirements"> Requirements</name>
        <t>This document specifies an active capacity measurement method using
        a load rate adjustment algorithm. The requirements following below and
        the currently standardised standardized load rate adjustment algorithms B <xref
        target="Y.1540Amd2"/> target="Y.1540Amd2" format="default"/> and C <xref target="TR-471"/> target="TR-471" format="default"/> result from years
        of experiments and testing by the original authors. These tests were
        performed in Labs, but labs, and also in the Internet Internet, and covered a set of
        different fixed, broadband, mobile mobile, and wireless access types and
        technologies in different countries and continents.

<!--[rfced] We are having trouble parsing this sentence. Please
clarify where the feedback received by the experts and the
changes resulting from standardization were included - was it in
the measurement method or testing?

Original:
   Feedback received by performance measurement experts was included,
   as well as changes resulting from the standardisation of [RFC9097]
   (reflected also in algorithm B [Y.1540Amd2], which updates a prior
   version of this algorithm).
-->

	Feedback received
        by performance measurement experts was included, as well as changes
        resulting from the standardization of <xref target="RFC9097"/> target="RFC9097" format="default"/>
        (reflected also in algorithm B <xref target="Y.1540Amd2"/>, target="Y.1540Amd2" format="default"/>, which
        updates a prior version of this algorithm).</t>
        <t>Load rate adjustment algorithms for capacity measurement MUST <bcp14>MUST</bcp14>
        comply with the requirements specified by this section. New standard
        load rate adjustment algorithms for capacity measurement MUST <bcp14>MUST</bcp14> be
        reviewed by IETF designated experts prior to assignment of a codepoint code point
        in the IETF Test "Test Activation PDU Rate Adjustment Algorithm
        Registry.</t>

        <t>Load Algorithm"
        registry.</t>
        <t>The load rate adjustment algorithm for capacity measurement
        requirements:</t>

        <t><list style="numbers">
        requirements is as follows:</t>
        <ol spacing="normal" type="1">
	  <li>
            <t>The measurement load rate adjustment algorithm described in
            this section MUST NOT <bcp14>MUST NOT</bcp14> be used as a general Congestion Control
            Algorithm (CCA).</t> CCA.</t>
          </li>
          <li>
            <t>This specification MUST <bcp14>MUST</bcp14> only be used in the application of
            diagnostic and operations measurements.</t>

            <t>Both,
          </li>
          <li>
            <t>Both Load PDU messages and Status Feedback PDU messages MUST <bcp14>MUST</bcp14>
            contain sequence numbers.</t>
          </li>
          <li>
            <t>The nominal duration of a measurement interval at the
            Destination, parameter testIntTime (I ("I" in <xref target="RFC9097"/>), MUST target="RFC9097" format="default"/>), <bcp14>MUST</bcp14>
            default to a value of no more than 10 seconds.</t>
          </li>
          <li>
            <t>A high-speed mode to achieve high sending rates quickly MUST <bcp14>MUST</bcp14>
            reduce the measurement load below a level for which the first
            feedback interval inferred "congestion" from the measurements.
            Consecutive feedback intervals that have a supra-threshold count
            of sequence number anomalies and/or contain an upper delay
            variation threshold exception in all of the consecutive intervals, intervals
            indicate "congestion" within a test. The threshold of consecutive
            feedback intervals SHALL <bcp14>SHALL</bcp14> be configurable with a default of 3
            intervals and a maximum duration to infer congestion of 500
            ms.</t>
          </li>
          <li>
            <t>Congestion MUST <bcp14>MUST</bcp14> be indicated, indicated if the Status Feedback PDUs
            either
            indicate that either sequence number anomalies were detected OR
            the delay range was above the upper delay variation threshold.

<!--[rfced] For clarity, may we update this sentence to contain a
serial list of the threshold values as shown below?

Original:
   The RECOMMENDED threshold values are 10 for sequence number gaps
   and 30 ms for lower and 90 ms for upper delay variation thresholds,
   respectively.

Perhaps:
   The RECOMMENDED threshold values are 10 for sequence number gaps,
   30 ms for lower delay variation thresholds, and 90 ms for upper
   delay variation thresholds.
-->
	    The
            <bcp14>RECOMMENDED</bcp14> threshold values are 10 for sequence number gaps and
            30 ms for lower and 90 ms for upper delay variation thresholds,
            respectively.</t>
          </li>
          <li>
            <t>The load rate adjustment algorithm MUST <bcp14>MUST</bcp14> include a Load PDU
            timeout and a Status PDU timeout timeout, which both stop the test when
            received PDU streams cease unexpectedly.</t>
          </li>
          <li>
            <t>The Load PDU timeout SHALL <bcp14>SHALL</bcp14> be reset to the configured value
            each time a Load PDU is received. If the Load PDU timeout expires,
            the receiver SHALL <bcp14>SHALL</bcp14> be closed and no further Status PDU feedback
            sent. The default Load PDU timeout MUST <bcp14>MUST</bcp14> be no more than 1 sec.</t> second.</t>
          </li>
          <li>
            <t>The Status PDU timeout SHALL <bcp14>SHALL</bcp14> be reset to the configured value
            each time a feedback message is received. If the Status PDU
            timeout expires, the sender SHALL <bcp14>SHALL</bcp14> be closed and no further load
            packets sent. The default Status PDU timeout timeout MUST <bcp14>MUST</bcp14> be no
            more than 1 second.</t>

            <t>If
          </li>
          <li>

<!--[rfced] Should this sentence be updated to more closely match
similar wording in Section 3.1? This would also help with how
"avoid activating the measurement" relates to the sentence.

Current:
   If a network operator is certain of the IP-Layer Capacity to be
   validated, then testing MAY start with a fixed-rate test at the
   IP-Layer Capacity and avoid activating the measurement load rate
   adjustment algorithm (see section Section 8.1 of [RFC9097])

Perhaps:
   A network operator who is certain of the IP-Layer Capacity to be
   validated MAY start with a fixed-rate test at the IP-Layer Capacity
   and avoid activating the measurement load rate adjustment algorithm
   (see Section 8.1 of [RFC9097])
-->
           <t>If a network operator is certain of the IP-Layer Capacity to be
            validated, then testing <bcp14>MAY</bcp14> start with a fixed-rate test at the
            IP-Layer Capacity and avoid activating the measurement load rate
            adjustment algorithm (see <xref
            target="RFC9097"/>). target="RFC9097" section="8.1"/>). However, the stimulus for a diagnostic test
            (such as a subscriber request) strongly implies that there is no
            certainty, and the load adjustment algorithm is RECOMMENDED.</t> <bcp14>RECOMMENDED</bcp14>.</t>
          </li>
          <li>
            <t>This specification MUST <bcp14>MUST</bcp14> only be used in circumstances
            consistent with Section 10 <xref target="RFC9097" section="10" sectionFormat="bare">Security
            Considerations</xref> of <xref target="RFC9097"/> ("Security
            Considerations").</t> target="RFC9097"/>.</t>
          </li>
          <li>
            <t>Further measurement load rate adjustment algorithm requirements
            are specified by <xref target="RFC9097"/>.</t>
          </list></t> target="RFC9097" format="default"/>.</t>
          </li>
        </ol>
        <t>The following measurement load rate adjustment algorithms are
        subject to these requirements:</t>

        <t><list style="bullets">
        <ul spacing="normal">
          <li>
            <t>Measurement load rate adjustment algorithm B <xref
            target="Y.1540Amd2"/>.</t> target="Y.1540Amd2" format="default"/>.</t>
          </li>
          <li>
            <t>Measurement load rate adjustment algorithm C <xref
            target="TR-471"/>.</t>
          </list></t> target="TR-471" format="default"/>.</t>
          </li>
        </ul>
      </section>
      <section title="Parameters numbered="true" toc="default">
        <name>Parameters and Definitions"> Definitions</name>
        <t>Please refer to Section 4 of <xref target="RFC9097"/> target="RFC9097" section="4"/> for an
        overview of Parameters related to the Maximum IP-Layer Capacity Metric
        and Method. A set of error-codes error codes to support debugging are provided in
        <xref target="Error-codes"/>.</t> target="Error-codes" format="default"/>.</t>
      </section>
      <section anchor="SecurityModes" title="Security numbered="true" toc="default">
        <name>Security Mode Operations"> Operations</name>
        <t>There are two security modes of operation that perform
        authentication of the client/server messaging. The two modes are:</t>

        <t><list style="numbers">
        <ol spacing="normal" type="1">
	  <li>
            <t>A REQUIRED <bcp14>REQUIRED</bcp14> mode with authentication during the Control phase
            (Test Setup and Test Activation exchanges). This mode may be
            preferred for large-scale servers or low-end client devices where
            processing power is a consideration (see <xref
            target="applicablity"/>).</t> target="applicablity" format="default"/>).</t>
          </li>
          <li>
            <t>An OPTIONAL <bcp14>OPTIONAL</bcp14> mode with the additional authentication of the
            Status Feedback messages during the Data phase. This mode may be
            preferred for environments that desire an additional level of
            message integrity verification throughout the test (see <xref
            target="applicablity"/>).</t>
          </list></t> target="applicablity" format="default"/>).</t>
          </li>
        </ol>
        <t>The requirements discussed hereafter refer to the PDUs in sections
        5 Sections
        <xref target="Test-Setup" format="counter"/> and 6 <xref target="Test-Activation" format="counter"/> below, primarily the authMode, keyId, authUnixTime, and
        authDigest fields. The roles in this section have been generalized so
        that the requirements for the PDU sender and receiver can be re-used
        and referred to by other sections within this document. Each
        successive mode increases security, security but comes with additional
        performance impacts and complexity. The protocol is used with
        unsubstantial payload payload, and it may operate on very low-end devices.
        Offering the flexibility of various security operation modes allows
        for accommodation of available end-device resources. In general, an
        active measurement technique as the one defined by this document is
        better suited to protect the privacy of those involved in measurements
        <xref target="RFC7594"/>.</t> target="RFC7594" format="default"/>.</t>
        <t>A load rate adjustment method needs to satisfy the requirements
        listed in <xref target="LoadRateAlgoReqs"/>. target="LoadRateAlgoReqs" format="default"/>. This is necessary also to
        avoid potentially inducing congestion after there is an overload or
        loss (including loss on the control path).</t>
        <section anchor="Auth-Mode-1"
                 title="Mode numbered="true" toc="default">
          <name>Mode 1: Required Authenticated Mode"> Mode</name>
          <t>In this mode, the client and the server SHALL <bcp14>SHALL</bcp14> be configured to
          use one of a number of shared secret keys, designated via the
          numeric keyId field (see <xref target="key-management"/>). target="key-management" format="default"/>). This key
          SHALL
          <bcp14>SHALL</bcp14> be used as input to the KDF (Key Derivation Function), KDF, as
          specified in <xref target="kdf"/>, target="kdf" format="default"/>, to obtain the actual keys used by
          the client and server for authentication.</t>
          <t>During the Control phase, the sender SHALL <bcp14>SHALL</bcp14> read the current
          system (wall-clock) time and populate the authUnixTime field
          and next calculate the 32-octet HMAC-SHA-256 hash of the entire PDU
          according to section 6 of <xref target="RFC6234"/> target="RFC6234" section="6"/> (with the
          authDigest and checkSum preset to all zeroes). The authDigest field
          is filled by the result, then the packet is sent to the receiver.
          The value in the authUnixTime field is a 32-bit timestamp timestamp, and a
          10-second tolerance window (+/- 5 seconds) SHALL <bcp14>SHALL</bcp14> be used by the
          receiver to distinguish a subsequent replay of a PDU. See Table 2 of
          <xref target="TR-471"/> target="TR-471" format="default"/> for a recommended timestamp resolution.</t>
          <t>Upon reception, the receiver SHALL <bcp14>SHALL</bcp14> validate the message PDU for
          correct length, validity of authDigest, immediacy of authUnixTime,
          and expected formatting (PDU-specific fields are also checked, such
          as protocol version). Validation of the authDigest requires that it
          will
          be extracted from the PDU and the field, along with the
          checkSum field, zeroed prior to the HMAC Hashed Message Authentication Code (HMAC) calculation used for
          comparison (see section 7.2 of <xref target="RFC9145"/>).</t>

          <t>If target="RFC9145" section="7.2"/>).</t>

<!--[rfced] Should "SHOULD" be added to the latter part of this
sentence for clarity (i.e., "SHOULD NOT continue with the Control
phase and SHOULD implement silent rejection")?

Original:
   If the validation fails, the receiver SHOULD NOT continue with the
   Control phase and implement silent rejection (no further packets
   sent on the address/port pairs).

Perhaps:
   If the validation fails, the receiver SHOULD NOT continue with the
   Control phase and SHOULD implement silent rejection (no further
   packets sent on the address/port pairs).
-->

          <t>If the validation fails, the receiver <bcp14>SHOULD NOT</bcp14> continue with
          the Control phase and implement silent rejection (no further packets
          sent on the address/port pairs). The exception is when the testing
          hosts have been configured for troubleshooting Control phase
          failures and rejection messages will aid in the process.</t>
          <t>If the validation succeeds, the receiver SHALL <bcp14>SHALL</bcp14> continue with the
          Control phase and compose a successful response or a response
          indicating the error conditions identified (if any).</t>
          <t>This process SHALL <bcp14>SHALL</bcp14> be executed for the request and response in
          the Test Setup exchange, including the Null Request (<xref
          target="Test-Setup"/>) target="Test-Setup" format="default"/>) and the Test Activation exchange (<xref
          target="Test-Activation"/>).</t> target="Test-Activation" format="default"/>).</t>
        </section>
        <section anchor="Auth-Mode-2"
                 title="Mode numbered="true" toc="default">
          <name>Mode 2: Optional Authenticated Mode for Data Phase"> Phase</name>
          <t>This mode incorporates Authenticated mode 1. When using the
          optional authentication during the Data phase, authentication SHALL <bcp14>SHALL</bcp14>
          also be applied to the Status Feedback PDU (see <xref
          target="Status-PDU"/>). target="Status-PDU" format="default"/>). The client sends the Status PDU in a
          downstream test, and the server sends it in an upstream test.</t>
          <t>The Status PDU sender SHALL <bcp14>SHALL</bcp14> 1) read the current system (wall-clock)
          time and populate the authUnixTime field, then 2) calculate the
          authDigest field of the entire Status PDU (with the authDigest and
          checkSum preset to all zeroes) zeroes), and 3) send the packet to the receiver.
          The values of authUnixTime field and authDigest field are determined
          as defined by <xref target="Auth-Mode-1"/>.</t> target="Auth-Mode-1" format="default"/>.</t>
          <t>Upon reception, the receiver SHALL <bcp14>SHALL</bcp14> validate the message PDU for
          correct length, validity of authDigest, immediacy of authUnixTime,
          and expected formatting (PDU-specific fields are also checked, such
          as protocol version). Validation of the authDigest will require that
          it be extracted from the PDU and the field, along with the checkSum
          field, zeroed prior to the HMAC calculation used for comparison.</t>
          <t>If the authentication validation fails, the receiver SHALL <bcp14>SHALL</bcp14> ignore
          the message. If the watchdog timer expires (due to successive failed
          validations), the test session will prematurely terminate (no (and no
          further load traffic SHALL <bcp14>SHALL</bcp14> be transmitted). This is necessary also
          to avoid potentially inducing congestion after there is an overload
          or loss on the control path.</t>
          <t>If this optional mode has not been selected, then the keyId,
          authUnixTime, and authDigest fields of the Status PDU (see <xref
          target="Status-PDU"/>) SHALL target="Status-PDU" format="default"/>) <bcp14>SHALL</bcp14> be set to all zeroes.</t>
        </section>
      </section>
      <section anchor="key-management" title="Key Management">
        <t>Section 2 of <xref target="RFC7210"/> numbered="true" toc="default">
        <name>Key Management</name>
        <t><xref target="RFC7210" section="2"/> specifies a conceptual
        database for long-lived cryptographic keys. The key table SHALL <bcp14>SHALL</bcp14> be
        used with the REQUIRED <bcp14>REQUIRED</bcp14> authentication mode and the OPTIONAL <bcp14>OPTIONAL</bcp14>
        authentication mode (using the same key). For authentication, this key
        SHALL
        <bcp14>SHALL</bcp14> only be used as input to the KDF, as specified in <xref
        target="kdf"/>, target="kdf" format="default"/>, to derive the actual keys used for authentication
        processing. Key rotation and related management specifics are beyond
        the scope of this document.</t>
        <t>The key table SHALL <bcp14>SHALL</bcp14> have (at least) the following fields, referring
        to Section 2 of fields per <xref target="RFC7210"/>:</t>

        <t><list style="symbols"> target="RFC7210" section="2"/>:</t>

<!--[rfced] We note a variance with the terms listed in Section 4.4
versus the terms listed in RFC 7210. In RFC 7210, "Time" is uppercase
(except in "SendLifetimeStart", which contains a lowercase "t"
both in this document and RFC 7210). Should this document be
updated as follows for consistency with RFC 7210?

Original:
   *  SendLifetimeEnd

   *  AcceptLifetimeStart

   *  AcceptLifetimeEnd

Perhaps:
   *  SendLifeTimeEnd

   *  AcceptLifeTimeStart

   *  AcceptLifeTimeEnd
-->

        <ul spacing="normal">
          <li>
            <t>AdminKeyName</t>
          </li>
          <li>
            <t>LocalKeyName</t>
          </li>
          <li>
            <t>KDF</t>
          </li>
          <li>
            <t>AlgID</t>
          </li>
          <li>
            <t>Key</t>
          </li>
          <li>
            <t>SendLifetimeStart</t>
          </li>
          <li>
            <t>SendLifetimeEnd</t>
          </li>
          <li>
            <t>AcceptLifetimeStart</t>
          </li>
          <li>
            <t>AcceptLifetimeEnd</t>
          </list></t>
          </li>
        </ul>
        <t>The LocalKeyName SHALL <bcp14>SHALL</bcp14> be determined from the corresponding keyId
        field in the PDUs that follow.</t>
        <section anchor="kdf" title="Key numbered="true" toc="default">
          <name>Key Derivation Function (KDF)"> (KDF)</name>
          <t>A Key Derivation Function (KDF) is a one-way function that
          provides cryptographic separation of key material. The protocol
          requires a KDF to securely derive cryptographic keys used for
          authentication of protocol messages. The inclusion of a KDF ensures
          that keys are generated in a standardized, cryptographically secure
          manner, reducing the risk of key compromise and enabling
          interoperability across implementations. The benefits of using a KDF
          include:</t>

          <t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>Security: A KDF produces keys with high entropy, resistant to
              brute-force and related-key attacks, ensuring robust protection
              for protocol communications.</t>
            </li>
            <li>
              <t>Flexibility: The KDF allows derivation of multiple keys from
              a single shared secret, supporting distinct keys for client and
              server authentication.</t>
            </li>
            <li>
              <t>Standardization: By adhering to established cryptographic
              standards, the KDF ensures compatibility with existing security
              frameworks and facilitates implementation audits.</t>
            </li>
            <li>
              <t>Efficiency: The KDF enables efficient key generation without
              requiring additional key exchange mechanisms, minimizing
              protocol overhead.</t>
            </list></t>
            </li>
          </ul>
          <t>The KDF algorithm SHALL <bcp14>SHALL</bcp14> be a Key Derivation Function in Counter
          Mode, as specified in Section 4.1 of <xref target="NIST800-108"/>. target="NIST800-108" format="default"/>.
          This algorithm uses a counter-based mechanism to generate key
          material from a shared secret, ensuring deterministic and secure key
          derivation. The Pseudorandom Function (PRF) used in the KDF SHALL <bcp14>SHALL</bcp14> be
          HMAC-SHA-256, as defined in section 6 of <xref target="RFC6234"/>. target="RFC6234" section="6"/>.
          IANA is asked to assign &ldquo;HMAC-SHA-256&rdquo; has assigned "HMAC-SHA-256" as a new KeyTable
          KDF (<xref target="kdf-HMAC-SHA-256"/>).</t> target="kdf-HMAC-SHA-256" format="default"/>).</t>
          <t>The KDF SHALL <bcp14>SHALL</bcp14> use the following parameters:</t>

          <t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>Kin (Key-derivation (key-derivation key): The shared key as identified by the
              keyId field in the PDU.</t>
            </li>
            <li>
              <t>Label: The fixed string "UDPSTP" (without quotes), encoded as
              a UTF-8 string, used to bind the derived keys to this specific
              protocol.</t>
            </li>
            <li>
              <t>Context: The UTF-8 string representation of the authUnixTime
              field received in the very first Setup Request PDU sent from the
              client to the server. This ensures that the derived keys are
              unique to the session and tied to the temporal context of the
              initial setup exchange. The authUnixTime field serves as a nonce
              and is protected from modification by the HMAC-SHA-256 hash
              present in the authDigest field.</t>
            </li>
            <li>
              <t>r: The length of the binary encoding of the counter SHALL <bcp14>SHALL</bcp14> be
              32 (bits).</t>
            </list></t>
            </li>
          </ul>
          <t>The total derived key material SHALL <bcp14>SHALL</bcp14> be 512 bits (64 octets) in
          length. The key material SHALL <bcp14>SHALL</bcp14> be structured as follows, from most
          significant bit (MSB) to least significant bit (LSB):</t>

          <t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>Client Authentication Key: 256 bits (32 octets), octets); used for
              authenticating messages sent by the client.</t>
            </li>
            <li>
              <t>Server Authentication Key: 256 bits (32 octets), octets); used for
              authenticating messages sent by the server.</t>
            </list></t>
            </li>
          </ul>
          <t>This structure ensures that the derived keys are sufficient for
          securing authentication operations within the protocol, while
          maintaining clear separation of function and directionality.</t>
          <t>If authentication of the initial Setup Request PDU received by
          the server fails, due to an invalid authDigest field, any and all
          derived keying material and keys SHALL <bcp14>SHALL</bcp14> be considered invalid.</t>
          <t>The key material derived from the initial Setup Request PDU,
          either at the client prior to transmission or at the server upon
          reception, SHALL <bcp14>SHALL</bcp14> be used for all subsequent PDUs sent between them
          for that test connection. As such, the KDF is only required to be
          executed once by the client and server for each test connection.</t>
          <t><xref target="KDF-Example"/>, target="KDF-Example" format="default"/>, <xref target="KDFfigure"/> target="KDFfigure" format="default"/> provides
          a code snippet demonstrating derivation of the specified keys from
          key material using the OpenSSL cryptographic library. Specifically, library, specifically
          the high-level Key-Based EVP_KDF implementation (Key-Based Envelope
          Key Derivation Function, Function); see <xref target="EVP_KDF-KB"/> target="EVP_KDF-KB" format="default"/> for
          details).</t>
          details.</t>
        </section>
      </section>
      <section title="Configuration numbered="true" toc="default">

<!--[rfced] Does "that 4-tuple" refer to the source and destination
addresses and port numbers? If so, may we update the text as
shown below for clarity?

Original:
   Successful interaction with a local firewall assumes the firewall is
   configured to allow a host to open a bidirectional connection using
   unique source and destination addresses as well as port numbers by
   sending a packet using that 4-tuple for a given transport protocol.

Perhaps:
   Successful interaction with a local firewall assumes the firewall
   is configured to allow a host to open a bidirectional connection
   using unique source and destination addresses as well as port
   numbers (i.e., a 4-tuple) by sending a packet using that 4-tuple
   for a given transport protocol.
-->

        <name>Configuration of Network Functions with Stateful Filtering"> Filtering</name>
        <t>Successful interaction with a local firewall assumes the firewall
        is configured to allow a host to open a bidirectional connection using
        unique source and destination addresses as well as port numbers by
        sending a packet using that 4-tuple for a given transport protocol.
        The client's interaction with its firewall depends on this
        configuration.</t>
        <t>The firewall at the server MUST <bcp14>MUST</bcp14> be configured with an open pinhole
        for the server IP address and standard UDP port of the server. All
        messages sent by the client to the server use this standard UDP
        port.</t>
        <t>The server uses one ephemeral UDP port per test connection.
        Assuming that the firewall administration at the server does not allow
        an open UDP ephemeral port range, then the server MUST <bcp14>MUST</bcp14> send a Null
        Request to the client from the ephemeral port communicated to the
        client in the Test Setup Response. The Null Request may not reach the
        client: it may be discarded by the client's firewall.</t>
        <t>If the server firewall administration allows an open UDP ephemeral
        port range, then the Null Request is not strictly necessary. However,
        the availability of an open port range policy cannot be assumed.</t>
        <t>Network Address Translators (NATs) are expected to offer support of
        a wider set of operational configurations as compared to Firewalls. firewalls.
        Specifications covering NAT behaviour behavior, apart from the above above, are out of
        the scope of this document, as are combined implementations of NAT and
        firewalls too.</t>
      </section>
      <section anchor="Checksum" title="Optional Checksum"> numbered="true" toc="default">
        <name>Optional Checksum</name>
        <t>The protocol MUST <bcp14>MUST</bcp14> utilize the standard UDP checksum for all IPv4
        and IPv6 datagrams it sends. The purpose of this checksum is to
        protect the intended recipient as well as other recipients to whom a
        corrupted packet may be delivered. This provides:</t>

        <t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>Protection of the endpoint transport state from unnecessary
            extra state (e.g., Invalid state from rogue packets).</t>
          </li>
          <li>
            <t>Protection of the endpoint transport state from corruption of
            internal state.</t>
          </li>
          <li>
            <t>Pre-filtering by the endpoint of erroneous data, to protect the
            transport from unnecessary processing and from corruption that it
            can not
            cannot itself reject.</t>
          </li>
          <li>
            <t>Pre-filtering of incorrectly addressed destination packets,
            before responding to a source address.</t>
          </list></t>
          </li>
        </ul>
        <t>All of the PDUs exchanged between the client and server support an
        optional header checksum that covers the various fields in the UDPSTP
        PDU (excluding the Payload Content payload content of the Load PDU and, to be clear,
        also the IP- IP and UDP-header). UDP headers).

<!--[rfced] Please clarify what "one" refers to in "16-bit one's
complement Internet checksum". Is the checksum 16 bits?

Original:
   The calculation is the same as the 16-bit one's complement Internet
   checksum used in the IPv4 packet header (see section 3.1 of
   [RFC0791]).
-->
	The calculation is the same as the
        16-bit one's complement Internet checksum used in the IPv4 packet
        header (see <xref target="RFC0791"/>). target="RFC0791" section="3.1"/>). This checksum is
        intended for environments where UDP data integrity may be uncertain.
        This includes situations where the standard UDP checksum is not
        verified upon reception or a nonstandard network API is in use (things
        typically done to improve performance on low-end devices). However,
        all UDPSTP datagrams transmitted via IPv4 or IPv6 SHALL <bcp14>SHALL</bcp14> include a
        standard UDP checksum to protect other potential recipients to whom a
        corrupted packet may be delivered. In the case of a nonstandard
        network API, one option to reduce processing overhead may be to
        restrict testing to only utilize a Payload Content payload content of all zeros so
        that the UDP checksum calculation need not include it for Load
        PDUs.</t>
        <t>If a PDU sender is populating the checkSum field, it SHALL <bcp14>SHALL</bcp14> do so as
        the last step after the PDU is built in all other respects (with the
        checkSum field set to zero prior to the calculation). The PDU receiver
        SHALL
        <bcp14>SHALL</bcp14> subsequently verify the PDU checksum whenever checksum
        processing has been configured and the field is populated. If PDU
        checksum validation fails, the PDU SHALL <bcp14>SHALL</bcp14> be discarded.</t>
        <t>Because of the redundancy when used in conjunction with
        authentication, it is OPTIONAL <bcp14>OPTIONAL</bcp14> for a PDU sender to utilize the UDPSTP
        checkSum field. However, because authentication is not applicable to
        the Load PDU, the checkSum field SHALL <bcp14>SHALL</bcp14> be utilized by the sender
        whenever UDP data integrity may be uncertain (as outlined above).</t>
      </section>
    </section>
    <section anchor="Test-Setup" title="Test numbered="true" toc="default">
      <name>Test Setup Request and Response"> Response</name>
      <t>The client source IP address and the server destination IP address
      MUST NOT
      <bcp14>MUST NOT</bcp14> be a broadcast or multicast address. Any Test Setup Request or
      Test Setup Response packet containing a multicast or broadcast source or
      destination IP address MUST <bcp14>MUST</bcp14> be silently dropped and ignored.</t>
      <t>The measurement method and the protocol specified by this document
      are expected to function with unicast and anycast IP addresses.</t>
      <section anchor="Setup-Fields"
               title="Client numbered="true" toc="default">
        <name>Client Generates Test Setup Request"> Request</name>
        <t>The client SHALL <bcp14>SHALL</bcp14> begin the Control phase exchange by sending a Test
        Setup Request message to the server's (standard) control port. This
        standard UDPSTP port number is utilized for each connection of a
        multi-connection test.</t>

        <t>The

<!--[rfced] May we rephrase the text in the parentheses for clarity as
follows?

Original:
   The client SHALL simultaneously start a test initiation timer so that
   if the Control phase fails to complete Test Setup and Test Activation
   exchanges in the allocated time, the client software SHALL exit
   (close the UDP socket and indicate an error message to the user).

Perhaps:
   The client SHALL simultaneously start a test initiation timer so that
   if the Control phase fails to complete Test Setup and Test Activation
   exchanges in the allocated time, the client software SHALL exit
   (i.e., the UDP socket will close and an error message will be displayed
   to the user).
-->

        <t>The client <bcp14>SHALL</bcp14> simultaneously start a test initiation timer so
        that if the Control phase fails to complete Test Setup and Test
        Activation exchanges in the allocated time, the client software <bcp14>SHALL</bcp14>
        exit (close the UDP socket and indicate an error message to the user).
        Lost messages result in a Test Setup and Test Activation failure. The
        test initiation timer MAY <bcp14>MAY</bcp14> reuse the test termination timeout
        value.</t>
        <t>The watchdog timeout is configured as a 1-second interval to
        trigger a warning message that the received traffic has stopped. The
        test termination timeout is based on the watchdog interval, interval and
        implements a wait time of 2 additional seconds before triggering a
        non-graceful termination.</t>
        <t>Note: Any field labeled as 'reserved for alignment', in any PDU,
        MUST
        <bcp14>MUST</bcp14> be set to 0 and MUST <bcp14>MUST</bcp14> be ignored upon receipt.</t>

        <t>The

<!--[rfced] Is "by most significant byte" correct, or should it be
"with the most significant byte" as shown below?

Original:
   The UDP PDU format layout SHALL be as follows (big-endian AB,
   starting by most significant byte ending by least
   significant byte):

Perhaps:
   The UDP PDU format layout SHALL be as follows (big-endian AB,
   starting with the most significant byte and ending with
   the least significant byte):
-->

	<t>The UDP PDU format layout <bcp14>SHALL</bcp14> be as follows (big-endian AB,
        starting by most significant byte and ending by least significant
        byte):</t>

        <t><figure anchor="Setup-PDU" title="Test

<!--[rfced] FYI: For Figures 2, 4, 6, 8, and 10, we moved the bit
ruler over one space to the right so that the numbers are
positioned over the dashes rather than the plus signs to match
use in the RFC Series.
-->

        <figure anchor="Setup-PDU">
          <name>Test Setup PDU Layout">
            <artwork> Layout</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            pduId              |          protocolVer          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    mcIndex    |    mcCount    |            mcIdent            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  cmdRequest   | cmdResponse   |         maxBandwidth          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           testPort            |modifierBitmap |   authMode    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         authUnixTime                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                     authDigest (32-octet) (32 octets)                    .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     keyId     | reservedAuth1 |           checkSum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        </artwork>

            <postamble/>
          </figure></t>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>

        <t>Additional details regarding the Setup Request and Response fields
        are as follows:</t>

        <t>pduId: A

<dl spacing="normal" newline="false">
        <dt>pduId:</dt><dd>A two-octet field. IANA is asked to assign has assigned the value hex value
        0xACE1 (<xref target="pduId"/>).</t>

        <t>protocolVer: A target="pduId" format="default"/>).</dd>
        <dt>protocolVer:</dt><dd>A two-octet field, field identifying the actual protocol
        version. IANA is asked to assign only one initial value, has assigned 20 as the value (<xref
        target="protocolVer"/>).</t>

        <t>mcIndex: A target="protocolVer" format="default"/>).</dd>
        <dt>mcIndex:</dt><dd>A one-octet field, field indicating the index of a connection
        relative to all connections that make up a single test (starting at 0,
        incremented by 1 per connection). It is used to differentiate separate
        connections within a multi-connection test. An implementation may
        restrict the number of connections supported for a single test to a
        value less than or equal to 255.</t>

        <t>mcCount: A 255.</dd>
        <dt>mcCount:</dt><dd>A one-octet field, field indicating the total count of
        connections that the client is attempting to setup.</t>

        <t>mcIdent: A set up.</dd>
        <dt>mcIdent:</dt><dd>A two-octet field containing a pseudorandom non-zero
        identifier (via a Random Number Generator, source port number,...) number, ...)
        that is common to all connections of a single test. It is used by
        clients/servers to associate separate connections with a single
        multi-connection test.</t>

        <t>cmdRequest: A test.</dd>
        <dt>cmdRequest:</dt><dd>A one-octet field set to CHSR_CREQ_SETUPREQ to indicate
        a Setup request Request message. Note that CHSR_CREQ_NONE remains unused.</t>

        <t>cmdResponse: A unused.</dd>
        <dt>cmdResponse:</dt><dd>A one-octet field. All Request PDUs always have a
        Command Response of XXXX_CRSP_NONE.</t>

        <t>maxBandwith: A XXXX_CRSP_NONE.</dd>
        <dt>maxBandwith:</dt><dd>A two-octet field. A non-zero value of this field
        specifies the maximum bit rate the client expects to send or receive
        during the requested test in Mbps. The server compares this value to
        its currently available configured limit for test admission control.
        This field MAY <bcp14>MAY</bcp14> be used for rate-limiting to rate-limit the maximum rate the server
        should attempt. The maxBandwidth field's most significant bit, the
        CHSR_USDIR_BIT, is set to 0 by default to indicate "downstream" and
        has to be set to 1 to indicate "upstream".</t>

        <t>testPort: A "upstream".</dd>
        <dt>testPort:</dt><dd>A two-octet field, field set to zero in the Test Setup Request
        and populated by the server in the Test Setup Response. It contains
        the UDP ephemeral port number on the server that the client has to use
        for the Test Activation Request and subsequent Load or Status
        PDUs.</t>

        <t>modifierBitmap: A
        PDUs.</dd>
        <dt>modifierBitmap:</dt><dd><t>A one-octet field. This document only assigns two
        bits in this bitmap, bitmap; see <xref target="Setup-modifierBitmap"/>:</t>

        <t><list style="hanging">
            <t hangText="CHSR_JUMBO_STATUS">This target="Setup-modifierBitmap" format="default"/>:</t>
        <dl newline="false" spacing="normal">
          <dt>CHSR_JUMBO_STATUS:</dt>
          <dd>This bit SHALL <bcp14>SHALL</bcp14> be set by default.
            By default, sending rates up to 1 Gbps SHALL NOT <bcp14>SHALL NOT</bcp14> produce IP packet
            sizes greater than 1250 bytes (unless CHSR_TRADITIONAL_MTU is set) set),
            while rates above 1 Gbps MAY <bcp14>MAY</bcp14> produce IP packet sizes up to 9000
            bytes. When CHSR_JUMBO_STATUS is not set, all sending rates SHALL
            NOT <bcp14>SHALL
            NOT</bcp14> produce IP packet sizes greater than 1250 bytes (unless
            CHSR_TRADITIONAL_MTU is set).</t>

            <t hangText="CHSR_TRADITIONAL_MTU">This set).</dd>
          <dt>CHSR_TRADITIONAL_MTU:</dt>
          <dd>This bit SHALL NOT <bcp14>SHALL NOT</bcp14> be set by
            default. If set, sending rates up to 1 Gbps MAY <bcp14>MAY</bcp14> produce IP packets
            up to the Traditional traditional size of 1500 bytes. If CHSR_JUMBO_STATUS is
            simultaneously not set, all sending rates SHALL NOT <bcp14>SHALL NOT</bcp14> produce IP
            packets greater than the Traditional traditional size of 1500 bytes.</t>
          </list>Other bytes.</dd>
        </dl></dd></dl>
        <t>Other bit positions are left unassigned by per this document.</t>

        <t>authMode: A
	<dl spacing="normal" newline="false">
        <dt>authMode:</dt><dd><t>A one-octet field. The authMode field currently has two
        values assigned (see <xref target="Setup-authMode"/>). target="Setup-authMode" format="default"/>). One of the
        following has to be set (see <xref target="SecurityModes"/> target="SecurityModes" format="default"/> for
        requirements and details of operation): <list style="hanging">
            <t hangText="AUTHMODE_1:">Required operation):</t>
        <dl newline="false" spacing="normal">
          <dt>AUTHMODE_1:</dt>
          <dd>Required Authentication for Control
            phase</t>

            <t hangText="AUTHMODE_2:">Optional
            phase.</dd>
          <dt>AUTHMODE_2:</dt>
          <dd>Optional Authentication for Control and
            Data phase (Status Feedback PDU only)</t>
          </list>A only).</dd>
        </dl>
      </dd></dl>
        <t>A range of 60 through 63 is reserved for experimentation.
        IANA is asked to create has created a registry for the assigned values; see the
        IANA Considerations Section.</t>

        <t>authUnixTime: A
        <xref target="IANA" format="title"/> section.</t>
	<dl spacing="normal" newline="false">
        <dt>authUnixTime:</dt><dd>A 32-bit timestamp of the current system (wall-clock)
        time since the Unix Epoch on January 1st, 1, 1970 at 00:00:00 UTC.</t>

        <t>authDigest: This UTC.</dd>
        <dt>authDigest:</dt><dd>This field contains the 32-octet HMAC-SHA-256 hash that
        covers the entire PDU. Normally, the calculation is done as the last
        step of building the PDU. However, if the optional checkSum field is
        being utilized, it becomes the penultimate step and is done just prior
        to the checksum calculation (with the checkSum field set to zero).</t>

        <t>keyId: A zero).</dd>
        <dt>keyId:</dt><dd>A one-octet field carrying localKeyName, the numeric key
        identifier for a key in the shared key table.</t>

        <t>reservedAuth1: A table.</dd>
        <dt>reservedAuth1:</dt><dd>A one-octet field. This field MUST <bcp14>MUST</bcp14> be set to 0 and
        MUST
        <bcp14>MUST</bcp14> be ignored upon receipt. Consistent naming and placement of the
        reservedAuth1 field across all PDUs is done to minimize authentication
        related authentication-related
        changes in future UDPSTP versions.</t>

        <t>checkSum: A versions.</dd>
        <dt>checkSum:</dt><dd>A two-octet field, field containing an optional checksum of the
        entire PDU (see <xref target="Checksum"/> target="Checksum" format="default"/> for guidance). The
        calculation is done as the very last step of building the PDU, with
        the checkSum field set to zero.</t> zero.</dd>
	</dl>
      </section>
      <section title="Server numbered="true" toc="default">
        <name>Server Test Setup Request Processing and Response Generation"> Generation</name>
        <t>This section describes the processes at the server that are used to evaluate the
        Test Setup Request and determine the next steps. When the server
        receives the Setup Request, it SHALL <bcp14>SHALL</bcp14> first perform the following:</t>
        <t anchor="VerifyPDU">Message Verification Procedure</t>

        <t><list style="numbers"> Procedure:</t>
        <ol spacing="normal" type="1"><li>
            <t>Verify that the size of the message is correct.</t>
          </li>
          <li>
            <t>If the optional checkSum field is being utilized, validate the
            checksum as described in <xref target="Checksum"/> target="Checksum" format="default"/> and (if valid)
            zero the checkSum field prior to authentication verification.</t>
          </li>
          <li>
            <t>Verify that the authMode value is valid and appropriate (per
            <xref target="SecurityModes"/>) target="SecurityModes" format="default"/>) for the message type.</t>
          </li>
          <li>
            <t>If the authMode is valid and appropriate, authenticate the
            message by checking the authDigest as prescribed in <xref
            target="SecurityModes"/>.</t> target="SecurityModes" format="default"/>.</t>
          </li>
          <li>
            <t>If the message is authentic, check the authUnixTime field for
            acceptable immediacy.</t>
          </list>Note:
          </li>
        </ol>
        <t>Note: If any of the above checks fail, the message SHALL <bcp14>SHALL</bcp14> be
        considered invalid.</t>
        <section title="Test numbered="true" toc="default">
          <name>Test Setup Request Processing - Rejection"> -- Rejection</name>
          <t>The server SHALL <bcp14>SHALL</bcp14> then evaluate the other fields in the protocol
          header, such as the protocol version, the PDU ID (to validate the
          type of message), the maximum Bandwidth bandwidth requested for the test, and
          the modifierBitmap for use of options such as Jumbo datagram status
          and Traditional MTU (1500 bytes).</t>
          <t>If the client has selected options for:<list style="symbols"> for</t>
          <ul spacing="normal">
            <li>
              <t>Jumbo datagram support (modifierBitmap),</t>
            </li>
            <li>
              <t>Traditional MTU (modifierBitmap),</t> (modifierBitmap), and </t>
            </li>
            <li>
              <t>Authentication mode (authMode)</t>
            </list></t>
            </li>
          </ul>
          <t>that do not match the server configuration, the server MUST <bcp14>MUST</bcp14>
          reject the Setup Request.</t>
          <t>If the Setup Request must be rejected, the conditions below
          determine whether the server sends a response:</t>

          <t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>If the authDigest is valid, a Test Setup Response SHALL <bcp14>SHALL</bcp14> be
              sent back to the client with a corresponding command response Command Response
              value indicating the reason for the rejection.</t>
            </li>
            <li>
              <t>If the authDigest is invalid, then the Test Setup Request
              SHOULD
              <bcp14>SHOULD</bcp14> fail silently. The exception is for operations support:
              server administrators are permitted to send a Setup Response to
              support operations and troubleshooting.</t>
            </list></t>
            </li>
          </ul>
          <t>The additional circumstances when a server SHALL NOT <bcp14>SHALL NOT</bcp14> communicate
          the appropriate Command Response code for an error condition (fail
          silently) are when: <list style="numbers"> </t>
          <ul spacing="normal"><li>
              <t>the Setup Request PDU size is not equal to the 'struct
              controlHdrSR' size shown in <xref target="CHSR"/>,</t> target="CHSR" format="default"/>,</t>
            </li>
            <li>
              <t>the PDU ID is not 0xACE1 (Test Setup PDU), or</t>
            </li>
            <li>
              <t>a directed attack has been detected,</t>
            </list>in which case detected.</t>
            </li>
          </ul>
          <t>In this case, the server will allow setup attempts to
          terminate silently. Attack detection is beyond the scope of this
          specification.</t>
          <t>When the server replies to a Test Setup Request message, the Test
          Setup Response PDU is structured identically to the Request PDU and
          SHALL
          <bcp14>SHALL</bcp14> retain the original values received in it, with the following
          exceptions:</t>

          <t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>The cmdRequest field is set to CHSR_CREQ_SETUPRSP, indicating
              a response.</t>
            </li>
            <li>
              <t>The cmdResponse field is set to an error code (starting at
              cmdResponse 2, Bad Protocol Version, Version; see <xref
              target="Error-codes"/>), target="Error-codes" format="default"/>), indicating the reason for rejection. If
              cmdResponse indicates a bad protocol version (CHSR_CRSP_BADVER),
              the protocolVer field is also updated to indicate the current
              expected version.</t>
            </li>
            <li>
              <t>The authUnixTime field is updated to the current system
              (wall-clock) time and, after the authDigest and checkSum fields
              are zeroed, the authDigest is recalculated and inserted. If the
              optional checkSum field is being utilized, it is then also
              calculated and inserted.</t>
            </list></t>
            </li>
          </ul>
          <t>The Setup Request/Response message PDU SHALL <bcp14>SHALL</bcp14> be organized as
          follows (here and in all following code figures coded by programming
          language C <xref target="C-Prog"/>):</t>

          <t><figure anchor="CHSR" title="Test Setup PDU">
              <artwork>
&lt;CODE BEGINS&gt; target="C-Prog" format="default"/>):</t>
          <figure anchor="CHSR">
            <name>Test Setup PDU</name>
            <sourcecode name="" type="c" markers="true"><![CDATA[
//
// Control header for UDP payload of Setup Request/Response PDUs
//
struct controlHdrSR {
#define CHSR_ID 0xACE1
        uint16_t pduId; // PDU ID
#define PROTOCOL_VER 20
        uint16_t protocolVer; // Protocol version
        uint8_t mcIndex;      // Multi-connection index
        uint8_t mcCount;      // Multi-connection count
        uint16_t mcIdent;     // Multi-connection identifier
#define CHSR_CREQ_NONE     0
#define CHSR_CREQ_SETUPREQ 1   // Setup request
#define CHSR_CREQ_SETUPRSP 2   // Setup response
        uint8_t cmdRequest;    // Command request
#define CHSR_CRSP_NONE     0   // (used with request)
#define CHSR_CRSP_ACKOK    1   // Acknowledgment
#define CHSR_CRSP_BADVER   2   // Bad version
#define CHSR_CRSP_BADJS    3   // Jumbo setting mismatch
#define CHSR_CRSP_AUTHNC   4   // Auth. not configured
#define CHSR_CRSP_AUTHREQ  5   // Auth. required
#define CHSR_CRSP_AUTHINV  6   // Auth. (mode) invalid
#define CHSR_CRSP_AUTHFAIL 7   // Auth. failure
#define CHSR_CRSP_AUTHTIME 8   // Auth. time invalid
#define CHSR_CRSP_NOMAXBW  9   // Max bandwidth required
#define CHSR_CRSP_CAPEXC   10  // Capacity exceeded
#define CHSR_CRSP_BADTMTU  11  // Trad. MTU mismatch
#define CHSR_CRSP_MCINVPAR 12  // Multi-conn. invalid params
#define CHSR_CRSP_CONNFAIL 13  // Conn. allocation failure
        uint8_t cmdResponse;   // Command response
#define CHSR_USDIR_BIT 0x8000  // Upstream direction bit
        uint16_t maxBandwidth; // Required bandwidth in Mbps
        uint16_t testPort;     // Test port on server
#define CHSR_JUMBO_STATUS    0x01
#define CHSR_TRADITIONAL_MTU 0x02
        uint8_t modifierBitmap; // Modifier bitmap
        // ========== Integrity Verification ==========
#define AUTHMODE_1 1 // Mode 1: Authenticated Control
#define AUTHMODE_2 2 // Mode 2: Authenticated Control+Status
        uint8_t authMode;      // Authentication mode
        uint32_t authUnixTime; // Authentication timestamp
#define AUTH_DIGEST_LENGTH 32  // SHA-256 digest length
        uint8_t authDigest[AUTH_DIGEST_LENGTH];
        uint8_t keyId;         // Key ID in shared table
        uint8_t reservedAuth1; // (reserved for alignment)
        uint16_t checkSum;     // Header checksum
};
#define SHA256_KEY_LEN 32 // Authentication key length
&lt;CODE ENDS&gt;
        </artwork>

              <postamble/>
            </figure></t>
]]></sourcecode>
          </figure>

        </section>
        <section title="Test numbered="true" toc="default">
          <name>Test Setup Request Processing - Acceptance"> -- Acceptance</name>
          <t>If the server finds that the Setup Request matches its
          configuration and is otherwise acceptable, the server SHALL <bcp14>SHALL</bcp14> initiate
          a new connection to receive the Test Activation Request from the
          client, using a new UDP socket allocated from the UDP ephemeral port
          range. This new socket will also be used for the subsequent Load and
          Status PDUs that are part of testing (with the port number
          communicated back to the client in testPort field of the Test Setup
          Response). Then, the server SHALL <bcp14>SHALL</bcp14> start a watchdog timer (to
          terminate the new connection if the client goes silent) and SHALL <bcp14>SHALL</bcp14>
          send the Test Setup Response back to the client. The watchdog timer
          is set to the same value as on the Client client side (see <xref
          target="Test-Setup"/>)</t> target="Test-Setup" format="default"/>)</t>
          <t>When the server replies to the Test Setup Request message, the
          Test Setup Response PDU is structured identically to the Request PDU
          and SHALL <bcp14>SHALL</bcp14> retain the original values received in it, with the
          following exceptions:</t>

          <t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>The cmdRequest field is set to CHSR_CREQ_SETUPRSP, indicating
              a response.</t>
            </li>
            <li>
              <t>The cmdResponse field is set to CHSR_CRSP_ACKOK, indicating
              an acknowledgment.</t>
            </li>
            <li>
              <t>The testPort field is set to the ephemeral port number to be
              used for the client's Test Activation Request and all subsequent
              communication.</t>
            </li>
            <li>
              <t>The authUnixTime field is updated to the current system
              (wall-clock) time and, after the authDigest and checkSum fields
              are zeroed, the authDigest is recalculated and inserted. If the
              optional checkSum field is being utilized, it is then also
              calculated and inserted.</t>
            </list></t>
            </li>
          </ul>
          <t>Finally, the new UDP connection associated with the new socket
          and port are made ready, and the server awaits further communication
          there.</t>
          <t>To ensure that a server's local firewall will successfully allow
          packets received for the new ephemeral port, the server SHALL <bcp14>SHALL</bcp14>
          immediately send a Null Request with the corresponding values
          including the source and destination IP addresses and port numbers.
          The source port SHALL <bcp14>SHALL</bcp14> be the new ephemeral port. This operation
          allows communication to the server even when the server's local
          firewall prohibits open ranges of ephemeral ports. The packet is not
          expected to arrive successfully at the client if the client-side
          firewall blocks unexpected traffic. If the Null Request arrives at
          the client, it is a confirmation that further exchanges are possible
          on the new port-pair (but this is not strictly necessary). If
          received, the client SHALL <bcp14>SHALL</bcp14> follow the message verification procedure Message Verification Procedure
          listed in <xref target="VerifyPDU"/>. target="VerifyPDU" format="default"/>. Note that there is no response
          to a Null Request.</t>
          <t>The UDP PDU format layout SHALL <bcp14>SHALL</bcp14> be as follows (big-endian
          AB):</t>

          <t><figure anchor="Null-Request" title="Null
          <figure anchor="Null-Request">
            <name>Null Request PDU Layout">
              <artwork> Layout</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            pduId              |          protocolVer          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  cmdRequest   |  cmdResponse  |   reserved1   |   authMode    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         authUnixTime                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                     authDigest (32-octet) (32 octets)                    .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     keyId     | reservedAuth1 |           checkSum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        </artwork>

              <postamble/>
            </figure></t>

          <t>Authentication
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure>

          <t>The authentication and checksum checkSum fields follow the same methodology as
          with the Setup Request and Response.</t>
          <t>Additional details regarding the Null Request fields are as
          follows:</t>

          <t>pduId: IANA is asked to assign
	  <dl spacing="normal" newline="false">
          <dt>pduId:</dt><dd>IANA has assigned the value hex value 0xDEAD (<xref
          target="pduId"/>).</t>

          <t>cmdRequest: Is set target="pduId" format="default"/>).</dd>
          <dt>cmdRequest:</dt><dd>Set to CHNR_CREQ_NULLREQ indicating to indicate a Null Request
          message.</t>

          <t>cmdResponse: Is set
          message.</dd>
          <dt>cmdResponse:</dt><dd>Set to CHNR_CRSP_NONE.</t>

          <t>authMode: Same CHNR_CRSP_NONE.</dd>
          <dt>authMode:</dt><dd>Same as in <xref target="Setup-Fields"/></t>

          <t>authUnixTime: Same target="Setup-Fields" format="default"/>.</dd>
          <dt>authUnixTime:</dt><dd>Same as in <xref target="Setup-Fields"/></t>

          <t>authDigest: Same target="Setup-Fields" format="default"/>.</dd>
          <dt>authDigest:</dt><dd>Same as in <xref target="Setup-Fields"/></t>

          <t>keyId: Same target="Setup-Fields" format="default"/>.</dd>
          <dt>keyId:</dt><dd>Same as in <xref target="Setup-Fields"/></t>

          <t>reservedAuth1: Same target="Setup-Fields" format="default"/>.</dd>
          <dt>reservedAuth1:</dt><dd>Same as in <xref target="Setup-Fields"/></t>

          <t>checkSum: Same target="Setup-Fields" format="default"/>.</dd>
          <dt>checkSum:</dt><dd>Same as in <xref target="Setup-Fields"/></t> target="Setup-Fields" format="default"/>.</dd>
	  </dl>
          <t>If a Test Activation Request is not subsequently received from
          the client on the new ephemeral port number before the watchdog
          timer expires, the server SHALL <bcp14>SHALL</bcp14> close the socket and deallocate the
          associated resources.</t>
          <t>The Null Request message PDU SHALL <bcp14>SHALL</bcp14> be organized as follows:</t>

          <t><figure anchor="CHNR" title="Null Request PDU">
              <artwork>
&lt;CODE BEGINS&gt;
          <figure anchor="CHNR">
            <name>Null Request PDU</name>
            <sourcecode name="" type="c" markers="true"><![CDATA[
//
// Control header for UDP payload of Null Request PDU
//
struct controlHdrNR {
#define CHNR_ID 0xDEAD
        uint16_t pduId;       // PDU ID
        uint16_t protocolVer; // Protocol version
#define CHNR_CREQ_NONE    0
#define CHNR_CREQ_NULLREQ 1  // Null request
        uint8_t cmdRequest;  // Command request
#define CHNR_CRSP_NONE 0     // (used with request)
        uint8_t cmdResponse; // Command response
        uint8_t reserved1;   // (reserved for alignment)
        // ========== Integrity Verification ==========
        uint8_t authMode;      // Authentication mode
        uint32_t authUnixTime; // Authentication timestamp
        uint8_t authDigest[AUTH_DIGEST_LENGTH];
        uint8_t keyId;         // Key ID in shared table
        uint8_t reservedAuth1; // (reserved for alignment)
        uint16_t checkSum;     // Header checksum
};
&lt;CODE ENDS&gt;
        </artwork>

              <postamble/>
            </figure></t>
]]></sourcecode>
          </figure>

        </section>
      </section>
      <section title="Setup numbered="true" toc="default">
        <name>Setup Response Processing at the Client"> Client</name>
        <t>When the client receives the Test Setup Response message, it SHALL <bcp14>SHALL</bcp14>
        first follow the Message Verification Procedure listed in <xref
        target="VerifyPDU"/>.</t>

        <t>It SHALL target="VerifyPDU" format="default"/>.</t>
        <t>The client <bcp14>SHALL</bcp14> then proceed to evaluate the other fields in the protocol,
        beginning with the protocol version, PDU ID (to validate the type of
        message), and cmdRequest for the role of the message, which MUST <bcp14>MUST</bcp14> be
        Test Setup Response, CHSR_CREQ_SETUPRSP, as indicated by <xref
        target="CHSR"/>.</t> target="CHSR" format="default"/>.</t>
        <t>If the cmdResponse value indicates an error (values greater than
        CHSR_CRSP_ACKOK)
        CHSR_CRSP_ACKOK), the client SHALL <bcp14>SHALL</bcp14> display/report a relevant message to
        the user or management process and exit. If the client receives a
        Command Response code that is not equal to one of the codes defined,
        the client MUST <bcp14>MUST</bcp14> terminate the connection and terminate operation of
        the current Setup Request. If the Command Server Response code value
        indicates success (CHSR_CRSP_ACKOK), the client SHALL <bcp14>SHALL</bcp14> compose a Test
        Activation Request with all the test parameters it desires, such as
        the test direction, the test duration, etc., as described below.</t>
      </section>
    </section>
    <section anchor="Test-Activation"
             title="Test numbered="true" toc="default">
      <name>Test Activation Request and Response"> Response</name>
      <t>This section is divided according to the sending and processing of
      the client, server, client and server and again at the client.</t>
      <section anchor="Client-Gen-Activation"
               title="Client numbered="true" toc="default">
        <name>Client Generates Test Activation Request"> Request</name>
        <t>Upon a successful setup exchange, the client SHALL <bcp14>SHALL</bcp14> compose and send
        the Test Activation Request to the UDP port number the server
        communicated in the Test Setup Response (the new ephemeral port, and
        not the standard UDPSTP port).</t>

        <t>The UDP PDU format layout is as follows (big-endian AB):</t>

        <t><figure anchor="Test-Activation-PDU"
            title="Test
        <figure anchor="Test-Activation-PDU">
          <name>Test Activation PDU Layout">
            <artwork> Layout</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          txInterval1                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          udpPayload1                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          burstSize1                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          txInterval2                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          udpPayload2                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          burstSize2                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           udpAddon2                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            pduId              |          protocolVer          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  cmdRequest   | cmdResponse   |           lowThresh           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         upperThresh           |           trialInt            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         testIntTime           |   reserved1   |   dscpEcn     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         srIndexConf           |  useOwDelVar  |highSpeedDelta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         slowAdjThresh         |         seqErrThresh          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ignoreOooDup  |modifierBitmap |  rateAdjAlgo  |   reserved2   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                      srStruct (28 octets)                     .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        subIntPeriod           |          reserved3            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          reserved4            |   reserved5   |   authMode    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         authUnixTime                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                     authDigest (32-octet) (32 octets)                    .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     keyId     | reservedAuth1 |           checkSum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        </artwork>

            <postamble/>
          </figure></t>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>

        <t>Fields are populated based on default values or command-line
        options. Authentication The authentication and checksum checkSum fields follow the same
        methodology as with the Setup Request and Response.</t>

        <t>pduId: IANA is asked to assign
	<dl spacing="normal" newline="false">
        <dt>pduId:</dt><dd>IANA has assigned the value hex value 0xACE2 (<xref
        target="pduId"/>).</t>

        <t>cmdRequest: Is set target="pduId" format="default"/>).</dd>
        <dt>cmdRequest:</dt><dd>Set to CHTA_CREQ_TESTACTUS to indicate an upstream
        test activation or alternatively to CHTA_CREQ_TESTACTDS to indicate a
        downstream test activation. Note that CHTA_CREQ_NONE remains unused.
        See <xref target="ActivationCmdRequest"/>.</t>

        <t>cmdResponse: three target="ActivationCmdRequest" format="default"/>.</dd>
        <dt>cmdResponse:</dt><dd>Three CHTA_CRSP_&lt;Indication&gt; values are defined, defined;
        see <xref target="CHTA"/>.</t>

        <t>lowThresh: target="CHTA" format="default"/>.</dd>

<!--[rfced] Section 6.1. We are having trouble parsing these
sentences. May we update as shown below for clarity?

Original:
 lowThresh: Two two-octet field, low threshold Low on the Range of
    Round Trip Time variation, RTT (Range is values above minimum RTT, see
    also Table 3 <xref target="TR-471"/>.</t>

        <t>upperThresh: [TR-471].

 upperThresh: Two two-octet field, upper threshold Low on the Range
    of Round Trip Time variation, RTT (Range is values above minimum
    RTT, see also Table 3 of [TR-471].

Perhaps:
 lowThresh: Two two-octet fields, with a low threshold Low on the
    Range of Round-Trip Time (RTT) variation (the range is composed
    of values above the minimum RTT); see also Table 3 [TR-471].

 upperThresh: Two two-octet fields, with an upper threshold Low on
    the Range of RTT variation (the range is composed of values above
    the minimum RTT); see also Table 3 of [TR-471].
-->

        <dt>lowThresh:</dt><dd>Two two-octet fields, low threshold Low on the Range of
        Round Trip Time variation, RTT (Range is values above minimum RTT); see
        also Table 3 <xref target="TR-471"/>.</t>

        <t>trialInt: A target="TR-471" format="default"/>.</dd>
        <dt>upperThresh:</dt><dd>Two two-octet field, fields, upper threshold Low on the Range
        of Round Trip Time variation, RTT (Range is values above minimum RTT);
        see also Table 3 of <xref target="TR-471" format="default"/>.</dd>
        <dt>trialInt:</dt><dd>A two-octet field indicating the Status Feedback / trial
        interval [ms]. The test interval Delta_t is subdivided into a number
        of sub-intervals dt, and each sub-interval is further divided into a
        number of trial intervals (see <xref target="TR-471"/>). target="TR-471" format="default"/>). Starts by 1
        and is continuously incremented during a single test interval
        (testIntTime).</t>

        <t>testIntTime: A
        (testIntTime).</dd>
        <dt>testIntTime:</dt><dd>A two-octet field. Duration of the test (either
        downlink or uplink) with search algorithm in use, which serves as the
        maximum duration of the search process in Seconds seconds (see also
        TestInterval,
        TestInterval in Table 3 of <xref target="TR-471"/>.</t>

        <t>dscpEcn: Diffserv target="TR-471" format="default"/>).</dd>
        <dt>dscpEcn:</dt><dd>Diffserv code point and ECN field, field; see also the DSCP field
        specified by <xref target="TR-471"/>. target="TR-471" format="default"/>. This specification does not
        provide an ECN-capable transport, therefore transport; therefore, the sender SHALL <bcp14>SHALL</bcp14> set the
        ECN field to not_ECT.</t>

        <t>srIndexConf: A not_ECT.</dd>
        <dt>srIndexConf:</dt><dd>A two-octet field. The requested Configured Sending
        Rate Table index, used in a Test Activation Request, of the desired
        fixed or starting sending rate (depending on whether
        CHTA_SRIDX_ISSTART is cleared or set set, respectively). Because a value of
        zero is a valid fixed or starting sending rate index, the field SHALL <bcp14>SHALL</bcp14>
        be set to its maximum (CHTA_SRIDX_DEF) when requesting the default
        behavior of the server (starting with the selected load rate adjustment
        algorithm at its minimum/zero index). This SHALL <bcp14>SHALL</bcp14> be equivalent to
        setting srIndexConf to zero and setting the CHTA_SRIDX_ISSTART
        bit.</t>

        <t>useOwDelVar: A
        bit.</dd>
        <dt>useOwDelVar:</dt><dd>A one-octet field. Boolean, default True (False: Use (if False, use
        RTT=round-trip delay variation in the load rate adjustment
        algorithm)(True: EnableIPDV
        algorithm; if True, use EnableIPDV, which uses one-way delay variation for the
        load rate adjustment algorithm), see algorithm). See EnableIPDV in Table 1 of <xref
        target="TR-471"/>.</t>

        <t>highSpeedDelta: A target="TR-471" format="default"/>.</dd>
        <dt>highSpeedDelta:</dt><dd>A one-octet field, field; see Appendix A of <xref
        target="RFC9097"/>.</t>

        <t>slowAdjThresh, seqErrThresh: Two section="A" target="RFC9097" format="default"/>.</dd>
        <dt>slowAdjThresh and seqErrThresh:</dt><dd>Two two-octet fields, fields; see Appendix
        <xref section="A" target="RFC9097" format="default"/>.</dd>

<!--[rfced] We note that the following sentences refer to "Loss,
Reordering, and Duplication" differently. Please let us know
if/how they can be updated for consistency (perhaps "loss,
out-of-order, and duplicate totals").

In addition, under Section 6.1, we updated "default true" to "default
is True".  Please let us know if this changes the intended meaning.

Original:
(Section 6.1)
   ignoreOooDup: ... When False, Loss, Reordering and
      Duplication are all counted as sequence number errors, default
      True (see also Table 3 of [TR-471]).

(Section 7.1)
   lpduSeqNo:  A four-octet field indicating the Load PDU sequence
      number (starting at 1).  Used to determine loss, out-of-order,
      and duplicates.

(Section 7.2)
   seqErrLoss/seqErrOoo/seqErrDup:  Three four-octet fields,
         populated by the Loss, out-of-order, and duplicate totals.

Perhaps:
(Section 6.1)
   ignoreOooDup: ... When False, loss, out-of-order, and
      duplicate totals are all counted as sequence number errors;
      default is True (see also Table 3 of <xref target="RFC9097"/>.</t>

        <t>ignoreOooDup: [TR-471]).

(Section 7.1)
   lpduSeqNo:  A four-octet field indicating the Load PDU sequence
      number (starting at 1).  Used to determine loss, out-of-order,
      and duplicate totals.

(Section 7.2)
   seqErrLoss/seqErrOoo/seqErrDup:  Three four-octet fields
         populated by the loss, out-of-order, and duplicate totals.
-->

        <dt>ignoreOooDup:</dt><dd>A one-octet field. Ignore out of oder out-of-order duplicates,
        Boolean. When True True, only Loss counts toward received packet sequence
        number errors. When False, Loss, Reordering Reordering, and Duplication are all
        counted as sequence number errors, errors; default True (see also Table 3 of
        <xref target="TR-471"/>).</t>

        <t>modifierBitmap: A target="TR-471" format="default"/>).</dd>
        <dt>modifierBitmap:</dt><dd><t>A one-octet field. This document only assigns two
        bits in this bitmap, bitmap; see <xref
        target="Activation-modifierBitmap"/>:</t>

        <t><list style="hanging">
            <t hangText="CHTA_SRIDX_ISSTART">Treat target="Activation-modifierBitmap" format="default"/>:</t>
        <dl newline="false" spacing="normal">
          <dt>CHTA_SRIDX_ISSTART:</dt>
          <dd>Treat srIndexConf as the starting
            sending rate to be used by the load rate adjustment algorithm</t>

            <t hangText="CHTA_RAND_PAYLOAD">Randomize algorithm.</dd>
          <dt>CHTA_RAND_PAYLOAD:</dt>
          <dd>Randomize the Payload Content payload content
            beyond the Load PDU header</t>
          </list>Other header.</dd>
        </dl></dd></dl>
        <t>Other bit positions are left unassigned by per this document.</t>

        <t>rateAdjAlgo: A
	<dl spacing="normal" newline="false">
        <dt>rateAdjAlgo:</dt><dd>A one-octet field. The applied Load Rate Adjustment
        Algorithm, load rate adjustment
        algorithm; see <xref target="Activation-rateAdjAlgo"/>.</t>

        <t>Sending target="Activation-rateAdjAlgo" format="default"/>.</dd>
	</dl>
        <t>srStruct: Sending Rate structure (srStruct), used structure. Used by the server in a Test
        Activation Response for an upstream test, test to communicate the (initial)
        Load PDU transmission parameters the client SHALL <bcp14>SHALL</bcp14> use. For a Test
        Activation Request or a downstream test, this structure SHALL <bcp14>SHALL</bcp14> be
        zeroed. Two sets of periodic transmission parameters are available,
        allowing for dual independent transmitters (to support a high degree
        of rate granularity). The fields are defined as follows:</t>

        <t>txInterval1
	<dl spacing="normal" newline="false">
        <dt>txInterval1 and txInterval2: Two txInterval2:</dt><dd>Two four-octet fields indicating the
        load rate transmit interval in [us]. A 100 us granularity is
        recommended for optimal rate selection.</t>

        <t>udpPayload1 selection.</dd>
        <dt>udpPayload1 and udpPayload2: Two udpPayload2:</dt><dd>Two four-octet fields indicating the
        UDP payload at load rate in [byte].</t>

        <t>burstSize1 [byte].</dd>
        <dt>burstSize1 and burstSize2: Two burstSize2:</dt><dd>Two four-octet fields indicating the
        burst size at load rate by a dimensionless number (of datagrams).</t>

        <t>udpAddon2: A datagrams).</dd>
        <dt>udpAddon2:</dt><dd>A four-octet field indicating the size of a single Load
        PDU to be sent at the end of the txInterval2 send sequence, even when
        udpPayload2 or burstSize2 are zero and result in no transmission of
        their own.</t>

        <t>subIntPeriod: A own.</dd>
        <dt>subIntPeriod:</dt><dd>A two-octet field. Test Sub-interval period in [ms], [ms]
        (see also Table 3 of <xref target="TR-471"/>). target="TR-471" format="default"/>). Trials with
        subIntPeriod in a range of 100 to 10000 [ms] resulted in a default
        value of 1000 ms.</t>

        <t>authMode: Same ms.</dd>
        <dt>authMode:</dt><dd>Same as in <xref target="Setup-Fields"/></t>

        <t>authUnixTime: Same target="Setup-Fields" format="default"/>.</dd>
        <dt>authUnixTime:</dt><dd>Same as in <xref target="Setup-Fields"/></t>

        <t>authDigest: Same target="Setup-Fields" format="default"/>.</dd>
        <dt>authDigest:</dt><dd>Same as in <xref target="Setup-Fields"/></t>

        <t>keyId: Same target="Setup-Fields" format="default"/>.</dd>
        <dt>keyId:</dt><dd>Same as in <xref target="Setup-Fields"/></t>

        <t>reservedAuth1: Same target="Setup-Fields" format="default"/>.</dd>
        <dt>reservedAuth1:</dt><dd>Same as in <xref target="Setup-Fields"/></t>

        <t>checkSum: Same target="Setup-Fields" format="default"/>.</dd>
        <dt>checkSum:</dt><dd>Same as in <xref target="Setup-Fields"/></t> target="Setup-Fields" format="default"/>.</dd>
	</dl>
        <t>The Test Activation Request/Response message PDU (as well as the
        included Sending Rate structure) SHALL <bcp14>SHALL</bcp14> be organized as follows:</t>

        <t><figure anchor="CHTA" title="Test Activation PDU">
            <artwork>
&lt;CODE BEGINS&gt;
        <figure anchor="CHTA">
          <name>Test Activation PDU</name>
          <sourcecode name="" type="c" markers="true"><![CDATA[
//
// Sending rate structure for a single row of transmission parameters
//
struct sendingRate {
        uint32_t txInterval1; // Transmit interval (us)
        uint32_t udpPayload1; // UDP payload (bytes)
        uint32_t burstSize1;  // UDP burst size per interval
        uint32_t txInterval2; // Transmit interval (us)
        uint32_t udpPayload2; // UDP payload (bytes)
        uint32_t burstSize2;  // UDP burst size per interval
        uint32_t udpAddon2;   // UDP add-on (bytes)
};
//
// Control header for UDP payload of Test Act. Request/Response PDUs
//
struct controlHdrTA {
#define CHTA_ID 0xACE2
        uint16_t pduId;       // PDU ID
        uint16_t protocolVer; // Protocol version
#define CHTA_CREQ_NONE      0
#define CHTA_CREQ_TESTACTUS 1 // Test activation upstream
#define CHTA_CREQ_TESTACTDS 2 // Test activation downstream
        uint8_t cmdRequest;   // Command request
#define CHTA_CRSP_NONE     0  // (used with request)
#define CHTA_CRSP_ACKOK    1  // Acknowledgment
#define CHTA_CRSP_BADPARAM 2  // Bad/invalid test params
        uint8_t cmdResponse;  // Command response
        uint16_t lowThresh;   // Low delay variation threshold (ms)
        uint16_t upperThresh; // Upper delay variation threshold (ms)
        uint16_t trialInt;    // Status Feedback/trial interval (ms)
        uint16_t testIntTime; // Test interval time (sec)
        uint8_t reserved1;    // (reserved for alignment)
        uint8_t dscpEcn;      // DiffServ Diffserv and ECN field for testing
#define CHTA_SRIDX_DEF UINT16_MAX // Request default server search
        uint16_t srIndexConf; // Configured Sending Rate Table index
        uint8_t useOwDelVar;  // Use one-way delay, not RTT (BOOL)
        uint8_t highSpeedDelta; // High-speed row adjustment delta
        uint16_t slowAdjThresh; // Slow rate adjustment threshold
        uint16_t seqErrThresh;  // Sequence error threshold
        uint8_t ignoreOooDup;   // Ignore Out-of-Order/Dup (BOOL)
#define CHTA_SRIDX_ISSTART 0x01 // Use srIndexConf as starting index
#define CHTA_RAND_PAYLOAD  0x02 // Randomize payload
        uint8_t modifierBitmap; // Modifier bitmap
#define CHTA_RA_ALGO_B 0     // Algorithm B
#define CHTA_RA_ALGO_C 1     // Algorithm C
        uint8_t rateAdjAlgo; // Rate adjust. algorithm
        uint8_t reserved2;   // (reserved for alignment)
        struct sendingRate srStruct; // Sending rate structure
        uint16_t subIntPeriod; // Sub-interval period (ms)
        uint16_t reserved3;    // (reserved for alignment)
        uint16_t reserved4;    // (reserved for alignment)
        uint8_t reserved5;     // (reserved for alignment)
        // ========== Integrity Verification ==========
        uint8_t authMode;      // Authentication mode
        uint32_t authUnixTime; // Authentication timestamp
        uint8_t authDigest[AUTH_DIGEST_LENGTH];
        uint8_t keyId;         // Key ID in shared table
        uint8_t reservedAuth1; // (reserved for alignment)
        uint16_t checkSum;     // Header checksum
};
&lt;CODE ENDS&gt;
        </artwork>

            <postamble/>
          </figure></t>
]]></sourcecode>
        </figure>

      </section>
      <section title="Server numbered="true" toc="default">
        <name>Server Processes Test Activation Request and Generates Response"> Response</name>
        <t>After the server receives the Test Activation Request on the new
        connection, it chooses to accept, ignore ignore, or modify any of the test
        parameters. When the server replies to the Test Activation Request
        message, the Test Activation Response PDU is structured identically to
        the Request PDU and SHALL <bcp14>SHALL</bcp14> retain the original values received in it
        unless they are explicitly coerced to a server acceptable server-acceptable value.</t>
        <t>When the server receives the Test Activation Request message, it
        SHALL
        <bcp14>SHALL</bcp14> first follow the Message Verification Procedure listed in <xref
        target="VerifyPDU"/>.</t> target="VerifyPDU" format="default"/>.</t>
        <section title="Server numbered="true" toc="default">
          <name>Server Rejects or Modifies Request"> Request</name>
          <t>When evaluating the Test Activation Request, the server MAY <bcp14>MAY</bcp14> allow
          the client to specify its own fixed or starting send rate via
          srIndexConf.</t>
          <t>Alternatively, the server MAY <bcp14>MAY</bcp14> enforce a maximum limit of the
          fixed or starting send rate rate, which the client can successfully
          request. If the client's Test Activation Request exceeds the
          server's configured maximum, the server MUST <bcp14>MUST</bcp14> either reject the
          request or coerce the value to the configured maximum bit rate, and
          communicate that maximum to the client in the Test Activation
          Response. The client can of course choose to end the test, as
          appropriate.</t>
          <t>Other parameters where the server has the OPTION to coerce the
          client to use values other than those in the Test Activation Request
          are (grouped by role):</t>

          <t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>Load rate adjustment algorithm: lowThresh, upperThresh,
              useOwDelayVar, highSpeedDelta, slowAdjThresh, seqErrThresh,
              highSpeedDelta, ignoreOooDup, rateAdjAlgo.</t> rateAdjAlgo</t>
            </li>
            <li>
              <t>Test duration/intervals: trialInt, testIntTime,
              subIntPeriod</t>
            </li>
            <li>
              <t>Packet marking: dscpEcn</t>
            </list>Coercion
            </li>
          </ul>
          <t>Coercion is a step towards performing a test with the
          server-configured values; even though the client might prefer
          certain values, the server gives the client an opportunity to run a
          test with different values than the preferred set. In these cases,
          the Command Response value SHALL <bcp14>SHALL</bcp14> be CHTA_CRSP_ACKOK.</t>
          <t>Note that the server also has the option of completely rejecting
          the request and sending back an appropriate cmdResponse field value
          (currently only CHTA_CRSP_BADPARAM, CHTA_CRSP_BADPARAM; see <xref
          target="Activation-cmdResponse"/>).</t> target="Activation-cmdResponse" format="default"/>).</t>
          <t>Whether this error response is sent or not depends on the
          Security
          security mode of operation and the outcome of authDigest
          validation.</t>
          <t>If the Test Activation Request must be rejected (due to the
          Command Response value being CHTA_CRSP_BADPARAM), and</t>

          <t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>If the authDigest is valid, a Test Activation Response SHALL <bcp14>SHALL</bcp14>
              be sent back to the client with a corresponding command response Command Response
              value indicating the reason for the rejection.</t>
            </li>
            <li>
              <t>If the authDigest is invalid, then the Test Activation
              Request SHOULD <bcp14>SHOULD</bcp14> fail silently. The exception is for operations
              support: server administrators are permitted to send a an
              Activation Response to support operations and
              troubleshooting.</t>
            </list></t>
            </li>
          </ul>
          <t>The additional circumstances when a server SHALL NOT <bcp14>SHALL NOT</bcp14> communicate
          the appropriate Command Response code for an error condition (fail
          silently) are when: <list style="numbers"> </t>
          <ul spacing="normal"><li>
              <t>the Test Activation Request PDU size is not equal to the
              'struct controlHdrTA' size shown in <xref target="CHTA"/>,</t> target="CHTA" format="default"/>,</t>
            </li>
            <li>
              <t>the PDU ID is not 0xACE2 (Test Activation PDU), or</t>
            </li>
            <li>
              <t>a directed attack has been detected,</t>
            </list>in which case detected.</t>
            </li>
          </ul>
          <t>In this case, the server will allow Test Activation
          Requests to terminate silently. Attack detection is beyond the scope
          of this specification.</t>
        </section>
        <section title="Server numbered="true" toc="default">
          <name>Server Accepts Request and Generates Response"> Response</name>
          <t>When the server sends the Test Activation Response, it SHALL <bcp14>SHALL</bcp14> set
          the cmdResponse field to CHTA_CRSP_ACKOK (see <xref
          target="Activation-cmdResponse"/>)</t> target="Activation-cmdResponse" format="default"/>).</t>
          <t>If the client has requested an upstream test, the server
          SHALL:</t>

          <t><list style="symbols">
          <bcp14>SHALL</bcp14>:</t>
          <ul spacing="normal">
            <li>

<!--[rfced] May we clarify the text in parentheses as shown below
(i.e., update "having been set to CHTA_SRIDX_DEF" to "and if the
parameters were set to CHTA_SRIDX_DEF")? Note that there are two
instances in the text.

Original:
   *  include the transmission parameters from the first row of the
      Sending Rate Table in the Sending Rate structure (if requested by
      srIndexConf having been set to CHTA_SRIDX_DEF), or

Perhaps:
   *  include the transmission parameters from the first row of the
      Sending Rate Table in the Sending Rate structure (if requested by
      srIndexConf and if the parameters were set to CHTA_SRIDX_DEF), or
-->

              <t>include the transmission parameters from the first row of the
              Sending Rate Table in the Sending Rate structure (if requested
              by srIndexConf having been set to CHTA_SRIDX_DEF), or</t>
            </li>
            <li>
              <t>include the transmission parameters from the designated
              Configured Sending Rate Table index (srIndexConf) of the Sending
              Rate Table where, if CHTA_SRIDX_ISSTART is set in
              modifierBitmap, this will be used as the starting rate for the
              load rate adjustment algorithm, else algorithm; else, it will be considered a
              fixed-rate test.</t>
            </list></t>
            </li>
          </ul>
          <t>When generating the Test Activation Response (acceptance) for a
          downstream test, the server SHALL <bcp14>SHALL</bcp14> set all octets of the Sending Rate
          structure to zero.</t>
          <t>If activation continues, the server prepares the new connection
          for an upstream OR downstream test.</t>
          <t>In the case of an upstream test, the server SHALL <bcp14>SHALL</bcp14> prepare to use
          a single timer to send Status PDUs at the specified interval. For a
          downstream test, the server SHALL <bcp14>SHALL</bcp14> prepare to utilize dual timers to
          send Load PDUs based on</t>

          <t><list style="symbols"> on:</t>
          <ul spacing="normal">
            <li>
              <t>the transmission parameters directly from the first row of
              the Sending Rate Table (if requested by srIndexConf having been
              set to CHTA_SRIDX_DEF), or</t>
            </li>
            <li>
              <t>the transmission parameters from the designated Configured
              Sending Rate Table index (srIndexConf) of the Sending Rate Table
              where, if CHTA_SRIDX_ISSTART is set in modifierBitmap, this will
              be used as the starting rate for the load rate adjustment
              algorithm, else
              algorithm; else, it will be considered a fixed-rate test.</t>
            </list></t>
            </li>
          </ul>
          <t>The server SHALL <bcp14>SHALL</bcp14> then send the Test Activation Response back to
          the client, update the watchdog timer with a new timeout value, and
          set a test duration timer to eventually stop the test.</t>
        </section>
      </section>
      <section title="Client numbered="true" toc="default">
        <name>Client Processes Test Activation Response"> Response</name>
        <t>When the client receives the Test Activation Response message, it
        SHALL
        <bcp14>SHALL</bcp14> first follow the Message Verification Procedure listed in <xref
        target="VerifyPDU"/>.</t> target="VerifyPDU" format="default"/>.</t>
        <t>After the client receives the (vetted) Test Activation Response, it
        first checks the command response Command Response value.</t>

        <t>If

<!--[rfced] We are having trouble parsing "SHALL display/report a
relevant message to the ... management process". Is "process"
essential to the sentence? Please let us know how we may update
the text for clarity.

Original:
   If the client receives a Test Activation cmdResponse field value that
   indicates an error, the client SHALL display/report a relevant
   message to the user or management process and exit.

Perhaps:
   If the client receives a Test Activation cmdResponse field value that
   indicates an error, the client SHALL display/report a relevant
   message to the user or management and exit.
-->

        <t>If the client receives a Test Activation cmdResponse field value
        that indicates an error, the client <bcp14>SHALL</bcp14> display/report a relevant
        message to the user or management process and exit.</t>
        <t>If the client receives a Test Activation cmdResponse field value
        that is not equal to one of the codes defined in <xref
        target="Activation-cmdResponse"/>, target="Activation-cmdResponse" format="default"/>, the client MUST <bcp14>MUST</bcp14> terminate the
        connection and terminate operation of the current setup procedure.</t>
        <t>If the client receives a Test Activation Command Response value
        that indicates success (CHTA_CRSP_ACKOK, (e.g., CHTA_CRSP_ACKOK; see <xref
        target="Activation-cmdResponse"/>), target="Activation-cmdResponse" format="default"/>), the client SHALL <bcp14>SHALL</bcp14> update its
        configuration to use any test parameters modified by the server. If
        the setup parameters coerced by the server are not acceptable to the
        client, the client ends the test.</t>
        <t>To finalize an accepted test activation, the client SHALL <bcp14>SHALL</bcp14> prepare
        its connection for either an upstream test with dual timers set to
        send Load PDUs (based on the starting transmission parameters sent by
        the server), server) OR a downstream test with a single timer to send Status
        PDUs at the specified interval.</t>
        <t>Then, the client SHALL <bcp14>SHALL</bcp14> stop the test initiation timer and start a
        watchdog timer to detect if the server goes quiet.</t>
        <t>The connection is now ready for testing.</t>
      </section>
    </section>
    <section anchor="Test-Measurement"
             title="Test numbered="true" toc="default">
      <name>Test Load Stream Transmission and Measurement Status Feedback Messages"> Messages</name>
      <t>This section describes the data Data phase of the protocol. The roles of
      sender and receiver vary depending on whether the direction of testing
      is from server to client, or the reverse.</t>
      <section title="Load numbered="true" toc="default" anchor="load_pdu_roles">
        <name>Load PDU and Roles"> Roles</name>
        <t>Testing proceeds with one endpoint sending Load PDUs, based on
        transmission parameters from the Sending Rate Table, and the other
        endpoint sending Status Feedback messages to communicate the traffic
        conditions at the receiver. When the server is sending Status Feedback
        messages, they will also contain the latest transmission parameters
        from the Sending Rate Table that the client SHALL <bcp14>SHALL</bcp14> use.</t>
        <t>When a Load PDU is received, the receiver SHALL first:</t>

        <t><list style="numbers"> <bcp14>SHALL</bcp14> do the following:</t>
        <ol spacing="normal" type="1"><li>
            <t>Verify that the size of the message is greater than or equal to
            the 'struct loadHdr' size shown in <xref target="LoadPDU"/>.</t>

            <t>If the optional checkSum field is being utilized, validate target="LoadPDU" format="default"/>.</t>
          </li>
          <li>
            <t>Validate the
            checksum for the Load PDU header portion of the total message (as
            described in <xref target="Checksum"/>).</t> target="Checksum" format="default"/>) if the optional
	    checkSum field is being utilized.</t>
          </li>
          <li>
            <t>Confirm that the PDU ID is 0xBEEF (Load PDU).</t>
          </list>Note:
          </li>
        </ol>
        <t>Note: If any of the above checks fail, the message SHALL <bcp14>SHALL</bcp14> be
        considered invalid.</t>
        <t>The watchdog timer at the receiver SHALL <bcp14>SHALL</bcp14> be reset each time a valid
        Load PDU is received (which includes verification of the checkSum, if
        in use). See non-graceful test stop in <xref target="Test-Stop"/> target="Test-Stop" format="default"/> for
        handling the watchdog timeout expiration at each endpoint. Note that
        the watchdog timer's purpose is to detect a connection failure or a
        massive congestion condition only.</t>
        <t>When the server is sending Load PDUs in the role of sender, it
        SHALL
        <bcp14>SHALL</bcp14> use the transmission parameters directly from the Sending Rate
        Table via the index that is currently selected (which was indirectly
        based on the feedback in its received Status Feedback messages).</t>
        <t>However, when the client is sending Load PDUs in the role of
        sender, it SHALL <bcp14>SHALL</bcp14> use the discreet transmission parameters that were
        communicated by the server in its periodic Status Feedback messages
        (and not referencing a Sending Rate Table directly). This approach
        allows the server to control the individual sending rates as well as
        the algorithm used to decide when and how to adjust the rate.</t>
        <t>The server uses a load rate adjustment algorithm which that evaluates
        measurements taken locally at the Load PDU receiver. When the client
        is the receiver, the information is communicated to the server via the
        periodic Status Feedback messages. When the server is the receiver,
        the information is used directly (although it is also communicated to
        the client via its periodic Status Feedback messages). This approach
        is unique to this protocol; it provides the ability to search for the
        Maximum IP Capacity and specify specific sender behaviors that are
        absent from other testing tools. Although the algorithm depends on the
        protocol, it is not part of the protocol per se.</t>
        <t>The default algorithm (B, (B; see <xref target="Y.1540"/>) target="Y.1540" format="default"/>) has three
        paths to its decision on the next sending rate:<list style="numbers"> rate:</t>
        <ol spacing="normal" type="1"><li>
            <t>When there are no impairments present (no sequence errors and
            low delay variation), resulting in a sending rate increase.</t>
          </li>
          <li>
            <t>When there are low impairments present (no sequence errors but
            higher levels of delay variation), the same sending rate is
            maintained.</t>
          </li>
          <li>
            <t>When the impairment levels are above the thresholds set for
            this purpose and "congestion" is inferred, resulting in a sending
            rate decrease.</t>
          </list></t>
          </li>
        </ol>
        <t>Algorithm B also has two modes for increasing/decreasing the
        sending rate:<list style="symbols"> rate:</t>
        <ul spacing="normal">
          <li>
            <t>A high-speed mode (fast) to achieve high sending rates quickly, quickly
            but that also back-off backs off quickly when "congestion" is inferred from the
            measurements. Consecutive feedback intervals that have a
            supra-threshold count of sequence number anomalies and/or contain
            an upper delay variation threshold exception in all of the
            consecutive intervals are sufficient to declare "congestion"
            within a test. The threshold of consecutive feedback intervals
            SHALL
            <bcp14>SHALL</bcp14> be configurable with a default of 3 intervals.</t>
          </li>
          <li>
            <t>A single-step (slow) mode where all rate adjustments use the
            minimum increase or decrease of one step in the sending rate
            table. The single step single-step mode continues after the first inference of
            "congestion" from measured impairments.</t>
          </list></t>
          </li>
        </ul>
        <t>An OPTIONAL <bcp14>OPTIONAL</bcp14> load rate adjustment algorithm (designated C) has been
        defined in <xref target="TR-471"/>. target="TR-471" format="default"/>.

<!--[rfced] May we rephrase "adds the possibility to" to "provides the
option to" for clarity?

Original:
   Algorithm C operation and modes are similar to B, but C uses
   multiplicative increases in the fast mode to reach the Gigabit
   range quickly and adds the possibility to re-try the fast mode
   during a test (which improves the measurement accuracy in dynamic
   or error-prone access, such as radio access).

Perhaps:
   Algorithm C operation and modes are similar to B, but C uses
   multiplicative increases in the fast mode to reach the gigabit
   range quickly and provides the option to retry the fast mode
   during a test (which improves the measurement accuracy in
   dynamic or error-prone access, such as radio access).
-->

	Algorithm C operation and modes
        are similar to B, but C uses multiplicative increases in the fast mode
        to reach the gigabit range quickly and adds the possibility to re-try
        the fast mode during a test (which improves the measurement accuracy
        in dynamic or error-prone access, such as radio access).</t>
        <t>On the other hand, the test configuration MAY <bcp14>MAY</bcp14> use a fixed sending
        rate requested by the client, using the field srIndexConf.</t>
        <t>The client MAY <bcp14>MAY</bcp14> communicate the desired fixed-rate fixed rate in its test
        activation request.</t> Test
        Activation Request.</t>
        <t>The UDP PDU format layout SHALL <bcp14>SHALL</bcp14> be as follows (big-endian AB):</t>

        <t><figure anchor="Load-PDU" title="Load
        <figure anchor="Load-PDU">
          <name>Load PDU Layout">
            <artwork> Layout</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            pduId              |   testAction  |   rxStopped   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           lpduSeqNo                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           udpPayload          |           spduSeqErr          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          spduTime_sec                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         spduTime_nsec                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          lpduTime_sec                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         lpduTime_nsec                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         rttRespDelay          |           checkSum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                       Payload Content...                      .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        </artwork>

            <postamble/>
          </figure></t>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>

        <t>Specific details regarding Load PDU fields are as follows:</t>

        <t>pduId: IANA is asked to assign
	<dl spacing="normal" newline="false">
        <dt>pduId:</dt><dd>IANA has assigned the value hex value 0xBEEF (<xref
        target="pduId"/>).</t>

        <t>testAction: A target="pduId" format="default"/>).</dd>
        <dt>testAction:</dt><dd>A one-octet fileld field designating the current test action
        as either TEST_ACT_TEST (testing in progress), TEST_ACT_STOP1 (first
        phase of graceful termination, used locally by server), or
        TEST_ACT_STOP2 (second phase of graceful termination, sent by server
        and reciprocated by client). See <xref target="Test-Stop"/> target="Test-Stop" format="default"/> for
        additional information on test termination.</t>

        <t>rxStopped: A termination.</dd>
        <dt>rxStopped:</dt><dd>A one-octet fileld. field. Boolean, 0 or 1, used to indicate to
        the remote endpoint that local receive traffic (either Load or Status
        PDUs) has stopped. All outgoing Load or Status PDUs SHALL <bcp14>SHALL</bcp14> continue to
        assert this indication until traffic is received again, or the test is
        terminated. The time threshold to trigger this condition is expected
        to be a reasonable fraction of the watchdog timeout (a default of one
        second is recommended).</t>

        <t>lpduSeqNo: A recommended).</dd>

        <dt>lpduSeqNo:</dt><dd>A four-octet field indicating the Load PDU sequence
        number (starting at 1). Used to determine loss, out-of-order, and
        duplicates.</t>

        <t>udpPayload: A
        duplicates.</dd>
        <dt>udpPayload:</dt><dd>A two-octet field indicating the total payload size of
        the UDP datagram including the Load PDU message header and Payload
        Content payload
        content (i.e., what the UDP socket read function would return). This
        field allows the Load PDU receiver to maintain accurate receive
        statistics if utilizing receive truncation (only requesting the Load
        PDU message header octets from the protocol stack).</t>

        <t>spduSeqErr: A stack).</dd>
        <dt>spduSeqErr:</dt><dd>A two-octet field indicating the Status PDU loss count,
        as seen by the Load PDU sender. This is determined by the Status PDU
        sequence number (spduSeqNo) in the most recently received Status PDU.
        Used to communicate to the Load PDU receiver that return traffic (in
        the unloaded direction) is being lost.</t>

        <t>spduTime_sec/spduTime_nsec: Two lost.</dd>
        <dt>spduTime_sec/spduTime_nsec:</dt><dd>Two four-octet fields containing a copy
        of the most recent spduTime_sec/spduTime_nsec from the last Status PDU
        received. Used for RTT measurements made by the Load PDU receiver.</t>

        <t>lpduTime_sec/lpduTime_nsec: Two receiver.</dd>
        <dt>lpduTime_sec/lpduTime_nsec:</dt><dd>Two four-octet fields containing the
        local send time of the Load PDU. Used for one-way delay variation
        measurements made by the Load PDU receiver.</t>

        <t>rttRespDelay: A receiver.</dd>
        <dt>rttRespDelay:</dt><dd>A two-octet field indicating the RTT response delay,
        used to "adjust" raw RTT. On the Load PDU sender, it is the number of
        milliseconds from reception of the most recent Status PDU (when the
        latest spduTime_sec/spduTime_nsec was obtained) to the transmission of
        the Load PDU (where the previously obtained spduTime_sec/spduTime_nsec
        is returned). When the Load PDU receiver is calculating RTT, by
        subtracting the copied Status PDU send time (in the Load PDU) from the
        local Load PDU receive time, this value is subtracted from the raw RTT
        to correct for any response delay due to Load PDU scheduling.</t>

        <t>checkSum: An scheduling.</dd>
        <dt>checkSum:</dt><dd>An optional checksum of only the Load PDU header (see
        <xref target="Checksum"/> target="Checksum" format="default"/> for guidance). The checksum does not cover
        the Payload Content. payload content. The calculation is done as the very last step of
        building the PDU header, with the checksum checkSum field set to zero.</t>

        <t>Payload Content: All zero.</dd>
        <dt>Payload Content:</dt><dd>All zeroes, all ones, or a pseudorandom binary
        sequence.</t>
        sequence.</dd>
	</dl>
        <t>The Load PDU SHALL <bcp14>SHALL</bcp14> be organized as follows (followed by any payload content):</t>

        <t><figure anchor="LoadPDU" title="Load PDU">
            <artwork>
&lt;CODE BEGINS&gt;
        <figure anchor="LoadPDU">
          <name>Load PDU</name>
          <sourcecode name="" type="c" markers="true"><![CDATA[
//
// Load header for UDP payload of Load PDUs
//
struct loadHdr {
#define LOAD_ID 0xBEEF
        uint16_t pduId;  // PDU ID
#define TEST_ACT_TEST  0 // Test active
#define TEST_ACT_STOP1 1 // Stop indication used locally by server
#define TEST_ACT_STOP2 2 // Stop indication exchanged with client
        uint8_t testAction;  // Test action
        uint8_t rxStopped;   // Receive traffic stopped (BOOL)
        uint32_t lpduSeqNo;  // Load PDU sequence number
        uint16_t udpPayload; // UDP payload (bytes)
        uint16_t spduSeqErr; // Status PDU sequence error count
        uint32_t spduTime_sec;  // Send time in last rx'd status PDU
        uint32_t spduTime_nsec; // Send time in last rx'd status PDU
        uint32_t lpduTime_sec;  // Send time of this load PDU
        uint32_t lpduTime_nsec; // Send time of this load PDU
        uint16_t rttRespDelay;  // Response delay for RTT (ms)
        uint16_t checkSum;      // Header checksum
};
&lt;CODE ENDS&gt;
        </artwork>

            <postamble/>
          </figure></t>
]]></sourcecode>
        </figure>

      </section>
      <section anchor="Status-PDU" title="Status PDU"> numbered="true" toc="default">
        <name>Status PDU</name>
        <t>The Load PDU receiver SHALL <bcp14>SHALL</bcp14> send a Status PDU to the sender during
        a test at the configured feedback interval, after at least one Load
        PDU has been received (when there is something to provide status on).
        In test scenarios with long delays between client and server, it is
        possible for the Status PDU send timer to fire before the first Load
        PDU arrives. In these cases, the Status PDU SHALL NOT <bcp14>SHALL NOT</bcp14> be sent.</t>
        <t>When the Load PDU sender receives a Status PDU message, it SHALL <bcp14>SHALL</bcp14>
        first follow the Message Verification Procedure listed in <xref
        target="VerifyPDU"/>.</t> target="VerifyPDU" format="default"/>.</t>
        <t>The watchdog timer at the Load PDU sender SHALL <bcp14>SHALL</bcp14> be reset each time
        a valid Status PDU is received (which includes verification of the
        checkSum and/or authDigest, if in use). See non-graceful test stop in
        <xref target="Test-Stop"/> target="Test-Stop" format="default"/> for handling the watchdog timeout
        expiration at each endpoint.</t>
        <t>The UDP PDU format layout SHALL <bcp14>SHALL</bcp14> be as follows (big-endian AB):</t>

        <t><figure anchor="StatPDU" title="Status
        <figure anchor="StatPDU">
          <name>Status PDU Layout">
            <artwork> Layout</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          rxDatagrams                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            rxBytes                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           deltaTime                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           seqErrLoss                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           seqErrOoo                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           seqErrDup                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          delayVarMin                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          delayVarMax                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          delayVarSum                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          delayVarCnt                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         rttVarMinimum                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         rttVarMaximum                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           accumTime                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             pduId             |   testAction  |   rxStopped   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           spduSeqNo                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                      srStruct (28 octets)                     .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          subIntSeqNo                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                      sisSav (56 octets)                       .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           seqErrLoss                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           seqErrOoo                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           seqErrDup                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         clockDeltaMin                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          delayVarMin                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          delayVarMax                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          delayVarSum                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          delayVarCnt                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          rttMinimum                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         rttVarSample                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  delayMinUpd  |   reserved1   |          reserved2            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          tiDeltaTime                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         tiRxDatagrams                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           tiRxBytes                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         spduTime_sec                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         spduTime_nsec                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          reserved3            |   reserved4   |   authMode    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         authUnixTime                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                     authDigest (32-octet) (32 octets)                    .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     keyId     | reservedAuth1 |           checkSum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        </artwork>

            <postamble/>
          </figure></t>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>

        <t>Note that the Sending Rate structure is defined in <xref
        target="Test-Activation"/>.</t> target="Test-Activation" format="default"/>.</t>
        <t>The primary role of the Status Feedback message is to communicate
        to the Load PDU sender
        the traffic conditions at the Load PDU
        receiver.
        receiver to the Load PDU sender. While the Sub-Interval Statistics structure (sisSav) covers
        the most recently saved (completed) sub-interval, similar fields
        directly in the Status PDU itself cover the most recent trial interval
        (the time period between Status Feedback messages, completed by this
        Status PDU). Both sets of statistics SHALL <bcp14>SHALL</bcp14> always be populated by the
        Load PDU receiver, regardless of role (client or server).</t>
        <t>Details on the Status PDU measurement fields are provided in <xref
        target="RFC9097"/>. Authentication target="RFC9097" format="default"/>. The authentication and checksum checkSum fields follow the same
        methodology as with the Setup Request and Response. Additional
        information regarding fields not defined previously are as
        follows:</t>

        <t>pduId: IANA is asked to assign
	<dl spacing="normal" newline="false">
        <dt>pduId:</dt><dd>IANA has assigned the value hex value 0xFEED (<xref
        target="pduId"/>).</t>

        <t>spduSeqNo: A target="pduId" format="default"/>).</dd>
        <dt>spduSeqNo:</dt><dd>A four-octet field containing the Status PDU sequence
        number (starting at 1). Used by the Load PDU sender to detect Status
        PDU loss (in the unloaded direction). The loss count is communicated
        back to the Load PDU receiver via spduSeqErr in subsequent Load
        PDUs.</t>

        <t>subIntSeqNo: A
        PDUs.</dd>
        <dt>subIntSeqNo:</dt><dd>A four-octet field containing the Sub-interval
        sequence number (starting at 1) that corresponds to the statistics
        provided in sisSav, for the last saved (completed) sub-interval.</t>

        <t>sisSav: Sub-interval sub-interval.</dd>

<!--[rfced] Please review the formatting of the list in Section 7.2,
in particular the indentation of terms following "SisSav". Please
let us know if this is correct (sisSav consists of all the fields
that follow) or if it needs an update.
-->
        <dt>sisSav:</dt><dd><t>Sub-interval statistics saved (completed) for the most
        recent sub-interval (as designated by the subIntSeqNo). These consist
        of the following fields:</t>

        <t>rxDatagrams: A
	<dl spacing="normal" newline="false">
        <dt>rxDatagrams:</dt><dd>A four-octet field Sub-interval indicating the number
        of received datagrams during the Sub-Interval.</t>

        <t>rxBytes: An Sub-Interval.</dd>
        <dt>rxBytes:</dt><dd>An eight-octet field indicating the Sub-Interval byte
        count (eight octets chosen to prevent overflow at high speeds).</t>

        <t>deltaTime: A speeds).</dd>
        <dt>deltaTime:</dt><dd>A four-octet field indicating the exact duration of the
        Sub-Interval in microseconds. Used to calculate the received traffic
        rate together with rxBytes.</t>

        <t>seqErrLoss/seqErrOoo/seqErrDup: Three rxBytes.</dd>
        <dt>seqErrLoss/seqErrOoo/seqErrDup:</dt><dd>Three four-octet fields, fields populated
        by the Loss, out-of-order, and duplicate totals. Available for both
        the sub-interval and trial interval, interval; it is a breakout of the SeqErrors
        count in Table 3 of <xref target="TR-471"/>. target="TR-471" format="default"/>. seqErrOoo and seqErrDup
        are realized by comparing sequence numbers. A lookback list of the
        last n sequence numbers received is used as the basis. Each Load PDU
        sequence number is checked against this lookback. The number n may
        depend on the implementation and on typical characteristics of
        environments, where UDPST UDPSTP is deployed (like mobile networks or Wi-Fi).
        Currently, a default sequence number interval of n=32 has been chosen.
        Specifically for seqErrOoo, each successively received higher seqno
        sets the next-expected-seqno next-expected seqno to seqno+1 seqno+1, and anything below that is
        considered out-of-order out of order (i.e., delayed). For example, given the
        sequence 93, 94, 95, 100, 96, 97, 101, 98, 99, 102, 103, ... reception
        of 96, 97, 98, and 99 would not increment the next-expected-seqno next-expected seqno and
        would all be considered out-of-order.</t>

        <t>delayVarMin/delayVarMax/delayVarSum/delayVarCnt: Four out of order.</dd>
        <dt>delayVarMin/delayVarMax/delayVarSum/delayVarCnt:</dt><dd>Four four-octet
        fields populated by the one-way delay variation measurements of all
        received Load PDUs (where avg = sum/cnt). For each Load PDU received,
        the send time (lpduTime_sec/lpduTime_nsec) is subtracted from the
        local receive time, which is then normalized by subtracting the
        current clockDeltaMin. Available for both the sub-interval and trial
        interval.</t>

        <t>rttVarMinimum/rttVarMaximum
        interval.</dd>
        <dt>rttVarMinimum/rttVarMaximum (in sisSav): Two sisSav):</dt><dd>Two four-octet fields
        populated by the minimum and maximum RTT delay variation
        (rttVarSample) in the sub-interval designated by the subIntSeqNo.</t>

        <t>accumTime: The subIntSeqNo.</dd>
        <dt>accumTime:</dt><dd>The accumulated time of the test in milliseconds, based
        on the duration of each sub-interval. Equivalent to the sum of each
        deltaTime (although in ms) sent in each Status PDU during the
        test.</t>

        <t>clockDeltaMin: A
        test.</dd>
        <dt>clockDeltaMin:</dt><dd>A four-octet field indicating the minimum clock
        delta (difference) since the beginning of the test. Obtained by
        subtracting the send time of each Load PDU
        (lpduTime_sec/lpduTime_nsec) from the local time that it was received.
        This value is initialized with the first Load PDU received and is
        updated with each subsequent one to maintain a current (and
        continuously updated) minimum. If the endpoint clocks are sufficiently
        synchronized, this will be the minimum one-way delay in milliseconds.
        Otherwise, this value may be negative, negative but still valid for one-way
        delay variation measurements for the default test duration (default is
        10 [s]). If the test duration is extended to a range of minutes, where
        significant clock drift can occur, synchronized (or at least
        well-disciplined) clocks may be required.</t>

        <t>rttMinimum required.</dd>
        <dt>rttMinimum (in Status PDU): A PDU):</dt><dd>A four-octet field indicating the
        minimum "adjusted" RTT measured since the beginning of the test. See
        rttRespDelay (<xref target="load_pdu_roles"/>) regarding "adjusted" measurements. RTT is obtained by
        subtracting the copied spduTime_sec/spduTime_nsec in the received Load
        PDU from the local time at which it was received. This minimum SHALL <bcp14>SHALL</bcp14>
        be kept current (and continuously updated) via each Load PDU received
        with an updated spduTime_sec/spduTime_nsec. This value MUST <bcp14>MUST</bcp14> be
        positive. Before an initial value can be established, and because zero
        is itself valid, it SHALL <bcp14>SHALL</bcp14> be set to STATUS_NODEL when communicated in
        the Status PDU.</t>

        <t>rttVarSample: A PDU.</dd>
        <dt>rttVarSample:</dt><dd>A four-octet field indicating the most recent
        "adjusted" RTT delay variation measurement. See rttRespDelay (<xref target="load_pdu_roles"/>) regarding
        "adjusted" measurements. RTT delay variation is obtained by
        subtracting the current (and continuously updated) "adjusted" RTT
        minimum, communicated as rttMinimum (in Status PDU), from each
        "adjusted" RTT measurement (which is itself obtained by subtracting
        the copied spduTime_sec/spduTime_nsec in the received Load PDU from
        the local time at which it was received). Note that while one-way
        delay variation is measured for every Load PDU received, RTT delay
        variation is only sampled via the Status PDU sent and the very next
        Load PDU received with the corresponding updated
        spduTime_sec/spduTime_nsec. When a new value is unavailable (possibly
        due to packet loss), and because zero is itself valid, it SHALL <bcp14>SHALL</bcp14> be set
        to STATUS_NODEL when communicated in the Status PDU.</t>

        <t>delayMinUpd: A PDU.</dd>
        <dt>delayMinUpd:</dt><dd>A one-octet field. Boolean, 0 or 1, indicating that
        the clockDeltaMin and/or rttMinimum (in Status PDU), as measured by
        the Load PDU receiver, has been updated.</t>

        <t>tiDeltaTime/tiRxDatagrams/tiRxBytes: Three updated.</dd>
        <dt>tiDeltaTime/tiRxDatagrams/tiRxBytes:</dt><dd>Three four-octet fields, fields
        populated by the trial interval time in microseconds, along with the
        received datagram and byte counts. Used to calculate the received
        traffic rate for the trial interval.</t>

        <t>spduTime_sec/spduTime_nsec: Two interval.</dd>
        <dt>spduTime_sec/spduTime_nsec:</dt><dd>Two four-octet fields, fields containing the
        local transmit time of the Status PDU. Expected to be copied into
        spduTime_sec/spduTime_nsec in subsequent Load PDUs after being
        received by the Load PDU sender. Used for RTT measurements.</t>

        <t>authMode: Same measurements.</dd>
        <dt>authMode:</dt><dd>Same as in <xref target="Setup-Fields"/></t>

        <t>authUnixTime: Same target="Setup-Fields" format="default"/>.</dd>
        <dt>authUnixTime:</dt><dd>Same as in <xref target="Setup-Fields"/></t>

        <t>authDigest: Same target="Setup-Fields" format="default"/>.</dd>
        <dt>authDigest:</dt><dd>Same as in <xref target="Setup-Fields"/></t>

        <t>keyId: Same target="Setup-Fields" format="default"/>.</dd>
        <dt>keyId:</dt><dd>Same as in <xref target="Setup-Fields"/></t>

        <t>reservedAuth1: Same target="Setup-Fields" format="default"/>.</dd>
        <dt>reservedAuth1:</dt><dd>Same as in <xref target="Setup-Fields"/></t>

        <t>checkSum: Same target="Setup-Fields" format="default"/>.</dd>
        <dt>checkSum:</dt><dd>Same as in <xref target="Setup-Fields"/></t> target="Setup-Fields" format="default"/>.</dd>
      </dl></dd></dl>
        <t>The Status Feedback message PDU (as well as the included
        Sub-Interval Statistics structure) SHALL <bcp14>SHALL</bcp14> be organized as follows:</t>

        <t><figure anchor="STATUS" title="Status PDU">
            <artwork>
&lt;CODE BEGINS&gt;
        <figure anchor="STATUS">
          <name>Status PDU</name>
          <sourcecode name="" type="c" markers="true"><![CDATA[
//
// Sub-interval statistics structure for received traffic information
//
struct subIntStats {
        uint32_t rxDatagrams; // Received datagrams
        uint64_t rxBytes;     // Received bytes (64 bits)
        uint32_t deltaTime;   // Time delta (us)
        uint32_t seqErrLoss;  // Loss sum
        uint32_t seqErrOoo;   // Out-of-Order sum
        uint32_t seqErrDup;   // Duplicate sum
        uint32_t delayVarMin; // Delay variation minimum (ms)
        uint32_t delayVarMax; // Delay variation maximum (ms)
        uint32_t delayVarSum; // Delay variation sum (ms)
        uint32_t delayVarCnt; // Delay variation count
        uint32_t rttMinimum;  // Minimum round-trip time (ms)
        uint32_t rttMaximum;  // Maximum round-trip time (ms)
        uint32_t accumTime;   // Accumulated time (ms)
};
//
// Status feedback header for UDP payload of status PDUs
//
struct statusHdr {
#define STATUS_ID 0xFEED
        uint16_t pduId;     // PDU ID
        uint8_t testAction; // Test action
        uint8_t rxStopped;  // Receive traffic stopped (BOOL)
        uint32_t spduSeqNo; // Status PDU sequence number
        struct sendingRate srStruct; // Sending rate structure
        uint32_t subIntSeqNo;        // Sub-interval sequence number
        struct subIntStats sisSav;   // Sub-interval saved stats
        uint32_t seqErrLoss;    // Loss sum
        uint32_t seqErrOoo;     // Out-of-Order sum
        uint32_t seqErrDup;     // Duplicate sum
        uint32_t clockDeltaMin; // Clock delta minimum (ms)
        uint32_t delayVarMin;   // Delay variation minimum (ms)
        uint32_t delayVarMax;   // Delay variation maximum (ms)
        uint32_t delayVarSum;   // Delay variation sum (ms)
        uint32_t delayVarCnt;   // Delay variation count
#define STATUS_NODEL UINT32_MAX // No delay data/value
        uint32_t rttMinimum;    // Min round-trip time sampled (ms)
        uint32_t rttVarSample;  // Last round-trip time sample (ms)
        uint8_t delayMinUpd;    // Delay minimum(s) updated (BOOL)
        uint8_t reserved1;      // (reserved for alignment)
        uint16_t reserved2;     // (reserved for alignment)
        uint32_t tiDeltaTime;   // Trial interval delta time (us)
        uint32_t tiRxDatagrams; // Trial interval receive datagrams
        uint32_t tiRxBytes;     // Trial interval receive bytes
        uint32_t spduTime_sec;  // Send time of this status PDU
        uint32_t spduTime_nsec; // Send time of this status PDU
        uint16_t reserved3;     // (reserved for alignment)
        uint8_t reserved4;      // (reserved for alignment)
        // ========== Integrity Verification ==========
        uint8_t authMode;      // Authentication mode
        uint32_t authUnixTime; // Authentication timestamp
        uint8_t authDigest[AUTH_DIGEST_LENGTH];
        uint8_t keyId;         // Key ID in shared table
        uint8_t reservedAuth1; // (reserved for alignment)
        uint16_t checkSum;     // Header checksum
};
&lt;CODE ENDS&gt;
        </artwork>

            <postamble/>
          </figure></t>
]]></sourcecode>
        </figure>

      </section>
    </section>
    <section anchor="Test-Stop" title="Stopping numbered="true" toc="default">
      <name>Stopping a Test"> Test</name>
      <t>When the test duration timer (testIntTime) on the server expires, it
      SHALL
      <bcp14>SHALL</bcp14> set the local connection test action to TEST_ACT_STOP1 (phase 1 of
      graceful termination). This is simply a non-reversible state awaiting
      the next message(s) to be sent from the server. During this time, any
      received Load or Status PDUs are processed normally.</t>
      <t>Upon transmission of the next Load or Status PDUs, the server SHALL <bcp14>SHALL</bcp14>
      set the local connection test action to TEST_ACT_STOP2 (phase 2 of
      graceful termination) and mark any outgoing PDUs with a testAction value
      of TEST_ACT_STOP2. While in this state, the server MAY <bcp14>MAY</bcp14> reduce any Load
      PDU bursts to a size of one.</t>
      <t>When the client receives a Load or Status PDU with the TEST_ACT_STOP2
      indication, it SHALL <bcp14>SHALL</bcp14> finalize testing, display the test results, and
      also
      mark its local connection with a test action of TEST_ACT_STOP2 (so
      that any PDUs subsequently received can be ignored).</t>
      <t>With the test action of the client's connection set to
      TEST_ACT_STOP2, the very next expiry of a send timer, for either a Load
      or a Status PDU, SHALL <bcp14>SHALL</bcp14> result in it and any subsequent PDUs to be being sent
      with a testAction value of TEST_ACT_STOP2 (as confirmation to the
      server). While in this state, the client MAY <bcp14>MAY</bcp14> reduce any Load PDU bursts
      to a size of one. The client SHALL <bcp14>SHALL</bcp14> then schedule an immediate end time
      for the connection.</t>
      <t>When the server receives the TEST_ACT_STOP2 confirmation in the Load
      or Status PDU, the server SHALL <bcp14>SHALL</bcp14> schedule an immediate end time for the
      connection which that closes the socket and deallocates the associated
      resources. The TEST_ACT_STOP2 exchange constitutes a graceful
      termination of the test.</t>
      <t>In a non-graceful test stop due to path failure, the watchdog
      timeouts at each endpoint will expire (sometimes at one endpoint first), first);
      notifications in logs, STDOUT, and/or formatted output SHALL <bcp14>SHALL</bcp14> be made, made;
      and the endpoint SHALL <bcp14>SHALL</bcp14> schedule an immediate end time for the
      connection.</t>
      <t>If an attacker clears the TEST_ACT_STOP2 indication, then the
      configured test duration timer (testIntTime) at the server and client
      SHALL
      <bcp14>SHALL</bcp14> take precedence and the endpoint SHALL <bcp14>SHALL</bcp14> schedule an immediate end
      time for the connection.</t>
    </section>
    <section title="Operational considerations numbered="true" toc="default">
      <name>Operational Considerations for the Measurement Method"> Method</name>
      <t>The architecture of the method requires two cooperating hosts
      operating in the roles of Src (test packet sender) and Dst (receiver),
      with a measured path and return path between them.</t>
      <t>The nominal duration of a measurement interval at the Destination,
      parameter testIntTime, MUST <bcp14>MUST</bcp14> be constrained in a production network,
      since this is an active test method and it will likely cause congestion
      on the Src to Dst host path during a test.</t>
      <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to locate test endpoints as close to the intended
      measured link(s) as practical. The testing operator MUST <bcp14>MUST</bcp14> set a value for
      the MaxHops Parameter, based on the expected path length. This Parameter
      can keep measurement traffic from straying too far beyond the intended
      path.</t>
      <t>It is obviously counterproductive to run more than one independent
      and concurrent test (regardless of the number of flows in the test
      stream) when attempting to measure the maximum capacity on a single path. The
      number of concurrent, independent tests of a path SHALL <bcp14>SHALL</bcp14> be limited to
      one.</t>
      <t>The load rate adjustment algorithm's scope is limited to helping
      determine the Maximum IP-Layer Capacity in the context of an infrequent,
      diagnostic, short-term measurement. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to discontinue
      non-measurement traffic that shares a subscriber's dedicated resources
      while testing: measurements may not be accurate, and throughput of
      competing elastic traffic may be greatly reduced.</t>
      <t>See section 8 of <xref target="RFC9097"/> target="RFC9097" section="8"/> for a discussion of the
      method
      Method of measurement Measurement beyond purely operational aspects.</t>
      <section title="Notes numbered="true" toc="default">
        <name>Notes on Interface Measurements"> Measurements</name>
        <t>Additional measurements may be useful in specific circumstances.
        For example, interface byte counters measured by a client at a
        residential gateway are possible when the client application has
        access to an interface that sees all traffic to/from a service
        subscriber's location. Adding a byte counter at the client for
        download or upload directions could be used to measure total traffic
        and possibly detect when non-test traffic is present (and using
        capacity). The client may not have the CPU cycles available to count
        both the interface traffic and IP-layer IP-Layer Capacity simultaneously, so
        this form of diagnostic measurement may not be possible.</t>
      </section>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Active metrics and measurements have a long history of security
      considerations. The security considerations that apply to any active
      measurement of live paths are relevant here. See <xref
      target="RFC4656"/> target="RFC4656" format="default"/> and <xref target="RFC5357"/>.</t>

      <t>When target="RFC5357" format="default"/>.</t>

<!--[rfced] Please clarify what 2 instances of "those" refer to in
this sentence.

Original:
   When considering privacy of those involved in measurement or those
   whose traffic is measured, the sensitive information available to
   potential observers is greatly reduced when using active techniques
   which are within this scope of work.
-->
      <t>When considering privacy of those involved in measurement or those
      whose traffic is measured, the sensitive information available to
      potential observers is greatly reduced when using active techniques
      that are within this scope of work. Passive observations of user
      traffic for measurement purposes raise many privacy issues. We refer the
      reader to See the
      privacy considerations described in the LMAP Framework
      <xref target="RFC7594"/>, target="RFC7594" format="default"/>, which covers active and passive
      techniques.</t>

      <t>There
      <t>Below are some new considerations for Capacity capacity measurement as
      described in this document.</t>

      <t><list style="numbers">
      <ol spacing="normal" type="1"><li>
          <t>Cooperating client and server hosts and agreements to test the
          path between the hosts are REQUIRED. <bcp14>REQUIRED</bcp14>. Hosts perform in either the
          server or the client roles. One way to assure a cooperative agreement
          employs the optional Authorization mode is through the use of the
          authDigest field and the known identity associated with the shared
          key used to create the authDigest field via the KDF. Other means are
          also possible, such as access control lists at the server.</t>
        </li>
        <li>
          <t>It is REQUIRED <bcp14>REQUIRED</bcp14> to have a user client-initiated setup handshake
          between cooperating hosts that allows firewalls to control inbound
          unsolicited UDP traffic which either that goes to either a control port or to
          ephemeral ports that are only created as needed. Firewalls
          protecting each host can both continue to do their job jobs normally.</t>
        </li>
        <li>
          <t>Client-server authentication and integrity protection for
          feedback messages conveying measurements is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>. To
          accommodate different host limitations and testing circumstances,
          different modes of operation are available, as described in <xref
          target="Security-Checksum"/> above.</t> target="Security-Checksum" format="default"/>.</t>
        </li>
        <li>
          <t>Hosts MUST <bcp14>MUST</bcp14> limit the number of simultaneous tests to avoid
          resource exhaustion and inaccurate results.</t>
        </li>
        <li>
          <t>Senders MUST <bcp14>MUST</bcp14> be rate-limited. This can be accomplished using a
          pre-built table defining all the offered sending rates that will be
          supported. The default and optional load rate adjustment algorithm
          results in "ramp up" from the lowest rate in the table. Optionally,
          the server could utilize the maxBandwidth field (and the CHSR_USDIR_BIT
          bit) in the Setup Request from the client to limit the maximum that
          it will attempt to achieve.</t>
        </li>
        <li>
          <t>Service subscribers with limited data volumes who conduct
          extensive capacity testing might experience the effects of Service
          Provider controls on their service. Testing with the Service
          Provider's measurement hosts SHOULD <bcp14>SHOULD</bcp14> be limited in frequency and/or
          overall volume of test traffic (for example, the range of test
          interval duration values should be limited).</t>
        </list></t>
        </li>
      </ol>
      <t>One specific attack that has been recognized is an on-path attack on
      the testAction field where the attacker would set or clear the STOP
      indication. Setting the indication in successive packets terminates the
      test prematurely, with no threat to the Internet but annoyance for the
      testers. If an attacker clears the STOP indication, the mitigation
      relies on knowledge of the test duration at the client and server, where
      these hosts cease all traffic when the specified test duration is
      complete.</t>
      <t>Authentication methods and requirements steadily evolve. Alternate
      authentication modes provide for algorithm agility by defining a new
      Mode,
      mode, whose support is indicated by an assigning a suitable "Test Setup
      PDU Authentication Mode Registry" Mode" registry value (see <xref
      target="Setup-authMode"/> target="Setup-authMode" format="default"/> ).</t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>This numbered="true" toc="default">

<!-- [rfced] We have included some specific questions about the IANA
text below. In addition to responding to those questions, please
review all of the IANA-related updates carefully and let us know
if any further changes are needed.

a) Section 11.1. In the "Service Name and Transport Protocol Port
Number Registry" <https://www.iana.org/assignments/
service-names-port-numbers/>, the Transport Protocol is listed as
"udp", but in this document, it is listed as "UDP". For consistency,
should this term be lowercase or uppercase? Note that we will
communicate any changes to the registry to IANA.

In this document:
   Transport Protocol:  UDP

In the registry:
   Transport Protocol:  upd

- Also in Section 11.1, should "performance measurement protocol" or
"performance measurement" perhaps be capitalized? (We note that it
appears as "Performance Measurement protocol" in RFC 6812.)

Current:
   Description:  UDP-based IP-Layer Capacity and performance
      measurement protocol

Perhaps:
   Description:  UDP-based IP-Layer Capacity and Performance
      Measurement protocol

b) IANA has added the following entry to the "KeyTable KDFs" registry.
Is "[RFC6234]" the correct reference? Should this document requests also be
added as a reference?

Current:
   KDF           Description                    Reference
   - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   HMAC-SHA-256  HMAC using the SHA-256 hash 	[RFC6234]

c) May we update the note in the "UDP Speed Test Protocol (UDPSTP)"
registry group for clarity as shown below (i.e., uppercase
"experimental use" and add "are expected")? If so, we will ask IANA to assign
update accordingly.

Original:
   Note: Values reserved for experimental use are not expected to be
   used on the Internet, but for experiments that are confined to closed
   environments.

Perhaps:
   Note: Values reserved for Experimental Use are not
   expected to be used on the Internet but are expected to be used for
   experiments that are confined to closed environments.

d) We note that the "Range" and "Value" column headers in the tables
listed below are different than what is listed in the corresponding
IANA registries. Should the IANA registries (which only list "Range"
and "Value") be updated to match this document, or should "(Hex)",
"(Decimal)", "(Bitmap)", "(Capital alphabet / UTF-8)", and
"(Numeric)" be removed from this document to match the IANA registries?

Current in this document (first header columns of the tables):
  Table 2: Range(Hex)
  Tables 4, 8, 10, 12, and 18: Range(Decimal)
  Tables 6 and 14: Range(Bitmap)
  Table 16: Range(Capital alphabet / UTF-8)
  Table 17: Value(Numeric)

e) In the "PDU Identifier" registry, we note that IANA has listed
"0x0001-0x7F00 / Specification Required" twice. We will ask IANA to
remove the duplicate entry. We also note that "0x8000-0xFFFE / IETF
Review" is missing. We will ask IANA to add it.

May we update the order of Table 2 in this document and in the IANA
registry as shown under the "Suggested" text below so that there is
consistency with the order of the number ranges?

Current in the "PDU Identifier" registry:

   Range           Registration Procedures
   - - - - - - - - - - - - - - - - - - - -
   0x0000 	   Reserved
   0x0001-0x7F00   Specification Required
   0x7F01-0x7FE0   Reserved for Experimental Use
   0x7FE1-0x7FFF   Reserved for Private Use
   0x0001-0x7F00   Specification Required
   0xFFFF 	   Reserved

Suggested (for the registry and this document):

   Range           Registration Procedures
   - - - - - - - - - - - - - - - - - - - -
   0x0000 	   Reserved
   0x0001-0x7F00   Specification Required
   0x7F01-0x7FE0   Experimental Use
   0x7FE1-0x7FFF   Private Use
   0x8000-0xFFFE   IETF Review
   0xFFFF 	   Reserved

f) In Table 7 under the description for value 0x02, is the hyphen
necessary in "IP-header" or may we remove it per use in most RFCs?
Also, may we add "an" before "IP header"?

Original:
   0x02   Use Traditional MTU (1500 bytes with IP-header)

Perhaps:
   0x02   Use Traditional MTU (1500 bytes with an IP header)

g) In the "Test Activation PDU Rate Adjustment Algo." registry name,
is the period after "Algo." necessary? We ask as there is no period
after the "rateAdjAlgo" field, for example.

Original:
   "Test Activation PDU Rate Adjustment Algo." registry

Perhaps:
   "Test Activation PDU Rate Adjustment Algo" registry

h) In Tables 11 and 19, how may we clarify the description for value 0.
Is "Request" referring to the "Setup Request" or other?

Original:
   0    None (used by client in Request)

Perhaps:
   0    None (used by client in the Setup Request)
-->

      <name>IANA Considerations</name>
      <t>Per this document, IANA has assigned a User/Registered UDP port for
      the Test Setup exchange in the Control phase of protocol operation, operation and
      to create
      has created a new registry group for the UDP Speed Test Protocol
      (UDPSTP).</t> UDPSTP.</t>
      <section title="New numbered="true" toc="default">
        <name>New User Port Number Assignment"> Assignment</name>
        <t>IANA will allocate has registered the following service name to in the "Service Name
        and Transport Protocol Port Number Registry" registry:</t>

        <t><list style="hanging">
            <t hangText="Service:">udpstp</t>

            <t hangText="Transport Protocol:">UDP</t>

            <t hangText="Assignee:">IESG &lt;iesg@ietf.org&gt;</t>

            <t hangText="Contact:">IETF Chair &lt;chair@ietf.org&gt;</t>

            <t hangText="Description:">UDP-based Registry":</t>
        <dl newline="false" spacing="compact">
          <dt>Service Name:</dt>
          <dd>udpstp</dd>
          <dt>Port Number:</dt>
          <dd>24601</dd>
          <dt>Transport Protocol:</dt>
          <dd>UDP</dd>
          <dt>Description:</dt>
          <dd>UDP-based IP-Layer Capacity and
            performance measurement protocol</t>

            <t hangText="Reference:">This RFC, RFCYYYY.</t>

            <t hangText="Port Number:">&lt;PORTNUM&gt; of the IANA User Port
            range (1024-49151)</t>
          </list></t> protocol</dd>
          <dt>Assignee:</dt>
          <dd>IESG &lt;iesg@ietf.org&gt;</dd>
          <dt>Contact:</dt>
          <dd>IETF Chair &lt;chair@ietf.org&gt;</dd>
          <dt>Reference:</dt>
          <dd>RFC 9946</dd>

        </dl>
        <t>The protocol uses IP-Layer Unicast. The assignment of a A single port
        number is requested was assigned to help configure firewalls and other port-based
        systems for access control prior to negotiating dynamic ports between
        client and server.</t>
      </section>
      <section anchor="kdf-HMAC-SHA-256" title="New numbered="true" toc="default">
        <name>New KeyTable KDF"> KDF</name>
        <t>IANA will allocate has added the following KDF entry to the existing list of
        KeyTable KDFs
        "KeyTable KDFs" registry (see
        https://www.iana.org/assignments/keytable/keytable.xhtml#kdf).</t>

        <t><figure>
            <artwork>
KDF             Description                    Reference
===============================================================
HMAC-SHA-256    HMAC
        <eref target="https://www.iana.org/assignments/keytable" brackets="angle"/>):</t>

	<table>
	  <name>KeyTable KDFs Registry</name>
  <thead>
    <tr><th>KDF</th><th>Description</th><th>Reference</th></tr>
  </thead>
  <tbody>
    <tr><td>HMAC-SHA-256</td><td>HMAC using the SHA-256 hash    [RFC6234]
</artwork>
          </figure></t> hash</td><td><xref target="RFC6234"/></td></tr>
  </tbody>
</table>
      </section>
      <section title="New numbered="true" toc="default">
        <name>New UDPSTP Registry Group"> Group</name>
        <t>IANA will create has created the following registries in the subsections that follow under a new registry group
        called "UDP Speed Test Protocol (UDPSTP)".</t>
        <t>IANA is requested to has added the following note under the "UDP Speed Test
        Protocol (UDPSTP)" registry group:</t>

        <t>Note:

        <blockquote>Note: Values reserved for experimental use are not expected to be
        used on the Internet, but for experiments that are confined to closed
        environments.</t>
        environments.</blockquote>

        <section anchor="pduId" title="PDU numbered="true" toc="default">
          <name>PDU Identifier Registry"> Registry</name>
          <t>IANA will create has created the "PDU Identifier" registry under the "UDP
          Speed Test Protocol (UDPSTP)" registry group. Every UDPSTP PDU
          contains a two octet two-octet pduId field identifying the role and format of
          the PDU that follows. The code points in this registry are allocated
          according to the registration procedures <xref target="RFC8126"/> target="RFC8126" format="default"/>
          described in Table 1.</t>

          <t><figure>
              <artwork>Range(Hex)             Registration <xref target="reg-proc-pdu-identifier"/>.</t>
<table anchor="reg-proc-pdu-identifier">
  <name>Registration Procedures
===============================================================
0xFFFF and 0x0000      Reserved

0x8000-0xFFFE          IETF Review

0x0001-0x7F00          Specification Required

0x7F01-0x7FE0          Experimental

0x7FE1-0x7FFF          Private Use

</artwork>
            </figure>Table 1: Registration procedures for the PDU Identifier
          registry</t>

          <t>Initially, IANA will assign Registry</name>
  <thead>
    <tr>
      <th>Range(Hex)</th>
      <th>Registration Procedures</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0xFFFF and 0x0000</td>
      <td>Reserved</td>
    </tr>
    <tr>
      <td>0x8000-0xFFFE</td>
      <td>IETF Review</td>
    </tr>
    <tr>
      <td>0x0001-0x7F00</td>
      <td>Specification Required</td>
    </tr>
    <tr>
      <td>0x7F01-0x7FE0</td>
      <td>Experimental Use</td>
    </tr>
    <tr>
      <td>0x7FE1-0x7FFF</td>
      <td>Private Use</td>
    </tr>
  </tbody>
</table>

          <t>IANA has assigned values in the "PDU Identifier" registry with as follows:</t>

<table anchor="init-pdu-iden-val">
  <name>Initial Values of the values in Table 2:</t>

          <t><figure>
              <artwork>Value    Description           Reference
===================================================
0xACE1   Test Setup PDU        &lt;this RFC&gt;

0xACE2   Test Identifier Registry</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
 <tr>
      <td>0x0000</td><td>Reserved</td><td>RFC 9946</td>
    </tr>
    <tr>
      <td>0x7F01-0x7FE0</td><td>Reserved for Experimental Use</td><td>RFC 9946</td>
    </tr>
    <tr>
      <td>0x7FE1-0x7FFF</td><td>Reserved for Private Use</td><td>RFC 9946</td>
    </tr>
    <tr>
      <td>0xACE1</td><td>Test Setup PDU</td><td>RFC 9946</td>
    </tr>
    <tr>
      <td>0xACE2</td><td>Test Activation PDU   &lt;this RFC&gt;

0xBEEF   Load PDU              &lt;this RFC&gt;

0xDEAD   Null PDU              &lt;this RFC&gt;

0xFEED   Status PDU</td><td>RFC 9946</td>
    </tr>
    <tr>
      <td>0xBEEF</td><td>Load PDU</td><td>RFC 9946</td>
    </tr>
    <tr>
      <td>0xDEAD</td><td>Null PDU</td><td>RFC 9946</td>
    </tr>
    <tr>
      <td>0xFEED</td><td>Status Feedback PDU   &lt;this RFC&gt;

</artwork>
            </figure>Table 2: Initial PDU Identifier Values</t> PDU</td><td>RFC 9946</td>
    </tr>
    <tr>  <td>0xFFFF</td><td>Reserved</td><td>RFC 9946</td>
    </tr>
  </tbody>
</table>
        </section>
        <section anchor="protocolVer" title="Protocol numbered="true" toc="default">
          <name>Protocol Version Registry"> Registry</name>
          <t>IANA will create has created the "Protocol Version" registry under the "UDP
          Speed Test Protocol (UDPSTP)" registry group. UDPSTP Test Setup
          Request, Test Setup Response Response, and Test Activation Request PDUs
          contain a two octet two-octet protocolVer field, identifying the version of
          the protocol in use. The code points in this registry are allocated
          according to the registration procedures <xref target="RFC8126"/> target="RFC8126" format="default"/>
          described in Table 3.</t>

          <t><figure>
              <artwork>Range(Decimal)         Registration <xref target="reg-proc-prot-ver-reg"/>.</t>

<table anchor="reg-proc-prot-ver-reg">
  <name>Registration Procedures
===============================================================
0-19                   Reserved

20-40960               IETF Review

40961-53248            Specification Required

53249-65534            Experimental

65535                  Reserved

</artwork>
            </figure>Table 3: Registration procedures for the Protocol Version
          registry</t>

          <t>Initially, IANA will assign the Registry</name>
  <thead>
    <tr>
      <th>Range(Decimal)</th>
      <th>Registration Procedures</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0-19</td>
      <td>Reserved</td>
    </tr>
    <tr>
      <td>20-40960</td>
      <td>IETF Review</td>
    </tr>
    <tr>
      <td>40961-53248</td>
      <td>Specification Required</td>
    </tr>
    <tr>
      <td>53249-65534</td>
      <td>Experimental Use</td>
    </tr>
    <tr>
      <td>65535</td>
      <td>Reserved</td>
    </tr>
  </tbody>
</table>
          <t>IANA has assigned decimal value 20 listed in Table
          4 in the "Protocol Version" registry:</t>

          <t><figure>
              <artwork>Value    Reference
================================================
20       &lt;this RFC&gt;

</artwork>
            </figure>Table 4: Initial registry as follows:</t>

<table anchor="init-pro-ver-val">
  <name>Initial Value of the Protocol Version value</t> Registry</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>20</td>
      <td>RFC 9946</td>
    </tr>
  </tbody>
</table>

        </section>
        <section anchor="Setup-modifierBitmap"
                 title="Test numbered="true" toc="default">
          <name>Test Setup PDU Modifier Bitmap Registry"> Registry</name>
          <t>IANA will create has created the "Test Setup PDU Modifier Bitmap" registry
          under the "UDP Speed Test Protocol (UDPSTP)" registry group. The
          Test Setup PDU layout contains a modifierBitmap field. The bitmaps
          in this registry are allocated according to the registration
          procedures <xref target="RFC8126"/> target="RFC8126" format="default"/> described in Table 5.</t>

          <t><figure>
              <artwork>Range(Bitmap)          Registration <xref target="reg-proc-test-set-pdu-mod-bit-reg"/>.</t>

<table anchor="reg-proc-test-set-pdu-mod-bit-reg">
	  <name>Registration Procedures
===============================================================
00000000-01111111      IETF Review

10000000               Reserved

</artwork>
            </figure>Table 5: Registration procedures for the Test Setup PDU Modifier Bitmap Registry</t>

          <t>Initially, IANA will assign the Registry</name>
	  <thead>
	    <tr>
	      <th>Range(Bitmap)</th>
              <th>Registration Procedures</th>
	    </tr>
	  </thead>
	  <tbody>
	    <tr>
	      <td>00000000-01111111</td>
	      <td>IETF Review</td>
	    </tr>
	    <tr>
	      <td>10000000</td>
              <td>Reserved</td>
	    </tr>
	  </tbody>
	</table>

          <t>IANA has assigned bitmap values defined by Table 6
          in the "Test Setup PDU Modifier Bitmap" registry.</t>

          <t><figure>
              <artwork>Value  Description             Reference
===============================================================
0x00   No modifications        &lt;this RFC&gt;

0x01   Allow registry as follows:</t>

<table anchor="init-test-set-pdu-mod-bit-val">
  <name>Initial Values of the Test Setup PDU Modifier Bitmap Registry</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0x00</td>
      <td>No modifications</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>0x01</td>
      <td>Allow Jumbo datagram    &lt;this RFC&gt; sizes above sending rates of 1 Gbps

0x02   Use Gbps</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>0x02</td>
      <td>Use Traditional MTU     &lt;this RFC&gt; (1500 bytes with
       IP-header)

</artwork>
            </figure>Table 6: Initial Test Setup PDU Modifier Bitmap
          values</t> IP-header)</td>
      <td>RFC 9946</td>
    </tr>
  </tbody>
</table>

        </section>
        <section anchor="Setup-authMode"
                 title="Test numbered="true" toc="default">
          <name>Test Setup PDU Authentication Mode Registry"> Registry</name>
          <t>IANA will create has created the "Test Setup PDU Authentication Mode"
          registry under the "UDP Speed Test Protocol (UDPSTP)" registry
          group. The Test Setup PDU layout contains an authMode field. The
          code points in this registry are allocated according to the
          registration procedures <xref target="RFC8126"/> target="RFC8126" format="default"/> described in Table
          7.</t>

          <t><figure>
              <artwork>Range(Decimal)         Registration
          <xref target="reg-proc-test-setup-pdu-auth-mode-reg"/>.</t>

<table anchor="reg-proc-test-setup-pdu-auth-mode-reg">
  <name>Registration Procedures
===============================================================
0-59                   IETF Review

60-63                  Experimental

64-255                 Reserved

</artwork>
            </figure>Table 7: Registration procedures for the Test Setup PDU Authentication Mode registry</t>

          <t>Initially, IANA will assign the Registry</name>
  <thead>
    <tr>
      <th>Range(Decimal)</th>
      <th>Registration Procedures</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0-59</td>
      <td>IETF Review</td>
    </tr>
    <tr>
      <td>60-63</td>
      <td>Experimental Use</td>
    </tr>
    <tr>
      <td>64-255</td>
      <td>Reserved</td>
    </tr>
  </tbody>
</table>

          <t>IANA has assigned decimal values defined by Table 8
          in the "Test Setup PDU Authentication Mode" registry.</t>

          <t><figure>
              <artwork>Value   Description                    Reference
===============================================================
0       Not used                       &lt;this RFC&gt;

1       Required registry as follows:</t>

<table anchor="init-test-set-pdu-auth-mode-values">
  <name>Initial Values of the Test Setup PDU Authentication Mode Registry</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>Not used</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>1</td>
      <td>Required authentication        &lt;this RFC&gt; for the Control phase

2       Optional phase</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>2</td>
      <td>Optional authentication for    &lt;this RFC&gt; the Data phase, in addition to the Control phase

</artwork>
            </figure>Table 8: Initial Test Setup PDU Authentication Mode
          values</t> phase</td>
      <td>RFC 9946</td>
    </tr>
  </tbody>
</table>

        </section>
        <section anchor="Error-codes"
                 title="Test numbered="true" toc="default">
          <name>Test Setup PDU Command Response Field Registry"> Registry</name>
          <t>IANA will create has created the "Test Setup PDU Command Response Field"
          registry under the "UDP Speed Test Protocol (UDPSTP)" registry
          group. The Test Setup PDU layout contains a cmdResponse field. The
          code points in this registry are allocated according to the
          registration procedures <xref target="RFC8126"/> target="RFC8126" format="default"/> described in Table
          9.</t>

          <t><figure>
              <artwork>Range(Decimal)         Registration
          <xref target="reg-proc-test-setup-pdu-comman-res-field-reg"/>.</t>

<table anchor="reg-proc-test-setup-pdu-comman-res-field-reg">
  <name>Registration Procedures
===============================================================
0-127                  IETF Review

128-239                Specification Required

240-249                Experimental

250-254                Private Use

255                    Reserved

</artwork>
            </figure>Table 9: Registration procedures for the Test Setup PDU Command Response Field Registry</t>

          <t>Initially, IANA will assign the Registry</name>
  <thead>
    <tr>
      <th>Range(Decimal)</th>
      <th>Registration Procedures</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0-127</td>
      <td>IETF Review</td>
    </tr>
    <tr>
      <td>128-239</td>
      <td>Specification Required</td>
    </tr>
    <tr>
      <td>240-249</td>
      <td>Experimental Use</td>
    </tr>
    <tr>
      <td>250-254</td>
      <td>Private Use</td>
    </tr>
    <tr>
      <td>255</td>
      <td>Reserved</td>
    </tr>
  </tbody>
</table>

          <t>IANA has assigned decimal values defined by Table
          10
          in the "Test Setup PDU Command Response Field" registry.</t>

          <t><figure>
              <artwork>Value   Description                    Reference
===============================================================
0       None registry as follows:</t>

<table anchor="init-test-setup-pdu-commend-res-field-val">
  <name>Initial Values of the Test Setup PDU Command Response Field Registry</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>None (used by                  &lt;this RFC&gt; client in Request)

1       Acknowledgment                 &lt;this RFC&gt;

2       Bad Protocol Version           &lt;this RFC&gt;

3       Invalid Request)</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>1</td>
      <td>Acknowledgment</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>2</td>
      <td>Bad protocol version</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>3</td>
      <td>Invalid Jumbo datagram         &lt;this RFC&gt;
        option

4       Unexpected Authentication      &lt;this RFC&gt; option</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>4</td>
      <td>Unexpected authentication in Setup Request

5       Authentication Request</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>5</td>
      <td>Authentication missing         &lt;this RFC&gt; in Setup Request

6       Invalid Request</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>6</td>
      <td>Invalid authentication         &lt;this RFC&gt;
        method

7       Authentication failure         &lt;this RFC&gt;

8       Authentication method</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>7</td>
      <td>Authentication failure</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>8</td>
      <td>Authentication time is         &lt;this RFC&gt; invalid in Setup Request

9       No Maximum Request</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>9</td>
      <td>No maximum test Bit bit rate       &lt;this RFC&gt;
        specified

10      Server Maximum Bit specified</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>10</td>
      <td>Server maximum bit rate        &lt;this RFC&gt;
        exceeded

11      MTU exceeded</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>11</td>
      <td>MTU option does not match      &lt;this RFC&gt;
        server

12      Multi-connection server</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>12</td>
      <td>Multi-connection parameters    &lt;this RFC&gt; rejected by server

13      Connection server</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>13</td>
      <td>Connection allocation          &lt;this RFC&gt; failure on server

</artwork>
            </figure>Table 10: Initial Test Setup PDU Command Response Field
          values</t> server</td>
      <td>RFC 9946</td>
    </tr>
     <tr>
      <td>240-249</td>
      <td>Reserved for Experimental Use</td>
      <td>RFC 9946</td>
     </tr>
         <tr>
      <td>250-254</td>
      <td>Reserved for Private Use</td>
      <td>RFC 9946</td>
	 </tr>
	 <tr>
      <td>255</td>
      <td>Reserved</td>
      <td>RFC 9946</td>
    </tr>
    </tbody>
    </table>

          <t>Note that value 4 is required for backward compatibility with
          previous experimental versions of software already in use. Further
          note, Further,
          value 6 signals that a client erroneously used an authMode
          which
          that hasn't been standardised standardized yet (i.e., authMode is greater than 1 or
          2).</t>
        </section>
        <section anchor="ActivationCmdRequest"
                 title="Test numbered="true" toc="default">
          <name>Test Activation PDU Command Request Registry"> Registry</name>
          <t>IANA will create has created the "Test Activation PDU Command Request"
          registry under the "UDP Speed Test Protocol (UDPSTP)" registry
          group. The Test Setup PDU layout contains a cmdRequest field. The
          code points in this registry are allocated according to the
          registration procedures <xref target="RFC8126"/> target="RFC8126" format="default"/> described in Table
          11.</t>

          <t><figure>
              <artwork>Range(Decimal)         Registration
          <xref target="reg-proc-test-act-pdu-command-req-reg"/>.</t>

<table anchor="reg-proc-test-act-pdu-command-req-reg">
  <name>Registration Procedures
===============================================================
0-127                  IETF Review

128-239                Specification Required

240-249                Experimental

250-254                Private Use

255                    Reserved

</artwork>
            </figure>Table 11: Registration procedures for the Test Activation PDU Command Request registry</t>

          <t>Initially, IANA will assign the Registry</name>
  <thead>
    <tr>
      <th>Range(Decimal)</th>
      <th>Registration Procedures</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0-127</td>
      <td>IETF Review</td>
    </tr>
    <tr>
      <td>128-239</td>
      <td>Specification Required</td>
    </tr>
    <tr>
      <td>240-249</td>
      <td>Experimental Use</td>
    </tr>
    <tr>
      <td>250-254</td>
      <td>Private Use</td>
    </tr>
    <tr>
      <td>255</td>
      <td>Reserved</td>
    </tr>
    </tbody>
    </table>

          <t>IANA has assigned decimal values defined by Table
          12
          in the "Test Activation PDU Command Request" registry.</t>

          <t><figure>
              <artwork>Value   Description                   Reference
===============================================================
0       No Request                    &lt;this RFC&gt;

1 registry as follows:</t>

<table anchor="init-test-act-pdu-comment-req-val">
  <name>Initial Values of the Test Activation PDU Command Request Registry</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>No Request</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>1</td>
      <td>Request test in Upstream      &lt;this RFC&gt; upstream direction (client to server)

2       Request server)</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>2</td>
      <td>Request test in Downstream    &lt;this RFC&gt; downstream direction (server to client)

</artwork>
            </figure>Table 12: Initial Test Activation PDU Command Request
          values</t> client)</td>
      <td>RFC 9946</td>
    </tr>
     <tr>
      <td>240-249</td>
      <td>Reserved for Experimental Use</td>
      <td>RFC 9946</td>
     </tr>
      <tr>
      <td>250-254</td>
      <td>Reserved for Private Use</td>
      <td>RFC 9946</td>
      </tr>
        <tr>
      <td>255</td>
      <td>Reserved</td>
      <td>RFC 9946</td>
    </tr>
  </tbody>
</table>

        </section>
        <section anchor="Activation-modifierBitmap"
                 title="Test numbered="true" toc="default">
          <name>Test Activation PDU Modifier Bitmap Registry"> Registry</name>
          <t>IANA will create has created the "Test Activation PDU Modifier Bitmap"
          registry under the "UDP Speed Test Protocol (UDPSTP)" registry
          group. The Test Activation PDU layout (also) contains a
          modifierBitmap field. The bitmaps in this registry are allocated
          according to the registration procedures <xref target="RFC8126"/> target="RFC8126" format="default"/>
          described in Table 13.</t>

          <t><figure>
              <artwork>Range(Bitmap)          Registration <xref target="reg-proc-test-act-pdu-mod-bit-reg"/>.</t>

<table anchor="reg-proc-test-act-pdu-mod-bit-reg">
  <name>Registration Procedures
===============================================================
00000000-01111111      IETF Review

10000000               Reserved

</artwork>
            </figure>Table 13: Registration procedures for the Test Activation PDU Modifier Bitmap registry</t>

          <t>Initially, IANA will assign the Registry</name>
  <thead>
    <tr>
      <th>Range(Bitmap)</th>
      <th>Registration Procedures</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>00000000-01111111</td>
      <td>IETF Review</td>
    </tr>
    <tr>
      <td>10000000</td>
      <td>Reserved</td>
    </tr>
  </tbody>
</table>

          <t>IANA has assigned bitmap values defined by Table 14
          in the "Test Activation PDU Modifier Bitmap" registry.</t>

          <t><figure>
              <artwork>Value    Description               Reference
===============================================================
0x00     No modifications          &lt;this RFC&gt;

0x01     Set registry as follows:</t>

<table anchor="init-test-act-pdu-mod-bit-val">
  <name>Initial Values of the Test Activation PDU Modifier Bitmap Registry</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0x00</td>
      <td>No modifications</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>0x01</td>
      <td>Set when srIndexConf is   &lt;this RFC&gt; start rate for search

0x02     Set search</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>0x02</td>
      <td>Set for randomized        &lt;this RFC&gt; UDP payload

</artwork>
            </figure>Table 14: Initial Test Activation PDU Modifier Bitmap
          values</t> payload</td>
      <td>RFC 9946</td>
    </tr>
  </tbody>
</table>

        </section>
        <section anchor="Activation-rateAdjAlgo"
                 title="Test numbered="true" toc="default">
          <name>Test Activation PDU Rate Adjustment Algo. Registry">
          <t>The Test Activation PDU layout contains a rateAdjAlgo field. The
          table below defines the assigned Capitalized alphabetic UTF-8 values
          in the registry.</t> Algo.&nbsp;Registry</name>
          <t>IANA will create has created the "Test Activation PDU Rate Adjustment Algo."
          registry under the "UDP Speed Test Protocol (UDPSTP)" registry
          group. The Test Activation PDU layout contains a rateAdjAlgo field.
          The code points in this registry are allocated according to the
          registration procedures <xref target="RFC8126"/> target="RFC8126" format="default"/> described in Table
          15.</t>

          <t><figure>
              <artwork>Range(Capital alphabet. UTF-8)     Registration
          <xref target="reg-proc-test-act-pdu-rate-adj-algo-reg"/>.</t>

<table anchor="reg-proc-test-act-pdu-rate-adj-algo-reg">
  <name>Registration Procedures
==========================================================
A-Y                                IETF review

Z                                  Reserved
</artwork>
            </figure>Table 15: Registration procedures for the Test Activation PDU Rate Adjustment Algo. registry</t>

          <t>Initially, IANA will assign the Capitalized Registry</name>
  <thead>
    <tr>
      <th>Range(Capital alphabet / UTF-8)</th>
      <th>Registration Procedures</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>A-Y</td>
      <td>IETF Review</td>
    </tr>
    <tr>
      <td>Z</td>
      <td>Reserved</td>
    </tr>
  </tbody>
  </table>

          <t>IANA has assigned capitalized alphabetic UTF-8
          values, as well as the corresponding incremental numeric, defined by
          Table 16 numeric values, in the "Test Activation PDU Rate Adjustment Algo."
          registry.</t>

          <t><figure>
              <artwork>Value(Numeric)   Description             Reference
========================================================
A(n/a)           Not used                &lt;this RFC&gt;

B(0)             Rate algorithm Type B   [Y.1540Amd2]

C(1)             Rate algorithm Type C   [TR-471]

</artwork>
            </figure>Table 16: Initial registry as follows:</t>

<table anchor="init-test-activ-pdu-rate-adj-val">
  <name>Initial Values of the Test Activation PDU Rate Adjustment Algo. values</t> Registry</name>
  <thead>
    <tr>
      <th>Value(Numeric)</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>A(n/a)</td>
      <td>Not used</td>
      <td>RFC 9946</td>
    </tr>
    <tr>
      <td>B(0)</td>
      <td>Rate algorithm Type B</td>
      <td><xref target="Y.1540Amd2"/></td>
    </tr>
    <tr>
      <td>C(1)</td>
      <td>Rate algorithm Type C</td>
      <td><xref target="TR-471"/></td>
    </tr>
  </tbody>
  </table>

        </section>
        <section anchor="Activation-cmdResponse"
                 title="Test numbered="true" toc="default">
          <name>Test Activation PDU Command Response Field Registry"> Registry</name>
          <t>IANA will create has created the "Test Activation PDU Command Response Field"
          registry under the "UDP Speed Test Protocol (UDPSTP)" registry
          group. The Test Activation PDU layout (also) contains a cmdResponse
          field. The code points in this registry are allocated according to
          the registration procedures <xref target="RFC8126"/> target="RFC8126" format="default"/> described in
          Table 17.</t>

          <t><figure>
              <artwork>Range(Decimal)         Registration
          <xref target="reg-proc-test-act-pdu-command-response-field-reg"/>.</t>

<table anchor="reg-proc-test-act-pdu-command-response-field-reg">
  <name>Registration Procedures
===============================================================
0-127                  IETF Review

128-239                Specification Required

240-249                Experimental

250-254                Private Use

255                    Reserved

</artwork>
            </figure>Table 17: Registration procedures for the Test Activation PDU Command Response Field registry</t>

          <t>Initially, IANA will assign the Registry</name>
  <thead>
    <tr>
      <th>Range(Decimal)</th>
      <th>Registration Procedures</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0-127</td>
      <td>IETF Review</td>
    </tr>
    <tr>
      <td>128-239</td>
      <td>Specification Required</td>
    </tr>
    <tr>
      <td>240-249</td>
      <td>Experimental Use</td>
    </tr>
    <tr>
      <td>250-254</td>
      <td>Private Use</td>
    </tr>
    <tr>
      <td>255</td>
      <td>Reserved</td>
    </tr>
  </tbody>
</table>

          <t>IANA has assigned decimal values defined by Table
          18
          in the "Test Activation PDU Command Response Field" registry.</t>

          <t><figure>
              <artwork>Value   Description                 Reference
===============================================================
0       None (used by               &lt;this RFC&gt;
        client in Request)

1       Server Acknowledgment       &lt;this RFC&gt;

2       Server indicates an error   &lt;this RFC&gt;

</artwork>
            </figure>Table 18: Initial registry as follows:</t>

<table anchor="init-test-act-pdu-command-resp-field-val">
	  <name>Initial Values of the Test Activation PDU Command Response Field values</t> Registry</name>
	  <thead>
	    <tr>
	      <th>Value</th>
	      <th>Description</th>
              <th>Reference</th>
	    </tr>
	  </thead>
	  <tbody>
	    <tr>
	      <td>0</td>
	      <td>None (used by client in Request)</td>
              <td>RFC 9946</td>
            </tr>
	    <tr>
	      <td>1</td>
	      <td>Server acknowledgment</td>
	      <td>RFC 9946</td>
	    </tr>
            <tr>
	      <td>2</td>
	      <td>Server indicates an error</td>
	      <td>RFC 9946</td>
	    </tr>
	     <tr>
	      <td>240-249</td>
	      <td>Reserved for Experimental Use</td>
	      <td>RFC 9946</td>
	     </tr>
	       <tr>
	      <td>250-254</td>
	      <td>Reserved for Private Use</td>
	      <td>RFC 9946</td>
	       </tr>
	         <tr>
	      <td>255</td>
	      <td>Reserved</td>
	      <td>RFC 9946</td>
	    </tr>
	    </tbody>
	    </table>

        </section>
      </section>
      <section title="Guidelines numbered="true" toc="default">
        <name>Guidelines for the Designated Experts"> Experts</name>
        <t>It is suggested that multiple designated experts be appointed for
        registry change requests.</t>
        <t>Criteria that should be applied by the designated experts include
        determining whether the proposed registration duplicates existing
        entries and whether the registration description is clear and fits the
        purpose of this registry.</t>
        <t>Registration requests are evaluated within a two-week review period
        on the advice of one or more designated experts. Within the review
        period, the designated experts will either approve or deny the
        registration request, communicating this decision to IANA. Denials
        should include an explanation and, if applicable, suggestions as to
        how to make the request successful.</t>
      </section>
    </section>

    <section title="Acknowledgments">
      <t>This document was edited by Al Morton, who passed away before being
      able to finalize this work. Ruediger Geib only joined later to help
      finalize this draft.</t>

      <t>Thanks to Lincoln Lavoie, Can Desem, Greg Mirsky, Bjoern Ivar Teigen,
      Ken Kerpez and Chen Li for reviewing this draft and providing helpful
      suggestions and areas for further development. Mohamed Boucadair's AD
      review improved comprehensibility of the document and he further
      navigated the document well through the final review stages. Tommy Pauly
      shepherded this document. Further comments by Gorry Fairhurst, Eric
      Vyncke, Roman Danyliw, Gunter van de Velde, Deb Cooley, Tianran Zhou,
      Andy Newton, Giuseppe Fioccola, Lars Eggert, Erik Kline and Benson Muite
      helped to shape the document. David Dong and Amanda Baber provided early
      reviews of the IANA Considerations section.</t>

      <t>Starting with the early SEC-DIR review, Brian Weis provided very
      constructive guidance regarding numerous security related protocol
      issues. Crypto Forum RG reviewed these parts, again providing guidance.
      Magnus Westerlund's review resulted in further changes and refinements.
      Ultimately, Paul Wouters' feedback was critical in finalizing the chosen
      security approach.</t>
    </section>

  </middle>
  <back>
    <references title="Normative References">
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5044.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5044.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7210.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7210.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8899.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8899.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9097.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9097.xml"/>

        <reference anchor="TR-471"
                 target="https://www.broadband-forum.org/technical/download/TR-471.pdf"> target="https://www.broadband-forum.org/pdfs/tr-471-4-0-0.pdf">
          <front>
          <title>Broadband Forum TR-471: IP Layer
            <title>Maximum IP-Layer Capacity Metrics Metric, Related Metrics,
and
          Measurement, Issue 4</title>

          <author fullname="" initials="Editor" surname="Morton, A,">
            <organization>AT&amp;T Labs</organization> Measurements</title>
<author>
  <organization>Broadband Forum</organization>
</author>
            <date day="" month="September" year="2024"/>
          </front>
          <refcontent>TR-471, Issue 4</refcontent>
        </reference>

        <reference anchor="Y.1540" derivedAnchor="Y.1540" quoteTitle="true" target="https://www.itu.int/rec/T-REC-Y.1540-201912-I/en">
          <front>
            <title>Internet protocol data communication service - IP packet
          transfer and availability performance parameters</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date month="December" year="2019"/>
          </front>

        <refcontent>ITU-T Recommendation Y.1540</refcontent>
          <seriesInfo name="ITU-T Recommendation" value="Y.1540"/>
        </reference>

        <reference anchor="Y.1540Amd2" derivedAnchor="Y.1540Amd2"
                 quoteTitle="true"
                 target="https://www.itu.int/rec/T-REC-Y.1540-201912-I/en"> target="https://www.itu.int/rec/T-REC-Y.1540-202303-I!Amd2/en">
          <front>
            <title>Internet protocol data communication service - IP packet
          transfer and availability performance parameters parameters, Amendment 2 -
          Revised Annex B: Additional search algorithms for IP-based capacity
          parameters and methods of measurement</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date month="March" year="2023"/>
          </front>
          <refcontent>ITU-T Recommendation Y.1540 Amd. 2</refcontent>
        </reference>

        <reference anchor="NIST800-108" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-108r1-upd1.pdf">
          <front>
            <title>Recommendation for Key Derivation Using Pseudorandom
          Functions (Revised, Update 1)</title>
          Functions</title>
            <author fullname="Lily Chen" initials="LC" surname="Chen"> Chen">
              <organization>National Institute of Standards and
            Technology</organization>
            </author>
            <date month="August" year="2022"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-108r1-upd1"/>
          <seriesInfo name="NIST SP" value="800-108r1-upd1"/>
        </reference>

      <reference anchor="C-Prog">
        <front>
          <title>ISO/IEC 9899:1999

<!-- [rfced] This reference points to the C99 version of the C Standard,
which has been withdrawn (see
<https://www.open-std.org/jtc1/sc22/wg14/www/projects#9899>). Should
this reference point specifically to the C99 version or should it
point to the most up-to-date version (ISO/IEC 9899:2024) as shown
below?

Current:
   [C-Prog]   ISO/IEC, "Programming languages - C", ISO/IEC 9899:1999,
              1999, <https://www.iso.org/standard/29237.html>.

Perhaps:
   [C-Prog]
              ISO/IEC, "Information technology - Programming languages
              - C", ISO/IEC 9899:2024, 2024,
              <https://www.iso.org/standard/82075.html>.
-->
        <reference anchor="C-Prog" target="https://www.iso.org/standard/29237.html">
          <front>
            <title>Programming languages -- C</title>
            <author>
              <organization>ISO/IEC</organization>
            </author>
            <date year="1999"/>
          </front>
          <seriesInfo name="ISO/IEC" value="9899:1999"/>
        </reference>

<!-- Note to PE: XML for possible update to [C-Prog]
(note I placed backslashes to avoid breaking XML comment)
        <reference anchor="C-Prog" target="https://www.iso.org/standard/82075.html">
          <front>
            <title>Information technology -/- Programming languages -/- C</title>
            <author>
              <organization>ISO/IEC</organization>
            </author>
            <date year="2024"/>
          </front>
          <seriesInfo name="ISO/IEC" value="9899:2024"/>
        </reference>
-->
      </references>

    <references title="Informative References">
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3148.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3148.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4656.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4656.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5136.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5136.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5357.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5357.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7497.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7497.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7594.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7594.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8337.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8337.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8762.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8762.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9145.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9145.xml"/>

        <reference anchor="EVP_KDF-KB" target="https://docs.openssl.org/master/man7/EVP_KDF-KB/">
          <front>
          <title>The
            <title>EVP_KDF-KB - The Key-Based EVP_KDF implementation</title>
            <author/>
          </front>
          <refcontent>OpenSSL Documentation</refcontent>
        </reference>

      </references>

    </references>
    <section anchor="KDF-Example" title="KDF numbered="true" toc="default">
      <name>KDF Example (OpenSSL)</name>

<!--[rfced] The KDF Example (OpenSSL)"> in Appendix A has 7 lines over the character
limit. Please let us know how you would like to break/wrap the
following lines.

Original:
 *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_MODE, "COUNTER", 0); - 8 characters over
 *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_MAC, "HMAC", 0); - 4 over
 *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_DIGEST, "SHA256", 0); - 9 over
 *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_KEY, Kin, strlen(Kin)); - 12 over
 *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SALT, "UDPSTP", 6); - 8 over
 *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_INFO, context, var); - 9 over
 *p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_USE_SEPARATOR, &var); - 7 over
-->

      <figure anchor="KDFfigure" title="KDF anchor="KDFfigure">
        <name>KDF Example Code Snippet">
        <artwork>
&lt;CODE BEGINS&gt; Snippet</name>
        <sourcecode name="" type="c" markers="true"><![CDATA[
//
// Output individual authentication keys of length SHA256_KEY_LEN
// from derived key material.
//
// Return Values: 0 = Failure, 1 = Success
//
int kdf_hmac_sha256(char *Kin, uint32_t authUnixTime,
  unsigned char *cAuthKey,   // Client key
  unsigned char *sAuthKey) { // Server key

  int var, keylen = SHA256_KEY_LEN * 2;
  char context[16];
  unsigned char *keyptr, keybuf[keylen];
  EVP_KDF *kdf = NULL;
  EVP_KDF_CTX *kctx = NULL;
  OSSL_PARAM params[16], *p = params;

  //
  // Fetch KDF algorithm and create context
  //
  if ((kdf = EVP_KDF_fetch(NULL, "KBKDF", NULL)) == NULL) {
    return 0;
  }
  if ((kctx = EVP_KDF_CTX_new(kdf)) == NULL) {
    EVP_KDF_free(kdf);
    return 0;
  }

  //
  // Set parameters for KBKDF
  // ---------------------------------------------------------
  *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_MODE, "COUNTER", 0);
  *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_MAC, "HMAC", 0);
  *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_DIGEST, "SHA256", 0);
  *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_KEY, Kin, strlen(Kin));
  *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SALT, "UDPSTP", 6);
  var = snprintf(context, sizeof(context), "%u", authUnixTime);
  *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_INFO, context, var);
  //
  // Confirm the following are enabled
  //
  var = 1;
  *p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_USE_L, &amp;var); &var);
  *p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_USE_SEPARATOR, &amp;var); &var);
  //
  // Set counter length in bits (available as of OpenSSL 3.1)
  //
  var = 32; // Length of 32 is backward compatible with OpenSSL 3.0
  *p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_R, &amp;var); &var);
  *p++ = OSSL_PARAM_construct_end();
  // ---------------------------------------------------------

  //
  // Derive key material
  //
  if (EVP_KDF_derive(kctx, keybuf, keylen, params) &lt; < 1) {
    EVP_KDF_CTX_free(kctx);
    EVP_KDF_free(kdf);
    return 0;
  }

  //
  // Output individual keys
  //
  keyptr = keybuf;
  memcpy(cAuthKey, keyptr, SHA256_KEY_LEN);
  keyptr += SHA256_KEY_LEN;
  memcpy(sAuthKey, keyptr, SHA256_KEY_LEN);

  //
  // Cleanup
  //
  EVP_KDF_CTX_free(kctx);
  EVP_KDF_free(kdf);
  return 1;
}
&lt;CODE ENDS&gt;
        </artwork>
]]></sourcecode>
      </figure>

    </section>

    <section numbered="false" toc="default">

<!--[rfced] How may we clarify "further navigated the document". Would
"provided further comments" be clearer as shown below?

Original:
   Mohamed Boucadair's AD review improved comprehensibility of the
   document, and he further navigated the document well through the
   final review stages.

Perhaps:
   Mohamed Boucadair's AD review improved comprehensibility of the
   document, and he provided further comments through the final
   review stages.
-->

      <name>Acknowledgments</name>
      <t>This document was edited by <contact fullname="Al Morton"/>, who
      passed away before being able to finalize this work. <contact
      fullname="Ruediger Geib"/> only joined later to help finalize this
      specification.</t>
      <t>Thanks to <contact fullname="Lincoln Lavoie"/>, <contact
      fullname="Can Desem"/>, <contact fullname="Greg Mirsky"/>, <contact
      fullname="Bjoern Ivar Teigen"/>, <contact fullname="Ken Kerpez"/>, and
      <contact fullname="Chen Li"/> for reviewing this specification and providing
      helpful suggestions and areas for further development. <contact
      fullname="Mohamed Boucadair"/>'s AD review improved comprehensibility of
      the document, and he further navigated the document well through the
      final review stages. <contact fullname="Tommy Pauly"/> shepherded this
      document. Further comments by <contact fullname="Gorry Fairhurst"/>,
      <contact fullname="Éric Vyncke"/>, <contact fullname="Roman Danyliw"/>,
      <contact fullname="Gunter Van de Velde"/>, <contact fullname="Deb
      Cooley"/>, <contact fullname="Tianran Zhou"/>, <contact fullname="Andy
      Newton"/>, <contact fullname="Giuseppe Fioccola"/>, <contact
      fullname="Lars Eggert"/>, <contact fullname="Erik Kline"/>, and <contact
      fullname="Benson Muite"/> helped to shape the document. <contact
      fullname="David Dong"/> and <contact fullname="Amanda Baber"/> provided
      early reviews of the IANA Considerations section.</t>
      <t>Starting with the early SEC-DIR review, <contact fullname="Brian
      Weis"/> provided constructive guidance regarding numerous security-related
      protocol issues. The Crypto Forum Research Group reviewed these parts, again
      providing guidance.  <contact fullname="Magnus Westerlund"/>'s review
      resulted in further changes and refinements.  Ultimately, <contact
      fullname="Paul Wouters"/>' feedback was critical in finalizing the
      chosen security approach.</t>
    </section>

  </back>

<!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).

Example:
   Note: When this specification is used for network debugging, it may
   be useful for fragmentation to be under the control of the test
   administrator.
-->

<!-- [rfced] Terminology

a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.

 [byte] vs. byte
 [ms] vs. ms vs. millisecond
 [s] vs. second
 [us] vs. us vs. microsecond

 Loss vs. loss

 Parameter vs. parameter

 Range vs. range

 Sending Rate Table vs. sending rate table
   [Note: RFC 9097 uses the lowercase form. Also consider
   whether the following terms need an update:
     - Sending Rate structure
     - Configured Sending Rate Table index]

b) FYI - We updated the following terms to reflect the forms on the
right for consistency within this document and/or with other
RFCs. Please let us know if any further updates are needed.

 Bit rate -> bit rate
 data phase -> Data phase
 command response -> Command Response
 Firewall -> firewall (per RFC 9097)
 IP-layer Capacity metric -> IP-layer Capacity Metric (per RFC 9097)
 Load Rate Adjustment Algorithm -> load rate adjustment algorithm
 Maximum IP-Layer Capacity metric -> Maximum IP-Layer Capacity Metric
                                      (per RFC 9097)
 message verification procedure -> Message Verification Procedure
 method of measurement -> Method of Measurement (Per 9097)
 Payload Content -> payload content (per 9097)
 Security mode of operation -> security mode of operation
 Setup request -> Setup Request
 test activation request -> Test Activation Request
 Test traffic -> test traffic (per RFC 9097)
 Traditional size -> traditional size

c) We note the following variances in the text - are these terms the
same or different? Please let us know if any updates are needed for
consistency.

  Bulk Transport Capacity vs. Bulk Capacity

  Command Server Response code vs. Command Response code

  Maximum IP-Layer Capacity Metric vs. Maximum IP Capacity

  Setup Request PDU (4 instances) vs. Request PDU (4 instances)
    [Note: Is "Request PDU" correct or should it be updated to
    "Setup Request PDU" or "Test Activation Request PDU"?]

d) "Sub-Interval" and "sisSav"

i) We note the following variances related to "sisSav" (placement and
inclusion of "saved"). Should these be made consistent?

Original:
   sisSav: Sub-interval statistics saved (completed)

   struct subIntStats sisSav;  // Sub-interval saved stats

   Sub-Interval Statistics structure (sisSav)

Perhaps:
   sisSav: Sub-interval statistics saved (completed)

   struct subIntStats sisSav;  // Sub-interval stats saved

   Sub-interval statistics saved (sisSav) structure

ii) We also note the following variances; please let us know
how we may make these consistent.

   Sub-Interval vs. Sub-interval vs. sub-interval

    Some examples:
      Sub-interval sequence
      Sub-interval period
      Sub-Interval byte count
      during the Sub-Interval
      each sub-interval is
      the last saved (completed) sub-interval

   Sub-Interval Statistics vs. Sub-interval statistics

e) We note the use of "Null Request". Should this perhaps be
"NULL Request", "NULL request", or other? We ask as we only
see "NULL request" used in other RFCs.

f) We note that the following terms appear as uppercase in the running
text but as lowercase in the descriptions in Figures 3, 5, 7, 9, and/or
11. Should we update the figures to reflect the uppercase forms for
consistency or is the case okay as is?

Current:
  Null request
  Command request
  command response
  load PDU
  Out-of-Order
  Sending rate structure
  Setup request
  Setup response
  Status feedback header
  status PDU

Perhaps:
  Null Request (or other per author response to the question above)
  Command Request
  Command Response
  Load PDU
  Out-of-order
  Sending Rate structure
  Setup Request
  Setup Response
  Status Feedback header
  Status PDU
-->

<!-- [rfced] Abbreviations

a) FYI - We have added expansions for the following abbreviations per
Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review these as
well as each expansion in the document carefully to ensure
correctness.

 Don't Fragment (DF)
 Hashed Message Authentication Code (HMAC)

b) FYI - We updated the following expansion to the form on the right for
correctness. Please let us know of any concerns.

 Packetization Layer Path MTU Discovery for Datagram Transports (DPLPMTUD) ->
   Datagram Packetization Layer PMTU Discovery (DPLPMTUD)

c) FYI - We updated "UDPST" to "UDPSTP" (one instance) as follows. Please
let us know if that is not correct.

Original:
   The number n may depend on the implementation and on typical
   characteristics of environments, where UDPST is deployed (like
   mobile networks or Wi-Fi).

Current:
   The number n may depend on the implementation and on typical
   characteristics of environments, where UDPSTP is deployed (like
   mobile networks or Wi-Fi).
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Please consider whether "traditional" should be updated for clarity.
While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/
nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.
-->

</rfc>