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

<!-- [CS] updated by Chris 06/14/21 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> "rfc2629-xhtml.ent">

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

  <!-- xml2rfc v2v3 conversion 3.8.0 -->
  <front>
    <title abbrev="IP Capacity Metrics/Methods">Metrics and Methods for
    One-way
    One-Way IP Capacity</title>
    <seriesInfo name="RFC" value="9097"/>
    <author fullname="Al Morton" initials="A." surname="Morton">
      <organization>AT&amp;T Labs</organization>
      <address>
        <postal>
          <street>200 Laurel Avenue South</street>
          <city>Middletown</city>
          <region>NJ</region>
          <code>07748</code>

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

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

        <uri/>
      </address>
    </author>
    <author fullname="Ruediger fullname="Rüdiger Geib" initials="R." surname="Geib">
      <organization>Deutsche Telekom</organization>
      <address>
        <postal>
          <street>Heinrich Hertz Str. 3-7</street>
          <city>Darmstadt</city>

          <region/>
          <code>64295</code>
          <country>Germany</country>
        </postal>
        <phone>+49 6151 5812747</phone>

        <facsimile/>
        <email>Ruediger.Geib@telekom.de</email>

        <uri/>
      </address>
    </author>
    <author fullname="Len Ciavattone" initials="L." surname="Ciavattone">
      <organization>AT&amp;T Labs</organization>
      <address>
        <postal>
          <street>200 Laurel Avenue South</street>
          <city>Middletown</city>
          <region>NJ</region>
          <code>07748</code>

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

        <phone/>

        <facsimile/>
        <phone>+1 732 420 1239</phone>
        <email>lencia@att.com</email>

        <uri/>
      </address>
    </author>
    <date day="9" month="June" month="November" year="2021"/>

<keyword>IP Layer</keyword>
<keyword>Performance</keyword>
<keyword>Speed</keyword>
<keyword>Access</keyword>

    <abstract>
      <t>This memo revisits the problem of Network Capacity metrics Metrics first
      examined in RFC 5136. The This memo specifies a more practical Maximum
      IP-Layer Capacity metric Metric definition catering for to measurement purposes,
      and outlines the corresponding methods Methods of measurement.</t> Measurement.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The IETF's efforts to define Network Capacity and Bulk Transport Capacity (BTC) have
      been chartered and progressed for over twenty years. Over that time, the
      performance community has seen the development of Informative definitions in
      <xref target="RFC3148"/> target="RFC3148" format="default"/> for the Framework for Bulk Transport Capacity
      (BTC), RFC 5136 Capacity, <xref target="RFC5136"/> for Network Capacity and Maximum IP-Layer Capacity, and the Experimental metric definitions and methods in
"<xref target="RFC8337" format="title"/>" <xref
      target="RFC8337"/>, Model-Based Metrics for BTC.</t> target="RFC8337" format="default"/>.</t>
      <t>This memo revisits the problem of Network Capacity metrics Metrics examined
      first in <xref target="RFC3148"/> target="RFC3148" format="default"/> and later in <xref target="RFC5136"/>. target="RFC5136" format="default"/>.
      Maximum IP-Layer Capacity and <xref target="RFC3148"/> Bulk Transfer Capacity <xref target="RFC3148" format="default"/> (goodput) are different metrics. Maximum IP-Layer Capacity is
      like the theoretical goal for goodput. There are many metrics in <xref
      target="RFC5136"/>, target="RFC5136" format="default"/>, such as Available Capacity. Measurements depend on
      the network path under test and the use case. Here, the main use case is
      to assess the maximum capacity Maximum Capacity of one or more networks where the
      subscriber receives specific performance assurances, sometimes referred
      to as the Internet access, or where a limit of the technology used on a
      path is being tested. For example, when a user subscribes to a 1 Gbps
      service, then the user, the service provider, Service Provider, and possibly other parties
      want to assure that the specified performance level is delivered. When a test confirms
      the subscribed performance level, then a tester can seek the location of
      a bottleneck elsewhere.</t>
      <t>This memo recognizes the importance of a definition of a Maximum
      IP-Layer Capacity Metric at a time when Internet subscription speeds
      have increased dramatically; dramatically -- a definition that is both practical and
      effective for the performance community's needs, including Internet
      users. The metric definition is definitions are intended to use Active Methods of
      Measurement <xref target="RFC7799"/>, target="RFC7799" format="default"/>, and a method Method of measurement Measurement is
      included.</t>
      included for each metric.</t>
      <t>The most direct active measurement Active Measurement of IP-Layer Capacity would use IP
      packets, but in practice a transport header is needed to traverse
      address and port translators. UDP offers the most direct assessment
      possibility, and in the <xref target="copycat"/> measurement study to investigate whether UDP is viable as a general Internet transport
      protocol, protocol <xref target="copycat" format="default"/>, the authors found that a high percentage of paths tested
      support UDP transport. A number of liaisons liaison statements have been exchanged on this
      topic <xref target="LS-SG12-A"/> target="LS-SG12-A" format="default"/> <xref target="LS-SG12-B"/>, target="LS-SG12-B" format="default"/>, discussing
      the laboratory and field tests that support the UDP-based approach to
      IP-Layer Capacity measurement.</t>
      <t>This memo also recognizes the many updates to the IP Performance
      Metrics (IPPM) Framework <xref target="RFC2330"/> target="RFC2330" format="default"/> that have been published over twenty years,
      and since 1998. In particular, it makes use of <xref target="RFC7312"/> target="RFC7312" format="default"/> for the Advanced Stream and
      Sampling Framework, Framework and <xref target="RFC8468"/> with target="RFC8468" format="default"/> for its IPv4, IPv6, and
      IPv4-IPv6 Coexistence Updates.</t>

      <t>Appendix A
      <t><xref target="app-a-load-rate-adj-pseudocode"/> describes the load rate adjustment algorithm in
      pseudo-code. Appendix B algorithm, using
      pseudocode. <xref target="app-b-rfc8085-udp"/> discusses the algorithm's compliance with <xref
      target="RFC8085"/>.</t> target="RFC8085" format="default"/>.</t>
      <section title="Requirements Language"> 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<xref BCP&nbsp;14
       <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section title="Scope, anchor="sec-2-scope" numbered="true" toc="default">
      <name>Scope, Goals, and Applicability"> Applicability</name>
      <t>The scope of this memo is to define Active Measurement metrics and
      corresponding methods to unambiguously determine Maximum IP-Layer
      Capacity and useful secondary metrics.</t>
      <t>Another goal is to harmonize the specified metric Metric and method Method across
      the industry, and this memo is the vehicle that captures IETF consensus,
      possibly resulting in changes to the specifications of other Standards
      Development Organizations (SDO) (SDOs) (through each SDO's normal contribution
      process,
      process or through liaison exchange).</t>
      <t>Secondary goals are to add considerations for test procedures, procedures and to
      provide interpretation of the Maximum IP-Layer Capacity results (to
      identify cases where more testing is warranted, possibly with alternate
      configurations). Fostering the development of protocol support for this
      metric
      Metric and method Method of measurement Measurement is also a goal of this memo (all active
      testing protocols currently defined by the IPPM WG are UDP-based, UDP based,
      meeting a key requirement of these methods). The supporting protocol
      development to measure this metric according to the specified method is
      a key future contribution to Internet measurement.</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 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 accurate, and throughput of
      competing elastic traffic may be greatly reduced.</t>
      <t>The primary application of the metric Metrics and method Methods of measurement Measurement
      described here is the same as what is described in Section 2 of <xref target="RFC7497"/>
      where:<list style="symbols">
          <t>The target="RFC7497" sectionFormat="of" section="2"/>, where:</t>

        <blockquote>The access portion of the network is the focus of this problem
          statement. The user typically subscribes to a service with
          bidirectional Internet [Internet] access partly described by rates in bits per
          second.</t>
        </list>In
          second.</blockquote>
      <t>In addition, the use of the load rate adjustment algorithm
      described in section 8.1 <xref target="load-rate-adj"/> has the following additional applicability
      limitations:</t>

      <t>- MUST
      <ul spacing="normal">
      <li>It <bcp14>MUST</bcp14> only be used in the application of diagnostic and operations
      measurements as described in this memo</t>

      <t>- MUST memo.</li>
      <li>It <bcp14>MUST</bcp14> only be used in circumstances consistent with Section 10,
      Security Considerations</t>

      <t>- If
      <xref target="sec-cons"/> ("Security Considerations").</li>
      <li>If a network operator is certain of the IP-layer capacity IP-Layer Capacity to be
      validated, then testing MAY <bcp14>MAY</bcp14> start with a fixed rate fixed-rate test at the IP-layer
      capacity IP-Layer
      Capacity and avoid activating the load adjustment algorithm. However,
      the stimulus for a diagnostic test (such as a subscriber request)
      strongly implies that there is no certainty certainty, and the load adjustment
      algorithm is RECOMMENDED.</t> <bcp14>RECOMMENDED</bcp14>.</li>
      </ul>
      <t>Further, the metric Metrics and method Methods of measurement Measurement are intended for use
      where specific exact path information is unknown within a range of
      possible values:</t>

      <t>- the
      <ul spacing="normal">
      <li>The subscriber's exact Maximum IP-Layer Capacity is unknown (which
      is sometimes the case; service rates can be increased due to upgrades
      without a subscriber's request, request or increased to provide a surplus to compensate
      for possible underestimates of TCP-based testing).</t>

      <t>- the testing).</li>
      <li>The size of the bottleneck buffer is unknown.</t> unknown.</li>
      </ul>
      <t>Finally, the measurement system's load rate adjustment algorithm
      SHALL NOT
      <bcp14>SHALL NOT</bcp14> be provided with the exact capacity value to be validated a
      priori. a&nbsp;priori. This restriction fosters a fair result, result and removes an
      opportunity for bad actors to operate with nefarious operation enabled by knowledge of the "right
      answer".</t> correct answer.</t>
    </section>
    <section title="Motivation"> numbered="true" toc="default">
      <name>Motivation</name>
      <t>As with any problem that has been worked on for many years in various
      SDOs without any special attempts at coordination, various solutions for
      metrics
      Metrics and methods Methods have emerged.</t>
      <t>There are five factors that have changed (or begun began to change) in the
      2013-2019 time frame, and the presence of any one of them on the path
      requires features in the measurement design to account for the
      changes:</t>

      <t><list style="numbers">
          <t>Internet
      changes:

</t>
      <ol spacing="normal" type="1"><li>Internet access is no longer the bottleneck for many users (but
          subscribers expect network providers to honor contracted
          performance).</t>

          <t>Both
          performance).</li>
        <li>Both transfer rate and latency are important to a user's
          satisfaction.</t>

          <t>UDP's growing
          satisfaction.</li>
        <li>UDP's role in Transport, transport is growing in areas where TCP once
          dominated.</t>

          <t>Content
          dominated.</li>
        <li>Content and applications are moving physically closer to
          users.</t>

          <t>There
          users.</li>
        <li>There is less emphasis on ISP gateway measurements, possibly due
          to less traffic crossing ISP gateways in the future.</t>
        </list></t> future.</li>
      </ol>
    </section>
    <section title="General anchor="gen-params-defs" numbered="true" toc="default">
      <name>General Parameters and Definitions"> Definitions</name>
      <t>This section lists the REQUIRED <bcp14>REQUIRED</bcp14> input factors to specify a Sender or
      Receiver metric.<list style="symbols">
          <t>Src, one metric.</t>
      <dl spacing="normal">
        <dt>Src:</dt><dd>One of the addresses of a host (such as a globally routable
          IP address).</t>

          <t>Dst, one address).</dd>
        <dt>Dst:</dt><dd>One of the addresses of a host (such as a globally routable
          IP address).</t>

          <t>MaxHops, the address).</dd>
        <dt>MaxHops:</dt><dd>The limit on the number of Hops a specific packet may
          visit as it traverses from the host at Src to the host at Dst
          (implemented in the TTL or Hop Limit).</t>

          <t>T0, the Limit).</dd>
        <dt>T0:</dt><dd>The time at the start of a measurement interval, when packets
          are first transmitted from the Source.</t>

          <t>I, the Source.</dd>
        <dt>I:</dt><dd>The nominal duration of a measurement interval at the
          destination
          Destination (default 10 sec)</t>

          <t>dt, the sec).</dd>
        <dt>dt:</dt><dd>The nominal duration of m equal sub-intervals in I at the
          destination
          Destination (default 1 sec)</t>

          <t>dtn, the sec).</dd>
        <dt>dtn:</dt><dd>The beginning boundary of a specific sub-interval, n, one of
          m sub-intervals in I</t>

          <t>FT, the I.</dd>
        <dt>FT:</dt><dd>The feedback time interval between status feedback messages
          communicating measurement results, sent from the receiver Receiver to control
          the sender. Sender. The results are evaluated throughout the test to
          determine how to adjust the current offered load rate at the sender Sender
          (default 50ms)</t>

          <t>Tmax, a 50 msec).</dd>
        <dt>Tmax:</dt><dd>A maximum waiting time for test packets to arrive at the
          destination,
          Destination, set sufficiently long to disambiguate packets with long
          delays from packets that are discarded (lost), such that the
          distribution of one-way delay is not truncated.</t>

          <t>F, the truncated.</dd>
        <dt>F:</dt><dd>The number of different flows synthesized by the method
          (default 1 flow)</t>

          <t>flow, the one flow).</dd>
        <dt>Flow:</dt><dd>The stream of packets with the same n-tuple of designated
          header fields that (when held constant) result in identical
          treatment in a multi-path multipath decision (such as the decision taken in
          load balancing). Note: The IPv6 flow label SHOULD <bcp14>SHOULD</bcp14> be included in the
          flow definition when routers have complied with <xref
          target="RFC6438"/> guidelines.</t>

          <t>Type-P, the guidelines provided in <xref target="RFC6438" format="default"/>.</dd>
        <dt>Type-P:</dt><dd>The complete description of the test packets for which
          this assessment applies (including the flow-defining fields). Note
          that the UDP transport layer is one requirement for test packets
          specified below. Type-P is a parallel concept parallel to "population of
          interest" as defined in clause Clause 6.1.1 of<xref target="Y.1540"/>.</t>

          <t>Payload Content, this IPPM Framework-conforming metric and method
          includes packet payload content as an of <xref target="Y.1540" format="default"/>.</dd>
        <dt>Payload Content:</dt><dd>An aspect of the Type-P
          parameter, which Parameter that
