rfc9097xml2.original.xml   rfc9097.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!-- [CS] updated by Chris 06/14/21 -->
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-ippm-capacit
<?rfc sortrefs="yes"?> y-metric-method-12"
<?rfc comments="yes"?> number="9097" ipr="trust200902" updates="" obsoletes="" submissionType="IETF" c
<?rfc inline="yes"?> ategory="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" symR
<?rfc compact="yes"?> efs="true" sortRefs="true" version="3">
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-ippm-capacity-metric-method-12" <!-- xml2rfc v2v3 conversion 3.8.0 -->
ipr="trust200902" updates="">
<front> <front>
<title abbrev="IP Capacity Metrics/Methods">Metrics and Methods for <title abbrev="IP Capacity Metrics/Methods">Metrics and Methods for
One-way IP Capacity</title> One-Way IP Capacity</title>
<seriesInfo name="RFC" value="9097"/>
<author fullname="Al Morton" initials="A." surname="Morton"> <author fullname="Al Morton" initials="A." surname="Morton">
<organization>AT&amp;T Labs</organization> <organization>AT&amp;T Labs</organization>
<address> <address>
<postal> <postal>
<street>200 Laurel Avenue South</street> <street>200 Laurel Avenue South</street>
<city>Middletown</city> <city>Middletown</city>
<region>NJ</region> <region>NJ</region>
<code>07748</code> <code>07748</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<phone>+1 732 420 1571</phone> <phone>+1 732 420 1571</phone>
<facsimile>+1 732 368 1192</facsimile>
<email>acm@research.att.com</email> <email>acm@research.att.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Rüdiger Geib" initials="R." surname="Geib">
<author fullname="Ruediger Geib" initials="R." surname="Geib">
<organization>Deutsche Telekom</organization> <organization>Deutsche Telekom</organization>
<address> <address>
<postal> <postal>
<street>Heinrich Hertz Str. 3-7</street> <street>Heinrich Hertz Str. 3-7</street>
<city>Darmstadt</city> <city>Darmstadt</city>
<region/>
<code>64295</code> <code>64295</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<phone>+49 6151 5812747</phone> <phone>+49 6151 5812747</phone>
<facsimile/>
<email>Ruediger.Geib@telekom.de</email> <email>Ruediger.Geib@telekom.de</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Len Ciavattone" initials="L." surname="Ciavattone"> <author fullname="Len Ciavattone" initials="L." surname="Ciavattone">
<organization>AT&amp;T Labs</organization> <organization>AT&amp;T Labs</organization>
<address> <address>
<postal> <postal>
<street>200 Laurel Avenue South</street> <street>200 Laurel Avenue South</street>
<city>Middletown</city> <city>Middletown</city>
<region>NJ</region> <region>NJ</region>
<code>07748</code> <code>07748</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<phone>+1 732 420 1239</phone>
<phone/>
<facsimile/>
<email>lencia@att.com</email> <email>lencia@att.com</email>
<uri/>
</address> </address>
</author> </author>
<date month="November" year="2021"/>
<date day="9" month="June" year="2021"/> <keyword>IP Layer</keyword>
<keyword>Performance</keyword>
<keyword>Speed</keyword>
<keyword>Access</keyword>
<abstract> <abstract>
<t>This memo revisits the problem of Network Capacity metrics first <t>This memo revisits the problem of Network Capacity Metrics first
examined in RFC 5136. The memo specifies a more practical Maximum examined in RFC 5136. This memo specifies a more practical Maximum
IP-Layer Capacity metric definition catering for measurement purposes, IP-Layer Capacity Metric definition catering to measurement
and outlines the corresponding methods of measurement.</t> and outlines the corresponding Methods of Measurement.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>The IETF's efforts to define Network and Bulk Transport Capacity have <name>Introduction</name>
<t>The IETF's efforts to define Network Capacity and Bulk Transport Capaci
ty (BTC) have
been chartered and progressed for over twenty years. Over that time, the been chartered and progressed for over twenty years. Over that time, the
performance community has seen development of Informative definitions in performance community has seen the development of Informative definitions
<xref target="RFC3148"/> for Framework for Bulk Transport Capacity in
(BTC), RFC 5136 for Network Capacity and Maximum IP-Layer Capacity, and <xref target="RFC3148" format="default"/> for the Framework for Bulk Trans
the Experimental metric definitions and methods in <xref port Capacity, <xref target="RFC5136"/> for Network Capacity and Maximum IP-Laye
target="RFC8337"/>, Model-Based Metrics for BTC.</t> r Capacity, and the Experimental metric definitions and methods in
"<xref target="RFC8337" format="title"/>" <xref target="RFC8337" format="default
<t>This memo revisits the problem of Network Capacity metrics examined "/>.</t>
first in <xref target="RFC3148"/> and later in <xref target="RFC5136"/>. <t>This memo revisits the problem of Network Capacity Metrics examined
Maximum IP-Layer Capacity and <xref target="RFC3148"/> Bulk Transfer first in <xref target="RFC3148" format="default"/> and later in <xref targ
Capacity (goodput) are different metrics. Maximum IP-Layer Capacity is et="RFC5136" format="default"/>.
like the theoretical goal for goodput. There are many metrics in <xref Maximum IP-Layer Capacity and Bulk Transfer Capacity <xref target="RFC3148
target="RFC5136"/>, such as Available Capacity. Measurements depend on " format="default"/> (goodput) are different metrics. Maximum IP-Layer Capacity
is
like the theoretical goal for goodput. There are many metrics in <xref tar
get="RFC5136" format="default"/>, such as Available Capacity. Measurements depen
d on
the network path under test and the use case. Here, the main use case is the network path under test and the use case. Here, the main use case is
to assess the maximum capacity of one or more networks where the to assess the Maximum Capacity of one or more networks where the
subscriber receives specific performance assurances, sometimes referred subscriber receives specific performance assurances, sometimes referred
to as the Internet access, or where a limit of the technology used on a to as 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 path is being tested. For example, when a user subscribes to a 1 Gbps
service, then the user, the service provider, and possibly other parties service, then the user, the Service Provider, and possibly other parties
want to assure that performance level is delivered. When a test confirms want to assure that the specified performance level is delivered. When a t
the subscribed performance level, then a tester can seek the location of est confirms
the subscribed performance level, a tester can seek the location of
a bottleneck elsewhere.</t> a bottleneck elsewhere.</t>
<t>This memo recognizes the importance of a definition of a Maximum <t>This memo recognizes the importance of a definition of a Maximum
IP-Layer Capacity Metric at a time when Internet subscription speeds IP-Layer Capacity Metric at a time when Internet subscription speeds
have increased dramatically; a definition that is both practical and have increased dramatically -- a definition that is both practical and
effective for the performance community's needs, including Internet effective for the performance community's needs, including Internet
users. The metric definition is intended to use Active Methods of users. The metric definitions are intended to use Active Methods of
Measurement <xref target="RFC7799"/>, and a method of measurement is Measurement <xref target="RFC7799" format="default"/>, and a Method of Mea
included.</t> surement is
included for each metric.</t>
<t>The most direct active measurement of IP-Layer Capacity would use IP <t>The most direct Active Measurement of IP-Layer Capacity would use IP
packets, but in practice a transport header is needed to traverse packets, but in practice a transport header is needed to traverse
address and port translators. UDP offers the most direct assessment address and port translators. UDP offers the most direct assessment
possibility, and in the <xref target="copycat"/> measurement study to possibility, and in the measurement study to investigate whether UDP is vi
investigate whether UDP is viable as a general Internet transport able as a general Internet transport protocol <xref target="copycat" format="def
protocol, the authors found that a high percentage of paths tested ault"/>, the authors found that a high percentage of paths tested
support UDP transport. A number of liaisons have been exchanged on this support UDP transport. A number of liaison statements have been exchanged
topic <xref target="LS-SG12-A"/> <xref target="LS-SG12-B"/>, discussing on this
topic <xref target="LS-SG12-A" format="default"/> <xref target="LS-SG12-B"
format="default"/>, discussing
the laboratory and field tests that support the UDP-based approach to the laboratory and field tests that support the UDP-based approach to
IP-Layer Capacity measurement.</t> IP-Layer Capacity measurement.</t>
<t>This memo also recognizes the updates to the IP Performance
<t>This memo also recognizes the many updates to the IP Performance Metrics (IPPM) Framework <xref target="RFC2330" format="default"/> that ha
Metrics Framework <xref target="RFC2330"/> published over twenty years, ve been published since 1998. In particular, it makes use of <xref target="RFC73
and makes use of <xref target="RFC7312"/> for Advanced Stream and 12" format="default"/> for the Advanced Stream and
Sampling Framework, and <xref target="RFC8468"/> with IPv4, IPv6, and Sampling Framework and <xref target="RFC8468" format="default"/> for its I
Pv4, IPv6, and
IPv4-IPv6 Coexistence Updates.</t> IPv4-IPv6 Coexistence Updates.</t>
<t><xref target="app-a-load-rate-adj-pseudocode"/> describes the load rate
<t>Appendix A describes the load rate adjustment algorithm in adjustment algorithm, using
pseudo-code. Appendix B discusses the algorithm's compliance with <xref pseudocode. <xref target="app-b-rfc8085-udp"/> discusses the algorithm's c
target="RFC8085"/>.</t> ompliance with <xref target="RFC8085" format="default"/>.</t>
<section numbered="true" toc="default">
<section title="Requirements Language"> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
14<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only "<bcp14>SHOULD NOT</bcp14>",
when, they appear in all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section> </section>
</section> </section>
<section anchor="sec-2-scope" numbered="true" toc="default">
<section title="Scope, Goals, and Applicability"> <name>Scope, Goals, and Applicability</name>
<t>The scope of this memo is to define Active Measurement metrics and <t>The scope of this memo is to define Active Measurement metrics and
corresponding methods to unambiguously determine Maximum IP-Layer corresponding methods to unambiguously determine Maximum IP-Layer
Capacity and useful secondary metrics.</t> Capacity and useful secondary metrics.</t>
<t>Another goal is to harmonize the specified Metric and Method across
<t>Another goal is to harmonize the specified metric and method across
the industry, and this memo is the vehicle that captures IETF consensus, the industry, and this memo is the vehicle that captures IETF consensus,
possibly resulting in changes to the specifications of other Standards possibly resulting in changes to the specifications of other Standards
Development Organizations (SDO) (through each SDO's normal contribution Development Organizations (SDOs) (through each SDO's normal contribution
process, or through liaison exchange).</t> process or through liaison exchange).</t>
<t>Secondary goals are to add considerations for test procedures and to
<t>Secondary goals are to add considerations for test procedures, and to
provide interpretation of the Maximum IP-Layer Capacity results (to provide interpretation of the Maximum IP-Layer Capacity results (to
identify cases where more testing is warranted, possibly with alternate identify cases where more testing is warranted, possibly with alternate
configurations). Fostering the development of protocol support for this configurations). Fostering the development of protocol support for this
metric and method of measurement is also a goal of this memo (all active Metric and Method of Measurement is also a goal of this memo (all active
testing protocols currently defined by the IPPM WG are UDP-based, testing protocols currently defined by the IPPM WG are UDP based,
meeting a key requirement of these methods). The supporting protocol meeting a key requirement of these methods). The supporting protocol
development to measure this metric according to the specified method is development to measure this metric according to the specified method is
a key future contribution to Internet measurement.</t> a key future contribution to Internet measurement.</t>
<t>The load rate adjustment algorithm's scope is limited to helping <t>The load rate adjustment algorithm's scope is limited to helping
determine the Maximum IP-Layer Capacity in the context of an infrequent, determine the Maximum IP-Layer Capacity in the context of an infrequent,
diagnostic, short term measurement. It is RECOMMENDED to discontinue diagnostic, short-term measurement. It is <bcp14>RECOMMENDED</bcp14> to di scontinue
non-measurement traffic that shares a subscriber's dedicated resources non-measurement traffic that shares a subscriber's dedicated resources
while testing: measurements may not be accurate and throughput of while testing: measurements may not be accurate, and throughput of
competing elastic traffic may be greatly reduced.</t> competing elastic traffic may be greatly reduced.</t>
<t>The primary application of the Metrics and Methods of Measurement
described here is the same as what is described in <xref target="RFC7497"
sectionFormat="of" section="2"/>, where:</t>
<t>The primary application of the metric and method of measurement <blockquote>The access portion of the network is the focus of this probl
described here is the same as in Section 2 of <xref target="RFC7497"/> em
where:<list style="symbols">
<t>The access portion of the network is the focus of this problem
statement. The user typically subscribes to a service with statement. The user typically subscribes to a service with
bidirectional Internet access partly described by rates in bits per bidirectional [Internet] access partly described by rates in bits per
second.</t> second.</blockquote>
</list>In addition, the use of the load rate adjustment algorithm <t>In addition, the use of the load rate adjustment algorithm
described in section 8.1 has the following additional applicability described in <xref target="load-rate-adj"/> has the following additional a
pplicability
limitations:</t> limitations:</t>
<ul spacing="normal">
<t>- MUST only be used in the application of diagnostic and operations <li>It <bcp14>MUST</bcp14> only be used in the application of diagnostic a
measurements as described in this memo</t> nd operations
measurements as described in this memo.</li>
<t>- MUST only be used in circumstances consistent with Section 10, <li>It <bcp14>MUST</bcp14> only be used in circumstances consistent with
Security Considerations</t> <xref target="sec-cons"/> ("Security Considerations").</li>
<li>If a network operator is certain of the IP-Layer Capacity to be
<t>- If a network operator is certain of the IP-layer capacity to be validated, then testing <bcp14>MAY</bcp14> start with a fixed-rate test at
validated, then testing MAY start with a fixed rate test at the IP-layer the IP-Layer
capacity and avoid activating the load adjustment algorithm. However, Capacity and avoid activating the load adjustment algorithm. However,
the stimulus for a diagnostic test (such as a subscriber request) the stimulus for a diagnostic test (such as a subscriber request)
strongly implies that there is no certainty and the load adjustment strongly implies that there is no certainty, and the load adjustment
algorithm is RECOMMENDED.</t> algorithm is <bcp14>RECOMMENDED</bcp14>.</li>
</ul>
<t>Further, the metric and method of measurement are intended for use <t>Further, the Metrics and Methods of Measurement are intended for use
where specific exact path information is unknown within a range of where specific exact path information is unknown within a range of
possible values:</t> possible values:</t>
<ul spacing="normal">
<t>- the subscriber's exact Maximum IP-Layer Capacity is unknown (which <li>The subscriber's exact Maximum IP-Layer Capacity is unknown (which
is sometimes the case; service rates can be increased due to upgrades is sometimes the case; service rates can be increased due to upgrades
without a subscriber's request, or to provide a surplus to compensate without a subscriber's request or increased to provide a surplus to compen
for possible underestimates of TCP-based testing).</t> sate
for possible underestimates of TCP-based testing).</li>
<t>- the size of the bottleneck buffer is unknown.</t> <li>The size of the bottleneck buffer is unknown.</li>
</ul>
<t>Finally, the measurement system's load rate adjustment algorithm <t>Finally, the measurement system's load rate adjustment algorithm
SHALL NOT be provided with the exact capacity value to be validated a <bcp14>SHALL NOT</bcp14> be provided with the exact capacity value to be v
priori. This restriction fosters a fair result, and removes an alidated a&nbsp;priori. This restriction fosters a fair result and removes an
opportunity for bad actors to operate with knowledge of the "right opportunity for nefarious operation enabled by knowledge of the correct an
answer".</t> swer.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Motivation"> <name>Motivation</name>
<t>As with any problem that has been worked for many years in various <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 SDOs without any special attempts at coordination, various solutions for
metrics and methods have emerged.</t> Metrics and Methods have emerged.</t>
<t>There are five factors that have changed (or began to change) in the
<t>There are five factors that have changed (or begun to change) in the
2013-2019 time frame, and the presence of any one of them on the path 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 requires features in the measurement design to account for the
changes:</t> changes:
<t><list style="numbers"> </t>
<t>Internet access is no longer the bottleneck for many users (but <ol spacing="normal" type="1"><li>Internet access is no longer the bottlen
eck for many users (but
subscribers expect network providers to honor contracted subscribers expect network providers to honor contracted
performance).</t> performance).</li>
<li>Both transfer rate and latency are important to a user's
<t>Both transfer rate and latency are important to user's satisfaction.</li>
satisfaction.</t> <li>UDP's role in transport is growing in areas where TCP once
dominated.</li>
<t>UDP's growing role in Transport, in areas where TCP once <li>Content and applications are moving physically closer to
dominated.</t> users.</li>
<li>There is less emphasis on ISP gateway measurements, possibly due
<t>Content and applications are moving physically closer to to less traffic crossing ISP gateways in the future.</li>
users.</t> </ol>
<t>There is less emphasis on ISP gateway measurements, possibly due
to less traffic crossing ISP gateways in the future.</t>
</list></t>
</section> </section>
<section anchor="gen-params-defs" numbered="true" toc="default">
<section title="General Parameters and Definitions"> <name>General Parameters and Definitions</name>
<t>This section lists the REQUIRED input factors to specify a Sender or <t>This section lists the <bcp14>REQUIRED</bcp14> input factors to specify
Receiver metric.<list style="symbols"> a Sender or
<t>Src, one of the addresses of a host (such as a globally routable Receiver metric.</t>
IP address).</t> <dl spacing="normal">
<dt>Src:</dt><dd>One of the addresses of a host (such as a globally rout
<t>Dst, one of the addresses of a host (such as a globally routable able
IP address).</t> IP address).</dd>
<dt>Dst:</dt><dd>One of the addresses of a host (such as a globally rout
<t>MaxHops, the limit on the number of Hops a specific packet may able
IP address).</dd>
<dt>MaxHops:</dt><dd>The limit on the number of Hops a specific packet m
ay
visit as it traverses from the host at Src to the host at Dst visit as it traverses from the host at Src to the host at Dst
(implemented in the TTL or Hop Limit).</t> (implemented in the TTL or Hop Limit).</dd>
<dt>T0:</dt><dd>The time at the start of a measurement interval, when pa
<t>T0, the time at the start of measurement interval, when packets ckets
are first transmitted from the Source.</t> are first transmitted from the Source.</dd>
<dt>I:</dt><dd>The nominal duration of a measurement interval at the
<t>I, the nominal duration of a measurement interval at the Destination (default 10 sec).</dd>
destination (default 10 sec)</t> <dt>dt:</dt><dd>The nominal duration of m equal sub-intervals in I at th
e
<t>dt, the nominal duration of m equal sub-intervals in I at the Destination (default 1 sec).</dd>
destination (default 1 sec)</t> <dt>dtn:</dt><dd>The beginning boundary of a specific sub-interval, n, o
ne of
<t>dtn, the beginning boundary of a specific sub-interval, n, one of m sub-intervals in I.</dd>
m sub-intervals in I</t> <dt>FT:</dt><dd>The feedback time interval between status feedback messa
ges
<t>FT, the feedback time interval between status feedback messages communicating measurement results, sent from the Receiver to control
communicating measurement results, sent from the receiver to control the Sender. The results are evaluated throughout the test to
the sender. The results are evaluated throughout the test to determine how to adjust the current offered load rate at the Sender
determine how to adjust the current offered load rate at the sender (default 50 msec).</dd>
(default 50ms)</t> <dt>Tmax:</dt><dd>A maximum waiting time for test packets to arrive at t
he
<t>Tmax, a maximum waiting time for test packets to arrive at the Destination, set sufficiently long to disambiguate packets with long
destination, set sufficiently long to disambiguate packets with long
delays from packets that are discarded (lost), such that the delays from packets that are discarded (lost), such that the
distribution of one-way delay is not truncated.</t> distribution of one-way delay is not truncated.</dd>
<dt>F:</dt><dd>The number of different flows synthesized by the method
<t>F, the number of different flows synthesized by the method (default one flow).</dd>
(default 1 flow)</t> <dt>Flow:</dt><dd>The stream of packets with the same n-tuple of designa
ted
<t>flow, the stream of packets with the same n-tuple of designated
header fields that (when held constant) result in identical header fields that (when held constant) result in identical
treatment in a multi-path decision (such as the decision taken in treatment in a multipath decision (such as the decision taken in
load balancing). Note: The IPv6 flow label SHOULD be included in the load balancing). Note: The IPv6 flow label <bcp14>SHOULD</bcp14> be in
flow definition when routers have complied with <xref cluded in the
target="RFC6438"/> guidelines.</t> flow definition when routers have complied with the guidelines provide
d in <xref target="RFC6438" format="default"/>.</dd>
<t>Type-P, the complete description of the test packets for which <dt>Type-P:</dt><dd>The complete description of the test packets for whi
ch
this assessment applies (including the flow-defining fields). Note this assessment applies (including the flow-defining fields). Note
that the UDP transport layer is one requirement for test packets that the UDP transport layer is one requirement for test packets
specified below. Type-P is a parallel concept to "population of specified below. Type-P is a concept parallel to "population of
interest" defined in clause 6.1.1 of<xref target="Y.1540"/>.</t> interest" as defined in Clause 6.1.1 of <xref target="Y.1540" format="
default"/>.</dd>
<t>Payload Content, this IPPM Framework-conforming metric and method <dt>Payload Content:</dt><dd>An aspect of the Type-P Parameter that
includes packet payload content as an aspect of the Type-P can help to improve measurement determinism. Specifying packet payload content
parameter, which can help to improve measurement determinism. If helps to ensure IPPM Framework-conforming Metrics and Methods. If
there is payload compression in the path and tests intend to there is payload compression in the path and tests intend to
characterize a possible advantage due to compression, then payload characterize a possible advantage due to compression, then payload
content SHOULD be supplied by a pseudo-random sequence generator, by content <bcp14>SHOULD</bcp14> be supplied by a pseudorandom sequence g
using part of a compressed file, or by other means. See Section enerator, by
3.1.2 of <xref target="RFC7312"/>.</t> using part of a compressed file, or by other means. See
<xref target="RFC7312" sectionFormat="of" section="3.1.2"/>.</dd>
<t>PM, a list of fundamental metrics, such as loss, delay, and <dt>PM:</dt><dd>A list of fundamental metrics, such as loss, delay, and
reordering, and corresponding target performance threshold. At least reordering, and corresponding target performance threshold(s). At leas
one fundamental metric and target performance threshold MUST be t
supplied (such as One-way IP Packet Loss <xref target="RFC7680"/> one fundamental metric and target performance threshold <bcp14>MUST</b
equal to zero).</t> cp14> be
</list>A non-Parameter which is required for several metrics is supplied (such as one-way IP packet loss <xref target="RFC7680" format
="default"/>
equal to zero).</dd>
</dl>
<t>A non-Parameter that is required for several metrics is
defined below:</t> defined below:</t>
<dl spacing="normal">
<t><list style="symbols"> <dt>T:</dt><dd>The host time of the <strong>first</strong> test packet's
<t>T, the host time of the *first* test packet's *arrival* as <strong>arrival</strong> as
measured at the destination Measurement Point, or MP(Dst). There may measured at the Destination Measurement Point, or MP(Dst). There may
be other packets sent between Source and Destination hosts that are be other packets sent between Source and Destination hosts that are
excluded, so this is the time of arrival of the first packet used excluded, so this is the time of arrival of the first packet used
for measurement of the metric.</t> for measurement of the metric.</dd>
</list>Note that time stamp format and resolution, sequence numbers, </dl>
<t>Note that timestamp format and resolution, sequence numbers,
etc. will be established by the chosen test protocol standard or etc. will be established by the chosen test protocol standard or
implementation.</t> implementation.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="IP-Layer Capacity Singleton Metric Definitions"> <name>IP-Layer Capacity Singleton Metric Definitions</name>
<t>This section sets requirements for the singleton metric that supports <t>This section sets requirements for the Singleton metric that supports
the Maximum IP-Layer Capacity Metric definition in Section 6.</t> the Maximum IP-Layer Capacity Metric definitions in <xref target="max-ip-m
etric-defs"/>.</t>
<section title="Formal Name"> <section numbered="true" toc="default">
<t>Type-P-One-way-IP-Capacity, or informally called IP-Layer <name>Formal Name</name>
Capacity.</t> <t>"Type-P-One-way-IP-Capacity" is the formal name; it is informally cal
led "IP-Layer Capacity".</t>
<t>Note that Type-P depends on the chosen method.</t> <t>Note that Type-P depends on the chosen method.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Parameters"> <name>Parameters</name>
<t>This section lists the REQUIRED input factors to specify the <t>This section lists the <bcp14>REQUIRED</bcp14> input factors to speci
metric, beyond those listed in Section 4.</t> fy the
metric, beyond those listed in <xref target="gen-params-defs"/>.</t>
<t>No additional Parameters are needed.</t> <t>No additional Parameters are needed.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Metric Definitions"> <name>Metric Definitions</name>
<t>This section defines the REQUIRED aspects of the measurable <t>This section defines the <bcp14>REQUIRED</bcp14> aspects of the measu
IP-Layer Capacity metric (unless otherwise indicated) for measurements rable
IP-Layer Capacity Metric (unless otherwise indicated) for measurements
between specified Source and Destination hosts:</t> between specified Source and Destination hosts:</t>
<t>Define the IP-Layer Capacity, C(T,dt,PM), to be the number of <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 IP-Layer bits (including header and data fields) in packets that can
be transmitted from the Src host and correctly received by the Dst be transmitted from the Src host and correctly received by the Dst
host during one contiguous sub-interval, dt in length. The IP-Layer 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 Capacity depends on the Src and Dst hosts, the host addresses, and the
path between the hosts.</t> path between the hosts.</t>
<t>The number of these IP-Layer bits is designated n0[dtn,dtn+1] for a <t>The number of these IP-Layer bits is designated n0[dtn,dtn+1] for a
specific dt.</t> specific dt.</t>
<t>When the packet size is known and of fixed size, the packet count <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 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> header and data fields is equal to n0[dtn,dtn+1].</t>
<t>Anticipating a Sample of Singletons, the number of sub-intervals <t>Anticipating a Sample of Singletons, the number of sub-intervals
with duration dt MUST be set to a natural number m, so that T+I = T + with duration dt <bcp14>MUST</bcp14> be set to a natural number m, so th at T+I = T +
m*dt with dtn+1 - dtn = dt for 1 &lt;= n &lt;= m.</t> m*dt with dtn+1 - dtn = dt for 1 &lt;= n &lt;= m.</t>
<t>Parameter PM represents other performance metrics (see <xref target="
<t>Parameter PM represents other performance metrics [see section 5.4 sec5-4-rt-delay"/>
below]; their measurement results SHALL be collected during below); their measurement results <bcp14>SHALL</bcp14> be collected duri
ng
measurement of IP-Layer Capacity and associated with the corresponding measurement of IP-Layer Capacity and associated with the corresponding
dtn for further evaluation and reporting. Users SHALL specify the dtn for further evaluation and reporting. Users <bcp14>SHALL</bcp14> spe
parameter Tmax as required by each metric's reference definition.</t> cify the
Parameter Tmax as required by each metric's reference definition.</t>
<t>Mathematically, this definition is represented as (for each n):</t> <t>Mathematically, this definition is represented as (for each n):</t>
<figure>
<t><figure title="Equation for IP-Layer Capacity"> <name>Equation for IP-Layer Capacity</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="ascii-art" alt=""><![CDATA[
( n0[dtn,dtn+1] ) ( n0[dtn,dtn+1] )
C(T,dt,PM) = ------------------------- C(T,dt,PM) = -------------------------
dt dt
]]></artwork> ]]></artwork>
</figure>and:<list style="symbols"> </figure>
<t>n0 is the total number of IP-Layer header and payload bits that <t>and:</t>
can be transmitted in standard-formed packets <xref <ul spacing="normal">
target="RFC8468"/> from the Src host and correctly received by the <li>n0 is the total number of IP-Layer header and payload bits that
can be transmitted in standard-formed packets <xref target="RFC8468"
format="default"/> from the Src host and correctly received by the
Dst host during one contiguous sub-interval, dt in length, during Dst host during one contiguous sub-interval, dt in length, during
the interval [T, T+I],</t> the interval [T,T+I].</li>
<li>C(T,dt,PM), the IP-Layer Capacity, corresponds to the value of
<t>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 n0 measured in any sub-interval beginning at dtn, divided by the
length of sub-interval, dt.</t> length of the sub-interval, dt.</li>
<li>PM represents other performance metrics (see <xref target="sec5-4-
<t>PM represents other performance metrics [see section 5.4 rt-delay"/>
below]; their measurement results SHALL be collected during below); their measurement results <bcp14>SHALL</bcp14> be collected
during
measurement of IP-Layer Capacity and associated with the measurement of IP-Layer Capacity and associated with the
corresponding dtn for further evaluation and reporting.</t> corresponding dtn for further evaluation and reporting.</li>
<li>All sub-intervals <bcp14>MUST</bcp14> be of equal duration. Choosi
<t>all sub-intervals MUST be of equal duration. Choosing dt as ng dt as
non-overlapping consecutive time intervals allows for a simple non-overlapping consecutive time intervals allows for a simple
implementation.</t> implementation.</li>
<li>The bit rate of the physical interface of the measurement
<t>The bit rate of the physical interface of the measurement devices <bcp14>MUST</bcp14> be higher than the smallest of the links
devices MUST be higher than the smallest of the links on the path on the path
whose C(T,I,PM) is to be measured (the bottleneck link).</t> whose C(T,I,PM) is to be measured (the bottleneck link).</li>
</list></t> </ul>
<t>Measurements according to this definition <bcp14>SHALL</bcp14> use th
<t>Measurements according to these definitions SHALL use the UDP e UDP
transport layer. Standard-formed packets are specified in Section 5 of transport layer. Standard-formed packets are specified in <xref target="
<xref target="RFC8468"/>. The measurement SHOULD use a randomized RFC8468" sectionFormat="of" section="5"/>. The measurement <bcp14>SHOULD</bcp14>
Source port or equivalent technique, and SHOULD send responses from use a randomized
the Source address matching the test packet destination address.</t> Source port or equivalent technique, and <bcp14>SHOULD</bcp14> send resp
onses from
<t>Some compression affects on measurement are discussed in Section 6 the Source address matching the test packet Destination address.</t>
of <xref target="RFC8468"/>.</t> <t>Some effects of compression on measurement are discussed in
<xref target="RFC8468" sectionFormat="of" section="6"/>.</t>
</section> </section>
<section anchor="sec5-4-rt-delay" numbered="true" toc="default">
<section title="Related Round-Trip Delay and One-way Loss Definitions"> <name>Related Round-Trip Delay and One-Way Loss Definitions</name>
<t>RTD[dtn,dtn+1] is defined as a Sample of the <xref <t>RTD[dtn,dtn+1] is defined as a Sample of the Round-Trip Delay <xref t
target="RFC2681"/> Round-trip Delay between the Src host and the Dst arget="RFC2681" format="default"/> between the Src host and the Dst
host over the interval [T,T+I] (that contains equal non-overlapping host during the interval [T,T+I] (that contains equal non-overlapping
intervals of dt). The "reasonable period of time" in <xref intervals of dt). The "reasonable period of time" mentioned in <xref tar
target="RFC2681"/> is the parameter Tmax in this memo. The statistics get="RFC2681" format="default"/> is the Parameter Tmax in this memo. The statist
used to summarize RTD[dtn,dtn+1] MAY include the minimum, maximum, ics
median, and mean, and the range = (maximum - minimum) is referred to used to summarize RTD[dtn,dtn+1] <bcp14>MAY</bcp14> include the minimum,
below in Section 8.1 for load adjustment purposes.</t> maximum,
median, mean, and the range = (maximum - minimum). Some of these statist
<t>OWL[dtn,dtn+1] is defined as a Sample of the <xref ics are needed for load adjustment purposes (<xref target="load-rate-adj"/>), me
target="RFC7680"/> One-way Loss between the Src host and the Dst host asurement qualification (<xref target="meas-qual-verif"/>), and reporting (<xref
over the interval [T,T+I] (that contains equal non-overlapping target="rpt-formats"/>).
intervals of dt). The statistics used to summarize OWL[dtn,dtn+1] MAY </t>
include the lost packet count and the lost packet ratio.</t> <t>OWL[dtn,dtn+1] is defined as a Sample of the One-Way Loss <xref targe
t="RFC7680" format="default"/> between the Src host and the Dst host
<t>Other metrics MAY be measured: one-way reordering, duplication, and during the interval [T,T+I] (that contains equal non-overlapping
intervals of dt). The statistics used to summarize OWL[dtn,dtn+1] <bcp14
>MAY</bcp14>
include the count of lost packets and the ratio of lost packets.</t>
<t>Other metrics <bcp14>MAY</bcp14> be measured: one-way reordering, dup
lication, and
delay variation.</t> delay variation.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Discussion"> <name>Discussion</name>
<t>See the corresponding section for Maximum IP-Layer Capacity.</t> <t>See the corresponding section for Maximum IP-Layer Capacity (<xref ta
rget="Maximum-IP-Layer-Capacity-Discussion" format="default"/>).
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Reporting the Metric"> <name>Reporting the Metric</name>
<t>The IP-Layer Capacity SHOULD be reported with at least single <t>The IP-Layer Capacity <bcp14>SHOULD</bcp14> be reported with at least
Megabit resolution, in units of Megabits per second (Mbps), (which is single-Megabit resolution, in units of Megabits per second (Mbps) (which
1,000,000 bits per second to avoid any confusion).</t> ,
to avoid any confusion, is 1,000,000 bits per second).</t>
<t>The related One-way Loss metric and Round Trip Delay measurements <t>The related One-Way Loss metric and Round-Trip Delay measurements
for the same Singleton SHALL be reported, also with meaningful for the same Singleton <bcp14>SHALL</bcp14> be reported, also with meani
ngful
resolution for the values measured.</t> resolution for the values measured.</t>
<t>Individual Capacity measurements <bcp14>MAY</bcp14> be reported in a
<t>Individual Capacity measurements MAY be reported in a manner manner
consistent with the Maximum IP-Layer Capacity, see Section 9.</t> consistent with the Maximum IP-Layer Capacity; see <xref target="rpt-for
mats"/>.</t>
</section> </section>
</section> </section>
<section anchor="max-ip-metric-defs" numbered="true" toc="default">
<section title="Maximum IP-Layer Capacity Metric Definitions (Statistic)"> <name>Maximum IP-Layer Capacity Metric Definitions (Statistics)</name>
<t>This section sets requirements for the following components to <t>This section sets requirements for the following components to
support the Maximum IP-Layer Capacity Metric.</t> support the Maximum IP-Layer Capacity Metric.</t>
<section numbered="true" toc="default">
<section title="Formal Name"> <name>Formal Name</name>
<t>Type-P-One-way-Max-IP-Capacity, or informally called Maximum <t>"Type-P-One-way-Max-IP-Capacity" is the formal name; it is informally
IP-Layer Capacity.</t> called "Maximum IP-Layer Capacity".</t>
<t>Note that Type-P depends on the chosen method.</t> <t>Note that Type-P depends on the chosen method.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Parameters"> <name>Parameters</name>
<t>This section lists the REQUIRED input factors to specify the <t>This section lists the <bcp14>REQUIRED</bcp14> input factors to speci
metric, beyond those listed in Section 4.</t> fy the
metric, beyond those listed in <xref target="gen-params-defs"/>.</t>
<t>No additional Parameters or definitions are needed.</t> <t>No additional Parameters or definitions are needed.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Metric Definitions"> <name>Metric Definitions</name>
<t>This section defines the REQUIRED aspects of the Maximum IP-Layer <t>This section defines the <bcp14>REQUIRED</bcp14> aspects of the Maxim
Capacity metric (unless otherwise indicated) for measurements between um IP-Layer
Capacity Metric (unless otherwise indicated) for measurements between
specified Source and Destination hosts:</t> specified Source and Destination hosts:</t>
<t>Define the Maximum IP-Layer Capacity, Maximum_C(T,I,PM), to be the <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 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 be transmitted in packets from the Src host and correctly received by
the Dst host, over all dt length intervals in [T, T+I], and meeting the Dst host, over all dt-length intervals in [T,T+I] and meeting
the PM criteria. Equivalently the Maximum of a Sample of size m of the PM criteria. An equivalent definition would be the maximum of a Samp
C(T,I,PM) collected during the interval [T, T+I] and meeting the PM le of size m of Singletons
C(T,I,PM) collected during the interval [T,T+I] and meeting the PM
criteria.</t> criteria.</t>
<t>The number of sub-intervals with duration dt <bcp14>MUST</bcp14> be s
<t>The number of sub-intervals with duration dt MUST be set to a et to a
natural number m, so that T+I = T + m*dt with dtn+1 - dtn = dt for 1 natural number m, so that T+I = T + m*dt with dtn+1 - dtn = dt for 1
&lt;= n &lt;= m.</t> &lt;= n &lt;= m.</t>
<t>Parameter PM represents the other performance metrics (see
<t>Parameter PM represents the other performance metrics (see Section <xref target="sec6-4-rt-delay"/> below) and their measurement results fo
6.4 below) and their measurement results for the Maximum IP-Layer r the Maximum IP-Layer
Capacity. At least one target performance threshold (PM criterion) Capacity. At least one target performance threshold (PM criterion)
MUST be defined. If more than one metric and target performance <bcp14>MUST</bcp14> be defined. If more than one metric and target perfo
threshold are defined, then the sub-interval with maximum number of rmance
bits transmitted MUST meet all the target performance thresholds. threshold is defined, then the sub-interval with the maximum number of
Users SHALL specify the parameter Tmax as required by each metric's bits transmitted <bcp14>MUST</bcp14> meet all the target performance thr
esholds.
Users <bcp14>SHALL</bcp14> specify the Parameter Tmax as required by eac
h metric's
reference definition.</t> reference definition.</t>
<t>Mathematically, this definition can be represented as:</t> <t>Mathematically, this definition can be represented as:</t>
<figure>
<t><figure title="Equation for Maximum Capacity"> <name>Equation for Maximum Capacity</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="ascii-art" alt=""><![CDATA[
max ( n0[dtn,dtn+1] ) max ( n0[dtn,dtn+1] )
[T,T+I] [T,T+I]
Maximum_C(T,I,PM) = ------------------------- Maximum_C(T,I,PM) = -------------------------
dt dt
where:
where:
T T+I T T+I
_________________________________________ _________________________________________
| | | | | | | | | | | | | | | | | | | | | |
dtn=1 2 3 4 5 6 7 8 9 10 n+1 dtn=1 2 3 4 5 6 7 8 9 10 n+1
n=m n=m
]]></artwork> ]]></artwork>
</figure>and:<list style="symbols"> </figure>
<t>n0 is the total number of IP-Layer header and payload bits that <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 can be transmitted in standard-formed packets from the Src host
and correctly received by the Dst host during one contiguous and correctly received by the Dst host during one contiguous
sub-interval, dt in length, during the interval [T, T+I],</t> sub-interval, dt in length, during the interval [T,T+I].</li>
<li>Maximum_C(T,I,PM), the Maximum IP-Layer Capacity, corresponds to
<t>Maximum_C(T,I,PM) the Maximum IP-Layer Capacity, corresponds to
the maximum value of n0 measured in any sub-interval beginning at the maximum value of n0 measured in any sub-interval beginning at
dtn, divided by the constant length of all sub-intervals, dt.</t> dtn, divided by the constant length of all sub-intervals, dt.</li>
<li>PM represents the other performance metrics (see <xref target="sec
<t>PM represents the other performance metrics (see Section 5.4) 6-4-rt-delay"/>)
and their measurement results for the Maximum IP-Layer Capacity. and their measurement results for the Maximum IP-Layer Capacity.
At least one target performance threshold (PM criterion) MUST be At least one target performance threshold (PM criterion) <bcp14>MUST
defined.</t> </bcp14> be
defined.</li>
<t>all sub-intervals MUST be of equal duration. Choosing dt as <li>All sub-intervals <bcp14>MUST</bcp14> be of equal duration. Choosi
ng dt as
non-overlapping consecutive time intervals allows for a simple non-overlapping consecutive time intervals allows for a simple
implementation.</t> implementation.</li>
<li>The bit rate of the physical interface of the measurement
<t>The bit rate of the physical interface of the measurement systems <bcp14>MUST</bcp14> be higher than the smallest of the links
systems MUST be higher than the smallest of the links on the path on the path
whose Maximum_C(T,I,PM) is to be measured (the bottleneck whose Maximum_C(T,I,PM) is to be measured (the bottleneck
link).</t> link).</li>
</list></t> </ul>
<t>In this definition, the m sub-intervals can be viewed as trials <t>In this definition, the m sub-intervals can be viewed as trials
when the Src host varies the transmitted packet rate, searching for 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 the maximum n0 that meets the PM criteria measured at the Dst host in
a test of duration, I. When the transmitted packet rate is held a test of duration I. When the transmitted packet rate is held
constant at the Src host, the m sub-intervals may also be viewed as 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 trials to evaluate the stability of n0 and metric(s) in the PM list
over all dt-length intervals in I.</t> over all dt-length intervals in I.</t>
<t>Measurements according to these definitions <bcp14>SHALL</bcp14> use
<t>Measurements according to these definitions SHALL use the UDP the UDP
transport layer.</t> transport layer.</t>
</section> </section>
<section anchor="sec6-4-rt-delay" numbered="true" toc="default">
<section title="Related Round-Trip Delay and One-way Loss Definitions"> <name>Related Round-Trip Delay and One-Way Loss Definitions</name>
<t>RTD[dtn,dtn+1] and OWL[dtn,dtn+1] are defined in Section 5.4. Here, <t>RTD[dtn,dtn+1] and OWL[dtn,dtn+1] are defined in <xref target="sec5-4
-rt-delay"/>. Here,
the test intervals are increased to match the capacity Samples, the test intervals are increased to match the capacity Samples,
RTD[T,I] and OWL[T,I].</t> RTD[T,I] and OWL[T,I].</t>
<t>The interval dtn,dtn+1 where Maximum_C(T,I,PM) occurs is the
<t>The interval dtn,dtn+1 where Maximum_C[T,I,PM] occurs is the reporting sub-interval for RTD[dtn,dtn+1] and OWL[dtn,dtn+1] within RTD[
reporting sub-interval within RTD[T,I] and OWL[T,I].</t> T,I] and OWL[T,I].</t>
<t>Other metrics <bcp14>MAY</bcp14> be measured: one-way reordering, dup
<t>Other metrics MAY be measured: one-way reordering, duplication, and lication, and
delay variation.</t> delay variation.</t>
</section> </section>
<section numbered="true" toc="default" anchor="Maximum-IP-Layer-Capacity-D
<section title="Discussion"> iscussion">
<name>Discussion</name>
<t>If traffic conditioning (e.g., shaping, policing) applies along a <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 path for which Maximum_C(T,I,PM) is to be determined, different values
for dt SHOULD be picked and measurements be executed during multiple for dt <bcp14>SHOULD</bcp14> be picked and measurements executed during
intervals [T, T+I]. Each duration dt SHOULD be chosen so that it is an multiple
intervals [T,T+I]. Each duration dt <bcp14>SHOULD</bcp14> be chosen so t
hat it is an
integer multiple of increasing values k times serialization delay of a integer multiple of increasing values k times serialization delay of a
path MTU at the physical interface speed where traffic conditioning is Path MTU (PMTU) at the physical interface speed where traffic conditioni ng is
expected. This should avoid taking configured burst tolerance expected. This should avoid taking configured burst tolerance
singletons as a valid Maximum_C(T,I,PM) result.</t> Singletons as a valid Maximum_C(T,I,PM) result.</t>
<t>A Maximum_C(T,I,PM) without any indication of bottleneck <t>A Maximum_C(T,I,PM) without any indication of bottleneck
congestion, be that an increasing latency, packet loss or ECN marks congestion, be that increased latency, packet loss, or Explicit Congesti
during a measurement interval I, is likely to underestimate on
Maximum_C(T,I,PM).</t> Notification (ECN) marks during a measurement interval, I, is likely an
underestimate of Maximum_C(T,I,PM).</t>
</section> </section>
<section anchor="sec6-6-rpt-the-metric" numbered="true" toc="default">
<section title="Reporting the Metric"> <name>Reporting the Metric</name>
<t>The IP-Layer Capacity SHOULD be reported with at least single <t>The IP-Layer Capacity <bcp14>SHOULD</bcp14> be reported with at least
Megabit resolution, in units of Megabits per second (Mbps) (which is single-Megabit resolution, in units of Megabits per second (Mbps) (which
1,000,000 bits per second to avoid any confusion).</t> ,
to avoid any confusion, is 1,000,000 bits per second).</t>
<t>The related One-way Loss metric and Round Trip Delay measurements <t>The related One-Way Loss metric and Round-Trip Delay measurements
for the same Singleton SHALL be reported, also with meaningful for the same Singleton <bcp14>SHALL</bcp14> be reported, also with meani
ngful
resolution for the values measured.</t> resolution for the values measured.</t>
<t>When there are demonstrated and repeatable Capacity modes in the <t>When there are demonstrated and repeatable Capacity modes in the
Sample, then the Maximum IP-Layer Capacity SHALL be reported for each Sample, the Maximum IP-Layer Capacity <bcp14>SHALL</bcp14> be reported f or each
mode, along with the relative time from the beginning of the stream mode, along with the relative time from the beginning of the stream
that the mode was observed to be present. Bimodal Maximum IP-Layer that the mode was observed to be present. Bimodal Maximum IP-Layer
Capacities have been observed with some services, sometimes called a Capacities have been observed with some services, sometimes called a
"turbo mode" intending to deliver short transfers more quickly, or "turbo mode" intending to deliver short transfers more quickly or
reduce the initial buffering time for some video streams. Note that reduce the initial buffering time for some video streams. Note that
modes lasting less than dt duration will not be detected.</t> modes lasting less than duration dt will not be detected.</t>
<t>Some transmission technologies have multiple methods of operation <t>Some transmission technologies have multiple methods of operation
that may be activated when channel conditions degrade or improve, and that may be activated when channel conditions degrade or improve, and
these transmission methods may determine the Maximum IP-Layer these transmission methods may determine the Maximum IP-Layer
Capacity. Examples include line-of-sight microwave modulator Capacity. Examples include line-of-sight microwave modulator
constellations, or cellular modem technologies where the changes may constellations, or cellular modem technologies where the changes may
be initiated by a user moving from one coverage area to another. be initiated by a user moving from one coverage area to another.
Operation in the different transmission methods may be observed over Operation in the different transmission methods may be observed over
time, but the modes of Maximum IP-Layer Capacity will not be activated time, but the modes of Maximum IP-Layer Capacity will not be activated
deterministically as with the "turbo mode" described in the paragraph deterministically as with the "turbo mode" described in the paragraph
above.</t> above.</t>
</section> </section>
</section> </section>
<section anchor="ip-layer-sender-br" numbered="true" toc="default">
<section title="IP-Layer Sender Bit Rate Singleton Metric Definitions"> <name>IP-Layer Sender Bit Rate Singleton Metric Definitions</name>
<t>This section sets requirements for the following components to <t>This section sets requirements for the following components to
support the IP-Layer Sender Bitrate Metric. This metric helps to check support the IP-Layer Sender Bit Rate Metric. This metric helps to check
that the sender actually generated the desired rates during a test, and that the Sender actually generated the desired rates during a test, and
measurement takes place at the Src host to network path interface (or as measurement takes place at the interface between the Src host and the netw
ork path (or as
close as practical within the Src host). It is not a metric for path close as practical within the Src host). It is not a metric for path
performance.</t> performance.</t>
<section numbered="true" toc="default">
<section title="Formal Name"> <name>Formal Name</name>
<t>Type-P-IP-Sender-Bit-Rate, or informally called IP-Layer Sender <t>"Type-P-IP-Sender-Bit-Rate" is the formal name; it is informally call
Bitrate.</t> ed the "IP-Layer Sender Bit Rate".</t>
<t>Note that Type-P depends on the chosen method.</t> <t>Note that Type-P depends on the chosen method.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Parameters"> <name>Parameters</name>
<t>This section lists the REQUIRED input factors to specify the <t>This section lists the <bcp14>REQUIRED</bcp14> input factors to speci
metric, beyond those listed in Section 4.</t> fy the
metric, beyond those listed in <xref target="gen-params-defs"/>.</t>
<t><list style="symbols"> <dl spacing="normal">
<t>S, the duration of the measurement interval at the Source</t> <dt>S:</dt><dd>The duration of the measurement interval at the Source.
</dd>
<t>st, the nominal duration of N sub-intervals in S (default st = <dt>st:</dt><dd>The nominal duration of N sub-intervals in S (default
0.05 seconds)</t> st =
0.05 seconds).</dd>
<t>stn, the beginning boundary of a specific sub-interval, n, one <dt>stn:</dt><dd>The beginning boundary of a specific sub-interval, n,
of N sub-intervals in S</t> one
</list></t> of N sub-intervals in S.</dd>
</dl>
<t>S SHALL be longer than I, primarily to account for on-demand <t>S <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 activation of the path, or any preamble to testing required, and the
delay of the path.</t> delay of the path.</t>
<t>st <bcp14>SHOULD</bcp14> be much smaller than the sub-interval dt and
<t>st SHOULD be much smaller than the sub-interval dt and on the same on the same
order as FT, otherwise the rate measurement will include many rate order as FT; otherwise, the rate measurement will include many rate
adjustments and include more time smoothing, thus missing the Maximum adjustments and include more time smoothing, possibly smoothing the inte
IP-Layer Capacity. The st parameter does not have relevance when the rval that contains the Maximum
IP-Layer Capacity (and therefore losing relevance). The st Parameter doe
s not have relevance when the
Source is transmitting at a fixed rate throughout S.</t> Source is transmitting at a fixed rate throughout S.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Metric Definition"> <name>Metric Definition</name>
<t>This section defines the REQUIRED aspects of the IP-Layer Sender <t>This section defines the <bcp14>REQUIRED</bcp14> aspects of the IP-La
Bitrate metric (unless otherwise indicated) for measurements at the yer Sender
Bit Rate Metric (unless otherwise indicated) for measurements at the
specified Source on packets addressed for the intended Destination specified Source on packets addressed for the intended Destination
host and matching the required Type-P:</t> host and matching the required Type-P:</t>
<t>Define the IP-Layer Sender Bit Rate, B(S,st), to be the number of <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 IP-Layer bits (including header and data fields) that are transmitted
from the Source with address pair Src and Dst during one contiguous from the Source with address pair Src and Dst during one contiguous
sub-interval, st, during the test interval S (where S SHALL be longer sub-interval, st, during the test interval S (where S <bcp14>SHALL</bcp1
than I), and where the fixed-size packet count during that single 4> be longer
than I) and where the fixed-size packet count during that single
sub-interval st also provides the number of IP-Layer bits in any sub-interval st also provides the number of IP-Layer bits in any
interval, [stn,stn+1].</t> interval, [stn,stn+1].</t>
<t>Measurements according to this definition <bcp14>SHALL</bcp14> use th
<t>Measurements according to these definitions SHALL use the UDP e UDP
transport layer. Any feedback from Dst host to Src host received by transport layer. Any feedback from the Dst host to the Src host received
Src host during an interval [stn,stn+1] SHOULD NOT result in an by the
Src host during an interval [stn,stn+1] <bcp14>SHOULD NOT</bcp14> result
in an
adaptation of the Src host traffic conditioning during this interval adaptation of the Src host traffic conditioning during this interval
(rate adjustment occurs on st interval boundaries).</t> (rate adjustment occurs on st interval boundaries).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Discussion"> <name>Discussion</name>
<t>Both the Sender and Receiver or (Source and Destination) bit rates <t>Both the Sender and Receiver (or Source and Destination) bit rates <b
SHOULD be assessed as part of an IP-Layer Capacity measurement. cp14>SHOULD</bcp14> be assessed as part of an IP-Layer Capacity measurement.
Otherwise, an unexpected sending rate limitation could produce an Otherwise, an unexpected sending rate limitation could produce an
erroneous Maximum IP-Layer Capacity measurement.</t> erroneous Maximum IP-Layer Capacity measurement.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Reporting the Metric"> <name>Reporting the Metric</name>
<t>The IP-Layer Sender Bit Rate SHALL be reported with meaningful <t>The IP-Layer Sender Bit Rate <bcp14>SHALL</bcp14> be reported with me
resolution, in units of Megabits per second (which is 1,000,000 bits aningful
per second to avoid any confusion).</t> resolution, in units of Megabits per second (which, to avoid any confusi
on,
is 1,000,000 bits per second).</t>
<t>Individual IP-Layer Sender Bit Rate measurements are discussed <t>Individual IP-Layer Sender Bit Rate measurements are discussed
further in Section 9.</t> further in <xref target="rpt-formats"/>.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Method of Measurement"> <name>Method of Measurement</name>
<t>The architecture of the method REQUIRES two cooperating hosts <t>It is <bcp14>REQUIRED</bcp14> per the architecture of the method that t
operating in the roles of Src (test packet sender) and Dst (receiver), wo cooperating hosts operate in the roles of Src (test packet Sender) and Dst (R
eceiver)
with a measured path and return path between them.</t> with a measured path and return path between them.</t>
<t>The duration of a test, Parameter I, <bcp14>MUST</bcp14> be constrained
<t>The duration of a test, parameter I, MUST be constrained in a in a
production network, since this is an active test method and it will production network, since this is an active test method and it will
likely cause congestion on the Src to Dst host path during a test.</t> likely cause congestion on the path from the Src host to the Dst host duri
ng a test.</t>
<section title="Load Rate Adjustment Algorithm"> <section anchor="load-rate-adj" numbered="true" toc="default">
<t>The algorithm described in this section MUST NOT be used as a <name>Load Rate Adjustment Algorithm</name>
general Congestion Control Algorithm (CCA). As stated in the Scope <t>The algorithm described in this section <bcp14>MUST NOT</bcp14> be us
Section 2, the load rate adjustment algorithm's goal is to help ed as a
general Congestion Control Algorithm (CCA). As stated in
<xref target="sec-2-scope"/> ("Scope, Goals, and Applicability"), the lo
ad rate adjustment algorithm's goal is to help
determine the Maximum IP-Layer Capacity in the context of an determine the Maximum IP-Layer Capacity in the context of an
infrequent, diagnostic, short term measurement. There is a tradeoff infrequent, diagnostic, short-term measurement. There is a trade-off
between test duration (also the test data volume) and algorithm between test duration (also the test data volume) and algorithm
aggressiveness (speed of ramp-up and down to the Maximum IP-Layer aggressiveness (speed of ramp-up and ramp-down to the Maximum IP-Layer
Capacity). The parameter values chosen below strike a well-tested Capacity). The Parameter values chosen below strike a well-tested
balance among these factors.</t> balance among these factors.</t>
<t>A table <bcp14>SHALL</bcp14> be pre-built (by the test administrator)
<t>A table SHALL be pre-built (by the test initiator) defining all the , defining all the
offered load rates that will be supported (R1 through Rn, in ascending offered load rates that will be supported (R1 through Rn, in ascending
order, corresponding to indexed rows in the table). It is RECOMMENDED order, corresponding to indexed rows in the table). It is <bcp14>RECOMME NDED</bcp14>
that rates begin with 0.5 Mbps at index zero, use 1 Mbps at index one, 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 and then continue in 1 Mbps increments to 1 Gbps. Above 1 Gbps, and up
to 10 Gbps, it is RECOMMENDED that 100 Mbps increments be used. Above to 10 Gbps, it is <bcp14>RECOMMENDED</bcp14> that 100 Mbps increments be
10 Gbps, increments of 1 Gbps are RECOMMENDED. A higher initial used. Above
IP-Layer Sender Bitrate might be configured when the test operator is 10 Gbps, increments of 1 Gbps are <bcp14>RECOMMENDED</bcp14>. A higher i
certain that the Maximum IP-Layer Capacity is well-above the initial nitial
IP-Layer Sender Bitrate and factors such as test duration and total IP-Layer Sender Bit Rate might be configured when the test operator is
test traffic play an important role. The sending rate table SHOULD certain that the Maximum IP-Layer Capacity is well above the initial
backet the maximum capacity where it will make measurements, including IP-Layer Sender Bit Rate and factors such as test duration and total
constrained rates less than 500kbps if applicable.</t> test traffic play an important role. The sending rate table <bcp14>SHOUL
D</bcp14>
bracket the Maximum Capacity where it will make measurements, including
constrained rates less than 500 kbps if applicable.</t>
<t>Each rate is defined as datagrams of size ss, sent as a burst of <t>Each rate is defined as datagrams of size ss, sent as a burst of
count cc, each time interval tt (default for tt is 1ms, a likely count cc, each time interval tt (the default for tt is 100 microsec, a l
system tick-interval). While it is advantageous to use datagrams of as ikely
system 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 large a size as possible, it may be prudent to use a slightly smaller
maximum that allows for secondary protocol headers and/or tunneling maximum that allows for secondary protocol headers and/or tunneling
without resulting in IP-Layer fragmentation. Selection of a new rate without resulting in IP-Layer fragmentation. Selection of a new rate
is indicated by a calculation on the current row, Rx. For example:</t> is indicated by a calculation on the current row, Rx. For example:</t>
<dl newline="false" spacing="normal">
<t>"Rx+1": the sender uses the next higher rate in the table.</t> <dt>"Rx+1":</dt><dd>The Sender uses the next-higher rate in the table.</
dd>
<t>"Rx-10": the sender uses the rate 10 rows lower in the table.</t> <dt>"Rx-10":</dt><dd>The Sender uses the rate 10 rows lower in the table
.</dd>
<t>At the beginning of a test, the sender begins sending at rate R1 </dl>
and the receiver starts a feedback timer of duration FT (while <t>At the beginning of a test, the Sender begins sending at rate R1
awaiting inbound datagrams). As datagrams are received they are and the Receiver starts a feedback timer of duration FT (while
awaiting inbound datagrams). As datagrams are received, they are
checked for sequence number anomalies (loss, out-of-order, checked for sequence number anomalies (loss, out-of-order,
duplication, etc.) and the delay range is measured (one-way or duplication, etc.) and the delay range is measured (one-way or
round-trip). This information is accumulated until the feedback timer round-trip). This information is accumulated until the feedback timer
FT expires and a status feedback message is sent from the receiver FT expires and a status feedback message is sent from the Receiver
back to the sender, to communicate this information. The accumulated back to the Sender, to communicate this information. The accumulated
statistics are then reset by the receiver for the next feedback statistics are then reset by the Receiver for the next feedback
interval. As feedback messages are received back at the sender, they interval. As feedback messages are received back at the Sender, they
are evaluated to determine how to adjust the current offered load rate are evaluated to determine how to adjust the current offered load rate
(Rx).</t> (Rx).</t>
<t>If the feedback indicates that no sequence number anomalies were <t>If the feedback indicates that no sequence number anomalies were
detected AND the delay range was below the lower threshold, the detected AND the delay range was below the lower threshold, the
offered load rate is increased. If congestion has not been confirmed offered load rate is increased. If congestion has not been confirmed
up to this point (see below for the method to declare congestion), the up to this point (see below for the method for declaring congestion), th
offered load rate is increased by more than one rate (e.g., Rx+10). e
offered load rate is increased by more than one rate setting (e.g., Rx+1
0).
This allows the offered load to quickly reach a near-maximum rate. This allows the offered load to quickly reach a near-maximum rate.
Conversely, if congestion has been previously confirmed, the offered Conversely, if congestion has been previously confirmed, the offered
load rate is only increased by one (Rx+1). However, if a rate load rate is only increased by one (Rx+1). However, if a rate
threshold between high and very high sending rates (such as 1 Gbps) is threshold above a high sending rate (such as 1 Gbps) is
exceeded, the offered load rate is only increased by one (Rx+1) above exceeded, the offered load rate is only increased by one (Rx+1)
the rate threshold in any congestion state.</t> in any congestion state.</t>
<t>If the feedback indicates that sequence number anomalies were <t>If the feedback indicates that sequence number anomalies were
detected OR the delay range was above the upper threshold, the offered detected OR the delay range was above the upper threshold, the offered
load rate is decreased. The RECOMMENDED threshold values are 0 for load rate is decreased. The <bcp14>RECOMMENDED</bcp14> threshold values
sequence number gaps and 30 ms for lower and 90 ms for upper delay are 10 for
sequence number gaps and 30 msec for lower and 90 msec for upper delay
thresholds, respectively. Also, if congestion is now confirmed for the thresholds, respectively. Also, if congestion is now confirmed for the
first time by the current feedback message being processed, then the first time by the current feedback message being processed, then the
offered load rate is decreased by more than one rate (e.g., Rx-30). offered load rate is decreased by more than one rate setting (e.g., Rx-3 0).
This one-time reduction is intended to compensate for the fast initial 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 ramp-up. In all other cases, the offered load rate is only decreased
by one (Rx-1).</t> by one (Rx-1).</t>
<t>If the feedback indicates that there were no sequence number <t>If the feedback indicates that there were no sequence number
anomalies AND the delay range was above the lower threshold, but below anomalies AND the delay range was above the lower threshold but below
the upper threshold, the offered load rate is not changed. This allows the upper threshold, the offered load rate is not changed. This allows
time for recent changes in the offered load rate to stabilize, and the time for recent changes in the offered load rate to stabilize and for th e
feedback to represent current conditions more accurately.</t> feedback to represent current conditions more accurately.</t>
<t>Lastly, the method for inferring congestion is that there were <t>Lastly, the method for inferring congestion is that there were
sequence number anomalies AND/OR the delay range was above the upper sequence number anomalies AND/OR the delay range was above the upper
threshold for two consecutive feedback intervals. The algorithm threshold for three consecutive feedback intervals. The algorithm
described above is also illustrated in ITU-T Rec. Y.1540, 2020 described above is also illustrated in Annex B of ITU-T Recommendation Y
version<xref target="Y.1540"/>, in Annex B, and implemented in the .1540, 2020
Appendix on Load Rate Adjustment Pseudo Code in this memo.</t> version <xref target="Y.1540" format="default"/> and is implemented in <
xref target="app-a-load-rate-adj-pseudocode"/> ("Load Rate Adjustment Pseudocode
<t>The load rate adjustment algorithm MUST include timers that stop ")
in this memo.</t>
<t>The load rate adjustment algorithm <bcp14>MUST</bcp14> include timers
that stop
the test when received packet streams cease unexpectedly. The timeout the test when received packet streams cease unexpectedly. The timeout
thresholds are provided in the table below, along with values for all thresholds are provided in <xref target="load-rate-adj-params"/>, along
other parameters and variables described in this section. Operation of with values for all
non-obvious parameters appear below:<list style="hanging"> other Parameters and variables described in this section. Operations of
<t hangText="load packet timeout">Operation: The load packet non-obvious Parameters appear below:</t>
timeout SHALL be reset to the configured value each time a load <dl newline="true" spacing="normal">
packet received. If the timeout expires, the receiver SHALL be <dt>load packet timeout:</dt>
closed and no further feedback sent.</t> <dd>The load packet
timeout <bcp14>SHALL</bcp14> be reset to the configured value each t
<t hangText="feedback message timeout">Operation: The feedback ime a load
message timeout SHALL be reset to the configured value each time a packet is received. If the timeout expires, the Receiver <bcp14>SHAL
feedback message is received. If the timeout expires, the sender L</bcp14> be
SHALL be closed and no further load packets sent.</t> closed and no further feedback sent.</dd>
</list></t> <dt>feedback message timeout:</dt>
<dd>The feedback
<t/> message timeout <bcp14>SHALL</bcp14> be reset to the configured valu
e each time a
<texttable style="all" feedback message is received. If the timeout expires, the Sender
title="Parameters for Load Rate Adjustment Algorithm"> <bcp14>SHALL</bcp14> be closed and no further load packets sent.</dd
<ttcol>Parameter</ttcol> >
</dl>
<ttcol>Default</ttcol> <table align="center" anchor="load-rate-adj-params">
<name>Parameters for Load Rate Adjustment Algorithm</name>
<ttcol>Tested Range or values</ttcol> <thead>
<tr>
<ttcol width="30">Expected Safe Range (not entirely tested, other <th align="left">Parameter</th>
values NOT RECOMMENDED)</ttcol> <th align="left">Default</th>
<th align="left">Tested Range or Values</th>
<c>FT, feedback time interval</c> <th align="left">Expected Safe Range (not entirely tested, other
values <bcp14>NOT RECOMMENDED</bcp14>)</th>
<c>50ms</c> </tr>
</thead>
<c>20ms, 50ms, 100ms</c> <tbody>
<tr>
<c>20ms &lt;= FT &lt;= 250ms Larger values may slow the rate <td align="left">FT, feedback time interval</td>
increase and fail to find the max</c> <td align="left">50 msec</td>
<td align="left">20 msec, 50 msec, 100 msec</td>
<c>Feedback message timeout (stop test)</c> <td align="left">20 msec &lt;= FT &lt;= 250 msec; larger values ma
y slow the rate
<c>L*FT, L=20 (1sec with FT=50ms)</c> increase and fail to find the max</td>
</tr>
<c>L=100 with FT=50ms (5sec)</c> <tr>
<td align="left">Feedback message timeout (stop test)</td>
<c>0.5sec &lt;= L*FT &lt;= 30sec Upper limit for very unreliable <td align="left">L*FT, L=20 (1 sec with FT=50 msec)</td>
test paths only</c> <td align="left">L=100 with FT=50 msec (5 sec)</td>
<td align="left">0.5 sec &lt;= L*FT &lt;= 30 sec; upper limit for
<c>load packet timeout (stop test)</c> very unreliable
test paths only</td>
<c>1sec</c> </tr>
<tr>
<c>5sec</c> <td align="left">Load packet timeout (stop test)</td>
<td align="left">1 sec</td>
<c>0.250sec - 30sec Upper limit for very unreliable test paths <td align="left">5 sec</td>
only</c> <td align="left">0.250-30 sec; upper limit for very unreliable tes
t paths
<c>table index 0</c> only</td>
</tr>
<c>0.5Mbps</c> <tr>
<td align="left">Table index 0</td>
<c>0.5Mbps</c> <td align="left">0.5 Mbps</td>
<td align="left">0.5 Mbps</td>
<c>when testing &lt;=10Gbps</c> <td align="left">When testing &lt;= 10 Gbps</td>
</tr>
<c>table index 1</c> <tr>
<td align="left">Table index 1</td>
<c>1Mbps</c> <td align="left">1 Mbps</td>
<td align="left">1 Mbps</td>
<c>1Mbps</c> <td align="left">When testing &lt;= 10 Gbps</td>
</tr>
<c>when testing &lt;=10Gbps</c> <tr>
<td align="left">Table index (step) size</td>
<c>table index (step) size</c> <td align="left">1 Mbps</td>
<td align="left">1 Mbps &lt;= rate &lt;= 1 Gbps</td>
<c>1Mbps</c> <td align="left">Same as tested</td>
</tr>
<c>1Mbps&lt;=rate&lt;= 1Gbps</c> <tr>
<td align="left">Table index (step) size, rate &gt; 1 Gbps</td>
<c>same as tested</c> <td align="left">100 Mbps</td>
<td align="left">1 Gbps &lt;= rate &lt;= 10 Gbps</td>
<c>table index (step) size, rate&gt;1Gbps</c> <td align="left">Same as tested</td>
</tr>
<c>100Mbps</c> <tr>
<td align="left">Table index (step) size, rate &gt; 10 Gbps</td>
<c>1Gbps&lt;=rate&lt;= 10Gbps</c> <td align="left">1 Gbps</td>
<td align="left">Untested</td>
<c>same as tested</c> <td align="left">&gt;10 Gbps</td>
</tr>
<c>table index (step) size, rate&gt;10Gbps</c> <tr>
<td align="left">ss, UDP payload size, bytes</td>
<c>1Gbps</c> <td align="left">None</td>
<td align="left">&lt;=1222</td>
<c>untested</c> <td align="left">Recommend max at largest value that avoids fragme
ntation; using a payload size that is too small might result in unexpected Sende
<c>&gt;10Gbps</c> r
limitations</td>
<c>ss, UDP payload size, bytes</c> </tr>
<tr>
<c>none</c> <td align="left">cc, burst count</td>
<td align="left">None</td>
<c>&lt;=1222</c> <td align="left">1 &lt;= cc &lt;= 100</td>
<td align="left">Same as tested. Vary cc as needed to create the d
<c>Recommend max at largest value that avoids fragmentation; use of esired maximum
too-small payload size might result in unexpected sender sending rate. Sender buffer size may limit cc in the implementation</t
limitations.</c> d>
</tr>
<c>cc, burst count</c> <tr>
<td align="left">tt, burst interval</td>
<c>none</c> <td align="left">100 microsec</td>
<td align="left">100 microsec, 1 msec</td>
<c>1&lt;=cc&lt;= 100</c> <td align="left">Available range of "tick" values (HZ param)</td>
</tr>
<c>same as tested. Vary cc as needed to create the desired maximum <tr>
sending rate. Sender buffer size may limit cc in implementation.</c> <td align="left">Low delay range threshold</td>
<td align="left">30 msec</td>
<c>tt, burst interval</c> <td align="left">5 msec, 30 msec</td>
<td align="left">Same as tested</td>
<c>100microsec</c> </tr>
<tr>
<c>100microsec, 1msec</c> <td align="left">High delay range threshold</td>
<td align="left">90 msec</td>
<c>available range of "tick" values (HZ param)</c> <td align="left">10 msec, 90 msec</td>
<td align="left">Same as tested</td>
<c>low delay range threshold</c> </tr>
<tr>
<c>30ms</c> <td align="left">Sequence error threshold</td>
<td align="left">10</td>
<c>5ms, 30ms</c> <td align="left">0, 1, 5, 10, 100</td>
<td align="left">Same as tested</td>
<c>same as tested</c> </tr>
<tr>
<c>high delay range threshold</c> <td align="left">Consecutive errored status report threshold</td>
<td align="left">3</td>
<c>90ms</c> <td align="left">2, 3, 4, 5</td>
<td align="left">Use values &gt;1 to avoid misinterpreting transie
<c>10ms, 90ms</c> nt loss</td>
</tr>
<c>same as tested</c> <tr>
<td align="left">Fast mode increase, in table index steps</td>
<c>sequence error threshold</c> <td align="left">10</td>
<td align="left">10</td>
<c>0</c> <td align="left">2 &lt;= steps &lt;= 30</td>
</tr>
<c>0, 100</c> <tr>
<td align="left">Fast mode decrease, in table index steps</td>
<c>same as tested</c> <td align="left">3 * Fast mode increase</td>
<td align="left">3 * Fast mode increase</td>
<c>consecutive errored status report threshold</c> <td align="left">Same as tested</td>
</tr>
<c>2</c> </tbody>
</table>
<c>2</c>
<c>Use values &gt;1 to avoid misinterpreting transient loss</c>
<c>Fast mode increase, in table index steps</c>
<c>10</c>
<c>10</c>
<c>2 &lt;= steps &lt;= 30</c>
<c>Fast mode decrease, in table index steps</c>
<c>3 * Fast mode increase</c>
<c>3 * Fast mode increase</c>
<c>same as tested</c>
</texttable>
<t>As a consequence of default parameterization, the Number of table <t>As a consequence of default parameterization, the Number of table
steps in total for rates &lt;10Gbps is 2000 (excluding index 0).</t> steps in total for rates less than 10 Gbps is 1090 (excluding index 0).<
/t>
<t>A related sender backoff response to network conditions occurs when <t>A related Sender backoff response to network conditions occurs when
one or more status feedback messages fail to arrive at the sender.</t> one or more status feedback messages fail to arrive at the Sender.</t>
<t>If no status feedback messages arrive at the Sender for the
<t>If no status feedback messages arrive at the sender for the
interval greater than the Lost Status Backoff timeout:</t> interval greater than the Lost Status Backoff timeout:</t>
<artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
<t><figure> UDRT + (2+w)*FT = Lost Status Backoff timeout
<artwork><![CDATA[ UDRT + (2+w)*FT = Lost Status Backoff t
imeout
where: where:
UDRT = upper delay range threshold (default 90ms)
FT = feedback time interval (default 50ms) UDRT = upper delay range threshold (default 90 msec)
FT = feedback time interval (default 50 msec)
w = number of repeated timeouts (w=0 initially, w++ on each w = number of repeated timeouts (w=0 initially, w++ on each
timeout, and reset to 0 when a message is received) timeout, and reset to 0 when a message is received)
]]></artwork> ]]></artwork>
</figure></t> <t>Beginning when the last message (of any type) was successfully
received at the Sender:</t>
<t>beginning when the last message (of any type) was successfully <t>The offered load <bcp14>SHALL</bcp14> then be decreased, following th
received at the sender:</t> e same
process as when the feedback indicates the presence of one or more
<t>Then the offered load SHALL be decreased, following the same
process as when the feedback indicates presence of one or more
sequence number anomalies OR the delay range was above the upper sequence number anomalies OR the delay range was above the upper
threshold (as described above), with the same load rate adjustment threshold (as described above), with the same load rate adjustment
algorithm variables in their current state. This means that rate algorithm variables in their current state. This means that lost status
reduction and congestion confirmation can result from a three-way OR feedback messages OR sequence errors OR delay variation can result in rate reduc
that includes lost status feedback messages, sequence errors, or delay tion and congestion confirmation.</t>
variation.</t> <t>The <bcp14>RECOMMENDED</bcp14> initial value for w is 0, taking a Rou
nd-Trip Time
<t>The RECOMMENDED initial value for w is 0, taking Round Trip Time (RTT) of less than FT into account. A test with an RTT longer than FT is
(RTT) less than FT into account. A test with RTT longer than FT is a a
valid reason to increase the initial value of w appropriately. valid reason to increase the initial value of w appropriately.
Variable w SHALL be incremented by 1 whenever the Lost Status Backoff Variable w <bcp14>SHALL</bcp14> be incremented by one whenever the Lost
timeout is exceeded. So with FT = 50ms and UDRT = 90ms, a status Status Backoff
feedback message loss would be declared at 190ms following a timeout is exceeded. So, with FT = 50 msec and UDRT = 90 msec, a status
successful message, again at 50ms after that (240ms total), and so feedback message loss would be declared at 190 msec following a
successful message, again at 50 msec after that (240 msec total), and so
on.</t> on.</t>
<t>Also, if congestion is now confirmed for the first time by a Lost <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 Status Backoff timeout, then the offered load rate is decreased by
more than one rate (e.g., Rx-30). This one-time reduction is intended more than one rate setting (e.g., Rx-30). This one-time reduction is int ended
to compensate for the fast initial ramp-up. In all other cases, the to compensate for the fast initial ramp-up. In all other cases, the
offered load rate is only decreased by one (Rx-1).</t> offered load rate is only decreased by one (Rx-1).</t>
<t><xref target="app-b-rfc8085-udp"/> discusses compliance with the appl
<t>Appendix B discusses compliance with the applicable mandatory icable mandatory
requirements of <xref target="RFC8085"/>, consistent with the goals of requirements of <xref target="RFC8085" format="default"/>, consistent wi
th the goals of
the IP-Layer Capacity Metric and Method, including the load rate the IP-Layer Capacity Metric and Method, including the load rate
adjustment algorithm described in this section.</t> adjustment algorithm described in this section.</t>
</section> </section>
<section anchor="meas-qual-verif" numbered="true" toc="default">
<section title="Measurement Qualification or Verification"> <name>Measurement Qualification or Verification</name>
<t>It is of course necessary to calibrate the equipment performing the <t>It is of course necessary to calibrate the equipment performing the
IP-Layer Capacity measurement, to ensure that the expected capacity IP-Layer Capacity measurement, to ensure that the expected capacity
can be measured accurately, and that equipment choices (processing can be measured accurately and that equipment choices (processing
speed, interface bandwidth, etc.) are suitably matched to the speed, interface bandwidth, etc.) are suitably matched to the
measurement range.</t> measurement range.</t>
<t>When assessing a maximum rate as the metric specifies, artificially
<t>When assessing a Maximum rate as the metric specifies, artificially
high (optimistic) values might be measured until some buffer on the high (optimistic) values might be measured until some buffer on the
path is filled. Other causes include bursts of back-to-back packets path is filled. Other causes include bursts of back-to-back packets
with idle intervals delivered by a path, while the measurement with idle intervals delivered by a path, while the measurement
interval (dt) is small and aligned with the bursts. The artificial interval (dt) is small and aligned with the bursts. The artificial
values might result in an un-sustainable Maximum Capacity observed values might result in an unsustainable Maximum Capacity observed
when the method of measurement is searching for the Maximum, and that when the Method of Measurement is searching for the maximum, and that
would not do. This situation is different from the bi-modal service would not do. This situation is different from the bimodal service
rates (discussed under Reporting), which are characterized by a rates (discussed in "<xref target="sec6-6-rpt-the-metric" format="title"
/>", <xref target="sec6-6-rpt-the-metric" format="default"/>), which are charact
erized by a
multi-second duration (much longer than the measured RTT) and multi-second duration (much longer than the measured RTT) and
repeatable behavior.</t> repeatable behavior.</t>
<t>There are many ways that the Method of Measurement could handle <t>There are many ways that the Method of Measurement could handle
this false-max issue. The default value for measurement of singletons this false-max issue. The default value for measurement of Singletons
(dt = 1 second) has proven to be of practical value during tests of (dt = 1 second) has proven to be of practical value during tests of
this method, allows the bimodal service rates to be characterized, and this method, allows the bimodal service rates to be characterized, and
it has an obvious alignment with the reporting units (Mbps).</t> has an obvious alignment with the reporting units (Mbps).</t>
<t>Another approach comes from <xref target="RFC2544" sectionFormat="of"
<t>Another approach comes from Section 24 of <xref target="RFC2544"/> section="24"/>
and its discussion of Trial duration, where relatively short trials and its discussion of trial duration, where relatively short trials
conducted as part of the search are followed by longer trials to make conducted as part of the search are followed by longer trials to make
the final determination. In the production network, measurements of the final determination. In the production network, measurements of
Singletons and Samples (the terms for trials and tests of Lab Singletons and Samples (the terms for trials and tests of Lab
Benchmarking) must be limited in duration because they may be Benchmarking) must be limited in duration because they may affect
service-affecting. But there is sufficient value in repeating a Sample service. But there is sufficient value in repeating a Sample
with a fixed sending rate determined by the previous search for the 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 Maximum IP-Layer Capacity, to qualify the result in terms of the other
performance metrics measured at the same time.</t> performance metrics measured at the same time.</t>
<t>A Qualification measurement for the search result is a subsequent
<t>A qualification measurement for the search result is a subsequent measurement, sending at a fixed 99.x percent of the Maximum IP-Layer
measurement, sending at a fixed 99.x % of the Maximum IP-Layer
Capacity for I, or an indefinite period. The same Maximum Capacity Capacity for I, or an indefinite period. The same Maximum Capacity
Metric is applied, and the Qualification for the result is a Sample Metric is applied, and the Qualification for the result is a Sample
without packet loss or a growing minimum delay trend in subsequent without supra-threshold packet losses or a growing minimum delay trend i
singletons (or each dt of the measurement interval, I). Samples n subsequent
exhibiting losses or increasing queue occupation require a repeated Singletons (or each dt of the measurement interval, I). Samples
search and/or test at reduced fixed sender rate for qualification.</t> exhibiting supra-threshold packet losses or increasing queue occupation
require a repeated
search and/or test at a reduced fixed Sender rate for Qualification.</t>
<t>Here, as with any Active Capacity test, the test duration must be <t>Here, as with any Active Capacity test, the test duration must be
kept short. 10 second tests for each direction of transmission are kept short. Ten-second tests for each direction of transmission are
common today. The default measurement interval specified here is I = common today. The default measurement interval specified here is I =
10 seconds. The combination of a fast and congestion-aware search 10 seconds. The combination of a fast and congestion-aware search
method and user-network coordination make a unique contribution to method and user-network coordination makes a unique contribution to
production testing. The Maximum IP Capacity metric and method for production testing. The Maximum IP Capacity Metric and Method for
assessing performance is very different from classic <xref assessing performance is very different from the classic Throughput Metr
target="RFC2544"/> Throughput metric and methods : it uses ic and Methods provided in <xref target="RFC2544" format="default"/>: it uses
near-real-time load adjustments that are sensitive to loss and delay, near-real-time load adjustments that are sensitive to loss and delay,
similar to other congestion control algorithms used on the Internet similar to other congestion control algorithms used on the Internet
every day, along with limited duration. On the other hand, <xref every day, along with limited duration. On the other hand, Throughput me
target="RFC2544"/> Throughput measurements can produce sustained asurements <xref target="RFC2544" format="default"/> can produce sustained
overload conditions for extended periods of time. Individual trials in overload conditions for extended periods of time. Individual trials in
a test governed by a binary search can last 60 seconds for each step, 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 and the final confirmation trial may be even longer. This is very
different from "normal" traffic levels, but overload conditions are different from "normal" traffic levels, but overload conditions are
not a concern in the isolated test environment. The concerns raised in not a concern in the isolated test environment. The concerns raised in
<xref target="RFC6815"/> were that <xref target="RFC2544"/> methods <xref target="RFC6815" format="default"/> were that the methods discusse
would be let loose on production networks, and instead the authors d in <xref target="RFC2544" format="default"/> would be let loose on production
challenged the standards community to develop metrics and methods like networks, and instead the authors
challenged the standards community to develop Metrics and Methods like
those described in this memo.</t> those described in this memo.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Measurement Considerations"> <name>Measurement Considerations</name>
<t>In general, the wide-spread measurements that this memo encourages <t>In general, the widespread measurements that this memo encourages
will encounter wide-spread behaviors. The bimodal IP Capacity will encounter widespread behaviors. The bimodal IP Capacity
behaviors already discussed in Section 6.6 are good examples.</t> behaviors already discussed in <xref target="sec6-6-rpt-the-metric"/> ar
e good examples.</t>
<t>In general, it is RECOMMENDED to locate test endpoints as close to <t>In general, it is <bcp14>RECOMMENDED</bcp14> to locate test endpoints
the intended measured link(s) as practical (this is not always as close to
possible for reasons of scale; there is a limit on number of test the intended measured link(s) as practical (for reasons of scale, this i
endpoints coming from many perspectives, management and measurement s not always possible; there is a limit on the number of test
traffic for example). The testing operator MUST set a value for the endpoints coming from many perspectives -- for example, management and m
MaxHops parameter, based on the expected path length. This parameter easurement traffic). The testing operator <bcp14>MUST</bcp14> set a value for th
e
MaxHops Parameter, based on the expected path length. This Parameter
can keep measurement traffic from straying too far beyond the intended can keep measurement traffic from straying too far beyond the intended
path.</t> path.</t>
<t>The measured path may be stateful based on many factors, and the
<t>The path measured may be stateful based on many factors, and the
Parameter "Time of day" when a test starts may not be enough Parameter "Time of day" when a test starts may not be enough
information. Repeatable testing may require the time from the information. Repeatable testing may require knowledge of the time from t
beginning of a measured flow, and how the flow is constructed he
beginning of a measured flow -- and how the flow is constructed,
including how much traffic has already been sent on that flow when a including how much traffic has already been sent on that flow when a
state-change is observed, because the state-change may be based on state change is observed -- because the state change may be based on
time or bytes sent or both. Both load packets and status feedback time, bytes sent, or both. Both load packets and status feedback
messages MUST contain sequence numbers, which helps with measurements messages <bcp14>MUST</bcp14> contain sequence numbers; this helps with m
easurements
based on those packets.</t> based on those packets.</t>
<t>Many different types of traffic shapers and on-demand <t>Many different types of traffic shapers and on-demand
communications access technologies may be encountered, as anticipated communications access technologies may be encountered, as anticipated
in <xref target="RFC7312"/>, and play a key role in measurement in <xref target="RFC7312" format="default"/>, and play a key role in mea
results. Methods MUST be prepared to provide a short preamble surement
transmission to activate on-demand communications access, and to results. Methods <bcp14>MUST</bcp14> be prepared to provide a short prea
mble
transmission to activate on-demand communications access and to
discard the preamble from subsequent test results.</t> discard the preamble from subsequent test results.</t>
<t>The following conditions might be encountered during measurement, whe
<t>Conditions which might be encountered during measurement, where re
packet losses may occur independently of the measurement sending packet losses may occur independently of the measurement sending
rate:</t> rate:</t>
<ol spacing="normal" type="1"><li>Congestion of an interconnection or ba
<t><list style="numbers"> ckbone interface may
<t>Congestion of an interconnection or backbone interface may
appear as packet losses distributed over time in the test stream, appear as packet losses distributed over time in the test stream,
due to much higher rate interfaces in the backbone.</t> due to much-higher-rate interfaces in the backbone.</li>
<li>Packet loss due to the use of Random Early Detection (RED) or othe
<t>Packet loss due to use of Random Early Detection (RED) or other r
active queue management may or may not affect the measurement flow active queue management may or may not affect the measurement flow
if competing background traffic (other flows) are simultaneously if competing background traffic (other flows) is simultaneously
present.</t> present.</li>
<li>There may be only a small delay variation independent of the sendi
<t>There may be only small delay variation independent of sending ng
rate under these conditions, too.</t> rate under these conditions as well.</li>
<li>Persistent competing traffic on measurement paths that include
<t>Persistent competing traffic on measurement paths that include
shared transmission media may cause random packet losses in the shared transmission media may cause random packet losses in the
test stream.</t> test stream.</li>
</list>It is possible to mitigate these conditions using the </ol>
flexibility of the load-rate adjusting algorithm described in Section <t>It is possible to mitigate these conditions using the
8.1 above (tuning specific parameters).</t> flexibility of the load rate adjustment algorithm described in
<xref target="load-rate-adj"/> above (tuning specific Parameters).</t>
<t>If the measurement flow burst duration happens to be on the order <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 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 path, then the line rate might be measured rather than the bandwidth
limit imposed by the shaper or policer. If this condition is limit imposed by the shaper or policer. If this condition is
suspected, alternate configurations SHOULD be used.</t> suspected, alternate configurations <bcp14>SHOULD</bcp14> be used.</t>
<t>In general, results depend on the sending stream's characteristics;
<t>In general, results depend on the sending stream characteristics; the measurement community has known this for a long time and needs to
the measurement community has known this for a long time, and needs to keep it foremost in mind. Although the default is a single flow (F=1) fo
keep it front of mind. Although the default is a single flow (F=1) for r
testing, use of multiple flows may be advantageous for the following testing, the use of multiple flows may be advantageous for the following
reasons:</t> reasons:</t>
<ol spacing="normal" type="1"><li>The test hosts may be able to create a
<t><list style="numbers"> higher load than with a
<t>the test hosts may be able to create higher load than with a single flow, or parallel test hosts may be used to generate one flow
single flow, or parallel test hosts may be used to generate 1 flow each.</li>
each.</t> <li>Link aggregation may be present (flow-based load balancing), and m
ultiple flows are needed to occupy each member of
<t>there may be link aggregation present (flow-based load the aggregate.</li>
balancing) and multiple flows are needed to occupy each member of <li>Internet access policies may limit the IP-Layer Capacity
the aggregate.</t> depending on the Type-P of the packets, possibly reserving capacity
for various stream types.</li>
<t>Internet access policies may limit the IP-Layer Capacity </ol>
depending on the Type-P of packets, possibly reserving capacity <t>Each flow would be controlled using its own implementation of
for various stream types.</t>
</list>Each flow would be controlled using its own implementation of
the load rate adjustment (search) algorithm.</t> the load rate adjustment (search) algorithm.</t>
<t>It is obviously counterproductive to run more than one independent
<t>It is obviously counter-productive to run more than one independent
and concurrent test (regardless of the number of flows in the test and concurrent test (regardless of the number of flows in the test
stream) attempting to measure the *maximum* capacity on a single path. stream) attempting to measure the <strong>maximum</strong> capacity on a
The number of concurrent, independent tests of a path SHALL be limited single path.
The number of concurrent, independent tests of a path <bcp14>SHALL</bcp1
4> be limited
to one.</t> to one.</t>
<t>Tests of a v4-v6 transition mechanism might well be the intended <t>Tests of a v4-v6 transition mechanism might well be the intended
subject of a capacity test. As long as the IPv4 and IPv6 packets subject of a capacity test. As long as both IPv4 packets and IPv6 packet
sent/received are both standard-formed, this should be allowed (and s
sent/received are standard-formed, this should be allowed (and
the change in header size easily accounted for on a per-packet the change in header size easily accounted for on a per-packet
basis).</t> basis).</t>
<t>As testing continues, implementers should expect the methods to evolv
<t>As testing continues, implementers should expect some evolution in e. The ITU-T has published a supplement (Supplement 60) to the Y-series
the methods. The ITU-T has published a Supplement (60) to the Y-series of ITU-T Recommendations, "Interpreting ITU-T Y.1540 maximum IP-layer
of Recommendations, "Interpreting ITU-T Y.1540 Maximum IP-Layer capacity measurements" <xref target="Y.Sup60" format="default"/>, which
Capacity measurements", <xref target="Y.Sup60"/>, which is the result is the result
of continued testing with the metric, and those results have improved of continued testing with the metric. Those results have improved
the method described here.</t> the methods 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/>
</section> </section>
</section> </section>
<section anchor="rpt-formats" numbered="true" toc="default">
<section title="Reporting Formats"> <name>Reporting Formats</name>
<t>The singleton IP-Layer Capacity results SHOULD be accompanied by the <t>The Singleton IP-Layer Capacity results <bcp14>SHOULD</bcp14> be accomp
context under which they were measured.<list style="symbols"> anied by the
<t>timestamp (especially the time when the maximum was observed in context under which they were measured.</t>
dtn)</t> <ul spacing="normal">
<li>Timestamp (especially the time when the maximum was observed in
<t>Source and Destination (by IP or other meaningful ID)</t> dtn).</li>
<li>Source and Destination (by IP or other meaningful ID).</li>
<t>other inner parameters of the test case (Section 4)</t> <li>Other inner Parameters of the test case (<xref target="gen-params-de
fs"/>).</li>
<t>outer parameters, such as "test conducted in motion" or other <li>Outer Parameters, such as "test conducted in motion" or other
factors belonging to the context of the measurement</t> factors belonging to the context of the measurement.</li>
<li>Result validity (indicating cases where the process was somehow
<t>result validity (indicating cases where the process was somehow interrupted or the attempt failed).</li>
interrupted or the attempt failed)</t> <li>A field where unusual circumstances could be documented, and
another one for "ignore / mask out" purposes in further processing.</l
<t>a field where unusual circumstances could be documented, and i>
another one for "ignore/mask out" purposes in further processing</t> </ul>
</list></t> <t>The Maximum IP-Layer Capacity results <bcp14>SHOULD</bcp14> be reported
in tabular
<t>The Maximum IP-Layer Capacity results SHOULD be reported in the format. There <bcp14>SHOULD</bcp14> be a column that identifies the test Phase
format of a table with a row for each of the test Phases and Number of .
Flows. There SHOULD be columns for the phases with number of flows, and There <bcp14>SHOULD</bcp14> be a column listing the number of flows used in th
for the resultant Maximum IP-Layer Capacity results for the aggregate at Phase.
and each flow tested.</t> The remaining columns <bcp14>SHOULD</bcp14> report the following results for t
he aggregate
<t>As mentioned in Section 6.6, bi-modal (or multi-modal) maxima SHALL of all flows, including the Maximum IP-Layer Capacity, the Loss Ratio,
the RTT minimum, RTT maximum, and other metrics tested having similar
relevance.</t>
<t>As mentioned in <xref target="sec6-6-rpt-the-metric"/>, bimodal (or mul
ti-modal) maxima <bcp14>SHALL</bcp14>
be reported for each mode separately.</t> be reported for each mode separately.</t>
<table align="center">
<texttable style="all" title="Maximum IP-layer Capacity Results"> <name>Maximum IP-Layer Capacity Results</name>
<ttcol>Phase, # Flows</ttcol> <thead>
<tr>
<ttcol>Maximum IP-Layer Capacity, Mbps</ttcol> <th align="left">Phase</th>
<th align="left">Number of Flows</th>
<ttcol>Loss Ratio</ttcol> <th align="left">Maximum IP-Layer Capacity (Mbps)</th>
<th align="left">Loss Ratio</th>
<ttcol>RTT min, max, msec</ttcol> <th align="left">RTT min (msec)</th>
<th align="left">RTT max (msec)</th>
<c>Search,1</c> </tr>
</thead>
<c>967.31</c> <tbody>
<tr>
<c>0.0002</c> <td align="left">Search</td>
<td align="left">1</td>
<c>30, 58</c> <td align="left">967.31</td>
<td align="left">0.0002</td>
<c>Verify,1</c> <td align="left">30</td>
<td align="left">58</td>
<c>966.00</c> </tr>
<tr>
<c>0.0000</c> <td align="left">Verify</td>
<td align="left">1</td>
<c>30, 38</c> <td align="left">966.00</td>
</texttable> <td align="left">0.0000</td>
<td align="left">30</td>
<t>Static and configuration parameters:</t> <td align="left">38</td>
</tr>
<t>The sub-interval time, dt, MUST accompany a report of Maximum </tbody>
IP-Layer Capacity results, and the remaining Parameters from Section 4, </table>
General Parameters.</t> <t>Static and configuration Parameters:</t>
<t>The sub-interval time, dt, <bcp14>MUST</bcp14> accompany a report of Ma
ximum
IP-Layer Capacity results, as well as the remaining Parameters from <xref
target="gen-params-defs"/> ("General Parameters and Definitions").</t>
<t>The PM list metrics corresponding to the sub-interval where the <t>The PM list metrics corresponding to the sub-interval where the
Maximum Capacity occurred MUST accompany a report of Maximum IP-Layer Maximum Capacity occurred <bcp14>MUST</bcp14> accompany a report of Maximu
Capacity results, for each test phase.</t> m IP-Layer
Capacity results, for each test Phase.</t>
<t>The IP-Layer Sender Bit rate results SHOULD be reported in the format <t>The IP-Layer Sender Bit Rate results <bcp14>SHOULD</bcp14> be reported
of a table with a row for each of the test phases, sub-intervals (st) in tabular format.
and number of flows. There SHOULD be columns for the phases with number There <bcp14>SHOULD</bcp14> be a column that identifies the test Phase.
of flows, and for the resultant IP-Layer Sender Bit rate results for the There <bcp14>SHOULD</bcp14> be a column listing each individual (numbered) flo
aggregate and each flow tested.</t> w used
in that Phase, or the aggregate of flows in that Phase. A corresponding column
<texttable style="all" title="IP-layer Sender Bit Rate Results"> <bcp14>SHOULD</bcp14> identify the
<ttcol>Phase, Flow or Aggregate</ttcol> specific sending rate sub-interval, stn, for each flow and aggregate. A final
column <bcp14>SHOULD</bcp14> report the
<ttcol>st, sec</ttcol> IP-Layer Sender Bit Rate results for each flow used, or the aggregate of all f
lows.</t>
<ttcol>Sender Bitrate, Mbps</ttcol> <table align="center">
<name>IP-Layer Sender Bit Rate Results (Example with Two Flows and st =
<c>Search,1</c> 0.05 (sec))</name>
<thead>
<c>0.00 - 0.05</c> <tr>
<th align="left">Phase</th>
<c>345</c> <th align="left">Flow Number or Aggregate</th>
<th align="left">stn (sec)</th>
<c>Search,2</c> <th align="left">Sender Bit Rate (Mbps)</th>
</tr>
<c>0.00 - 0.05</c> </thead>
<tbody>
<c>289</c> <tr>
<td align="left">Search</td>
<c>Search,Agg</c> <td align="left">1</td>
<td align="left">0.00</td>
<c>0.00 - 0.05</c> <td align="left">345</td>
</tr>
<c>634</c> <tr>
</texttable> <td align="left">Search</td>
<td align="left">2</td>
<t>Static and configuration parameters:</t> <td align="left">0.00</td>
<td align="left">289</td>
<t>The subinterval time, st, MUST accompany a report of Sender IP-Layer </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>
<t>The sub-interval duration, st, <bcp14>MUST</bcp14> accompany a report o
f Sender IP-Layer
Bit Rate results.</t> Bit Rate results.</t>
<t>Also, the values of the remaining Parameters from <xref target="gen-par
<t>Also, the values of the remaining Parameters from Section 4, General ams-defs"/> ("General Parameters and Definitions") <bcp14>MUST</bcp14> be report
Parameters, MUST be reported.</t> ed.</t>
<section numbered="true" toc="default">
<t/> <name>Configuration and Reporting Data Formats</name>
<section title="Configuration and Reporting Data Formats">
<t>As a part of the multi-Standards Development Organization (SDO) <t>As a part of the multi-Standards Development Organization (SDO)
harmonization of this metric and method of measurement, one of the harmonization of this Metric and Method of Measurement, one of the
areas where the Broadband Forum (BBF) contributed its expertise was in areas where the Broadband Forum (BBF) contributed its expertise was in
the definition of an information model and data model for the definition of an information model and data model for
configuration and reporting. These models are consistent with the configuration and reporting. These models are consistent with the
metric parameters and default values specified as lists is this memo. metric Parameters and default values specified as lists in this memo.
<xref target="TR-471"/> provides the Information model that was used <xref target="TR-471" format="default"/> provides the information model
that was used
to prepare a full data model in related BBF work. The BBF has also to prepare a full data model in related BBF work. The BBF has also
carefully considered topics within its purview, such as placement of carefully considered topics within its purview, such as the placement of
measurement systems within the Internet access architecture. For measurement systems within the Internet access architecture. For
example, timestamp resolution requirements that influence the choice example, timestamp resolution requirements that influence the choice
of the test protocol are provided in Table 2 of <xref of the test protocol are provided in Table 2 of <xref target="TR-471" fo
target="TR-471"/>.</t> rmat="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="sec-cons" numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t>Active metrics and measurements have a long history of security <t>Active Metrics and Active Measurements have a long history of security
considerations. The security considerations that apply to any active considerations. The security considerations that apply to any Active
measurement of live paths are relevant here. See <xref Measurement of live paths are relevant here. See <xref target="RFC4656" fo
target="RFC4656"/> and <xref target="RFC5357"/>.</t> rmat="default"/> and <xref target="RFC5357" format="default"/>.</t>
<t>When considering the privacy of those involved in measurement or those
<t>When considering privacy of those involved in measurement or those
whose traffic is measured, the sensitive information available to whose traffic is measured, the sensitive information available to
potential observers is greatly reduced when using active techniques potential observers is greatly reduced when using active techniques
which are within this scope of work. Passive observations of user that are within this scope of work. Passive observations of user
traffic for measurement purposes raise many privacy issues. We refer the traffic for measurement purposes raise many privacy issues. We refer the
reader to the privacy considerations described in the Large Scale reader to the privacy considerations described in the Large-scale
Measurement of Broadband Performance (LMAP) Framework <xref Measurement of Broadband Performance (LMAP) Framework <xref target="RFC759
target="RFC7594"/>, which covers active and passive techniques.</t> 4" format="default"/>, which covers active and passive techniques.</t>
<t>There are some new considerations for Capacity measurement as <t>There are some new considerations for Capacity measurement as
described in this memo.</t> described in this memo.</t>
<ol spacing="normal" type="1"><li>Cooperating Source and Destination hosts
<t><list style="numbers"> and agreements to test
<t>Cooperating Source and Destination hosts and agreements to test the path between the hosts are <bcp14>REQUIRED</bcp14>. Hosts perform
the path between the hosts are REQUIRED. Hosts perform in either the in either the
Src or Dst roles.</t> Src role or the Dst role.</li>
<li>It is <bcp14>REQUIRED</bcp14> to have a user client-initiated setup
<t>It is REQUIRED to have a user client-initiated setup handshake handshake
between cooperating hosts that allows firewalls to control inbound between cooperating hosts that allows firewalls to control inbound
unsolicited UDP traffic which either goes to a control port unsolicited UDP traffic that goes to either a control port
[expected and w/authentication] or to ephemeral ports that are only (expected and with authentication) or ephemeral ports that are only
created as needed. Firewalls protecting each host can both continue created as needed. Firewalls protecting each host can both continue
to do their job normally.</t> to do their job normally.</li>
<li>Client-server authentication and integrity protection for
<t>Client-server authentication and integrity protection for feedback messages conveying measurements are <bcp14>RECOMMENDED</bcp14
feedback messages conveying measurements is RECOMMENDED.</t> >.</li>
<li>Hosts <bcp14>MUST</bcp14> limit the number of simultaneous tests to
<t>Hosts MUST limit the number of simultaneous tests to avoid avoid
resource exhaustion and inaccurate results.</t> resource exhaustion and inaccurate results.</li>
<li>Senders <bcp14>MUST</bcp14> be rate limited. This can be accomplishe
<t>Senders MUST be rate-limited. This can be accomplished using a d using a
pre-built table defining all the offered load rates that will be pre-built table defining all the offered load rates that will be
supported (Section 8.1). The recommended load-control search supported (<xref target="load-rate-adj"/>). The recommended load contr ol search
algorithm results in "ramp-up" from the lowest rate in the algorithm results in "ramp-up" from the lowest rate in the
table.</t> table.</li>
<li>Service subscribers with limited data volumes who conduct
<t>Service subscribers with limited data volumes who conduct
extensive capacity testing might experience the effects of Service extensive capacity testing might experience the effects of Service
Provider controls on their service. Testing with the Service Provider controls on their service. Testing with the Service
Provider's measurement hosts SHOULD be limited in frequency and/or Provider's measurement hosts <bcp14>SHOULD</bcp14> be limited in frequ ency and/or
overall volume of test traffic (for example, the range of duration overall volume of test traffic (for example, the range of duration
values, I, SHOULD be limited).</t> values, I, <bcp14>SHOULD</bcp14> be limited).</li>
</list></t> </ol>
<t>The exact specification of these features is left for future
<t>The exact specification of these features is left for the future
protocol development.</t> protocol development.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This memo makes no requests of IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2330.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7680.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8468.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6438.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4737.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4656.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2681.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5357.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7497.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2544.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3148.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5136.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6815.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7312.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7594.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7799.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8085.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8337.xml"/>
<section title="Acknowledgments"> <reference anchor="copycat" target="https://irtf.org/anrw/2017/anrw17-fi
<t>Thanks to Joachim Fabini, Matt Mathis, J.Ignacio Alvarez-Hamelin, nal5.pdf">
Wolfgang Balzer, Frank Brockners, Greg Mirsky, Martin Duke, Murray <front>
Kucherawy, and Benjamin Kaduk for their extensive comments on the memo <title>copycat: Testing Differential Treatment of New Transport
and related topics. In a second round of reviews, we acknowledge Magnus Protocols in the Wild</title>
Westerlund, Lars Eggert, and Zahed Sarkar.</t> <author fullname="Korian Edeline" initials="K." surname="Edeline">
</section> <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>
<section title="Appendix A - Load Rate Adjustment Pseudo Code"> <reference anchor="Y.Sup60" target="https://www.itu.int/rec/T-REC-Y.Sup6
<t>The following is a pseudo-code implementation of the algorithm 0/en">
described in Section 8.1.</t> <front>
<title>Interpreting ITU-T Y.1540 maximum IP-layer capacity measureme
nts</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/techn
ical/download/TR-471.pdf">
<front>
<title>Maximum IP-Layer Capacity Metric, Related Metrics, and Measur
ements</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/liais
on/1645/">
<front>
<title>Liaison statement: LS on harmonization of IP Capacity and Lat
ency Parameters: Consent of Draft Rec. Y.1540 on IP packet transfer performance
parameters and 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/liais
on/1632/">
<front>
<title>Liaison statement: LS - Harmonization of IP Capacity and Late
ncy 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="defaul
t">
<name>Load Rate Adjustment Pseudocode</name>
<t>This appendix provides a pseudocode implementation of the algorithm
described in <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 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), msec
lowThresh = 30 # Low threshold on the Range of RTD, msec
upperThresh = 90 # Upper threshold on the Range of RTD, msec
hSpeedThresh = 1 # Threshold for transition between sending rate
# step sizes (such as 1 Mbps and 100 Mbps), Gbps
slowAdjCount = 0 # Measured Number of consecutive status reports
# indicating loss and/or delay variation above
# upperThresh
slowAdjThresh = 3 # Threshold on slowAdjCount used to infer
# congestion. Use values > 1 to avoid
# misinterpreting transient loss.
highSpeedDelta = 10 # The number of rows to move in a single
# adjustment when initially increasing offered
# load (to ramp up quickly)
<t><figure>
<artwork><![CDATA[Rx = 0 # The current sending rate (equivalent to a
row of the table)
seqErr = 0 # Measured count of any of Loss or Reordering impairments
delay = 0 # Measured Range of Round Trip Delay, RTD, ms
lowThresh = 30 # Low threshold on the Range of RTD, ms
upperThresh = 90 # Upper threshold on the Range of RTD, ms
hSpeedTresh = 1 Gbps # Threshold for transition between sending rate step
sizes (such as 1 Mbps and 100 Mbps)
slowAdjCount = 0 # Measured Number of consecutive status reports
indicating loss and/or delay variation above upperThresh
slowAdjThresh = 2 # Threshold on slowAdjCount used to infer congestion.
Use values >1 to avoid misinterpreting transient loss
highSpeedDelta = 10 # The number of rows to move in a single adjustment
when initially increasing offered load (to ramp-up quickly)
maxLoadRates = 2000 # Maximum table index (rows) maxLoadRates = 2000 # Maximum table index (rows)
if ( seqErr == 0 && delay < lowThresh ) { if ( seqErr <= seqErrThresh && delay < lowThresh ) {
if ( Rx < hSpeedTresh && slowAdjCount < slowAdjThresh ) { if ( Rx < hSpeedThresh && slowAdjCount < slowAdjThresh ) {
Rx += highSpeedDelta; Rx += highSpeedDelta;
slowAdjCount = 0; slowAdjCount = 0;
} else { } else {
if ( Rx < maxLoadRates - 1 ) if ( Rx < maxLoadRates - 1 )
Rx++; Rx++;
} }
} else if ( seqErr > 0 || delay > upperThresh ) { } else if ( seqErr > seqErrThresh || delay > upperThresh ) {
slowAdjCount++; slowAdjCount++;
if ( Rx < hSpeedTresh && slowAdjCount == slowAdjThresh ) { if ( Rx < hSpeedThresh && slowAdjCount == slowAdjThresh ) {
if ( Rx > highSpeedDelta * 3 ) if ( Rx > highSpeedDelta * 3 )
Rx -= highSpeedDelta * 3; Rx -= highSpeedDelta * 3;
else else
Rx = 0; Rx = 0;
} else { } else {
if ( Rx > 0 ) if ( Rx > 0 )
Rx--; Rx--;
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t>
<t/>
</section> </section>
<section anchor="app-b-rfc8085-udp" numbered="true" toc="default">
<section title="Appendix B - RFC 8085 UDP Guidelines Check"> <name>RFC 8085 UDP Guidelines Check</name>
<t>The BCP on UDP usage guidelines <xref target="RFC8085"/> focuses <t><xref target="RFC8085" sectionFormat="of" section="3.1"/>
primarily on congestion control in section 3.1. The Guidelines appear in (BCP 145), which provides UDP usage guidelines, focuses
mandatory (MUST) and recommendation (SHOULD) categories.</t> primarily on congestion control. The guidelines appear in
mandatory (<bcp14>MUST</bcp14>) and recommendation (<bcp14>SHOULD</bcp14>)
<section title="Assessment of Mandatory Requirements"> categories.</t>
<t>The mandatory requirements in Section 3 of <xref target="RFC8085"/> <section numbered="true" toc="default">
include:<list style="hanging"> <name>Assessment of Mandatory Requirements</name>
<t>Internet paths can have widely varying characteristics, ... <t>The mandatory requirements in <xref target="RFC8085" sectionFormat="o
Consequently, applications that may be used on the Internet MUST f" section="3"/>
NOT make assumptions about specific path characteristics. They include the following:</t>
MUST instead use mechanisms that let them operate safely under <blockquote>Internet paths can have widely varying characteristics, ..
.
Consequently, applications that may be used on the Internet <bcp14>M
UST
NOT</bcp14> make assumptions about specific path characteristics. Th
ey
<bcp14>MUST</bcp14> instead use mechanisms that let them operate saf
ely under
very different path conditions. Typically, this requires very different path conditions. Typically, this requires
conservatively probing the current conditions of the Internet path conservatively probing the current conditions of the Internet path
they communicate over to establish a transmission behavior that it they communicate over to establish a transmission behavior that it
can sustain and that is reasonably fair to other traffic sharing can sustain and that is reasonably fair to other traffic sharing
the path.</t> the path.</blockquote>
</list></t> <t>The purpose of the load rate adjustment algorithm described in <xref
target="load-rate-adj"/> is
<t>The purpose of the load rate adjustment algorithm in Section 8.1 is
to probe the network and enable Maximum IP-Layer Capacity measurements to probe the network and enable Maximum IP-Layer Capacity measurements
with as few assumptions about the measured path as possible, and with as few assumptions about the measured path as possible and
within the range application described in Section 2. The degree of within the range of applications described in <xref target="sec-2-scope"
probing conservatism is in tension with the need to minimize both the />.
traffic dedicated to testing (especially with Gigabit rate There is tension between the goals of probing conservatism and
measurements) and the duration of the test (which is one contributing minimization of both the traffic dedicated to testing (especially with
Gigabit rate measurements) and the duration of the test (which is one co
ntributing
factor to the overall algorithm fairness).</t> factor to the overall algorithm fairness).</t>
<t>The text of <xref target="RFC8085" sectionFormat="of" section="3"/>
<t>The text of Section 3 of <xref target="RFC8085"/> goes on to goes on to
recommend alternatives to UDP to meet the mandatory requirements, but recommend alternatives to UDP to meet the mandatory requirements, but
none are suitable for the scope and purpose of the metrics and methods none are suitable for the scope and purpose of the Metrics and Methods
in this memo. In fact, ad hoc TCP-based methods fail to achieve the in this memo. In fact, ad hoc TCP-based methods fail to achieve the
measurement accuracy repeatedly proven in comparison measurements with measurement accuracy repeatedly proven in comparison measurements with
the running code <xref target="LS-SG12-A"/> <xref target="LS-SG12-B"/> the running code <xref target="LS-SG12-A" format="default"/> <xref targe
<xref target="Y.Sup60"/>. Also, the UDP aspect of these methods is t="LS-SG12-B" format="default"/>
<xref target="Y.Sup60" format="default"/>. Also, the UDP aspect of the
se methods is
present primarily to support modern Internet transmission where a present primarily to support modern Internet transmission where a
transport protocol is required <xref target="copycat"/>; the metric is transport protocol is required <xref target="copycat" format="default"/>
based on the IP-Layer and UDP allows simple correlation to the ; the metric is
IP-Layer.</t> based on the IP Layer, and UDP allows simple correlation to the
IP Layer.</t>
<t>Section 3.1.1 of <xref target="RFC8085"/> discusses protocol timer <t><xref target="RFC8085" sectionFormat="of" section="3.1.1"/> discusses
protocol timer
guidelines:</t> guidelines:</t>
<blockquote>Latency samples <bcp14>MUST NOT</bcp14> be derived from am
<t><list style="hanging"> biguous
<t>Latency samples MUST NOT be derived from ambiguous
transactions. The canonical example is in a protocol that transactions. The canonical example is in a protocol that
retransmits data, but subsequently cannot determine which copy is retransmits data, but subsequently cannot determine which copy is
being acknowledged.</t> being acknowledged.</blockquote>
</list>Both load packets and status feedback messages MUST contain <t>Both load packets and status feedback messages <bcp14>MUST</bcp14> co
sequence numbers, which helps with measurements based on those ntain
packets, and there are no retransmissions needed.<list style="hanging"> sequence numbers; this helps with measurements based on those
<t>When a latency estimate is used to arm a timer that provides packets, and there are no retransmissions needed.</t>
<blockquote>When a latency estimate is used to arm a timer that provid
es
loss detection -- with or without retransmission -- expiry of the loss detection -- with or without retransmission -- expiry of the
timer MUST be interpreted as an indication of congestion in the timer <bcp14>MUST</bcp14> be interpreted as an indication of congest ion in the
network, causing the sending rate to be adapted to a safe network, causing the sending rate to be adapted to a safe
conservative rate...</t> conservative rate ...</blockquote>
</list></t> <t>The methods described in this memo use timers for sending rate
<t>The method described in this memo uses timers for sending rate
backoff when status feedback messages are lost (Lost Status Backoff backoff when status feedback messages are lost (Lost Status Backoff
timeout), and for stopping a test when connectivity is lost for a timeout) and for stopping a test when connectivity is lost for a
longer interval (Feedback message or load packet timeouts).</t> longer interval (feedback message or load packet timeouts).</t>
<t>This memo does not foresee any specific benefit of using Explicit Con
<t>There is no specific benefit foreseen by using Explicit Congestion gestion
Notification (ECN) in this memo.</t> Notification (ECN).</t>
<t><xref target="RFC8085" sectionFormat="of" section="3.2"/> discusses m
<t>Section 3.2 of <xref target="RFC8085"/> discusses message size essage size
guidelines:<list style="hanging"> guidelines:</t>
<t>To determine an appropriate UDP payload size, applications MUST <blockquote>To determine an appropriate UDP payload size, applications
<bcp14>MUST</bcp14>
subtract the size of the IP header (which includes any IPv4 subtract the size of the IP header (which includes any IPv4
optional headers or IPv6 extension headers) as well as the length optional headers or IPv6 extension headers) as well as the length
of the UDP header (8 bytes) from the PMTU size.</t> of the UDP header (8 bytes) from the PMTU size.</blockquote>
</list></t>
<t>The method uses a sending rate table with a maximum UDP payload <t>The method uses a sending rate table with a maximum UDP payload
size that anticipates significant header overhead and avoids size that anticipates significant header overhead and avoids
fragmentation.</t> fragmentation.</t>
<t><xref target="RFC8085" sectionFormat="of" section="3.3"/> provides re
<t>Section 3.3 of <xref target="RFC8085"/> provides reliability liability
guidelines:<list style="hanging"> guidelines:</t>
<t>Applications that do require reliable message delivery MUST <blockquote>Applications that do require reliable message delivery <bc
implement an appropriate mechanism themselves.</t> p14>MUST</bcp14>
</list></t> implement an appropriate mechanism themselves.</blockquote>
<t>The IP-Layer Capacity Metrics and Methods do not require reliable
<t>The IP-Layer Capacity Metric and Method do not require reliable delivery.</t>
delivery.<list style="hanging"> <blockquote>Applications that require ordered delivery <bcp14>MUST</bc
<t>Applications that require ordered delivery MUST reestablish p14> reestablish
datagram ordering themselves.</t> datagram ordering themselves.</blockquote>
</list></t> <t>The IP-Layer Capacity Metrics and Methods do not need to
reestablish packet order; it is preferable to measure packet reordering
<t>The IP-Layer Capacity Metric and Method does not need to if it occurs <xref target="RFC4737" format="default"/>.</t>
reestablish packet order; it is preferred to measure packet reordering
if it occurs <xref target="RFC4737"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Assessment of Recommendations"> <name>Assessment of Recommendations</name>
<t>The load rate adjustment algorithm's goal is to determine the <t>The load rate adjustment algorithm's goal is to determine the
Maximum IP-Layer Capacity in the context of an infrequent, diagnostic, Maximum IP-Layer Capacity in the context of an infrequent, diagnostic,
short term measurement. This goal is a global exception to many <xref short-term measurement. This goal is a global exception to many <bcp14>S
target="RFC8085"/> SHOULD-level requirements, of which many are HOULD</bcp14>-level requirements as listed in <xref target="RFC8085" format="def
intended for long-lived flows that must coexist with other traffic in ault"/>, of which many are
more-or-less fair way. However, the algorithm (as specified in Section intended for long-lived flows that must coexist with other traffic in a
8.1 and Appendix A above) reacts to indications of congestion in more or less fair way. However, the algorithm (as specified in
<xref target="load-rate-adj"/> and <xref target="app-a-load-rate-adj-pse
udocode"/> above) reacts to indications of congestion in
clearly defined ways.</t> clearly defined ways.</t>
<t>A specific recommendation is provided as an example. <xref target="RF
<t>A specific recommendation is provided as an example. Section 3.1.5 C8085" sectionFormat="of" section="3.1.5"/> (regarding the implications of RTT a
of <xref target="RFC8085"/> on implications of RTT and Loss nd loss measurements on congestion control) says:</t>
Measurements on Congestion Control says:<list style="hanging"> <blockquote>A congestion control [algorithm] designed for UDP <bcp14>S
<t>A congestion control designed for UDP SHOULD respond as quickly HOULD</bcp14> respond as quickly
as possible when it experiences congestion, and it SHOULD take as possible when it experiences congestion, and it <bcp14>SHOULD</bc
p14> take
into account both the loss rate and the response time when into account both the loss rate and the response time when
choosing a new rate.</t> choosing a new rate.</blockquote>
</list></t>
<t>The load rate adjustment algorithm responds to loss and RTT <t>The load rate adjustment algorithm responds to loss and RTT
measurements with a clear and concise rate reduction when warranted, measurements with a clear and concise rate reduction when warranted,
and the response makes use of direct measurements (more exact than can and the response makes use of direct measurements (more exact than can
be inferred from TCP ACKs).</t> be inferred from TCP ACKs).</t>
<t><xref target="RFC8085" sectionFormat="of" section="3.1.5"/> goes on t
<t>Section 3.1.5 of <xref target="RFC8085"/> goes on to specify:<list o specify the following:</t>
style="hanging"> <blockquote>The implemented congestion control scheme <bcp14>SHOULD</b
<t>The implemented congestion control scheme SHOULD result in cp14> result in
bandwidth (capacity) use that is comparable to that of TCP within bandwidth (capacity) use that is comparable to that of TCP within
an order of magnitude, so that it does not starve other flows an order of magnitude, so that it does not starve other flows
sharing a common bottleneck.</t> sharing a common bottleneck.</blockquote>
</list></t>
<t>This is a requirement for coexistent streams, and not for <t>This is a requirement for coexistent streams, and not for
diagnostic and infrequent measurements using short durations. The rate diagnostic and infrequent measurements using short durations. The rate
oscillations during short tests allow other packets to pass, and oscillations during short tests allow other packets to pass and
don&rsquo;t starve other flows.</t> don't starve other flows.</t>
<t>Ironically, ad hoc TCP-based measurements of "Internet Speed" are <t>Ironically, ad hoc TCP-based measurements of "Internet Speed" are
also designed to work around this SHOULD-level requirement, by also designed to work around this <bcp14>SHOULD</bcp14>-level requiremen t, by
launching many flows (9, for example) to increase the outstanding data launching many flows (9, for example) to increase the outstanding data
dedicated to testing.</t> dedicated to testing.</t>
<t>The load rate adjustment algorithm cannot become a TCP-like <t>The load rate adjustment algorithm cannot become a TCP-like
congestion control, or it will have the same weaknesses of TCP when congestion control, or it will have the same weaknesses of TCP when
trying to make a Maximum IP-Layer Capacity measurement, and will not trying to make a Maximum IP-Layer Capacity measurement and will not
achieve the goal. The results of the referenced testing <xref achieve the goal. The results of the referenced testing <xref target="LS
target="LS-SG12-A"/> <xref target="LS-SG12-B"/> <xref -SG12-A" format="default"/> <xref target="LS-SG12-B" format="default"/> <xref ta
target="Y.Sup60"/> supported this statement hundreds of times, with rget="Y.Sup60" format="default"/> supported this statement hundreds of times, wi
th
comparisons to multi-connection TCP-based measurements.</t> comparisons to multi-connection TCP-based measurements.</t>
<t>A brief review of requirements from <xref target="RFC8085"/> follows (marked "Yes" when this memo is compliant, or "NA" (Not Applicable)):</t>
<t>A brief review of some other SHOULD-level requirements follows (Yes <table anchor="recs-rfc8085">
or Not applicable = NA) :<figure> <name>Summary of Key Guidelines from RFC 8085</name>
<artwork><![CDATA[+--+---------------------------------------------- <thead>
-----------+---------+ <tr>
|Y?| RFC 8085 Recommendation | Section | <th>Yes?</th>
+--+---------------------------------------------------------+---------+ <th>Recommendation in RFC 8085</th>
Yes| MUST tolerate a wide range of Internet path conditions | 3 | <th>Section</th>
NA | SHOULD use a full-featured transport (e.g., TCP) | | </tr>
| | | </thead>
Yes| SHOULD control rate of transmission | 3.1 | <tbody>
NA | SHOULD perform congestion control over all traffic | | <tr>
| | | <td>Yes</td>
| for bulk transfers, | 3.1.2 | <td><bcp14>MUST</bcp14> tolerate a wide range of Internet path conditions<
NA | SHOULD consider implementing TFRC | | /td>
NA | else, SHOULD in other ways use bandwidth similar to TCP | | <td><xref target="RFC8085" section="3" sectionFormat="bare"/></td>
| | | </tr>
| for non-bulk transfers, | 3.1.3 | <tr>
NA | SHOULD measure RTT and transmit max. 1 datagram/RTT | 3.1.1 | <td>NA</td>
NA | else, SHOULD send at most 1 datagram every 3 seconds | | <td><bcp14>SHOULD</bcp14> use a full-featured transport (e.g., TCP)</td>
NA | SHOULD back-off retransmission timers following loss | | <td></td>
| | | </tr>
Yes| SHOULD provide mechanisms to regulate the bursts of | 3.1.6 | <tr>
| transmission | | <td colspan="3"></td>
| | | </tr>
NA | MAY implement ECN; a specific set of application | 3.1.7 | <tr>
| mechanisms are REQUIRED if ECN is used. | | <td>Yes</td>
| | | <td><bcp14>SHOULD</bcp14> control rate of transmission</td>
Yes| for DiffServ, SHOULD NOT rely on implementation of PHBs | 3.1.8 | <td><xref target="RFC8085" section="3.1" sectionFormat="bare"/></td>
| | | </tr>
Yes| for QoS-enabled paths, MAY choose not to use CC | 3.1.9 | <tr>
| | | <td>NA</td>
Yes| SHOULD NOT rely solely on QoS for their capacity | 3.1.10 | <td><bcp14>SHOULD</bcp14> perform congestion control over all traffic</td>
| non-CC controlled flows SHOULD implement a transport | | <td></td>
| circuit breaker | | </tr>
| MAY implement a circuit breaker for other applications | | <tr>
| | | <td colspan="3"></td>
| for tunnels carrying IP traffic, | 3.1.11 | </tr>
NA | SHOULD NOT perform congestion control | | <tr>
NA | MUST correctly process the IP ECN field | | <th></th>
| | | <th>For bulk transfers,</th>
| for non-IP tunnels or rate not determined by traffic, | | <th><xref target="RFC8085" section="3.1.2" sectionFormat="bare"/></th>
NA | SHOULD perform CC or use circuit breaker | 3.1.11 | </tr>
NA | SHOULD restrict types of traffic transported by the | | <tr>
| tunnel | | <td>NA</td>
| | | <td><bcp14>SHOULD</bcp14> consider implementing TFRC</td>
Yes| SHOULD NOT send datagrams that exceed the PMTU, i.e., | 3.2 | <td></td>
Yes| SHOULD discover PMTU or send datagrams < minimum PMTU; | | </tr>
NA | Specific application mechanisms are REQUIRED if PLPMTUD | | <tr>
| is used. | | <td>NA</td>
| | | <td>else, <bcp14>SHOULD</bcp14> in other ways use bandwidth similar to TCP
Yes| SHOULD handle datagram loss, duplication, reordering | 3.3 | </td>
NA | SHOULD be robust to delivery delays up to 2 minutes | | <td></td>
| | | </tr>
Yes| SHOULD enable IPv4 UDP checksum | 3.4 | <tr>
Yes| SHOULD enable IPv6 UDP checksum; Specific application | 3.4.1 | <td colspan="3"></td>
| mechanisms are REQUIRED if a zero IPv6 UDP checksum is | | </tr>
| used. | | <tr>
| | | <th></th>
NA | SHOULD provide protection from off-path attacks | 5.1 | <th>For non-bulk transfers,</th>
| else, MAY use UDP-Lite with suitable checksum coverage | 3.4.2 | <th><xref target="RFC8085" section="3.1.3" sectionFormat="bare"/></th>
| | | </tr>
NA | SHOULD NOT always send middlebox keep-alive messages | 3.5 | <tr>
NA | MAY use keep-alives when needed (min. interval 15 sec) | | <td>NA</td>
| | | <td><bcp14>SHOULD</bcp14> measure RTT and transmit max. 1 datagram/RTT</td
Yes| Applications specified for use in limited use (or | 3.6 | >
| controlled environments) SHOULD identify equivalent | | <td><xref target="RFC8085" section="3.1.1" sectionFormat="bare"/></td>
| mechanisms and describe their use case. | | </tr>
| | | <tr>
NA | Bulk-multicast apps SHOULD implement congestion control | 4.1.1 | <td>NA</td>
| | | <td>else, <bcp14>SHOULD</bcp14> send at most 1 datagram every 3 seconds</t
NA | Low volume multicast apps SHOULD implement congestion | 4.1.2 | d>
| control | | <td></td>
| | | </tr>
NA | Multicast apps SHOULD use a safe PMTU | 4.2 | <tr>
| | | <td>NA</td>
Yes| SHOULD avoid using multiple ports | 5.1.2 | <td><bcp14>SHOULD</bcp14> back-off retransmission timers following loss</t
Yes| MUST check received IP source address | | d>
| | | <td></td>
NA | SHOULD validate payload in ICMP messages | 5.2 | </tr>
| | | <tr>
Yes| SHOULD use a randomized source port or equivalent | 6 | <td colspan="3"></td>
| technique, and, for client/server applications, SHOULD | | </tr>
| send responses from source address matching request | | <tr>
| 5.1 | | <td>Yes</td>
NA | SHOULD use standard IETF security protocols when needed | 6 | <td><bcp14>SHOULD</bcp14> provide mechanisms to regulate the bursts of tra
+---------------------------------------------------------+---------+]]></art nsmission</td>
work> <td><xref target="RFC8085" section="3.1.6" sectionFormat="bare"/></td>
</figure></t> </tr>
<tr>
<t/> <td colspan="3"></td>
</tr>
<t/> <tr>
<td>NA</td>
<td><bcp14>MAY</bcp14> implement ECN; a specific set of application mechan
isms are <bcp14>REQUIRED</bcp14> if ECN is 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, <bcp14>SHOULD NOT</bcp14> rely on implementation of 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, <bcp14>MAY</bcp14> choose not to use 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</td>
<td><xref target="RFC8085" section="3.1.10" sectionFormat="bare"/></td>
</tr>
<tr>
<td>NA</td>
<td>non-CC controlled flows <bcp14>SHOULD</bcp14> implement a transport ci
rcuit breaker</td>
<td></td>
</tr>
<tr>
<td>Yes</td>
<td><bcp14>MAY</bcp14> implement a circuit breaker for other applications<
/td>
<td></td>
</tr>
<tr>
<td colspan="3"></td>
</tr>
<tr>
<th></th>
<th>For tunnels carrying IP 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</td>
<td></td>
</tr>
<tr>
<td>NA</td>
<td><bcp14>MUST</bcp14> correctly process the IP ECN 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,</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</td>
<td></td>
</tr>
<tr>
<td>NA</td>
<td><bcp14>SHOULD</bcp14> restrict types of traffic transported by the tun
nel</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.,</
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 PMT
U</td>
<td></td>
</tr>
<tr>
<td>NA</td>
<td>Specific application mechanisms are <bcp14>REQUIRED</bcp14> if PLPMTUD
is used</td>
<td></td>
</tr>
<tr>
<td colspan="3"></td>
</tr>
<tr>
<td>Yes</td>
<td><bcp14>SHOULD</bcp14> handle datagram loss, duplication, reordering</t
d>
<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</td
>
<td></td>
</tr>
<tr>
<td colspan="3"></td>
</tr>
<tr>
<td>Yes</td>
<td><bcp14>SHOULD</bcp14> enable IPv4 UDP 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 application m
echanisms are <bcp14>REQUIRED</bcp14> if a zero IPv6 UDP checksum is 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</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<
/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</t
d>
<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)<
/td>
<td></td>
</tr>
<tr>
<td colspan="3"></td>
</tr>
<tr>
<td>Yes</td>
<td>Applications specified for use in limited use (or controlled environme
nts) <bcp14>SHOULD</bcp14> identify equivalent mechanisms and describe their use
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 <bcp14>SHOULD</bcp14> implement congestion 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 <bcp14>SHOULD</bcp14> implement congestion c
ontrol</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 <bcp14>SHOULD</bcp14> use a safe 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</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</td>
<td></td>
</tr>
<tr>
<td colspan="3"></td>
</tr>
<tr>
<td>NA</td>
<td><bcp14>SHOULD</bcp14> validate payload in ICMP 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 port or equivalent techn
ique, and, for client/server applications, <bcp14>SHOULD</bcp14> send responses
from source address matching 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
</td>
<td><xref target="RFC8085" section="6" sectionFormat="bare"/></td>
</tr>
</tbody>
</table>
</section> </section>
</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-4
71.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 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 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 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 ?> <section numbered="false" toc="default">
</references> <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"/>, <conta
ct fullname="Murray Kucherawy"/>, and <contact fullname="Benjamin Kaduk"/> for t
heir extensive comments on this memo
and related topics. In a second round of reviews, we acknowledge <contact
fullname="Magnus Westerlund"/>, <contact fullname="Lars Eggert"/>, and <contact
fullname="Zaheduzzaman Sarker"/>.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 252 change blocks. 
1477 lines changed or deleted 1678 lines changed or added

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