can help to improve measurement determinism. Specifying packet payload content
helps to ensure IPPM Framework-conforming Metrics and Methods. If
          there is payload compression in the path and tests intend to
          characterize a possible advantage due to compression, then payload
          content SHOULD <bcp14>SHOULD</bcp14> be supplied by a pseudo-random pseudorandom sequence generator, by
          using part of a compressed file, or by other means. See Section
          3.1.2 of
          <xref target="RFC7312"/>.</t>

          <t>PM, a target="RFC7312" sectionFormat="of" section="3.1.2"/>.</dd>
        <dt>PM:</dt><dd>A list of fundamental metrics, such as loss, delay, and
          reordering, and corresponding target performance threshold. threshold(s). At least
          one fundamental metric and target performance threshold MUST <bcp14>MUST</bcp14> be
          supplied (such as One-way one-way IP Packet Loss packet loss <xref target="RFC7680"/> target="RFC7680" format="default"/>
          equal to zero).</t>
        </list>A zero).</dd>
      </dl>
      <t>A non-Parameter which that is required for several metrics is
      defined below:</t>

      <t><list style="symbols">
          <t>T, the
      <dl spacing="normal">
        <dt>T:</dt><dd>The host time of the *first* <strong>first</strong> test packet's *arrival* <strong>arrival</strong> as
          measured at the destination Destination Measurement Point, or MP(Dst). There may
          be other packets sent between Source and Destination hosts that are
          excluded, so this is the time of arrival of the first packet used
          for measurement of the metric.</t>
        </list>Note metric.</dd>
      </dl>
      <t>Note that time stamp timestamp format and resolution, sequence numbers,
      etc. will be established by the chosen test protocol standard or
      implementation.</t>
    </section>
    <section title="IP-Layer numbered="true" toc="default">
      <name>IP-Layer Capacity Singleton Metric Definitions"> Definitions</name>
      <t>This section sets requirements for the singleton Singleton metric that supports
      the Maximum IP-Layer Capacity Metric definition definitions in Section 6.</t> <xref target="max-ip-metric-defs"/>.</t>
      <section title="Formal Name">
        <t>Type-P-One-way-IP-Capacity, or numbered="true" toc="default">
        <name>Formal Name</name>
        <t>"Type-P-One-way-IP-Capacity" is the formal name; it is informally called IP-Layer
        Capacity.</t> "IP-Layer Capacity".</t>
        <t>Note that Type-P depends on the chosen method.</t>
      </section>
      <section title="Parameters"> numbered="true" toc="default">
        <name>Parameters</name>
        <t>This section lists the REQUIRED <bcp14>REQUIRED</bcp14> input factors to specify the
        metric, beyond those listed in Section 4.</t> <xref target="gen-params-defs"/>.</t>
        <t>No additional Parameters are needed.</t>
      </section>
      <section title="Metric Definitions"> numbered="true" toc="default">
        <name>Metric Definitions</name>
        <t>This section defines the REQUIRED <bcp14>REQUIRED</bcp14> aspects of the measurable
        IP-Layer Capacity metric Metric (unless otherwise indicated) for measurements
        between specified Source and Destination hosts:</t>
        <t>Define the IP-Layer Capacity, C(T,dt,PM), to be the number of
        IP-Layer bits (including header and data fields) in packets that can
        be transmitted from the Src host and correctly received by the Dst
        host during one contiguous sub-interval, dt in length. The IP-Layer
        Capacity depends on the Src and Dst hosts, the host addresses, and the
        path between the hosts.</t>
        <t>The number of these IP-Layer bits is designated n0[dtn,dtn+1] for a
        specific dt.</t>
        <t>When the packet size is known and of fixed size, the packet count
        during a single sub-interval dt multiplied by the total bits in IP
        header and data fields is equal to n0[dtn,dtn+1].</t>
        <t>Anticipating a Sample of Singletons, the number of sub-intervals
        with duration dt MUST <bcp14>MUST</bcp14> be set to a natural number m, so that T+I = T +
        m*dt with dtn+1 - dtn = dt for 1 &lt;= n &lt;= m.</t>
        <t>Parameter PM represents other performance metrics [see section 5.4
        below]; (see <xref target="sec5-4-rt-delay"/>
        below); their measurement results SHALL <bcp14>SHALL</bcp14> be collected during
        measurement of IP-Layer Capacity and associated with the corresponding
        dtn for further evaluation and reporting. Users SHALL <bcp14>SHALL</bcp14> specify the
        parameter
        Parameter Tmax as required by each metric's reference definition.</t>
        <t>Mathematically, this definition is represented as (for each n):</t>

        <t><figure title="Equation
        <figure>
          <name>Equation for IP-Layer Capacity"> Capacity</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="ascii-art" alt=""><![CDATA[
                 ( n0[dtn,dtn+1] )
 C(T,dt,PM) = -------------------------
                        dt
]]></artwork>
          </figure>and:<list style="symbols">
            <t>n0
        </figure>
        <t>and:</t>
        <ul spacing="normal">
          <li>n0 is the total number of IP-Layer header and payload bits that
            can be transmitted in standard-formed packets <xref
            target="RFC8468"/> target="RFC8468" format="default"/> from the Src host and correctly received by the
            Dst host during one contiguous sub-interval, dt in length, during
            the interval [T, T+I],</t>

            <t>C(T,dt,PM) [T,T+I].</li>
          <li>C(T,dt,PM), the IP-Layer Capacity, corresponds to the value of
            n0 measured in any sub-interval beginning at dtn, divided by the
            length of the sub-interval, dt.</t>

            <t>PM dt.</li>
          <li>PM represents other performance metrics [see section 5.4
            below]; (see <xref target="sec5-4-rt-delay"/>
            below); their measurement results SHALL <bcp14>SHALL</bcp14> be collected during
            measurement of IP-Layer Capacity and associated with the
            corresponding dtn for further evaluation and reporting.</t>

            <t>all reporting.</li>
          <li>All sub-intervals MUST <bcp14>MUST</bcp14> be of equal duration. Choosing dt as
            non-overlapping consecutive time intervals allows for a simple
            implementation.</t>

            <t>The
            implementation.</li>
          <li>The bit rate of the physical interface of the measurement
            devices MUST <bcp14>MUST</bcp14> be higher than the smallest of the links on the path
            whose C(T,I,PM) is to be measured (the bottleneck link).</t>
          </list></t> link).</li>
        </ul>
        <t>Measurements according to these definitions SHALL this definition <bcp14>SHALL</bcp14> use the UDP
        transport layer. Standard-formed packets are specified in Section 5 of <xref target="RFC8468"/>. target="RFC8468" sectionFormat="of" section="5"/>. The measurement SHOULD <bcp14>SHOULD</bcp14> use a randomized
        Source port or equivalent technique, and SHOULD <bcp14>SHOULD</bcp14> send responses from
        the Source address matching the test packet destination Destination address.</t>
        <t>Some effects of compression affects on measurement are discussed in Section 6
        of
<xref target="RFC8468"/>.</t> target="RFC8468" sectionFormat="of" section="6"/>.</t>
      </section>
      <section title="Related anchor="sec5-4-rt-delay" numbered="true" toc="default">
        <name>Related Round-Trip Delay and One-way One-Way Loss Definitions"> Definitions</name>
        <t>RTD[dtn,dtn+1] is defined as a Sample of the <xref
        target="RFC2681"/> Round-trip Round-Trip Delay <xref target="RFC2681" format="default"/> between the Src host and the Dst
        host over during the interval [T,T+I] (that contains equal non-overlapping
        intervals of dt). The "reasonable period of time" mentioned in <xref
        target="RFC2681"/> target="RFC2681" format="default"/> is the parameter Parameter Tmax in this memo. The statistics
        used to summarize RTD[dtn,dtn+1] MAY <bcp14>MAY</bcp14> include the minimum, maximum,
        median, and mean, and the range = (maximum - minimum) is referred to
        below in Section 8.1 minimum). Some of these statistics are needed for load adjustment purposes.</t> purposes (<xref target="load-rate-adj"/>), measurement qualification (<xref target="meas-qual-verif"/>), and reporting (<xref target="rpt-formats"/>).
</t>
        <t>OWL[dtn,dtn+1] is defined as a Sample of the <xref
        target="RFC7680"/> One-way One-Way Loss <xref target="RFC7680" format="default"/> between the Src host and the Dst host
        over
        during the interval [T,T+I] (that contains equal non-overlapping
        intervals of dt). The statistics used to summarize OWL[dtn,dtn+1] MAY <bcp14>MAY</bcp14>
        include the lost packet count of lost packets and the ratio of lost packet ratio.</t> packets.</t>
        <t>Other metrics MAY <bcp14>MAY</bcp14> be measured: one-way reordering, duplication, and
        delay variation.</t>
      </section>
      <section title="Discussion"> numbered="true" toc="default">
        <name>Discussion</name>
        <t>See the corresponding section for Maximum IP-Layer Capacity.</t> Capacity (<xref target="Maximum-IP-Layer-Capacity-Discussion" format="default"/>).
</t>
      </section>
      <section title="Reporting numbered="true" toc="default">
        <name>Reporting the Metric"> Metric</name>
        <t>The IP-Layer Capacity SHOULD <bcp14>SHOULD</bcp14> be reported with at least single
        Megabit
        single-Megabit resolution, in units of Megabits per second (Mbps), (which (Mbps) (which,
        to avoid any confusion, is 1,000,000 bits per second to avoid any confusion).</t> second).</t>
        <t>The related One-way One-Way Loss metric and Round Trip Round-Trip Delay measurements
        for the same Singleton SHALL <bcp14>SHALL</bcp14> be reported, also with meaningful
        resolution for the values measured.</t>
        <t>Individual Capacity measurements MAY <bcp14>MAY</bcp14> be reported in a manner
        consistent with the Maximum IP-Layer Capacity, Capacity; see Section 9.</t> <xref target="rpt-formats"/>.</t>
      </section>
    </section>
    <section title="Maximum anchor="max-ip-metric-defs" numbered="true" toc="default">
      <name>Maximum IP-Layer Capacity Metric Definitions (Statistic)"> (Statistics)</name>
      <t>This section sets requirements for the following components to
      support the Maximum IP-Layer Capacity Metric.</t>
      <section title="Formal Name">
        <t>Type-P-One-way-Max-IP-Capacity, or numbered="true" toc="default">
        <name>Formal Name</name>
        <t>"Type-P-One-way-Max-IP-Capacity" is the formal name; it is informally called Maximum "Maximum IP-Layer Capacity.</t> Capacity".</t>
        <t>Note that Type-P depends on the chosen method.</t>
      </section>
      <section title="Parameters"> numbered="true" toc="default">
        <name>Parameters</name>
        <t>This section lists the REQUIRED <bcp14>REQUIRED</bcp14> input factors to specify the
        metric, beyond those listed in Section 4.</t> <xref target="gen-params-defs"/>.</t>
        <t>No additional Parameters or definitions are needed.</t>
      </section>
      <section title="Metric Definitions"> numbered="true" toc="default">
        <name>Metric Definitions</name>
        <t>This section defines the REQUIRED <bcp14>REQUIRED</bcp14> aspects of the Maximum IP-Layer
        Capacity metric Metric (unless otherwise indicated) for measurements between
        specified Source and Destination hosts:</t>
        <t>Define the Maximum IP-Layer Capacity, Maximum_C(T,I,PM), to be the
        maximum number of IP-Layer bits n0[dtn,dtn+1] divided by dt that can
        be transmitted in packets from the Src host and correctly received by
        the Dst host, over all dt length dt-length intervals in [T, T+I], [T,T+I] and meeting
        the PM criteria. Equivalently An equivalent definition would be the Maximum maximum of a Sample of size m of Singletons
        C(T,I,PM) collected during the interval [T, T+I] [T,T+I] and meeting the PM
        criteria.</t>
        <t>The number of sub-intervals with duration dt MUST <bcp14>MUST</bcp14> be set to a
        natural number m, so that T+I = T + m*dt with dtn+1 - dtn = dt for 1
        &lt;= n &lt;= m.</t>
        <t>Parameter PM represents the other performance metrics (see Section
        6.4
        <xref target="sec6-4-rt-delay"/> below) and their measurement results for the Maximum IP-Layer
        Capacity. At least one target performance threshold (PM criterion)
        MUST
        <bcp14>MUST</bcp14> be defined. If more than one metric and target performance
        threshold are is defined, then the sub-interval with the maximum number of
        bits transmitted MUST <bcp14>MUST</bcp14> meet all the target performance thresholds.
        Users SHALL <bcp14>SHALL</bcp14> specify the parameter Parameter Tmax as required by each metric's
        reference definition.</t>
        <t>Mathematically, this definition can be represented as:</t>

        <t><figure title="Equation
        <figure>
          <name>Equation for Maximum Capacity"> Capacity</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="ascii-art" alt=""><![CDATA[
                        max  ( n0[dtn,dtn+1] )
                        [T,T+I]
  Maximum_C(T,I,PM) = -------------------------
                                 dt

  where:

    T                                      T+I
    _________________________________________
    |   |   |   |   |   |   |   |   |   |   |
dtn=1   2   3   4   5   6   7   8   9  10  n+1
                                       n=m
]]></artwork>
          </figure>and:<list style="symbols">
            <t>n0
        </figure>
        <t>and:</t>
        <ul spacing="normal">
          <li>n0 is the total number of IP-Layer header and payload bits that
            can be transmitted in standard-formed packets from the Src host
            and correctly received by the Dst host during one contiguous
            sub-interval, dt in length, during the interval [T, T+I],</t>

            <t>Maximum_C(T,I,PM) [T,T+I].</li>
          <li>Maximum_C(T,I,PM), the Maximum IP-Layer Capacity, corresponds to
            the maximum value of n0 measured in any sub-interval beginning at
            dtn, divided by the constant length of all sub-intervals, dt.</t>

            <t>PM dt.</li>
          <li>PM represents the other performance metrics (see Section 5.4) <xref target="sec6-4-rt-delay"/>)
            and their measurement results for the Maximum IP-Layer Capacity.
            At least one target performance threshold (PM criterion) MUST <bcp14>MUST</bcp14> be
            defined.</t>

            <t>all
            defined.</li>
          <li>All sub-intervals MUST <bcp14>MUST</bcp14> be of equal duration. Choosing dt as
            non-overlapping consecutive time intervals allows for a simple
            implementation.</t>

            <t>The
            implementation.</li>
          <li>The bit rate of the physical interface of the measurement
            systems MUST <bcp14>MUST</bcp14> be higher than the smallest of the links on the path
            whose Maximum_C(T,I,PM) is to be measured (the bottleneck
            link).</t>
          </list></t>
            link).</li>
        </ul>
        <t>In this definition, the m sub-intervals can be viewed as trials
        when the Src host varies the transmitted packet rate, searching for
        the maximum n0 that meets the PM criteria measured at the Dst host in
        a test of duration, duration I. When the transmitted packet rate is held
        constant at the Src host, the m sub-intervals may also be viewed as
        trials to evaluate the stability of n0 and metric(s) in the PM list
        over all dt-length intervals in I.</t>
        <t>Measurements according to these definitions SHALL <bcp14>SHALL</bcp14> use the UDP
        transport layer.</t>
      </section>
      <section title="Related anchor="sec6-4-rt-delay" numbered="true" toc="default">
        <name>Related Round-Trip Delay and One-way One-Way Loss Definitions"> Definitions</name>
        <t>RTD[dtn,dtn+1] and OWL[dtn,dtn+1] are defined in Section 5.4. <xref target="sec5-4-rt-delay"/>. Here,
        the test intervals are increased to match the capacity Samples,
        RTD[T,I] and OWL[T,I].</t>
        <t>The interval dtn,dtn+1 where Maximum_C[T,I,PM] Maximum_C(T,I,PM) occurs is the
        reporting sub-interval for RTD[dtn,dtn+1] and OWL[dtn,dtn+1] within RTD[T,I] and OWL[T,I].</t>
        <t>Other metrics MAY <bcp14>MAY</bcp14> be measured: one-way reordering, duplication, and
        delay variation.</t>
      </section>
      <section title="Discussion"> numbered="true" toc="default" anchor="Maximum-IP-Layer-Capacity-Discussion">
        <name>Discussion</name>
        <t>If traffic conditioning (e.g., shaping, policing) applies along a
        path for which Maximum_C(T,I,PM) is to be determined, different values
        for dt SHOULD <bcp14>SHOULD</bcp14> be picked and measurements be executed during multiple
        intervals [T, T+I]. [T,T+I]. Each duration dt SHOULD <bcp14>SHOULD</bcp14> be chosen so that it is an
        integer multiple of increasing values k times serialization delay of a
        path
        Path MTU (PMTU) at the physical interface speed where traffic conditioning is
        expected. This should avoid taking configured burst tolerance
        singletons
        Singletons as a valid Maximum_C(T,I,PM) result.</t>
        <t>A Maximum_C(T,I,PM) without any indication of bottleneck
        congestion, be that an increasing increased latency, packet loss loss, or ECN Explicit Congestion
        Notification (ECN) marks during a measurement interval interval, I, is likely to an
        underestimate of Maximum_C(T,I,PM).</t>
      </section>
      <section title="Reporting anchor="sec6-6-rpt-the-metric" numbered="true" toc="default">
        <name>Reporting the Metric"> Metric</name>
        <t>The IP-Layer Capacity SHOULD <bcp14>SHOULD</bcp14> be reported with at least single
        Megabit
        single-Megabit resolution, in units of Megabits per second (Mbps) (which (which,
        to avoid any confusion, is 1,000,000 bits per second to avoid any confusion).</t> second).</t>
        <t>The related One-way One-Way Loss metric and Round Trip Round-Trip Delay measurements
        for the same Singleton SHALL <bcp14>SHALL</bcp14> be reported, also with meaningful
        resolution for the values measured.</t>
        <t>When there are demonstrated and repeatable Capacity modes in the
        Sample, then the Maximum IP-Layer Capacity SHALL <bcp14>SHALL</bcp14> be reported for each
        mode, along with the relative time from the beginning of the stream
        that the mode was observed to be present. Bimodal Maximum IP-Layer
        Capacities have been observed with some services, sometimes called a
        "turbo mode" intending to deliver short transfers more quickly, quickly or
        reduce the initial buffering time for some video streams. Note that
        modes lasting less than dt duration dt will not be detected.</t>
        <t>Some transmission technologies have multiple methods of operation
        that may be activated when channel conditions degrade or improve, and
        these transmission methods may determine the Maximum IP-Layer
        Capacity. Examples include line-of-sight microwave modulator
        constellations, or cellular modem technologies where the changes may
        be initiated by a user moving from one coverage area to another.
        Operation in the different transmission methods may be observed over
        time, but the modes of Maximum IP-Layer Capacity will not be activated
        deterministically as with the "turbo mode" described in the paragraph
        above.</t>
      </section>
    </section>
    <section title="IP-Layer anchor="ip-layer-sender-br" numbered="true" toc="default">
      <name>IP-Layer Sender Bit Rate Singleton Metric Definitions"> Definitions</name>
      <t>This section sets requirements for the following components to
      support the IP-Layer Sender Bitrate Bit Rate Metric. This metric helps to check
      that the sender Sender actually generated the desired rates during a test, and
      measurement takes place at the interface between the Src host to and the network path interface (or as
      close as practical within the Src host). It is not a metric for path
      performance.</t>
      <section title="Formal Name">
        <t>Type-P-IP-Sender-Bit-Rate, or numbered="true" toc="default">
        <name>Formal Name</name>
        <t>"Type-P-IP-Sender-Bit-Rate" is the formal name; it is informally called IP-Layer the "IP-Layer Sender
        Bitrate.</t> Bit Rate".</t>
        <t>Note that Type-P depends on the chosen method.</t>
      </section>
      <section title="Parameters"> numbered="true" toc="default">
        <name>Parameters</name>
        <t>This section lists the REQUIRED <bcp14>REQUIRED</bcp14> input factors to specify the
        metric, beyond those listed in Section 4.</t>

        <t><list style="symbols">
            <t>S, the <xref target="gen-params-defs"/>.</t>
        <dl spacing="normal">
          <dt>S:</dt><dd>The duration of the measurement interval at the Source</t>

            <t>st, the Source.</dd>
          <dt>st:</dt><dd>The nominal duration of N sub-intervals in S (default st =
            0.05 seconds)</t>

            <t>stn, the seconds).</dd>
          <dt>stn:</dt><dd>The beginning boundary of a specific sub-interval, n, one
            of N sub-intervals in S</t>
          </list></t> S.</dd>
	</dl>
        <t>S SHALL <bcp14>SHALL</bcp14> be longer than I, primarily to account for on-demand
        activation of the path, or any preamble to testing required, and the
        delay of the path.</t>
        <t>st SHOULD <bcp14>SHOULD</bcp14> be much smaller than the sub-interval dt and on the same
        order as FT, otherwise FT; otherwise, the rate measurement will include many rate
        adjustments and include more time smoothing, thus missing possibly smoothing the interval that contains the Maximum
        IP-Layer Capacity. Capacity (and therefore losing relevance). The st parameter Parameter does not have relevance when the
        Source is transmitting at a fixed rate throughout S.</t>
      </section>
      <section title="Metric Definition"> numbered="true" toc="default">
        <name>Metric Definition</name>
        <t>This section defines the REQUIRED <bcp14>REQUIRED</bcp14> aspects of the IP-Layer Sender
        Bitrate metric
        Bit Rate Metric (unless otherwise indicated) for measurements at the
        specified Source on packets addressed for the intended Destination
        host and matching the required Type-P:</t>
        <t>Define the IP-Layer Sender Bit Rate, B(S,st), to be the number of
        IP-Layer bits (including header and data fields) that are transmitted
        from the Source with address pair Src and Dst during one contiguous
        sub-interval, st, during the test interval S (where S SHALL <bcp14>SHALL</bcp14> be longer
        than I), I) and where the fixed-size packet count during that single
        sub-interval st also provides the number of IP-Layer bits in any
        interval, [stn,stn+1].</t>
        <t>Measurements according to these definitions SHALL this definition <bcp14>SHALL</bcp14> use the UDP
        transport layer. Any feedback from the Dst host to the Src host received by the
        Src host during an interval [stn,stn+1] SHOULD NOT <bcp14>SHOULD NOT</bcp14> result in an
        adaptation of the Src host traffic conditioning during this interval
        (rate adjustment occurs on st interval boundaries).</t>
      </section>
      <section title="Discussion"> numbered="true" toc="default">
        <name>Discussion</name>
        <t>Both the Sender and Receiver or (Source (or Source and Destination) bit rates
        SHOULD <bcp14>SHOULD</bcp14> be assessed as part of an IP-Layer Capacity measurement.
        Otherwise, an unexpected sending rate limitation could produce an
        erroneous Maximum IP-Layer Capacity measurement.</t>
      </section>
      <section title="Reporting numbered="true" toc="default">
        <name>Reporting the Metric"> Metric</name>
        <t>The IP-Layer Sender Bit Rate SHALL <bcp14>SHALL</bcp14> be reported with meaningful
        resolution, in units of Megabits per second (which (which, to avoid any confusion,
        is 1,000,000 bits per second to avoid any confusion).</t> second).</t>
        <t>Individual IP-Layer Sender Bit Rate measurements are discussed
        further in Section 9.</t> <xref target="rpt-formats"/>.</t>
      </section>
    </section>
    <section title="Method numbered="true" toc="default">
      <name>Method of Measurement">
      <t>The Measurement</name>
      <t>It is <bcp14>REQUIRED</bcp14> per the architecture of the method REQUIRES that two cooperating hosts
      operating operate in the roles of Src (test packet sender) Sender) and Dst (receiver), (Receiver)
      with a measured path and return path between them.</t>
      <t>The duration of a test, parameter Parameter I, 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 path from the Src host to the Dst host path during a test.</t>
      <section title="Load anchor="load-rate-adj" numbered="true" toc="default">
        <name>Load Rate Adjustment Algorithm"> Algorithm</name>
        <t>The algorithm described in this section MUST NOT <bcp14>MUST NOT</bcp14> be used as a
        general Congestion Control Algorithm (CCA). As stated in the Scope
        Section 2,
        <xref target="sec-2-scope"/> ("Scope, Goals, and Applicability"), 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 short-term measurement. There is a tradeoff trade-off
        between test duration (also the test data volume) and algorithm
        aggressiveness (speed of ramp-up and down ramp-down to the Maximum IP-Layer
        Capacity). The parameter Parameter values chosen below strike a well-tested
        balance among these factors.</t>
        <t>A table SHALL <bcp14>SHALL</bcp14> be pre-built (by the test initiator) administrator), defining all the
        offered load rates that will be supported (R1 through Rn, in ascending
        order, corresponding to indexed rows in the table). It is RECOMMENDED <bcp14>RECOMMENDED</bcp14>
        that rates begin with 0.5 Mbps at index zero, use 1 Mbps at index one,
        and then continue in 1 Mbps increments to 1 Gbps. Above 1 Gbps, and up
        to 10 Gbps, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that 100 Mbps increments be used. Above
        10 Gbps, increments of 1 Gbps are RECOMMENDED. <bcp14>RECOMMENDED</bcp14>. A higher initial
        IP-Layer Sender Bitrate Bit Rate might be configured when the test operator is
        certain that the Maximum IP-Layer Capacity is well-above well above the initial
        IP-Layer Sender Bitrate Bit Rate and factors such as test duration and total
        test traffic play an important role. The sending rate table SHOULD
        backet <bcp14>SHOULD</bcp14>
        bracket the maximum capacity Maximum Capacity where it will make measurements, including
        constrained rates less than 500kbps 500 kbps if applicable.</t>
        <t>Each rate is defined as datagrams of size ss, sent as a burst of
        count cc, each time interval tt (default (the default for tt is 1ms, 100 microsec, a likely
        system tick-interval). tick interval). While it is advantageous to use datagrams of as
        large a size as possible, it may be prudent to use a slightly smaller
        maximum that allows for secondary protocol headers and/or tunneling
        without resulting in IP-Layer fragmentation. Selection of a new rate
        is indicated by a calculation on the current row, Rx. For example:</t>

        <t>"Rx+1": the sender
        <dl newline="false" spacing="normal">
        <dt>"Rx+1":</dt><dd>The Sender uses the next higher next-higher rate in the table.</t>

        <t>"Rx-10": the sender table.</dd>
        <dt>"Rx-10":</dt><dd>The Sender uses the rate 10 rows lower in the table.</t> table.</dd>
	</dl>
        <t>At the beginning of a test, the sender Sender begins sending at rate R1
        and the receiver Receiver starts a feedback timer of duration FT (while
        awaiting inbound datagrams). As datagrams are received received, they are
        checked for sequence number anomalies (loss, out-of-order,
        duplication, etc.) and the delay range is measured (one-way or
        round-trip). This information is accumulated until the feedback timer
        FT expires and a status feedback message is sent from the receiver Receiver
        back to the sender, Sender, to communicate this information. The accumulated
        statistics are then reset by the receiver Receiver for the next feedback
        interval. As feedback messages are received back at the sender, Sender, they
        are evaluated to determine how to adjust the current offered load rate
        (Rx).</t>
        <t>If the feedback indicates that no sequence number anomalies were
        detected AND the delay range was below the lower threshold, the
        offered load rate is increased. If congestion has not been confirmed
        up to this point (see below for the method to declare for declaring congestion), the
        offered load rate is increased by more than one rate setting (e.g., Rx+10).
        This allows the offered load to quickly reach a near-maximum rate.
        Conversely, if congestion has been previously confirmed, the offered
        load rate is only increased by one (Rx+1). However, if a rate
        threshold between high and very above a high sending rates rate (such as 1 Gbps) is
        exceeded, the offered load rate is only increased by one (Rx+1) above
        the rate threshold
        in any congestion state.</t>
        <t>If the feedback indicates that sequence number anomalies were
        detected OR the delay range was above the upper threshold, the offered
        load rate is decreased. The RECOMMENDED <bcp14>RECOMMENDED</bcp14> threshold values are 0 10 for
        sequence number gaps and 30 ms msec for lower and 90 ms msec for upper delay
        thresholds, respectively. Also, if congestion is now confirmed for the
        first time by the current feedback message being processed, then the
        offered load rate is decreased by more than one rate setting (e.g., Rx-30).
        This one-time reduction is intended to compensate for the fast initial
        ramp-up. In all other cases, the offered load rate is only decreased
        by one (Rx-1).</t>
        <t>If the feedback indicates that there were no sequence number
        anomalies AND the delay range was above the lower threshold, threshold but below
        the upper threshold, the offered load rate is not changed. This allows
        time for recent changes in the offered load rate to stabilize, stabilize and for the
        feedback to represent current conditions more accurately.</t>
        <t>Lastly, the method for inferring congestion is that there were
        sequence number anomalies AND/OR the delay range was above the upper
        threshold for two three consecutive feedback intervals. The algorithm
        described above is also illustrated in Annex B of ITU-T Rec. Recommendation Y.1540, 2020
        version<xref target="Y.1540"/>, in Annex B,
        version <xref target="Y.1540" format="default"/> and is implemented in the
        Appendix on Load <xref target="app-a-load-rate-adj-pseudocode"/> ("Load Rate Adjustment Pseudo Code Pseudocode")
        in this memo.</t>
        <t>The load rate adjustment algorithm MUST <bcp14>MUST</bcp14> include timers that stop
        the test when received packet streams cease unexpectedly. The timeout
        thresholds are provided in the table below, <xref target="load-rate-adj-params"/>, along with values for all
        other parameters Parameters and variables described in this section. Operation Operations of
        non-obvious parameters Parameters appear below:<list style="hanging">
            <t hangText="load below:</t>
        <dl newline="true" spacing="normal">
          <dt>load packet timeout">Operation: The timeout:</dt>
          <dd>The load packet
            timeout SHALL <bcp14>SHALL</bcp14> be reset to the configured value each time a load
            packet is received. If the timeout expires, the receiver SHALL Receiver <bcp14>SHALL</bcp14> be
            closed and no further feedback sent.</t>

            <t hangText="feedback sent.</dd>
          <dt>feedback message timeout">Operation: The timeout:</dt>
          <dd>The feedback
            message timeout SHALL <bcp14>SHALL</bcp14> be reset to the configured value each time a
            feedback message is received. If the timeout expires, the sender
            SHALL Sender
            <bcp14>SHALL</bcp14> be closed and no further load packets sent.</t>
          </list></t>

        <t/>

        <texttable style="all"
                   title="Parameters sent.</dd>
        </dl>
        <table align="center" anchor="load-rate-adj-params">
          <name>Parameters for Load Rate Adjustment Algorithm">
          <ttcol>Parameter</ttcol>

          <ttcol>Default</ttcol>

          <ttcol>Tested Algorithm</name>
          <thead>
            <tr>
              <th align="left">Parameter</th>
              <th align="left">Default</th>
              <th align="left">Tested Range or values</ttcol>

          <ttcol width="30">Expected Values</th>
              <th align="left">Expected Safe Range (not entirely tested, other
          values NOT RECOMMENDED)</ttcol>

          <c>FT, <bcp14>NOT RECOMMENDED</bcp14>)</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">FT, feedback time interval</c>

          <c>50ms</c>

          <c>20ms, 50ms, 100ms</c>

          <c>20ms interval</td>
              <td align="left">50 msec</td>
              <td align="left">20 msec, 50 msec, 100 msec</td>
              <td align="left">20 msec &lt;= FT &lt;= 250ms Larger 250 msec; larger values may slow the rate
          increase and fail to find the max</c>

          <c>Feedback max</td>
            </tr>
            <tr>
              <td align="left">Feedback message timeout (stop test)</c>

          <c>L*FT, test)</td>
              <td align="left">L*FT, L=20 (1sec with FT=50ms)</c>

          <c>L=100 (1 sec with FT=50ms (5sec)</c>

          <c>0.5sec FT=50 msec)</td>
              <td align="left">L=100 with FT=50 msec (5 sec)</td>
              <td align="left">0.5 sec &lt;= L*FT &lt;= 30sec Upper 30 sec; upper limit for very unreliable
          test paths only</c>

          <c>load only</td>
            </tr>
            <tr>
              <td align="left">Load packet timeout (stop test)</c>

          <c>1sec</c>

          <c>5sec</c>

          <c>0.250sec - 30sec Upper test)</td>
              <td align="left">1 sec</td>
              <td align="left">5 sec</td>
              <td align="left">0.250-30 sec; upper limit for very unreliable test paths
          only</c>

          <c>table
          only</td>
            </tr>
            <tr>
              <td align="left">Table index 0</c>

          <c>0.5Mbps</c>

          <c>0.5Mbps</c>

          <c>when 0</td>
              <td align="left">0.5 Mbps</td>
              <td align="left">0.5 Mbps</td>
              <td align="left">When testing &lt;=10Gbps</c>

          <c>table &lt;= 10 Gbps</td>
            </tr>
            <tr>
              <td align="left">Table index 1</c>

          <c>1Mbps</c>

          <c>1Mbps</c>

          <c>when 1</td>
              <td align="left">1 Mbps</td>
              <td align="left">1 Mbps</td>
              <td align="left">When testing &lt;=10Gbps</c>

          <c>table &lt;= 10 Gbps</td>
            </tr>
            <tr>
              <td align="left">Table index (step) size</c>

          <c>1Mbps</c>

          <c>1Mbps&lt;=rate&lt;= 1Gbps</c>

          <c>same as tested</c>

          <c>table size</td>
              <td align="left">1 Mbps</td>
              <td align="left">1 Mbps &lt;= rate &lt;= 1 Gbps</td>
              <td align="left">Same as tested</td>
            </tr>
            <tr>
              <td align="left">Table index (step) size, rate&gt;1Gbps</c>

          <c>100Mbps</c>

          <c>1Gbps&lt;=rate&lt;= 10Gbps</c>

          <c>same as tested</c>

          <c>table rate &gt; 1 Gbps</td>
              <td align="left">100 Mbps</td>
              <td align="left">1 Gbps &lt;= rate &lt;= 10 Gbps</td>
              <td align="left">Same as tested</td>
            </tr>
            <tr>
              <td align="left">Table index (step) size, rate&gt;10Gbps</c>

          <c>1Gbps</c>

          <c>untested</c>

          <c>&gt;10Gbps</c>

          <c>ss, rate &gt; 10 Gbps</td>
              <td align="left">1 Gbps</td>
              <td align="left">Untested</td>
              <td align="left">&gt;10 Gbps</td>
            </tr>
            <tr>
              <td align="left">ss, UDP payload size, bytes</c>

          <c>none</c>

          <c>&lt;=1222</c>

          <c>Recommend bytes</td>
              <td align="left">None</td>
              <td align="left">&lt;=1222</td>
              <td align="left">Recommend max at largest value that avoids fragmentation; use of
          too-small using a payload size that is too small might result in unexpected sender
          limitations.</c>

          <c>cc, Sender
          limitations</td>
            </tr>
            <tr>
              <td align="left">cc, burst count</c>

          <c>none</c>

          <c>1&lt;=cc&lt;= 100</c>

          <c>same count</td>
              <td align="left">None</td>
              <td align="left">1 &lt;= cc &lt;= 100</td>
              <td align="left">Same as tested. Vary cc as needed to create the desired maximum
          sending rate. Sender buffer size may limit cc in implementation.</c>

          <c>tt, the implementation</td>
            </tr>
            <tr>
              <td align="left">tt, burst interval</c>

          <c>100microsec</c>

          <c>100microsec, 1msec</c>

          <c>available interval</td>
              <td align="left">100 microsec</td>
              <td align="left">100 microsec, 1 msec</td>
              <td align="left">Available range of "tick" values (HZ param)</c>

          <c>low param)</td>
            </tr>
            <tr>
              <td align="left">Low delay range threshold</c>

          <c>30ms</c>

          <c>5ms, 30ms</c>

          <c>same as tested</c>

          <c>high threshold</td>
              <td align="left">30 msec</td>
              <td align="left">5 msec, 30 msec</td>
              <td align="left">Same as tested</td>
            </tr>
            <tr>
              <td align="left">High delay range threshold</c>

          <c>90ms</c>

          <c>10ms, 90ms</c>

          <c>same as tested</c>

          <c>sequence threshold</td>
              <td align="left">90 msec</td>
              <td align="left">10 msec, 90 msec</td>
              <td align="left">Same as tested</td>
            </tr>
            <tr>
              <td align="left">Sequence error threshold</c>

          <c>0</c>

          <c>0, 100</c>

          <c>same as tested</c>

          <c>consecutive threshold</td>
              <td align="left">10</td>
              <td align="left">0, 1, 5, 10, 100</td>
              <td align="left">Same as tested</td>
            </tr>
            <tr>
              <td align="left">Consecutive errored status report threshold</c>

          <c>2</c>

          <c>2</c>

          <c>Use threshold</td>
              <td align="left">3</td>
              <td align="left">2, 3, 4, 5</td>
              <td align="left">Use values &gt;1 to avoid misinterpreting transient loss</c>

          <c>Fast loss</td>
            </tr>
            <tr>
              <td align="left">Fast mode increase, in table index steps</c>

          <c>10</c>

          <c>10</c>

          <c>2 steps</td>
              <td align="left">10</td>
              <td align="left">10</td>
              <td align="left">2 &lt;= steps &lt;= 30</c>

          <c>Fast 30</td>
            </tr>
            <tr>
              <td align="left">Fast mode decrease, in table index steps</c>

          <c>3 steps</td>
              <td align="left">3 * Fast mode increase</c>

          <c>3 increase</td>
              <td align="left">3 * Fast mode increase</c>

          <c>same as tested</c>
        </texttable> increase</td>
              <td align="left">Same as tested</td>
            </tr>
          </tbody>
        </table>
        <t>As a consequence of default parameterization, the Number of table
        steps in total for rates &lt;10Gbps less than 10 Gbps is 2000 1090 (excluding index 0).</t>
        <t>A related sender Sender backoff response to network conditions occurs when
        one or more status feedback messages fail to arrive at the sender.</t> Sender.</t>
        <t>If no status feedback messages arrive at the sender Sender for the
        interval greater than the Lost Status Backoff timeout:</t>

        <t><figure>
            <artwork><![CDATA[
        <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[           UDRT + (2+w)*FT = Lost Status Backoff timeout

   where:

   UDRT = upper delay range threshold (default 90ms) 90 msec)
   FT   = feedback time interval (default 50ms) 50 msec)
   w    = number of repeated timeouts (w=0 initially, w++ on each
          timeout, and reset to 0 when a message is received)
]]></artwork>
          </figure></t>

        <t>beginning
        <t>Beginning when the last message (of any type) was successfully
        received at the sender:</t>

        <t>Then the Sender:</t>
        <t>The offered load SHALL <bcp14>SHALL</bcp14> then be decreased, following the same
        process as when the feedback indicates the presence of one or more
        sequence number anomalies OR the delay range was above the upper
        threshold (as described above), with the same load rate adjustment
        algorithm variables in their current state. This means that rate
        reduction and congestion confirmation can result from a three-way OR
        that includes lost status feedback messages, messages OR sequence errors, or errors OR delay
        variation.</t> variation can result in rate reduction and congestion confirmation.</t>
        <t>The RECOMMENDED <bcp14>RECOMMENDED</bcp14> initial value for w is 0, taking Round Trip a Round-Trip Time
        (RTT) of less than FT into account. A test with an RTT longer than FT is a
        valid reason to increase the initial value of w appropriately.
        Variable w SHALL <bcp14>SHALL</bcp14> be incremented by 1 one whenever the Lost Status Backoff
        timeout is exceeded. So So, with FT = 50ms 50 msec and UDRT = 90ms, 90 msec, a status
        feedback message loss would be declared at 190ms 190 msec following a
        successful message, again at 50ms 50 msec after that (240ms (240 msec total), and so
        on.</t>
        <t>Also, if congestion is now confirmed for the first time by a Lost
        Status Backoff timeout, then the offered load rate is decreased by
        more than one rate setting (e.g., Rx-30). This one-time reduction is intended
        to compensate for the fast initial ramp-up. In all other cases, the
        offered load rate is only decreased by one (Rx-1).</t>

        <t>Appendix B
        <t><xref target="app-b-rfc8085-udp"/> discusses compliance with the applicable mandatory
        requirements of <xref target="RFC8085"/>, target="RFC8085" format="default"/>, consistent with the goals of
        the IP-Layer Capacity Metric and Method, including the load rate
        adjustment algorithm described in this section.</t>
      </section>
      <section title="Measurement anchor="meas-qual-verif" numbered="true" toc="default">
        <name>Measurement Qualification or Verification"> Verification</name>
        <t>It is of course necessary to calibrate the equipment performing the
        IP-Layer Capacity measurement, to ensure that the expected capacity
        can be measured accurately, accurately and that equipment choices (processing
        speed, interface bandwidth, etc.) are suitably matched to the
        measurement range.</t>
        <t>When assessing a Maximum maximum rate as the metric specifies, artificially
        high (optimistic) values might be measured until some buffer on the
        path is filled. Other causes include bursts of back-to-back packets
        with idle intervals delivered by a path, while the measurement
        interval (dt) is small and aligned with the bursts. The artificial
        values might result in an un-sustainable unsustainable Maximum Capacity observed
        when the method Method of measurement Measurement is searching for the Maximum, maximum, and that
        would not do. This situation is different from the bi-modal bimodal service
        rates (discussed under Reporting), in "<xref target="sec6-6-rpt-the-metric" format="title"/>", <xref target="sec6-6-rpt-the-metric" format="default"/>), which are characterized by a
        multi-second duration (much longer than the measured RTT) and
        repeatable behavior.</t>
        <t>There are many ways that the Method of Measurement could handle
        this false-max issue. The default value for measurement of singletons Singletons
        (dt = 1 second) has proven to be of practical value during tests of
        this method, allows the bimodal service rates to be characterized, and
        it
        has an obvious alignment with the reporting units (Mbps).</t>
        <t>Another approach comes from Section 24 of <xref target="RFC2544"/> target="RFC2544" sectionFormat="of" section="24"/>
        and its discussion of Trial trial duration, where relatively short trials
        conducted as part of the search are followed by longer trials to make
        the final determination. In the production network, measurements of
        Singletons and Samples (the terms for trials and tests of Lab
        Benchmarking) must be limited in duration because they may be
        service-affecting. affect
        service. But there is sufficient value in repeating a Sample
        with a fixed sending rate determined by the previous search for the
        Maximum IP-Layer Capacity, to qualify the result in terms of the other
        performance metrics measured at the same time.</t>
        <t>A qualification Qualification measurement for the search result is a subsequent
        measurement, sending at a fixed 99.x % percent of the Maximum IP-Layer
        Capacity for I, or an indefinite period. The same Maximum Capacity
        Metric is applied, and the Qualification for the result is a Sample
        without supra-threshold packet loss losses or a growing minimum delay trend in subsequent
        singletons
        Singletons (or each dt of the measurement interval, I). Samples
        exhibiting supra-threshold packet losses or increasing queue occupation require a repeated
        search and/or test at a reduced fixed sender Sender rate for qualification.</t> Qualification.</t>
        <t>Here, as with any Active Capacity test, the test duration must be
        kept short. 10 second Ten-second tests for each direction of transmission are
        common today. The default measurement interval specified here is I =
        10 seconds. The combination of a fast and congestion-aware search
        method and user-network coordination make makes a unique contribution to
        production testing. The Maximum IP Capacity metric Metric and method Method for
        assessing performance is very different from the classic <xref
        target="RFC2544"/> Throughput metric Metric and methods : Methods provided in <xref target="RFC2544" format="default"/>: it uses
        near-real-time load adjustments that are sensitive to loss and delay,
        similar to other congestion control algorithms used on the Internet
        every day, along with limited duration. On the other hand, <xref
        target="RFC2544"/> Throughput measurements <xref target="RFC2544" format="default"/> can produce sustained
        overload conditions for extended periods of time. Individual trials in
        a test governed by a binary search can last 60 seconds for each step,
        and the final confirmation trial may be even longer. This is very
        different from "normal" traffic levels, but overload conditions are
        not a concern in the isolated test environment. The concerns raised in
        <xref target="RFC6815"/> target="RFC6815" format="default"/> were that <xref target="RFC2544"/> the methods discussed in <xref target="RFC2544" format="default"/> would be let loose on production networks, and instead the authors
        challenged the standards community to develop metrics Metrics and methods Methods like
        those described in this memo.</t>
      </section>
      <section title="Measurement Considerations"> numbered="true" toc="default">
        <name>Measurement Considerations</name>
        <t>In general, the wide-spread widespread measurements that this memo encourages
        will encounter wide-spread widespread behaviors. The bimodal IP Capacity
        behaviors already discussed in Section 6.6 <xref target="sec6-6-rpt-the-metric"/> are good examples.</t>
        <t>In general, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to locate test endpoints as close to
        the intended measured link(s) as practical (this (for reasons of scale, this is not always
        possible for reasons of scale; possible; there is a limit on the number of test
        endpoints coming from many perspectives, perspectives -- for example, management and measurement
        traffic for example). traffic). The testing operator MUST <bcp14>MUST</bcp14> set a value for the
        MaxHops parameter, Parameter, based on the expected path length. This parameter Parameter
        can keep measurement traffic from straying too far beyond the intended
        path.</t>
        <t>The path measured path may be stateful based on many factors, and the
        Parameter "Time of day" when a test starts may not be enough
        information. Repeatable testing may require knowledge of the time from the
        beginning of a measured flow, flow -- and how the flow is constructed constructed,
        including how much traffic has already been sent on that flow when a
        state-change
        state change is observed, observed -- because the state-change state change may be based on
        time or
        time, bytes sent sent, or both. Both load packets and status feedback
        messages MUST <bcp14>MUST</bcp14> contain sequence numbers, which numbers; this helps with measurements
        based on those packets.</t>
        <t>Many different types of traffic shapers and on-demand
        communications access technologies may be encountered, as anticipated
        in <xref target="RFC7312"/>, target="RFC7312" format="default"/>, and play a key role in measurement
        results. Methods MUST <bcp14>MUST</bcp14> be prepared to provide a short preamble
        transmission to activate on-demand communications access, access and to
        discard the preamble from subsequent test results.</t>

        <t>Conditions which
        <t>The following conditions might be encountered during measurement, where
        packet losses may occur independently of the measurement sending
        rate:</t>

        <t><list style="numbers">
            <t>Congestion
        <ol spacing="normal" type="1"><li>Congestion of an interconnection or backbone interface may
            appear as packet losses distributed over time in the test stream,
            due to much higher rate much-higher-rate interfaces in the backbone.</t>

            <t>Packet backbone.</li>
          <li>Packet loss due to the use of Random Early Detection (RED) or other
            active queue management may or may not affect the measurement flow
            if competing background traffic (other flows) are is simultaneously
            present.</t>

            <t>There
            present.</li>
          <li>There may be only a small delay variation independent of the sending
            rate under these conditions, too.</t>

            <t>Persistent conditions as well.</li>
          <li>Persistent competing traffic on measurement paths that include
            shared transmission media may cause random packet losses in the
            test stream.</t>
          </list>It stream.</li>
        </ol>
        <t>It is possible to mitigate these conditions using the
        flexibility of the load-rate adjusting load rate adjustment algorithm described in Section
        8.1
        <xref target="load-rate-adj"/> above (tuning specific parameters).</t> Parameters).</t>
        <t>If the measurement flow burst duration happens to be on the order
        of or smaller than the burst size of a shaper or a policer in the
        path, then the line rate might be measured rather than the bandwidth
        limit imposed by the shaper or policer. If this condition is
        suspected, alternate configurations SHOULD <bcp14>SHOULD</bcp14> be used.</t>
        <t>In general, results depend on the sending stream stream's characteristics;
        the measurement community has known this for a long time, time and needs to
        keep it front of foremost in mind. Although the default is a single flow (F=1) for
        testing, the use of multiple flows may be advantageous for the following
        reasons:</t>

        <t><list style="numbers">
            <t>the
        <ol spacing="normal" type="1"><li>The test hosts may be able to create a higher load than with a
            single flow, or parallel test hosts may be used to generate 1 one flow
            each.</t>

            <t>there
            each.</li>
          <li>Link aggregation may be link aggregation present (flow-based load
            balancing) balancing), and multiple flows are needed to occupy each member of
            the aggregate.</t>

            <t>Internet aggregate.</li>
          <li>Internet access policies may limit the IP-Layer Capacity
            depending on the Type-P of the packets, possibly reserving capacity
            for various stream types.</t>
          </list>Each types.</li>
        </ol>
        <t>Each flow would be controlled using its own implementation of
        the load rate adjustment (search) algorithm.</t>
        <t>It is obviously counter-productive counterproductive to run more than one independent
        and concurrent test (regardless of the number of flows in the test
        stream) attempting to measure the *maximum* <strong>maximum</strong> capacity on a single path.
        The number of concurrent, independent tests of a path SHALL <bcp14>SHALL</bcp14> be limited
        to one.</t>
        <t>Tests of a v4-v6 transition mechanism might well be the intended
        subject of a capacity test. As long as the both IPv4 packets and IPv6 packets
        sent/received are both standard-formed, this should be allowed (and
        the change in header size easily accounted for on a per-packet
        basis).</t>
        <t>As testing continues, implementers should expect some evolution in the methods. methods to evolve. The ITU-T has published a Supplement (60) supplement (Supplement 60) to the Y-series
        of ITU-T Recommendations, "Interpreting ITU-T Y.1540 Maximum IP-Layer
        Capacity measurements", maximum IP-layer
        capacity measurements" <xref target="Y.Sup60"/>, target="Y.Sup60" format="default"/>, which is the result
        of continued testing with the metric, and those metric. Those results have improved
        the method described here.</t>
      </section>

      <section title="Running Code">
        <t>RFC Editor: This section is for the benefit of the Document
        Shepherd's form, and will be deleted prior to publication.</t>

        <t>Much of the development of the method and comparisons with existing methods conducted at IETF Hackathons and elsewhere have been based on
        the example udpst Linux measurement tool (which is a working reference
        for further development) <xref target="udpst"/>. The current
        project:<list style="symbols">
            <t>is a utility that can function as a client or server daemon</t>

            <t>requires a successful client-initiated setup handshake between
            cooperating hosts and allows firewalls to control inbound
            unsolicited UDP which either go to a control port [expected and
            w/authentication] or to ephemeral ports that are only created as
            needed. Firewalls protecting each host can both continue to do
            their job normally. This aspect is similar to many other test
            utilities available.</t>

            <t>is written in C, and built with gcc (release 9.3) and its
            standard run-time libraries</t>

            <t>allows configuration of most of the parameters described in
            Sections 4 and 7.</t>

            <t>supports IPv4 and IPv6 address families.</t>

            <t>supports IP-Layer packet marking.</t>
          </list></t>

        <t/> here.</t>
      </section>
    </section>
    <section title="Reporting Formats"> anchor="rpt-formats" numbered="true" toc="default">
      <name>Reporting Formats</name>
      <t>The singleton Singleton IP-Layer Capacity results SHOULD <bcp14>SHOULD</bcp14> be accompanied by the
      context under which they were measured.<list style="symbols">
          <t>timestamp measured.</t>
      <ul spacing="normal">
        <li>Timestamp (especially the time when the maximum was observed in
          dtn)</t>

          <t>Source
          dtn).</li>
        <li>Source and Destination (by IP or other meaningful ID)</t>

          <t>other ID).</li>
        <li>Other inner parameters Parameters of the test case (Section 4)</t>

          <t>outer parameters, (<xref target="gen-params-defs"/>).</li>
        <li>Outer Parameters, such as "test conducted in motion" or other
          factors belonging to the context of the measurement</t>

          <t>result measurement.</li>
        <li>Result validity (indicating cases where the process was somehow
          interrupted or the attempt failed)</t>

          <t>a failed).</li>
        <li>A field where unusual circumstances could be documented, and
          another one for "ignore/mask "ignore / mask out" purposes in further processing</t>
        </list></t> processing.</li>
      </ul>
      <t>The Maximum IP-Layer Capacity results SHOULD <bcp14>SHOULD</bcp14> be reported in the
      format of a table with tabular
  format. There <bcp14>SHOULD</bcp14> be a row for each of column that identifies the test Phases and Number of
      Flows. Phase.
  There SHOULD <bcp14>SHOULD</bcp14> be a column listing the number of flows used in that Phase.
  The remaining columns <bcp14>SHOULD</bcp14> report the following results for the phases with number aggregate
  of all flows, and
      for including the resultant Maximum IP-Layer Capacity results for Capacity, the aggregate Loss Ratio,
  the RTT minimum, RTT maximum, and each flow tested.</t> other metrics tested having similar
  relevance.</t>
      <t>As mentioned in Section 6.6, bi-modal <xref target="sec6-6-rpt-the-metric"/>, bimodal (or multi-modal) maxima SHALL <bcp14>SHALL</bcp14>
      be reported for each mode separately.</t>

      <texttable style="all" title="Maximum IP-layer Capacity Results">
        <ttcol>Phase, # Flows</ttcol>

        <ttcol>Maximum IP-Layer Capacity, Mbps</ttcol>

        <ttcol>Loss Ratio</ttcol>

        <ttcol>RTT min, max, msec</ttcol>

        <c>Search,1</c>

        <c>967.31</c>

        <c>0.0002</c>

        <c>30, 58</c>

        <c>Verify,1</c>

        <c>966.00</c>

        <c>0.0000</c>

        <c>30, 38</c>
      </texttable>
      <table align="center">
        <name>Maximum IP-Layer Capacity Results</name>
        <thead>
          <tr>
            <th align="left">Phase</th>
            <th align="left">Number of Flows</th>
            <th align="left">Maximum IP-Layer Capacity (Mbps)</th>
            <th align="left">Loss Ratio</th>
            <th align="left">RTT min (msec)</th>
            <th align="left">RTT max (msec)</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">Search</td>
            <td align="left">1</td>
            <td align="left">967.31</td>
            <td align="left">0.0002</td>
            <td align="left">30</td>
            <td align="left">58</td>
          </tr>
          <tr>
            <td align="left">Verify</td>
            <td align="left">1</td>
            <td align="left">966.00</td>
            <td align="left">0.0000</td>
            <td align="left">30</td>
            <td align="left">38</td>
          </tr>
        </tbody>
      </table>
      <t>Static and configuration parameters:</t> Parameters:</t>
      <t>The sub-interval time, dt, MUST <bcp14>MUST</bcp14> accompany a report of Maximum
      IP-Layer Capacity results, and as well as the remaining Parameters from Section 4,
      General Parameters.</t> <xref target="gen-params-defs"/> ("General Parameters and Definitions").</t>
      <t>The PM list metrics corresponding to the sub-interval where the
      Maximum Capacity occurred MUST <bcp14>MUST</bcp14> accompany a report of Maximum IP-Layer
      Capacity results, for each test phase.</t> Phase.</t>
      <t>The IP-Layer Sender Bit rate Rate results SHOULD <bcp14>SHOULD</bcp14> be reported in the format
      of a table with tabular format.
  There <bcp14>SHOULD</bcp14> be a row for each of column that identifies the test phases, sub-intervals (st)
      and number of flows. Phase.
  There SHOULD <bcp14>SHOULD</bcp14> be columns for a column listing each individual (numbered) flow used
  in that Phase, or the phases with number aggregate of flows, and flows in that Phase. A corresponding column <bcp14>SHOULD</bcp14> identify the
  specific sending rate sub-interval, stn, for each flow and aggregate. A final column <bcp14>SHOULD</bcp14> report the resultant
  IP-Layer Sender Bit rate Rate results for the
      aggregate and each flow tested.</t>

      <texttable style="all" title="IP-layer used, or the aggregate of all flows.</t>
      <table align="center">
        <name>IP-Layer Sender Bit Rate Results">
        <ttcol>Phase, Flow or Aggregate</ttcol>

        <ttcol>st, sec</ttcol>

        <ttcol>Sender Bitrate, Mbps</ttcol>

        <c>Search,1</c>

        <c>0.00 - 0.05</c>

        <c>345</c>

        <c>Search,2</c>

        <c>0.00 - 0.05</c>

        <c>289</c>

        <c>Search,Agg</c>

        <c>0.00 - 0.05</c>

        <c>634</c>
      </texttable> Results (Example with Two Flows and st = 0.05 (sec))</name>
        <thead>
          <tr>
            <th align="left">Phase</th>
            <th align="left">Flow Number or Aggregate</th>
            <th align="left">stn (sec)</th>
            <th align="left">Sender Bit Rate (Mbps)</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">Search</td>
            <td align="left">1</td>
            <td align="left">0.00</td>
            <td align="left">345</td>
          </tr>
          <tr>
            <td align="left">Search</td>
            <td align="left">2</td>
            <td align="left">0.00</td>
            <td align="left">289</td>
          </tr>
          <tr>
            <td align="left">Search</td>
            <td align="left">Agg</td>
            <td align="left">0.00</td>
            <td align="left">634</td>
          </tr>
          <tr>
            <td align="left">Search</td>
            <td align="left">1</td>
            <td align="left">0.05</td>
            <td align="left">499</td>
          </tr>
          <tr>
            <td align="left">Search</td>
            <td align="left">...</td>
            <td align="left">0.05</td>
            <td align="left">...</td>
          </tr>
        </tbody>
      </table>
      <t>Static and configuration parameters:</t> Parameters:</t>
      <t>The subinterval time, sub-interval duration, st, MUST <bcp14>MUST</bcp14> accompany a report of Sender IP-Layer
      Bit Rate results.</t>
      <t>Also, the values of the remaining Parameters from Section 4, General
      Parameters, MUST <xref target="gen-params-defs"/> ("General Parameters and Definitions") <bcp14>MUST</bcp14> be reported.</t>

      <t/>
      <section title="Configuration numbered="true" toc="default">
        <name>Configuration and Reporting Data Formats"> Formats</name>
        <t>As a part of the multi-Standards Development Organization (SDO)
        harmonization of this metric Metric and method Method of measurement, Measurement, one of the
        areas where the Broadband Forum (BBF) contributed its expertise was in
        the definition of an information model and data model for
        configuration and reporting. These models are consistent with the
        metric parameters Parameters and default values specified as lists is in this memo.
        <xref target="TR-471"/> target="TR-471" format="default"/> provides the Information information model that was used
        to prepare a full data model in related BBF work. The BBF has also
        carefully considered topics within its purview, such as the placement of
        measurement systems within the Internet access architecture. For
        example, timestamp resolution requirements that influence the choice
        of the test protocol are provided in Table 2 of <xref
        target="TR-471"/>.</t> target="TR-471" format="default"/>.</t>
      </section>
    </section>
    <section title="Security Considerations"> anchor="sec-cons" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Active metrics Metrics and measurements Active Measurements have a long history of security
      considerations. The security considerations that apply to any active
      measurement Active
      Measurement of live paths are relevant here. See <xref
      target="RFC4656"/> target="RFC4656" format="default"/> and <xref target="RFC5357"/>.</t> target="RFC5357" format="default"/>.</t>
      <t>When considering the 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
      that are within this scope of work. Passive observations of user
      traffic for measurement purposes raise many privacy issues. We refer the
      reader to the privacy considerations described in the Large Scale Large-scale
      Measurement of Broadband Performance (LMAP) Framework <xref
      target="RFC7594"/>, target="RFC7594" format="default"/>, which covers active and passive techniques.</t>
      <t>There are some new considerations for Capacity measurement as
      described in this memo.</t>

      <t><list style="numbers">
          <t>Cooperating
      <ol spacing="normal" type="1"><li>Cooperating Source and Destination hosts and agreements to test
          the path between the hosts are REQUIRED. <bcp14>REQUIRED</bcp14>. Hosts perform in either the
          Src role or the Dst roles.</t>

          <t>It role.</li>
        <li>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
          [expected
          (expected and w/authentication] with authentication) or to ephemeral ports that are only
          created as needed. Firewalls protecting each host can both continue
          to do their job normally.</t>

          <t>Client-server normally.</li>
        <li>Client-server authentication and integrity protection for
          feedback messages conveying measurements is RECOMMENDED.</t>

          <t>Hosts MUST are <bcp14>RECOMMENDED</bcp14>.</li>
        <li>Hosts <bcp14>MUST</bcp14> limit the number of simultaneous tests to avoid
          resource exhaustion and inaccurate results.</t>

          <t>Senders MUST results.</li>
        <li>Senders <bcp14>MUST</bcp14> be rate-limited. rate limited. This can be accomplished using a
          pre-built table defining all the offered load rates that will be
          supported (Section 8.1). (<xref target="load-rate-adj"/>). The recommended load-control load control search
          algorithm results in "ramp-up" from the lowest rate in the
          table.</t>

          <t>Service
          table.</li>
        <li>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 duration
          values, I, SHOULD <bcp14>SHOULD</bcp14> be limited).</t>
        </list></t> limited).</li>
      </ol>
      <t>The exact specification of these features is left for the future
      protocol development.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This memo makes document has no requests of IANA.</t> IANA actions.</t>
    </section>

    <section title="Acknowledgments">
      <t>Thanks to Joachim Fabini, Matt Mathis, J.Ignacio Alvarez-Hamelin,
      Wolfgang Balzer, Frank Brockners, Greg Mirsky, Martin Duke, Murray
      Kucherawy,
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2330.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7680.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8468.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6438.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4737.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4656.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2681.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5357.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7497.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2544.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3148.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5136.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6815.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7312.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7594.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8337.xml"/>

        <reference anchor="copycat" target="https://irtf.org/anrw/2017/anrw17-final5.pdf">
          <front>
            <title>copycat: Testing Differential Treatment of New Transport
          Protocols in the Wild</title>
            <author fullname="Korian Edeline" initials="K." surname="Edeline">
              <organization/>
            </author>
            <author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind">
              <organization/>
            </author>
            <author fullname="Brian Trammell" initials="B." surname="Trammell">
              <organization/>
            </author>
            <author fullname="Benoit Donnet" initials="B." surname="Donnet">
              <organization/>
            </author>
            <date month="July" year="2017"/>
          </front>
          <refcontent>ANRW '17</refcontent>
         <seriesInfo name="DOI" value="10.1145/3106328.3106330"/>
        </reference>

        <reference anchor="Y.Sup60" target="https://www.itu.int/rec/T-REC-Y.Sup60/en">
          <front>
            <title>Interpreting ITU-T Y.1540 maximum IP-layer capacity measurements</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date month="October" year="2021"/>
          </front>
         <refcontent>ITU-T Recommendation Y.Sup60</refcontent>
        </reference>
        <reference anchor="TR-471" target="https://www.broadband-forum.org/technical/download/TR-471.pdf">
          <front>
            <title>Maximum IP-Layer Capacity Metric, Related Metrics, and Benjamin Kaduk for their extensive comments Measurements</title>
            <author fullname="Al Morton" initials="A." surname="Morton">
              <organization>AT&amp;T Labs</organization>
            </author>
            <date month="July" year="2020"/>
          </front>
        <refcontent>Broadband Forum TR-471</refcontent>

        </reference>

        <reference anchor="Y.1540" 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>ITU-T</organization></author>
            <date month="December" year="2019"/>
          </front>
         <refcontent>ITU-T Recommendation Y.1540</refcontent>
        </reference>

        <reference anchor="LS-SG12-B" target="https://datatracker.ietf.org/liaison/1645/">
          <front>
            <title>Liaison statement: LS on the memo harmonization of IP Capacity and related topics. In a second round Latency Parameters: Consent of reviews, we acknowledge Magnus
      Westerlund, Lars Eggert, Draft Rec. Y.1540 on IP packet transfer performance parameters and Zahed Sarkar.</t>
    </section>

    <section title="Appendix New Annex A with Lab &amp; Field Evaluation Plans</title>
            <author/>
            <date month="May" year="2019"/>
          </front>
          <refcontent>From ITU-T-SG-12</refcontent>
        </reference>

        <reference anchor="LS-SG12-A" target="https://datatracker.ietf.org/liaison/1632/">
          <front>
            <title>Liaison statement: LS - Load Harmonization of IP Capacity and Latency Parameters: Revision of Draft Rec. Y.1540 on IP packet transfer performance parameters and New Annex A with Lab Evaluation Plan</title>
            <author/>
            <date month="March" year="2019"/>
          </front>
         <refcontent>From ITU-T SG 12</refcontent>
        </reference>
      </references>
    </references>

    <section anchor="app-a-load-rate-adj-pseudocode" numbered="true" toc="default">
      <name>Load Rate Adjustment Pseudo Code">
      <t>The following is Pseudocode</name>
      <t>This appendix provides a pseudo-code pseudocode implementation of the algorithm
      described in Section 8.1.</t>

      <t><figure>
          <artwork><![CDATA[Rx <xref target="load-rate-adj"/>.</t>

<sourcecode name="pseudocode-for-algorithm" type="pseudocode"><![CDATA[
Rx = 0              # The current sending rate (equivalent to a row
                    # of the table)

seqErr = 0          # Measured count of any of that includes Loss or Reordering
                    # or Duplication impairments (all appear
                    # initially as errors in the packet sequence
                    # numbering)

seqErrThresh = 10   # Threshold on seqErr count that includes Loss or
                    # Reordering or Duplication impairments (all
                    # appear initially as errors in the packet
                    # sequence numbering)

delay = 0           # Measured Range of Round Trip Delay, RTD, ms Delay (RTD), msec

lowThresh = 30      # Low threshold on the Range of RTD, ms msec

upperThresh = 90    # Upper threshold on the Range of RTD, ms
hSpeedTresh msec

hSpeedThresh = 1 Gbps    # Threshold for transition between sending rate
                    # step sizes (such as 1 Mbps and 100 Mbps) Mbps), Gbps

slowAdjCount = 0    # Measured Number of consecutive status reports
                    # indicating loss and/or delay variation above
                    # upperThresh

slowAdjThresh = 2 3   # Threshold on slowAdjCount used to infer
                    # congestion. Use values >1 > 1 to avoid
                    # misinterpreting transient loss loss.

highSpeedDelta = 10 # The number of rows to move in a single
                    # adjustment when initially increasing offered
                    # load (to ramp-up ramp up quickly)

maxLoadRates = 2000 # Maximum table index (rows)

if ( seqErr == 0 <= seqErrThresh && delay < lowThresh ) {
        if ( Rx < hSpeedTresh hSpeedThresh && slowAdjCount < slowAdjThresh ) {
                        Rx += highSpeedDelta;
                        slowAdjCount = 0;
        } else {
                        if ( Rx < maxLoadRates - 1 )
                                        Rx++;
        }
} else if ( seqErr > 0 seqErrThresh || delay > upperThresh ) {
        slowAdjCount++;
        if ( Rx < hSpeedTresh hSpeedThresh && slowAdjCount == slowAdjThresh ) {
                        if ( Rx > highSpeedDelta * 3 )
                                        Rx -= highSpeedDelta * 3;
                        else
                                        Rx = 0;
        } else {
                        if ( Rx > 0 )
                                        Rx--;
        }
}
]]></artwork>
        </figure></t>

      <t/>
]]></sourcecode>

    </section>
    <section title="Appendix B - RFC anchor="app-b-rfc8085-udp" numbered="true" toc="default">
      <name>RFC 8085 UDP Guidelines Check">
      <t>The BCP on Check</name>
      <t><xref target="RFC8085" sectionFormat="of" section="3.1"/>
(BCP 145), which provides UDP usage guidelines <xref target="RFC8085"/> guidelines, focuses
      primarily on congestion control in section 3.1. control. The Guidelines guidelines appear in
      mandatory (MUST) (<bcp14>MUST</bcp14>) and recommendation (SHOULD) (<bcp14>SHOULD</bcp14>) categories.</t>
      <section title="Assessment numbered="true" toc="default">
        <name>Assessment of Mandatory Requirements"> Requirements</name>
        <t>The mandatory requirements in Section 3 of <xref target="RFC8085"/>
        include:<list style="hanging">
            <t>Internet target="RFC8085" sectionFormat="of" section="3"/>
        include the following:</t>
          <blockquote>Internet paths can have widely varying characteristics, ...
            Consequently, applications that may be used on the Internet MUST
            NOT <bcp14>MUST
            NOT</bcp14> make assumptions about specific path characteristics. They
            MUST
            <bcp14>MUST</bcp14> instead use mechanisms that let them operate safely under
            very different path conditions. Typically, this requires
            conservatively probing the current conditions of the Internet path
            they communicate over to establish a transmission behavior that it
            can sustain and that is reasonably fair to other traffic sharing
            the path.</t>
          </list></t> path.</blockquote>
        <t>The purpose of the load rate adjustment algorithm described in Section 8.1 <xref target="load-rate-adj"/> is
        to probe the network and enable Maximum IP-Layer Capacity measurements
        with as few assumptions about the measured path as possible, possible and
        within the range application of applications described in Section 2. The degree of
        probing conservatism <xref target="sec-2-scope"/>.
        There is in tension with between the need to minimize goals of probing conservatism and
        minimization of both the traffic dedicated to testing (especially with
        Gigabit rate measurements) and the duration of the test (which is one contributing
        factor to the overall algorithm fairness).</t>
        <t>The text of Section 3 of <xref target="RFC8085"/> target="RFC8085" sectionFormat="of" section="3"/>
 goes on to
        recommend alternatives to UDP to meet the mandatory requirements, but
        none are suitable for the scope and purpose of the metrics Metrics and methods Methods
        in this memo.  In fact, ad hoc TCP-based methods fail to achieve the
        measurement accuracy repeatedly proven in comparison measurements with
        the running code <xref target="LS-SG12-A"/> target="LS-SG12-A" format="default"/> <xref target="LS-SG12-B"/> target="LS-SG12-B" format="default"/>
          <xref target="Y.Sup60"/>. target="Y.Sup60" format="default"/>. Also, the UDP aspect of these methods is
        present primarily to support modern Internet transmission where a
        transport protocol is required <xref target="copycat"/>; target="copycat" format="default"/>; the metric is
        based on the IP-Layer IP Layer, and UDP allows simple correlation to the
        IP-Layer.</t>

        <t>Section 3.1.1 of <xref target="RFC8085"/>
        IP Layer.</t>
        <t><xref target="RFC8085" sectionFormat="of" section="3.1.1"/> discusses protocol timer
        guidelines:</t>

        <t><list style="hanging">
            <t>Latency
          <blockquote>Latency samples MUST NOT <bcp14>MUST NOT</bcp14> be derived from ambiguous
            transactions. The canonical example is in a protocol that
            retransmits data, but subsequently cannot determine which copy is
            being acknowledged.</t>
          </list>Both acknowledged.</blockquote>
        <t>Both load packets and status feedback messages MUST <bcp14>MUST</bcp14> contain
        sequence numbers, which numbers; this helps with measurements based on those
        packets, and there are no retransmissions needed.<list style="hanging">
            <t>When needed.</t>
          <blockquote>When a latency estimate is used to arm a timer that provides
            loss detection -- with or without retransmission -- expiry of the
            timer MUST <bcp14>MUST</bcp14> be interpreted as an indication of congestion in the
            network, causing the sending rate to be adapted to a safe
            conservative rate...</t>
          </list></t> rate ...</blockquote>
        <t>The method methods described in this memo uses use timers for sending rate
        backoff when status feedback messages are lost (Lost Status Backoff
        timeout),
        timeout) and for stopping a test when connectivity is lost for a
        longer interval (Feedback (feedback message or load packet timeouts).</t>

        <t>There is no
        <t>This memo does not foresee any specific benefit foreseen by of using Explicit Congestion
        Notification (ECN) in this memo.</t>

        <t>Section 3.2 of <xref target="RFC8085"/> (ECN).</t>
        <t><xref target="RFC8085" sectionFormat="of" section="3.2"/> discusses message size
        guidelines:<list style="hanging">
            <t>To
        guidelines:</t>
          <blockquote>To determine an appropriate UDP payload size, applications MUST <bcp14>MUST</bcp14>
            subtract the size of the IP header (which includes any IPv4
            optional headers or IPv6 extension headers) as well as the length
            of the UDP header (8 bytes) from the PMTU size.</t>
          </list></t> size.</blockquote>

        <t>The method uses a sending rate table with a maximum UDP payload
        size that anticipates significant header overhead and avoids
        fragmentation.</t>

        <t>Section 3.3 of <xref target="RFC8085"/>
        <t><xref target="RFC8085" sectionFormat="of" section="3.3"/> provides reliability
        guidelines:<list style="hanging">
            <t>Applications
        guidelines:</t>
          <blockquote>Applications that do require reliable message delivery MUST <bcp14>MUST</bcp14>
            implement an appropriate mechanism themselves.</t>
          </list></t> themselves.</blockquote>
        <t>The IP-Layer Capacity Metric Metrics and Method Methods do not require reliable
        delivery.<list style="hanging">
            <t>Applications
        delivery.</t>
          <blockquote>Applications that require ordered delivery MUST <bcp14>MUST</bcp14> reestablish
            datagram ordering themselves.</t>
          </list></t> themselves.</blockquote>
        <t>The IP-Layer Capacity Metric Metrics and Method does Methods do not need to
        reestablish packet order; it is preferred preferable to measure packet reordering
        if it occurs <xref target="RFC4737"/>.</t> target="RFC4737" format="default"/>.</t>
      </section>
      <section title="Assessment numbered="true" toc="default">
        <name>Assessment of Recommendations"> Recommendations</name>
        <t>The load rate adjustment algorithm's goal is to determine the
        Maximum IP-Layer Capacity in the context of an infrequent, diagnostic,
        short term
        short-term measurement. This goal is a global exception to many <bcp14>SHOULD</bcp14>-level requirements as listed in <xref
        target="RFC8085"/> SHOULD-level requirements, target="RFC8085" format="default"/>, of which many are
        intended for long-lived flows that must coexist with other traffic in
        more-or-less a
        more or less fair way. However, the algorithm (as specified in Section
        8.1
        <xref target="load-rate-adj"/> and Appendix A <xref target="app-a-load-rate-adj-pseudocode"/> above) reacts to indications of congestion in
        clearly defined ways.</t>
        <t>A specific recommendation is provided as an example. Section 3.1.5
        of <xref target="RFC8085"/> on target="RFC8085" sectionFormat="of" section="3.1.5"/> (regarding the implications of RTT and Loss
        Measurements loss measurements on Congestion Control says:<list style="hanging">
            <t>A congestion control) says:</t>
          <blockquote>A congestion control [algorithm] designed for UDP SHOULD <bcp14>SHOULD</bcp14> respond as quickly
            as possible when it experiences congestion, and it SHOULD <bcp14>SHOULD</bcp14> take
            into account both the loss rate and the response time when
            choosing a new rate.</t>
          </list></t> rate.</blockquote>
        <t>The load rate adjustment algorithm responds to loss and RTT
        measurements with a clear and concise rate reduction when warranted,
        and the response makes use of direct measurements (more exact than can
        be inferred from TCP ACKs).</t>

        <t>Section 3.1.5 of <xref target="RFC8085"/>
        <t><xref target="RFC8085" sectionFormat="of" section="3.1.5"/> goes on to specify:<list
            style="hanging">
            <t>The specify the following:</t>
          <blockquote>The implemented congestion control scheme SHOULD <bcp14>SHOULD</bcp14> result in
            bandwidth (capacity) use that is comparable to that of TCP within
            an order of magnitude, so that it does not starve other flows
            sharing a common bottleneck.</t>
          </list></t> bottleneck.</blockquote>
        <t>This is a requirement for coexistent streams, and not for
        diagnostic and infrequent measurements using short durations. The rate
        oscillations during short tests allow other packets to pass, pass and
        don&rsquo;t
        don't starve other flows.</t>
        <t>Ironically, ad hoc TCP-based measurements of "Internet Speed" are
        also designed to work around this SHOULD-level <bcp14>SHOULD</bcp14>-level requirement, by
        launching many flows (9, for example) to increase the outstanding data
        dedicated to testing.</t>
        <t>The load rate adjustment algorithm cannot become a TCP-like
        congestion control, or it will have the same weaknesses of TCP when
        trying to make a Maximum IP-Layer Capacity measurement, measurement and will not
        achieve the goal. The results of the referenced testing <xref
        target="LS-SG12-A"/> target="LS-SG12-A" format="default"/> <xref target="LS-SG12-B"/> target="LS-SG12-B" format="default"/> <xref
        target="Y.Sup60"/> target="Y.Sup60" format="default"/> supported this statement hundreds of times, with
        comparisons to multi-connection TCP-based measurements.</t>
        <t>A brief review of some other SHOULD-level requirements from <xref target="RFC8085"/> follows (Yes (marked "Yes" when this memo is compliant, or Not applicable = NA) :<figure>
            <artwork><![CDATA[+--+---------------------------------------------------------+---------+
|Y?| "NA" (Not Applicable)):</t>

<table anchor="recs-rfc8085">
  <name>Summary of Key Guidelines from RFC 8085 Recommendation                                 | Section |
+--+---------------------------------------------------------+---------+
Yes| MUST 8085</name>
  <thead>
    <tr>
      <th>Yes?</th>
      <th>Recommendation in RFC 8085</th>
      <th>Section</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Yes</td>
      <td><bcp14>MUST</bcp14> tolerate a wide range of Internet path conditions  | 3       |
NA | SHOULD conditions</td>
      <td><xref target="RFC8085" section="3" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td>NA</td>
      <td><bcp14>SHOULD</bcp14> use a full-featured transport (e.g., TCP)        |         |
   |                                                         |         |
Yes| SHOULD TCP)</td>
      <td></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>Yes</td>
      <td><bcp14>SHOULD</bcp14> control rate of transmission                     | 3.1     |
NA | SHOULD transmission</td>
      <td><xref target="RFC8085" section="3.1" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td>NA</td>
      <td><bcp14>SHOULD</bcp14> perform congestion control over all traffic      |         |
   |                                                         |         |
   | for traffic</td>
      <td></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <th></th>
      <th>For bulk transfers,                                     | 3.1.2   |
NA | SHOULD transfers,</th>
      <th><xref target="RFC8085" section="3.1.2" sectionFormat="bare"/></th>
    </tr>
    <tr>
      <td>NA</td>
      <td><bcp14>SHOULD</bcp14> consider implementing TFRC                       |         |
NA | else, SHOULD TFRC</td>
      <td></td>
    </tr>
    <tr>
      <td>NA</td>
      <td>else, <bcp14>SHOULD</bcp14> in other ways use bandwidth similar to TCP |         |
   |                                                         |         |
   | for TCP</td>
      <td></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <th></th>
      <th>For non-bulk transfers,                                 | 3.1.3   |
NA | SHOULD transfers,</th>
      <th><xref target="RFC8085" section="3.1.3" sectionFormat="bare"/></th>
    </tr>
    <tr>
      <td>NA</td>
      <td><bcp14>SHOULD</bcp14> measure RTT and transmit max. 1 datagram/RTT     | 3.1.1   |
NA | else, SHOULD datagram/RTT</td>
      <td><xref target="RFC8085" section="3.1.1" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td>NA</td>
      <td>else, <bcp14>SHOULD</bcp14> send at most 1 datagram every 3 seconds    |         |
NA | SHOULD seconds</td>
      <td></td>
    </tr>
    <tr>
      <td>NA</td>
      <td><bcp14>SHOULD</bcp14> back-off retransmission timers following loss    |         |
   |                                                         |         |
Yes| SHOULD loss</td>
      <td></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>Yes</td>
      <td><bcp14>SHOULD</bcp14> provide mechanisms to regulate the bursts of     | 3.1.6   |
   | transmission                                            |         |
   |                                                         |         |
NA | MAY transmission</td>
      <td><xref target="RFC8085" section="3.1.6" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>NA</td>
      <td><bcp14>MAY</bcp14> implement ECN; a specific set of application        | 3.1.7   |
   | mechanisms are REQUIRED <bcp14>REQUIRED</bcp14> if ECN is used.                 |         |
   |                                                         |         |
Yes| for used</td>
      <td><xref target="RFC8085" section="3.1.7" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>Yes</td>
      <td>For DiffServ, SHOULD NOT <bcp14>SHOULD NOT</bcp14> rely on implementation of PHBs | 3.1.8   |
   |                                                         |         |
Yes| for PHBs</td>
      <td><xref target="RFC8085" section="3.1.8" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>Yes</td>
      <td>For QoS-enabled paths, MAY <bcp14>MAY</bcp14> choose not to use CC         | 3.1.9   |
   |                                                         |         |
Yes| SHOULD NOT CC</td>
      <td><xref target="RFC8085" section="3.1.9" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>Yes</td>
      <td><bcp14>SHOULD NOT</bcp14> rely solely on QoS for their capacity        | 3.1.10  |
   | non-CC capacity</td>
      <td><xref target="RFC8085" section="3.1.10" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td>NA</td>
      <td>non-CC controlled flows SHOULD <bcp14>SHOULD</bcp14> implement a transport    |         |
   | circuit breaker                                         |         |
   | MAY breaker</td>
      <td></td>
    </tr>
    <tr>
      <td>Yes</td>
      <td><bcp14>MAY</bcp14> implement a circuit breaker for other applications  |         |
   |                                                         |         |
   | for applications</td>
      <td></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <th></th>
      <th>For tunnels carrying IP traffic,                        | 3.1.11  |
NA | SHOULD NOT traffic,</th>
      <th><xref target="RFC8085" section="3.1.11" sectionFormat="bare"/></th>
    </tr>
    <tr>
      <td>NA</td>
      <td><bcp14>SHOULD NOT</bcp14> perform congestion control                   |         |
NA | MUST control</td>
      <td></td>
    </tr>
    <tr>
      <td>NA</td>
      <td><bcp14>MUST</bcp14> correctly process the IP ECN field                 |         |
   |                                                         |         |
   | for field</td>
      <td></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <th></th>
      <th>For non-IP tunnels or rate not determined by traffic,   |         |
NA | SHOULD traffic,</th>
      <th><xref target="RFC8085" section="3.1.11" sectionFormat="bare"/></th>
    </tr>
    <tr>
      <td>NA</td>
      <td><bcp14>SHOULD</bcp14> perform CC or use circuit breaker                | 3.1.11  |
NA | SHOULD breaker</td>
      <td></td>
    </tr>
    <tr>
      <td>NA</td>
      <td><bcp14>SHOULD</bcp14> restrict types of traffic transported by the     |         |
   | tunnel                                                  |         |
   |                                                         |         |
Yes| SHOULD NOT tunnel</td>
      <td></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>Yes</td>
      <td><bcp14>SHOULD NOT</bcp14> send datagrams that exceed the PMTU, i.e.,   | 3.2     |
Yes| SHOULD i.e.,</td>
      <td><xref target="RFC8085" section="3.2" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td>Yes</td>
      <td><bcp14>SHOULD</bcp14> discover PMTU or send datagrams < &lt; minimum PMTU;  |         |
NA | Specific PMTU</td>
      <td></td>
    </tr>
    <tr>
      <td>NA</td>
      <td>Specific application mechanisms are REQUIRED <bcp14>REQUIRED</bcp14> if PLPMTUD |         |
   | is used.                                                |         |
   |                                                         |         |
Yes| SHOULD used</td>
      <td></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>Yes</td>
      <td><bcp14>SHOULD</bcp14> handle datagram loss, duplication, reordering    | 3.3     |
NA | SHOULD reordering</td>
      <td><xref target="RFC8085" section="3.3" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td>NA</td>
      <td><bcp14>SHOULD</bcp14> be robust to delivery delays up to 2 minutes     |         |
   |                                                         |         |
Yes| SHOULD minutes</td>
      <td></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>Yes</td>
      <td><bcp14>SHOULD</bcp14> enable IPv4 UDP checksum                         | 3.4     |
Yes| SHOULD checksum</td>
      <td><xref target="RFC8085" section="3.4" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td>Yes</td>
      <td><bcp14>SHOULD</bcp14> enable IPv6 UDP checksum; Specific specific application   | 3.4.1   |
   | mechanisms are REQUIRED <bcp14>REQUIRED</bcp14> if a zero IPv6 UDP checksum is  |         |
   | used.                                                   |         |
   |                                                         |         |
NA | SHOULD used</td>
      <td><xref target="RFC8085" section="3.4.1" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>NA</td>
      <td><bcp14>SHOULD</bcp14> provide protection from off-path attacks         | 5.1     |
   | else, MAY attacks</td>
      <td><xref target="RFC8085" section="5.1" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td></td>
      <td>else, <bcp14>MAY</bcp14> use UDP-Lite with suitable checksum coverage  | 3.4.2   |
   |                                                         |         |
NA | SHOULD NOT coverage</td>
      <td><xref target="RFC8085" section="3.4.2" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>NA</td>
      <td><bcp14>SHOULD NOT</bcp14> always send middlebox keep-alive messages    | 3.5     |
NA | MAY messages</td>
      <td><xref target="RFC8085" section="3.5" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td>NA</td>
      <td><bcp14>MAY</bcp14> use keep-alives when needed (min. interval 15 sec)  |         |
   |                                                         |         |
Yes| Applications sec)</td>
      <td></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>Yes</td>
      <td>Applications specified for use in limited use (or       | 3.6     |
   | controlled environments) SHOULD <bcp14>SHOULD</bcp14> identify equivalent     |         |
   | mechanisms and describe their use case.                 |         |
   |                                                         |         |
NA | Bulk-multicast case</td>
      <td><xref target="RFC8085" section="3.6" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>NA</td>
      <td>Bulk-multicast apps SHOULD <bcp14>SHOULD</bcp14> implement congestion control | 4.1.1   |
   |                                                         |         |
NA | Low control</td>
      <td><xref target="RFC8085" section="4.1.1" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>NA</td>
      <td>Low volume multicast apps SHOULD <bcp14>SHOULD</bcp14> implement congestion   | 4.1.2   |
   | control                                                 |         |
   |                                                         |         |
NA | Multicast control</td>
      <td><xref target="RFC8085" section="4.1.2" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>NA</td>
      <td>Multicast apps SHOULD <bcp14>SHOULD</bcp14> use a safe PMTU                   | 4.2     |
   |                                                         |         |
Yes| SHOULD PMTU</td>
      <td><xref target="RFC8085" section="4.2" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>Yes</td>
      <td><bcp14>SHOULD</bcp14> avoid using multiple ports                       | 5.1.2   |
Yes| MUST ports</td>
      <td><xref target="RFC8085" section="5.1.2" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td>Yes</td>
      <td><bcp14>MUST</bcp14> check received IP source address                   |         |
   |                                                         |         |
NA | SHOULD address</td>
      <td></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>NA</td>
      <td><bcp14>SHOULD</bcp14> validate payload in ICMP messages                | 5.2     |
   |                                                         |         |
Yes| SHOULD messages</td>
      <td><xref target="RFC8085" section="5.2" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td colspan="3"></td>
    </tr>
    <tr>
      <td>Yes</td>
      <td><bcp14>SHOULD</bcp14> use a randomized source Source port or equivalent       | 6       |
   | technique, and, for client/server applications, SHOULD  |         |
   | <bcp14>SHOULD</bcp14> send responses from source address matching request     |         |
   | 5.1                                                     |         |
NA | SHOULD request</td>
      <td><xref target="RFC8085" section="6" sectionFormat="bare"/></td>
    </tr>
    <tr>
      <td>NA</td>
      <td><bcp14>SHOULD</bcp14> use standard IETF security protocols when needed | 6       |
   +---------------------------------------------------------+---------+]]></artwork>
          </figure></t>

        <t/>

        <t/> needed</td>
      <td><xref target="RFC8085" section="6" sectionFormat="bare"/></td>
    </tr>
  </tbody>
</table>
      </section>
    </section>
  </middle>

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

      <?rfc ?>

      <?rfc ?>

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

      <?rfc ?>

      <?rfc ?>

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

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

      <?rfc ?>

      <?rfc ?>

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

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

      <?rfc ?>

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

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

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

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

      <?rfc ?>

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

      <?rfc ?>

      <?rfc ?>
    </references>

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

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

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

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

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

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

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

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

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

      <reference anchor="copycat"
                 target="https://irtf.org/anrw/2017/anrw17-final5.pdf">
        <front>
          <title>copycat: Testing Differential Treatment of New Transport
          Protocols in the Wild (ANRW '17)</title>

          <author fullname="Korian Edeline" initials="K." surname="Edleine">
            <organization/>
          </author>

          <author fullname="Mirja Kuhlewind" initials="K." surname="Kuhlewind">
            <organization/>
          </author>

          <author fullname="Brian Trammell" initials="B." surname="Trammell">
            <organization/>
          </author>

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

          <date day="15" month="July" year="2017"/>
        </front>
      </reference>

      <reference anchor="Y.Sup60"
                 target="https://www.itu.int/rec/T-REC-Y.Sup60/en">
        <front>
          <title>Recommendation Y.Sup60, (09/20) Interpreting ITU-T Y.1540
          maximum IP-layer capacity measurements, and Errata</title>

          <author fullname="Al Morton" initials="A., Rapporteur"
                  surname="Morton">
            <organization>AT&amp;T</organization>
          </author>

          <date day="11" month="September" year="2020"/>
        </front>
      </reference>

      <reference anchor="TR-471"
                 target="https://www.broadband-forum.org/technical/download/TR-471.pdf">
        <front>
          <title>Broadband Forum TR-471: IP Layer Capacity Metrics and
          Measurement</title>

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

          <date day="10" month="July" year="2020"/>
        </front>
      </reference>

      <reference anchor="Y.1540"
                 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 fullname="ITU-T Recommendation Y.1540" surname="">
            <organization>ITU-T</organization>
          </author>

          <date month="December" year="2019"/>
        </front>
      </reference>

      <reference anchor="LS-SG12-B"
                 target="https://datatracker.ietf.org/liaison/1645/">
        <front>
          <title>LS on harmonization of IP Capacity and Latency Parameters:
          Consent of Draft Rec. Y.1540

    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>Thanks to <contact fullname="Joachim Fabini"/>, <contact fullname="Matt Mathis"/>, <contact fullname="J. Ignacio Alvarez-Hamelin"/>,
      <contact fullname="Wolfgang Balzer"/>, <contact fullname="Frank Brockners"/>, <contact fullname="Greg Mirsky"/>, <contact fullname="Martin Duke"/>, <contact fullname="Murray Kucherawy"/>, and <contact fullname="Benjamin Kaduk"/> for their extensive comments on IP packet transfer performance
          parameters and New Annex A with Lab &amp; Field Evaluation
          Plans</title>

          <author fullname="ITU-T SG 12" surname="">
            <organization>ITU-T</organization>
          </author>

          <date month="March" year="2019"/>
        </front>
      </reference>

      <reference anchor="LS-SG12-A"
                 target="https://datatracker.ietf.org/liaison/1632/">
        <front>
          <title>LS - Harmonization of IP Capacity this memo
      and Latency Parameters:
          Revision related topics. In a second round of Draft Rec. Y.1540 on IP packet transfer performance
          parameters and New Annex A with Lab Evaluation Plan</title>

          <author fullname="ITU-T SG 12" surname="">
            <organization>ITU-T</organization>
          </author>

          <date month="May" year="2019"/>
        </front>
      </reference>

      <reference anchor="udpst"
                 target="https://github.com/BroadbandForum/obudpst">
        <front>
          <title>UDP Speed Test Open Broadband project</title>

          <author fullname="" surname="">
            <organization>udpst Project Collaborators</organization>
          </author>

          <date month="December" year="2020"/>
        </front>
      </reference>

      <?rfc ?>

      <?rfc ?>
    </references> reviews, we acknowledge <contact fullname="Magnus Westerlund"/>, <contact fullname="Lars Eggert"/>, and <contact fullname="Zaheduzzaman Sarker"/>.</t>
    </section>
  </back>
</rfc>