< draft-ietf-ippm-capacity-metric-method-05.txt   draft-ietf-ippm-capacity-metric-method-12.txt >
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Standards Track R. Geib Intended status: Standards Track R. Geib
Expires: August 5, 2021 Deutsche Telekom Expires: December 11, 2021 Deutsche Telekom
L. Ciavattone L. Ciavattone
AT&T Labs AT&T Labs
February 1, 2021 June 9, 2021
Metrics and Methods for One-way IP Capacity Metrics and Methods for One-way IP Capacity
draft-ietf-ippm-capacity-metric-method-05 draft-ietf-ippm-capacity-metric-method-12
Abstract Abstract
This memo revisits the problem of Network Capacity metrics first 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. The memo specifies a more practical Maximum
IP-layer Capacity metric definition catering for measurement IP-Layer Capacity metric definition catering for measurement
purposes, and outlines the corresponding methods of measurement. purposes, and outlines the corresponding methods of measurement.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 5, 2021. This Internet-Draft will expire on December 11, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Scope and Goals . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope, Goals, and Applicability . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. General Parameters and Definitions . . . . . . . . . . . . . 5 4. General Parameters and Definitions . . . . . . . . . . . . . 6
5. IP-Layer Capacity Singleton Metric Definitions . . . . . . . 6 5. IP-Layer Capacity Singleton Metric Definitions . . . . . . . 8
5.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 6 5.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 8
5.4. Related Round-Trip Delay and One-way Loss Definitions . . 8 5.4. Related Round-Trip Delay and One-way Loss Definitions . . 9
5.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 5.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 10
5.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 8 5.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 10
6. Maximum IP-Layer Capacity Metric Definitions (Statistic) . . 9 6. Maximum IP-Layer Capacity Metric Definitions (Statistic) . . 10
6.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 9 6.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 11
6.4. Related Round-Trip Delay and One-way Loss Definitions . . 11 6.4. Related Round-Trip Delay and One-way Loss Definitions . . 13
6.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 11 6.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 13
6.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 11 6.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 13
7. IP-Layer Sender Bit Rate Singleton Metric Definitions . . . . 12 7. IP-Layer Sender Bit Rate Singleton Metric Definitions . . . . 14
7.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 14
7.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 13 7.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 15
7.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 13 7.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 15
7.5. Reporting the Metric . . . . . . . . . . . . . . . . . . 13 7.5. Reporting the Metric . . . . . . . . . . . . . . . . . . 15
8. Method of Measurement . . . . . . . . . . . . . . . . . . . . 13 8. Method of Measurement . . . . . . . . . . . . . . . . . . . . 15
8.1. Load Rate Adjustment Algorithm . . . . . . . . . . . . . 13 8.1. Load Rate Adjustment Algorithm . . . . . . . . . . . . . 16
8.2. Measurement Qualification or Verification . . . . . . . . 15 8.2. Measurement Qualification or Verification . . . . . . . . 21
8.3. Measurement Considerations . . . . . . . . . . . . . . . 16 8.3. Measurement Considerations . . . . . . . . . . . . . . . 22
8.4. Running Code . . . . . . . . . . . . . . . . . . . . . . 18 8.4. Running Code . . . . . . . . . . . . . . . . . . . . . . 24
9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 18 9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Configuration and Reporting Data Formats . . . . . . . . 20 9.1. Configuration and Reporting Data Formats . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
13. Appendix - Load Rate Adjustment Pseudo Code . . . . . . . . . 22 13. Appendix A - Load Rate Adjustment Pseudo Code . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 14. Appendix B - RFC 8085 UDP Guidelines Check . . . . . . . . . 29
14.1. Normative References . . . . . . . . . . . . . . . . . . 23 14.1. Assessment of Mandatory Requirements . . . . . . . . . . 29
14.2. Informative References . . . . . . . . . . . . . . . . . 24 14.2. Assessment of Recommendations . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
15.1. Normative References . . . . . . . . . . . . . . . . . . 34
15.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
The IETF's efforts to define Network and Bulk Transport Capacity have The IETF's efforts to define Network and Bulk Transport Capacity have
been chartered and progressed for over twenty years. Over that time, been chartered and progressed for over twenty years. Over that time,
the performance community has seen development of Informative the performance community has seen development of Informative
definitions in [RFC3148] for Framework for Bulk Transport Capacity definitions in [RFC3148] for Framework for Bulk Transport Capacity
(BTC), RFC 5136 for Network Capacity and Maximum IP-layer Capacity, (BTC), RFC 5136 for Network Capacity and Maximum IP-Layer Capacity,
and the Experimental metric definitions and methods in [RFC8337], and the Experimental metric definitions and methods in [RFC8337],
Model-Based Metrics for BTC. Model-Based Metrics for BTC.
This memo revisits the problem of Network Capacity metrics examined This memo revisits the problem of Network Capacity metrics examined
first in [RFC3148] and later in [RFC5136]. Maximum IP-Layer Capacity first in [RFC3148] and later in [RFC5136]. Maximum IP-Layer Capacity
and [RFC3148] Bulk Transfer Capacity (goodput) are different metrics. and [RFC3148] Bulk Transfer Capacity (goodput) are different metrics.
Maximum IP-layer Capacity is like the theoretical goal for goodput. Maximum IP-Layer Capacity is like the theoretical goal for goodput.
There are many metrics in [RFC5136], such as Available Capacity. There are many metrics in [RFC5136], such as Available Capacity.
Measurements depend on the network path under test and the use case. Measurements depend on the network path under test and the use case.
Here, the main use case is to assess the maximum capacity of the Here, the main use case is to assess the maximum capacity of one or
access network, with specific performance criteria used in the more networks where the subscriber receives specific performance
measurement. assurances, sometimes referred to as the Internet access, or where a
limit of the technology used on a path is being tested. For example,
when a user subscribes to a 1 Gbps service, then the user, the
service provider, and possibly other parties want to assure that
performance level is delivered. When a test confirms the subscribed
performance level, then a tester can seek the location of a
bottleneck elsewhere.
This memo recognizes the importance of a definition of a Maximum IP- This memo recognizes the importance of a definition of a Maximum IP-
layer Capacity Metric at a time when access speeds have increased Layer Capacity Metric at a time when Internet subscription speeds
dramatically; a definition that is both practical and effective for have increased dramatically; a definition that is both practical and
the performance community's needs, including Internet users. The effective for the performance community's needs, including Internet
metric definition is intended to use Active Methods of Measurement users. The metric definition is intended to use Active Methods of
[RFC7799], and a method of measurement is included. Measurement [RFC7799], and a method of measurement is included.
The most direct active measurement of IP-layer Capacity would use IP 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 [copycat] measurement study to investigate possibility, and in the [copycat] measurement study to investigate
whether UDP is viable as a general Internet transport protocol, the whether UDP is viable as a general Internet transport protocol, the
authors found that a high percentage of paths tested support UDP authors found that a high percentage of paths tested support UDP
transport. A number of liaisons have been exchanged on this topic transport. A number of liaisons have been exchanged on this topic
[LS-SG12-A] [LS-SG12-B], discussing the laboratory and field tests [LS-SG12-A] [LS-SG12-B], discussing the laboratory and field tests
that support the UDP-based approach to IP-layer Capacity measurement. that support the UDP-based approach to IP-Layer Capacity measurement.
This memo also recognizes the many updates to the IP Performance This memo also recognizes the many updates to the IP Performance
Metrics Framework [RFC2330] published over twenty years, and makes Metrics Framework [RFC2330] published over twenty years, and makes
use of [RFC7312] for Advanced Stream and Sampling Framework, and use of [RFC7312] for Advanced Stream and Sampling Framework, and
[RFC8468] with IPv4, IPv6, and IPv4-IPv6 Coexistence Updates. [RFC8468] with IPv4, IPv6, and IPv4-IPv6 Coexistence Updates.
Appendix A describes the load rate adjustment algorithm in pseudo-
code. Appendix B discusses the algorithm's compliance with
[RFC8085].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14[RFC2119] [RFC8174] when, and only when, they appear in all 14[RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Scope and Goals 2. Scope, Goals, and Applicability
The scope of this memo is to define a metric and corresponding method The scope of this memo is to define Active Measurement metrics and
to unambiguously perform Active measurements of Maximum IP-Layer corresponding methods to unambiguously determine Maximum IP-Layer
Capacity, along with related metrics and methods. Capacity and useful secondary metrics.
The main goal is to harmonize the specified metric and method across Another goal is to harmonize the specified metric and method across
the industry, and this memo is the vehicle through which working the industry, and this memo is the vehicle that captures IETF
group (and eventually, IETF) consensus will be captured and consensus, possibly resulting in changes to the specifications of
communicated to achieve broad agreement, and possibly result in other Standards Development Organizations (SDO) (through each SDO's
changes in the specifications of other Standards Development normal contribution process, or through liaison exchange).
Organizations (SDO) (through the SDO's normal contribution process,
or through liaison exchange).
A local goal is to aid efficient test procedures where possible, and Secondary goals are to add considerations for test procedures, and to
to recommend reporting with additional interpretation of the results. provide interpretation of the Maximum IP-Layer Capacity results (to
Also, to foster the development of protocol support for this metric identify cases where more testing is warranted, possibly with
and method of measurement (all active testing protocols currently alternate configurations). Fostering the development of protocol
defined by the IPPM WG are UDP-based, meeting a key requirement of support for this metric and method of measurement is also a goal of
these methods). The supporting protocol development to measure this this memo (all active testing protocols currently defined by the IPPM
metric according to the specified method is a key future contribution WG are UDP-based, meeting a key requirement of these methods). The
to Internet measurement. supporting protocol development to measure this metric according to
the specified method is a key future contribution to Internet
measurement.
The load rate adjustment algorithm's scope is limited to helping
determine the Maximum IP-Layer Capacity in the context of an
infrequent, diagnostic, short term measurement. It is RECOMMENDED to
discontinue non-measurement traffic that shares a subscriber's
dedicated resources while testing: measurements may not be accurate
and throughput of competing elastic traffic may be greatly reduced.
The primary application of the metric and method of measurement
described here is the same as in Section 2 of [RFC7497] where:
o The access portion of the network is the focus of this problem
statement. The user typically subscribes to a service with
bidirectional Internet access partly described by rates in bits
per second.
In addition, the use of the load rate adjustment algorithm described
in section 8.1 has the following additional applicability
limitations:
- MUST only be used in the application of diagnostic and operations
measurements as described in this memo
- MUST only be used in circumstances consistent with Section 10,
Security Considerations
- If a network operator is certain of the IP-layer capacity to be
validated, then testing MAY start with a fixed rate test at the IP-
layer capacity and avoid activating the load adjustment algorithm.
However, the stimulus for a diagnostic test (such as a subscriber
request) strongly implies that there is no certainty and the load
adjustment algorithm is RECOMMENDED.
Further, the metric and method of measurement are intended for use
where specific exact path information is unknown within a range of
possible values:
- the subscriber's exact Maximum IP-Layer Capacity is unknown (which
is sometimes the case; service rates can be increased due to upgrades
without a subscriber's request, or to provide a surplus to compensate
for possible underestimates of TCP-based testing).
- the size of the bottleneck buffer is unknown.
Finally, the measurement system's load rate adjustment algorithm
SHALL NOT be provided with the exact capacity value to be validated a
priori. This restriction fosters a fair result, and removes an
opportunity for bad actors to operate with knowledge of the "right
answer".
3. Motivation 3. Motivation
As with any problem that has been worked for many years in various As with any problem that has been worked for many years in various
SDOs without any special attempts at coordination, various solutions SDOs without any special attempts at coordination, various solutions
for metrics and methods have emerged. for metrics and methods have emerged.
There are five factors that have changed (or begun to change) in the 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: changes:
1. Internet access is no longer the bottleneck for many users. 1. Internet access is no longer the bottleneck for many users (but
subscribers expect network providers to honor contracted
performance).
2. Both transfer rate and latency are important to user's 2. Both transfer rate and latency are important to user's
satisfaction. satisfaction.
3. UDP's growing role in Transport, in areas where TCP once 3. UDP's growing role in Transport, in areas where TCP once
dominated. dominated.
4. Content and applications moving physically closer to users. 4. Content and applications are moving physically closer to users.
5. Less emphasis on ISP gateway measurements, possibly due to less 5. There is less emphasis on ISP gateway measurements, possibly due
traffic crossing ISP gateways in future. to less traffic crossing ISP gateways in the future.
4. General Parameters and Definitions 4. General Parameters and Definitions
This section lists the REQUIRED input factors to specify a Sender or This section lists the REQUIRED input factors to specify a Sender or
Receiver metric. Receiver metric.
o Src, the address of a host (such as the globally routable IP o Src, one of the addresses of a host (such as a globally routable
address). IP address).
o Dst, the address of a host (such as the globally routable IP o Dst, one of the addresses of a host (such as a globally routable
address). IP address).
o MaxHops, the limit on the number of Hops a specific packet may o MaxHops, the limit on the number of Hops a specific packet may
visit as it traverses from the host at Src to the host at Dst visit as it traverses from the host at Src to the host at Dst
(implemented in the TTL or Hop Limit). (implemented in the TTL or Hop Limit).
o T, the time at the start of measurement interval, when packets are o T0, the time at the start of measurement interval, when packets
first transmitted from the Source. are first transmitted from the Source.
o I, the nominal duration of a measurement interval at the o I, the nominal duration of a measurement interval at the
destination (default 10 sec) destination (default 10 sec)
o dt, the nominal duration of m equal sub-intervals in I at the o dt, the nominal duration of m equal sub-intervals in I at the
destination (default 1 sec) destination (default 1 sec)
o dtn, a specific sub-interval, n, one of m sub-intervals in I o dtn, the beginning boundary of a specific sub-interval, n, one of
m sub-intervals in I
o FT, the feedback time interval between status feedback messages
communicating measurement results, sent from the receiver to
control the sender. The results are evaluated throughout the test
to determine how to adjust the current offered load rate at the
sender (default 50ms)
o Tmax, a maximum waiting time for test packets to arrive at the o Tmax, a maximum waiting time for test packets to arrive at the
destination, set sufficiently long to disambiguate packets with destination, set sufficiently long to disambiguate packets with
long delays from packets that are discarded (lost), such that the long delays from packets that are discarded (lost), such that the
distribution of one-way delay is not truncated. distribution of one-way delay is not truncated.
o F, the number of different flows synthesized by the method o F, the number of different flows synthesized by the method
(default 1 flow) (default 1 flow)
o flow, the stream of packets with the same n-tuple of designated o 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 multi-path decision (such as the decision taken in
load balancing). Note: The IPv6 flow label MAY be included in the load balancing). Note: The IPv6 flow label SHOULD be included in
flow definition when routers have complied with [RFC6438] the flow definition when routers have complied with [RFC6438]
guidelines at the Tunnel End Points (TEP), and the source of the guidelines.
measurement is a TEP.
o Type-P, the complete description of the test packets for which o Type-P, the complete description of the test packets for which
this assessment applies (including the flow-defining fields). this assessment applies (including the flow-defining fields).
Note that the UDP transport layer is one requirement for test Note that the UDP transport layer is one requirement for test
packets specified below. Type-P is a parallel concept to packets specified below. Type-P is a parallel concept to
"population of interest" defined in clause 6.1.1 of[Y.1540]. "population of interest" defined in clause 6.1.1 of[Y.1540].
o Payload Content, this IPPM Framework-conforming metric and method
includes packet payload content as an aspect of the Type-P
parameter, which can help to improve measurement determinism. If
there is payload compression in the path and tests intend to
characterize a possible advantage due to compression, then payload
content SHOULD be supplied by a pseudo-random sequence generator,
by using part of a compressed file, or by other means. See
Section 3.1.2 of [RFC7312].
o PM, a list of fundamental metrics, such as loss, delay, and o PM, a list of fundamental metrics, such as loss, delay, and
reordering, and corresponding target performance threshold. At reordering, and corresponding target performance threshold. At
least one fundamental metric and target performance threshold MUST least one fundamental metric and target performance threshold MUST
be supplied (such as One-way IP Packet Loss [RFC7680] equal to be supplied (such as One-way IP Packet Loss [RFC7680] equal to
zero). zero).
A non-Parameter which is required for several metrics is defined A non-Parameter which is required for several metrics is defined
below: below:
o T, the host time of the *first* test packet's *arrival* as o T, the host time of the *first* test packet's *arrival* as
measured at the destination Measurement Point, or MP(Dst). There measured at the destination Measurement Point, or MP(Dst). There
may be other packets sent between source and destination hosts may be other packets sent between Source and Destination hosts
that are excluded, so this is the time of arrival of the first that are excluded, so this is the time of arrival of the first
packet used for measurement of the metric. packet used for measurement of the metric.
Note that time stamp format and resolution, sequence numbers, etc. Note that time stamp format and resolution, sequence numbers, etc.
will be established by the chosen test protocol standard or will be established by the chosen test protocol standard or
implementation. implementation.
5. IP-Layer Capacity Singleton Metric Definitions 5. IP-Layer Capacity Singleton Metric Definitions
This section sets requirements for the following components to This section sets requirements for the singleton metric that supports
support the Maximum IP-layer Capacity Metric. the Maximum IP-Layer Capacity Metric definition in Section 6.
5.1. Formal Name 5.1. Formal Name
Type-P-One-way-IP-Capacity, or informally called IP-layer Capacity. Type-P-One-way-IP-Capacity, or informally called IP-Layer Capacity.
Note that Type-P depends on the chosen method. Note that Type-P depends on the chosen method.
5.2. Parameters 5.2. Parameters
This section lists the REQUIRED input factors to specify the metric, This section lists the REQUIRED input factors to specify the metric,
beyond those listed in Section 4. beyond those listed in Section 4.
No additional Parameters are needed. No additional Parameters are needed.
5.3. Metric Definitions 5.3. Metric Definitions
This section defines the REQUIRED aspects of the measurable IP-layer This section defines the REQUIRED aspects of the measurable IP-Layer
Capacity metric (unless otherwise indicated) for measurements between Capacity metric (unless otherwise indicated) for measurements between
specified Source and Destination hosts: specified Source and Destination hosts:
Define the IP-layer capacity, C(T,dt,PM), to be the number of IP- Define the IP-Layer Capacity, C(T,dt,PM), to be the number of IP-
layer bits (including header and data fields) in packets that can be Layer bits (including header and data fields) in packets that can be
transmitted from the Src host and correctly received by the Dst host transmitted from the Src host and correctly received by the Dst host
during one contiguous sub-interval, dt in length. The IP-layer during one contiguous sub-interval, dt in length. The IP-Layer
capacity depends on the Src and Dst hosts, the host addresses, and Capacity depends on the Src and Dst hosts, the host addresses, and
the path between the hosts. the path between the hosts.
The number of these IP-layer bits is designated n0[dtn,dtn+1] for a The number of these IP-Layer bits is designated n0[dtn,dtn+1] for a
specific dt. specific dt.
When the packet size is known and of fixed size, the packet count 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]. header and data fields is equal to n0[dtn,dtn+1].
Anticipating a Sample of Singletons, the interval dt SHOULD be set to Anticipating a Sample of Singletons, the number of sub-intervals with
a natural number m so that T+I = T + m*dt with dtn+1 - dtn = dt and duration dt MUST be set to a natural number m, so that T+I = T + m*dt
with 1 <= n <= m. with dtn+1 - dtn = dt for 1 <= n <= m.
Parameter PM represents other performance metrics [see section 5.4 Parameter PM represents other performance metrics [see section 5.4
below]; their measurement results SHALL be collected during below]; their measurement results SHALL 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. Users SHALL corresponding dtn for further evaluation and reporting. Users SHALL
specify the parameter Tmax as required by each metric's reference specify the parameter Tmax as required by each metric's reference
definition. definition.
Mathematically, this definition can be represented as: Mathematically, this definition is represented as (for each n):
( n0[dtn,dtn+1] ) ( n0[dtn,dtn+1] )
C(T,dt,PM) = ------------------------- C(T,dt,PM) = -------------------------
dt dt
Equation for IP-Layer Capacity Equation for IP-Layer Capacity
and: and:
o n0 is the total number of IP-layer header and payload bits that o n0 is the total number of IP-Layer header and payload bits that
can be transmitted in Standard Formed packets [RFC8468] from the can be transmitted in standard-formed packets [RFC8468] from the
Src host and correctly received by the Dst host during one Src host and correctly received by the Dst host during one
contiguous sub-interval, dt in length, during the interval [T, contiguous sub-interval, dt in length, during the interval [T,
T+I], T+I],
o C(T,dt,PM) the IP-Layer Capacity, corresponds to the value of n0 o C(T,dt,PM) the IP-Layer Capacity, corresponds to the value of n0
measured in any sub-interval ending at dtn (meaning T + n*dt), measured in any sub-interval beginning at dtn, divided by the
divided by the length of sub-interval, dt. length of sub-interval, dt.
o PM represents other performance metrics [see section 5.4 below]; o PM represents other performance metrics [see section 5.4 below];
their measurement results SHALL be collected during measurement of their measurement results SHALL be collected during measurement of
IP-layer Capacity and associated with the corresponding dtn for IP-Layer Capacity and associated with the corresponding dtn for
further evaluation and reporting. further evaluation and reporting.
o all sub-intervals MUST be of equal duration. Choosing dt as non- o all sub-intervals MUST be of equal duration. Choosing dt as non-
overlapping consecutive time intervals allows for a simple overlapping consecutive time intervals allows for a simple
implementation. implementation.
o The bit rate of the physical interface of the measurement device o The bit rate of the physical interface of the measurement devices
must be higher than that of the link whose C(T,I,PM) is to be MUST be higher than the smallest of the links on the path whose
measured. C(T,I,PM) is to be measured (the bottleneck link).
Measurements according to these definitions SHALL use the UDP Measurements according to these definitions SHALL use the UDP
transport layer. Standard Formed packets are specified in Section 5 transport layer. Standard-formed packets are specified in Section 5
of [RFC8468]. Some compression affects on measurement are discussed of [RFC8468]. The measurement SHOULD use a randomized Source port or
in Section 6 of [RFC8468], as well. equivalent technique, and SHOULD send responses from the Source
address matching the test packet destination address.
Some compression affects on measurement are discussed in Section 6 of
[RFC8468].
5.4. Related Round-Trip Delay and One-way Loss Definitions 5.4. Related Round-Trip Delay and One-way Loss Definitions
RTD[dtn-1,dtn] is defined as a sample of the [RFC2681] Round-trip RTD[dtn,dtn+1] is defined as a Sample of the [RFC2681] Round-trip
Delay between the Src host and the Dst host over the interval [T,T+I] Delay between the Src host and the Dst host over the interval [T,T+I]
(that contains equal non-overlapping intervals of dt). The (that contains equal non-overlapping intervals of dt). The
"reasonable period of time" in [RFC2681] is the parameter Tmax in "reasonable period of time" in [RFC2681] is the parameter Tmax in
this memo. The statistics used to to summarize RTD[dtn-1,dtn] MAY this memo. The statistics used to summarize RTD[dtn,dtn+1] MAY
include the minimum, maximum, median, and mean, and the range = include the minimum, maximum, median, and mean, and the range =
(maximum - minimum) is referred to below in Section 8.1 for load (maximum - minimum) is referred to below in Section 8.1 for load
adjustment purposes. adjustment purposes.
OWL[dtn-1,dtn] is defined as a sample of the [RFC7680] One-way Loss OWL[dtn,dtn+1] is defined as a Sample of the [RFC7680] One-way Loss
between the Src host and the Dst host over the interval [T,T+I] (that between the Src host and the Dst host over the interval [T,T+I] (that
contains equal non-overlapping intervals of dt). The statistics used contains equal non-overlapping intervals of dt). The statistics used
to to summarize OWL[dtn-1,dtn] MAY include the lost packet count and to summarize OWL[dtn,dtn+1] MAY include the lost packet count and the
the lost packet ratio. lost packet ratio.
Other metrics MAY be measured: one-way reordering, duplication, and Other metrics MAY be measured: one-way reordering, duplication, and
delay variation. delay variation.
5.5. Discussion 5.5. Discussion
See the corresponding section for Maximum IP-Layer Capacity. See the corresponding section for Maximum IP-Layer Capacity.
5.6. Reporting the Metric 5.6. Reporting the Metric
The IP-Layer Capacity SHOULD be reported with at least single Megabit The IP-Layer Capacity SHOULD be reported with at least single Megabit
resolution, in units of Megabits per second (Mbps). resolution, in units of Megabits per second (Mbps), (which is
1,000,000 bits per second to avoid any confusion).
The Related Round Trip Delay and/or Loss metric measurements for the The related One-way Loss metric and Round Trip Delay measurements for
same Singleton SHALL be reported, also with meaningful resolution for the same Singleton SHALL be reported, also with meaningful resolution
the values measured. for the values measured.
Individual Capacity measurements MAY be reported in a manner Individual Capacity measurements MAY be reported in a manner
consistent with the Maximum IP-Layer Capacity, see Section 9. consistent with the Maximum IP-Layer Capacity, see Section 9.
6. Maximum IP-Layer Capacity Metric Definitions (Statistic) 6. Maximum IP-Layer Capacity Metric Definitions (Statistic)
This section sets requirements for the following components to This section sets requirements for the following components to
support the Maximum IP-layer Capacity Metric. support the Maximum IP-Layer Capacity Metric.
6.1. Formal Name 6.1. Formal Name
Type-P-One-way-Max-IP-Capacity, or informally called Maximum IP-layer Type-P-One-way-Max-IP-Capacity, or informally called Maximum IP-Layer
Capacity. Capacity.
Note that Type-P depends on the chosen method. Note that Type-P depends on the chosen method.
6.2. Parameters 6.2. Parameters
This section lists the REQUIRED input factors to specify the metric, This section lists the REQUIRED input factors to specify the metric,
beyond those listed in Section 4. beyond those listed in Section 4.
No additional Parameters or definitions are needed. No additional Parameters or definitions are needed.
6.3. Metric Definitions 6.3. Metric Definitions
This section defines the REQUIRED aspects of the Maximum IP-layer This section defines the REQUIRED aspects of the Maximum IP-Layer
Capacity metric (unless otherwise indicated) for measurements between Capacity metric (unless otherwise indicated) for measurements between
specified Source and Destination hosts: specified Source and Destination hosts:
Define the Maximum IP-layer capacity, Maximum_C(T,I,PM), to be the Define the Maximum IP-Layer Capacity, Maximum_C(T,I,PM), to be the
maximum number of IP-layer bits n0[dtn,dtn+1] that can be transmitted maximum number of IP-Layer bits n0[dtn,dtn+1] divided by dt that can
in packets from the Src host and correctly received by the Dst host, be transmitted in packets from the Src host and correctly received by
over all dt length intervals in [T, T+I], and meeting the PM the Dst host, over all dt length intervals in [T, T+I], and meeting
criteria. Equivalently the Maximum of a Sample of size m of the PM criteria. Equivalently the Maximum of a Sample of size m of
C(T,I,PM) collected during the interval [T, T+I] and meeting the PM C(T,I,PM) collected during the interval [T, T+I] and meeting the PM
criteria. criteria.
The interval dt SHOULD be set to a natural number m so that T+I = T + The number of sub-intervals with duration dt MUST be set to a natural
m*dt with dtn+1 - dtn = dt and with 1 <= n <= m. number m, so that T+I = T + m*dt with dtn+1 - dtn = dt for 1 <= n <=
m.
Parameter PM represents the other performance metrics (see Parameter PM represents the other performance metrics (see
Section 6.4 below) and their measurement results for the maximum IP- Section 6.4 below) and their measurement results for the Maximum IP-
layer capacity. At least one target performance threshold (PM Layer Capacity. At least one target performance threshold (PM
criterion) MUST be defined. If more than one metric and target criterion) MUST be defined. If more than one metric and target
performance threshold are defined, then the sub-interval with maximum performance threshold are defined, then the sub-interval with maximum
number of bits transmitted MUST meet all the target performance number of bits transmitted MUST meet all the target performance
thresholds. Users SHALL specify the parameter Tmax as required by thresholds. Users SHALL specify the parameter Tmax as required by
each metric's reference definition. each metric's reference definition.
Mathematically, this definition can be represented as: Mathematically, this definition can be represented as:
max ( n0[dtn,dtn+1] ) max ( n0[dtn,dtn+1] )
[T,T+I] [T,T+I]
skipping to change at page 10, line 20 skipping to change at page 12, line 20
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
Equation for Maximum Capacity Equation for Maximum Capacity
and: and:
o n0 is the total number of IP-layer header and payload bits that o 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 sub- and correctly received by the Dst host during one contiguous sub-
interval, dt in length, during the interval [T, T+I], interval, dt in length, during the interval [T, T+I],
o Maximum_C(T,I,PM) the Maximum IP-Layer Capacity, corresponds to o Maximum_C(T,I,PM) the Maximum IP-Layer Capacity, corresponds to
the maximum value of n0 measured in any sub-interval ending at dtn the maximum value of n0 measured in any sub-interval beginning at
(meaning T + n*dt), divided by the constant length of all sub- dtn, divided by the constant length of all sub-intervals, dt.
intervals, dt.
o PM represents the other performance metrics (see Section 5.4) and o PM represents the other performance metrics (see Section 5.4) and
their measurement results for the maximum IP-layer capacity. At their measurement results for the Maximum IP-Layer Capacity. At
least one target performance threshold (PM criterion) MUST be least one target performance threshold (PM criterion) MUST be
defined. defined.
o all sub-intervals MUST be of equal duration. Choosing dt as non- o all sub-intervals MUST be of equal duration. Choosing dt as non-
overlapping consecutive time intervals allows for a simple overlapping consecutive time intervals allows for a simple
implementation. implementation.
o The bit rate of the physical interface of the measurement systems o The bit rate of the physical interface of the measurement systems
must be higher than that of the link whose Maximum_C(T,I,PM) is to MUST be higher than the smallest of the links on the path whose
be measured (the bottleneck link). Maximum_C(T,I,PM) is to be measured (the bottleneck link).
In this definition, the m sub-intervals can be viewed as trials when In this definition, the m sub-intervals can be viewed as trials when
the Src host varies the transmitted packet rate, searching for the the Src host varies the transmitted packet rate, searching for the
maximum n0 that meets the PM criteria measured at the Dst host in a 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 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. over all dt-length intervals in I.
Measurements according to these definitions SHALL use the UDP Measurements according to these definitions SHALL use the UDP
transport layer. transport layer.
6.4. Related Round-Trip Delay and One-way Loss Definitions 6.4. Related Round-Trip Delay and One-way Loss Definitions
RTD[dtn,dtn+1] and OWL[dtn,dtn+1] are defined in Section 5.4. Here, RTD[dtn,dtn+1] and OWL[dtn,dtn+1] are defined in Section 5.4. 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]. RTD[T,I] and OWL[T,I].
The interval dtn,dtn+1 where Maximum_C[T,I,PM] occurs is the The interval dtn,dtn+1 where Maximum_C[T,I,PM] occurs is the
reporting sub-interval for RTD[T,I] and OWL[T,I]. reporting sub-interval within RTD[T,I] and OWL[T,I].
Other metrics MAY be measured: one-way reordering, duplication, and Other metrics MAY be measured: one-way reordering, duplication, and
delay variation. delay variation.
6.5. Discussion 6.5. Discussion
If traffic conditioning (e.g., shaping, policing) applies along a If traffic conditioning (e.g., shaping, policing) applies along a
path for which Maximum_C(T,I,PM) is to be determined, different path for which Maximum_C(T,I,PM) is to be determined, different
values for dt SHOULD be picked and measurements be executed during values for dt SHOULD be picked and measurements be executed during
multiple intervals [T, T+I]. A single constant interval dt SHOULD be multiple intervals [T, T+I]. Each duration dt SHOULD be chosen so
chosen so that is an integer multiple of increasing values k times that it is an integer multiple of increasing values k times
serialisation delay of a path MTU at the physical interface speed serialization delay of a path MTU at the physical interface speed
where traffic conditioning is expected. This should avoid taking where traffic conditioning is expected. This should avoid taking
configured burst tolerance singletons as a valid Maximum_C(T,I,PM) configured burst tolerance singletons as a valid Maximum_C(T,I,PM)
result. result.
A Maximum_C(T,I,PM) without any indication of bottleneck congestion, A Maximum_C(T,I,PM) without any indication of bottleneck congestion,
be that an increasing latency, packet loss or ECN marks during a be that an increasing latency, packet loss or ECN marks during a
measurement interval I, is likely to underestimate Maximum_C(T,I,PM). measurement interval I, is likely to underestimate Maximum_C(T,I,PM).
6.6. Reporting the Metric 6.6. Reporting the Metric
The IP-Layer Capacity SHOULD be reported with at least single Megabit The IP-Layer Capacity SHOULD be reported with at least single Megabit
resolution, in units of Megabits per second (Mbps) (which is resolution, in units of Megabits per second (Mbps) (which is
1,000,000 bits per second to avoid any confusion). 1,000,000 bits per second to avoid any confusion).
The Related Round Trip Delay and/or Loss metric measurements for the The related One-way Loss metric and Round Trip Delay measurements for
same Singleton SHALL be reported, also with meaningful resolution for the same Singleton SHALL be reported, also with meaningful resolution
the values measured. for the values measured.
When there are demonstrated and repeatable Capacity modes in the When there are demonstrated and repeatable Capacity modes in the
Sample, then the Maximum IP-Layer Capacity SHALL be reported for each Sample, then the Maximum IP-Layer Capacity SHALL be reported for 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 Maxima have been that the mode was observed to be present. Bimodal Maximum IP-Layer
observed with some services, sometimes called a "turbo mode" Capacities have been observed with some services, sometimes called a
intending to deliver short transfers more quickly, or reduce the "turbo mode" intending to deliver short transfers more quickly, or
initial buffering time for some video streams. Note that modes reduce the initial buffering time for some video streams. Note that
lasting less than dt duration will not be detected. modes lasting less than dt duration will not be detected.
Some transmission technologies have multiple methods of operation 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 time, but the modes of Maximum IP-Layer Capacity will not be
activated deterministically as with the "turbo mode" described in the activated deterministically as with the "turbo mode" described in the
paragraph above. paragraph above.
7. IP-Layer Sender Bit Rate Singleton Metric Definitions 7. IP-Layer Sender Bit Rate Singleton Metric Definitions
This section sets requirements for the following components to This section sets requirements for the following components to
support the IP-layer Sender Bitrate Metric. This metric helps to support the IP-Layer Sender Bitrate Metric. This metric helps to
check that the sender actually generated the desired rates during a check that the sender actually generated the desired rates during a
test, and measurement takes place at the Src host to network path test, and measurement takes place at the Src host to network path
interface (or as close as practical). It is not a metric for path interface (or as close as practical within the Src host). It is not
performance. a metric for path performance.
7.1. Formal Name 7.1. Formal Name
Type-P-IP-Sender-Bit-Rate, or informally called IP-layer Sender Type-P-IP-Sender-Bit-Rate, or informally called IP-Layer Sender
Bitrate. Bitrate.
Note that Type-P depends on the chosen method. Note that Type-P depends on the chosen method.
7.2. Parameters 7.2. Parameters
This section lists the REQUIRED input factors to specify the metric, This section lists the REQUIRED input factors to specify the metric,
beyond those listed in Section 4. beyond those listed in Section 4.
o S, the duration of the measurement interval at the Source o S, the duration of the measurement interval at the Source
o st, the nominal duration of N sub-intervals in S (default = 0.05 o st, the nominal duration of N sub-intervals in S (default st =
seconds) 0.05 seconds)
o stn, the beginning boundary of a specific sub-interval, n, one of
N sub-intervals in S
S SHALL be longer than I, primarily to account for on-demand S SHALL 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. delay of the path.
st SHOULD be much smaller than the sub-interval dt. The st parameter st SHOULD be much smaller than the sub-interval dt and on the same
does not have relevance when the Source is transmitting at a fixed order as FT, otherwise the rate measurement will include many rate
rate throughout S. adjustments and include more time smoothing, thus missing the Maximum
IP-Layer Capacity. The st parameter does not have relevance when the
Source is transmitting at a fixed rate throughout S.
7.3. Metric Definition 7.3. Metric Definition
This section defines the REQUIRED aspects of the IP-layer Sender This section defines the REQUIRED aspects of the IP-Layer Sender
Bitrate metric (unless otherwise indicated) for measurements at the Bitrate 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: host and matching the required Type-P:
Define the IP-layer Sender Bit Rate, B(S,st), to be the number of IP- 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 Layer bits (including header and data fields) that are transmitted
from the Source during one contiguous sub-interval, st, during the from the Source with address pair Src and Dst during one contiguous
test interval S (where S SHALL be longer than I), and where the sub-interval, st, during the test interval S (where S SHALL be longer
fixed-size packet count during that single sub-interval st also than I), and where the fixed-size packet count during that single
provides the number of IP-layer bits in any interval: n0[stn-1,stn]. sub-interval st also provides the number of IP-Layer bits in any
interval, [stn,stn+1].
Measurements according to these definitions SHALL use the UDP Measurements according to these definitions SHALL use the UDP
transport layer. Any feedback from Dst host to Src host received by transport layer. Any feedback from Dst host to Src host received by
Src host during an interval [stn-1,stn] MUST NOT result in an Src host during an interval [stn,stn+1] SHOULD NOT 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 boundaries). (rate adjustment occurs on st interval boundaries).
7.4. Discussion 7.4. Discussion
Both the Sender and Receiver or (source and destination) bit rates Both the Sender and Receiver or (Source and Destination) bit rates
SHOULD be assessed as part of an IP-layer Capacity measurement. SHOULD be assessed as part of an IP-Layer Capacity measurement.
Otherwise, an unexpected sending rate limitation could produce an
erroneous Maximum IP-Layer Capacity measurement.
7.5. Reporting the Metric 7.5. Reporting the Metric
The IP-Layer Sender Bit Rate SHALL be reported with meaningful The IP-Layer Sender Bit Rate SHALL be reported with meaningful
resolution, in units of Megabits per second. resolution, in units of Megabits per second (which is 1,000,000 bits
per second to avoid any confusion).
Individual IP-Layer Sender Bit Rate measurements are discussed Individual IP-Layer Sender Bit Rate measurements are discussed
further in Section 9. further in Section 9.
8. Method of Measurement 8. Method of Measurement
The architecture of the method REQUIRES two cooperating hosts The architecture of the method REQUIRES two cooperating hosts
operating in the roles of Src (test packet sender) and Dst operating in the roles of Src (test packet sender) and Dst
(receiver), with a measured path and return path between them. (receiver), with a measured path and return path between them.
The duration of a test, parameter I, MUST be constrained in a The duration of a test, parameter I, MUST be constrained 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. likely cause congestion on the Src to Dst host path during a test.
8.1. Load Rate Adjustment Algorithm 8.1. Load Rate Adjustment Algorithm
A table SHALL be pre-built defining all the offered load rates that The algorithm described in this section MUST NOT be used as a general
will be supported (R1 through Rn, in ascending order, corresponding Congestion Control Algorithm (CCA). As stated in the Scope
to indexed rows in the table). Each rate is defined as datagrams of Section 2, the load rate adjustment algorithm's goal is to help
size ss, sent as a burst of count cc, every time interval tt (default determine the Maximum IP-Layer Capacity in the context of an
for tt is 1ms, a likely system tick-interval). While it is infrequent, diagnostic, short term measurement. There is a tradeoff
advantageous to use datagrams of as large a size as possible, it may between test duration (also the test data volume) and algorithm
be prudent to use a slightly smaller maximum that allows for aggressiveness (speed of ramp-up and down to the Maximum IP-Layer
secondary protocol headers and/or tunneling without resulting in IP- Capacity). The parameter values chosen below strike a well-tested
layer fragmentation. Selection of a new rate is indicated by a balance among these factors.
calculation on the current row, Rx. For example:
A table SHALL be pre-built (by the test initiator) defining all the
offered load rates that will be supported (R1 through Rn, in
ascending order, corresponding to indexed rows in the table). It is
RECOMMENDED that rates begin with 0.5 Mbps at index zero, use 1 Mbps
at index one, and then continue in 1 Mbps increments to 1 Gbps.
Above 1 Gbps, and up to 10 Gbps, it is RECOMMENDED that 100 Mbps
increments be used. Above 10 Gbps, increments of 1 Gbps are
RECOMMENDED. A higher initial IP-Layer Sender Bitrate might be
configured when the test operator is certain that the Maximum IP-
Layer Capacity is well-above the initial IP-Layer Sender Bitrate and
factors such as test duration and total test traffic play an
important role. The sending rate table SHOULD backet the maximum
capacity where it will make measurements, including constrained rates
less than 500kbps if applicable.
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
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 maximum that allows for secondary protocol headers and/or
tunneling without resulting in IP-Layer fragmentation. Selection of
a new rate is indicated by a calculation on the current row, Rx. For
example:
"Rx+1": the sender uses the next higher rate in the table. "Rx+1": the sender uses the next higher rate in the table.
"Rx-10": the sender uses the rate 10 rows lower in the table. "Rx-10": the sender uses the rate 10 rows lower in the table.
At the beginning of a test, the sender begins sending at rate R1 and At the beginning of a test, the sender begins sending at rate R1 and
the receiver starts a feedback timer at interval F (while awaiting the receiver starts a feedback timer of duration FT (while awaiting
inbound datagrams). As datagrams are received they are checked for inbound datagrams). As datagrams are received they are checked for
sequence number anomalies (loss, out-of-order, duplication, etc.) and sequence number anomalies (loss, out-of-order, duplication, etc.) and
the delay range is measured (one-way or round-trip). This the delay range is measured (one-way or round-trip). This
information is accumulated until the feedback timer F expires and a information is accumulated until the feedback timer FT expires and a
status feedback message is sent from the receiver back to the sender, status feedback message is sent from the receiver back to the sender,
to communicate this information. The accumulated statistics are then to communicate this information. The accumulated statistics are then
reset by the receiver for the next feedback interval. As feedback reset by the receiver for the next feedback interval. As feedback
messages are received back at the sender, they are evaluated to messages are received back at the sender, they are evaluated to
determine how to adjust the current offered load rate (Rx). determine how to adjust the current offered load rate (Rx).
If the feedback indicates that no sequence number anomalies were 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, the offered load rate is increased by more than one up to this point (see below for the method to declare congestion),
rate (e.g., Rx+10). This allows the offered load to quickly reach a the offered load rate is increased by more than one rate (e.g.,
near-maximum rate. Conversely, if congestion has been previously Rx+10). This allows the offered load to quickly reach a near-maximum
confirmed, the offered load rate is only increased by one (Rx+1). rate. Conversely, if congestion has been previously confirmed, the
offered load rate is only increased by one (Rx+1). However, if a
rate threshold between high and very high sending rates (such as 1
Gbps) is exceeded, the offered load rate is only increased by one
(Rx+1) above the rate threshold in any congestion state.
If the feedback indicates that sequence number anomalies were If the feedback indicates that sequence number anomalies were
detected OR the delay range was above the upper threshold, the detected OR the delay range was above the upper threshold, the
offered load rate is decreased. Also, if congestion is now confirmed offered load rate is decreased. The RECOMMENDED threshold values are
by the current feedback message being processed, then the offered 0 for sequence number gaps and 30 ms for lower and 90 ms for upper
load rate is decreased by more than one rate (e.g., Rx-30). This delay thresholds, respectively. Also, if congestion is now confirmed
one-time reduction is intended to compensate for the fast initial for the first time by the current feedback message being processed,
ramp-up. In all other cases, the offered load rate is only decreased then the offered load rate is decreased by more than one rate (e.g.,
by one (Rx-1). Rx-30). This one-time reduction is intended to compensate for the
fast initial ramp-up. In all other cases, the offered load rate is
only decreased by one (Rx-1).
If the feedback indicates that there were no sequence number If the feedback indicates that there were no sequence number
anomalies AND the delay range was above the lower threshold, but anomalies AND the delay range was above the lower threshold, but
below the upper threshold, the offered load rate is not changed. below the upper threshold, the offered load rate is not changed.
This allows time for recent changes in the offered load rate to This allows time for recent changes in the offered load rate to
stabilize, and the feedback to represent current conditions more stabilize, and the feedback to represent current conditions more
accurately. accurately.
Lastly, the method for inferring congestion is that there were 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 two consecutive feedback intervals. The algorithm
described above is also illustrated in ITU-T Rec. Y.1540, 2020 described above is also illustrated in ITU-T Rec. Y.1540, 2020
version[Y.1540], in Annex B, and implemented in the Appendix on Load version[Y.1540], in Annex B, and implemented in the Appendix on Load
Rate Adjustment Pseudo Code in this memo. Rate Adjustment Pseudo Code in this memo.
All the values used above are relevant to searches in the 1 Mbps to The load rate adjustment algorithm MUST include timers that stop the
10 Gbps capacity range. Searches can accommodate higher rate test when received packet streams cease unexpectedly. The timeout
capacities by changing the rates in the pre-built table. thresholds are provided in the table below, along with values for all
other parameters and variables described in this section. Operation
of non-obvious parameters appear below:
load packet timeout Operation: The load packet timeout SHALL be
reset to the configured value each time a load packet received.
If the timeout expires, the receiver SHALL be closed and no
further feedback sent.
feedback message timeout Operation: The feedback message timeout
SHALL be reset to the configured value each time a feedback
message is received. If the timeout expires, the sender SHALL be
closed and no further load packets sent.
+-------------+-------------+---------------+-----------------------+
| Parameter | Default | Tested Range | Expected Safe Range |
| | | or values | (not entirely tested, |
| | | | other |
| | | | values NOT |
| | | | RECOMMENDED) |
+-------------+-------------+---------------+-----------------------+
| FT, | 50ms | 20ms, 50ms, | 20ms <= FT <= 250ms |
| feedback | | 100ms | Larger values may |
| time | | | slow the rate |
| interval | | | increase and fail to |
| | | | find the max |
+-------------+-------------+---------------+-----------------------+
| Feedback | L*FT, L=20 | L=100 with | 0.5sec <= L*FT <= |
| message | (1sec with | FT=50ms | 30sec Upper limit for |
| timeout | FT=50ms) | (5sec) | very unreliable |
| (stop test) | | | test paths only |
+-------------+-------------+---------------+-----------------------+
| load packet | 1sec | 5sec | 0.250sec - 30sec |
| timeout | | | Upper limit for very |
| (stop test) | | | unreliable test paths |
| | | | only |
+-------------+-------------+---------------+-----------------------+
| table index | 0.5Mbps | 0.5Mbps | when testing <=10Gbps |
| 0 | | | |
+-------------+-------------+---------------+-----------------------+
| table index | 1Mbps | 1Mbps | when testing <=10Gbps |
| 1 | | | |
+-------------+-------------+---------------+-----------------------+
| table index | 1Mbps | 1Mbps<=rate<= | same as tested |
| (step) size | | 1Gbps | |
+-------------+-------------+---------------+-----------------------+
| table index | 100Mbps | 1Gbps<=rate<= | same as tested |
| (step) | | 10Gbps | |
| size, | | | |
| rate>1Gbps | | | |
+-------------+-------------+---------------+-----------------------+
| table index | 1Gbps | untested | >10Gbps |
| (step) | | | |
| size, | | | |
| rate>10Gbps | | | |
+-------------+-------------+---------------+-----------------------+
| ss, UDP | none | <=1222 | Recommend max at |
| payload | | | largest value that |
| size, bytes | | | avoids fragmentation; |
| | | | use of too- |
| | | | small payload size |
| | | | might result in |
| | | | unexpected sender |
| | | | limitations. |
+-------------+-------------+---------------+-----------------------+
| cc, burst | none | 1<=cc<= 100 | same as tested. Vary |
| count | | | cc as needed to |
| | | | create the desired |
| | | | maximum |
| | | | sending rate. Sender |
| | | | buffer size may limit |
| | | | cc in implementation. |
+-------------+-------------+---------------+-----------------------+
| tt, burst | 100microsec | 100microsec, | available range of |
| interval | | 1msec | "tick" values (HZ |
| | | | param) |
+-------------+-------------+---------------+-----------------------+
| low delay | 30ms | 5ms, 30ms | same as tested |
| range | | | |
| threshold | | | |
+-------------+-------------+---------------+-----------------------+
| high delay | 90ms | 10ms, 90ms | same as tested |
| range | | | |
| threshold | | | |
+-------------+-------------+---------------+-----------------------+
| sequence | 0 | 0, 100 | same as tested |
| error | | | |
| threshold | | | |
+-------------+-------------+---------------+-----------------------+
| consecutive | 2 | 2 | Use values >1 to |
| errored | | | avoid misinterpreting |
| status | | | transient loss |
| report | | | |
| threshold | | | |
+-------------+-------------+---------------+-----------------------+
| Fast mode | 10 | 10 | 2 <= steps <= 30 |
| increase, | | | |
| in table | | | |
| index steps | | | |
+-------------+-------------+---------------+-----------------------+
| Fast mode | 3 * Fast | 3 * Fast mode | same as tested |
| decrease, | mode | increase | |
| in table | increase | | |
| index steps | | | |
+-------------+-------------+---------------+-----------------------+
Parameters for Load Rate Adjustment Algorithm
As a consequence of default parameterization, the Number of table
steps in total for rates <10Gbps is 2000 (excluding index 0).
A related sender backoff response to network conditions occurs when
one or more status feedback messages fail to arrive at the sender.
If no status feedback messages arrive at the sender for the interval
greater than the Lost Status Backoff timeout:
UDRT + (2+w)*FT = Lost Status Backoff timeout
where:
UDRT = upper delay range threshold (default 90ms)
FT = feedback time interval (default 50ms)
w = number of repeated timeouts (w=0 initially, w++ on each
timeout, and reset to 0 when a message is received)
beginning when the last message (of any type) was successfully
received at the sender:
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 threshold (as
described above), with the same load rate adjustment algorithm
variables in their current state. This means that rate reduction and
congestion confirmation can result from a three-way OR that includes
lost status feedback messages, sequence errors, or delay variation.
The RECOMMENDED initial value for w is 0, taking Round Trip Time
(RTT) less than FT into account. A test with RTT longer than FT is a
valid reason to increase the initial value of w appropriately.
Variable w SHALL be incremented by 1 whenever the Lost Status Backoff
timeout is exceeded. So with FT = 50ms and UDRT = 90ms, a status
feedback message loss would be declared at 190ms following a
successful message, again at 50ms after that (240ms total), and so
on.
Also, if congestion is now confirmed for the first time by a Lost
Status Backoff timeout, then the offered load rate is decreased by
more than one rate (e.g., Rx-30). This one-time reduction is
intended to compensate for the fast initial ramp-up. In all other
cases, the offered load rate is only decreased by one (Rx-1).
Appendix B discusses compliance with the applicable mandatory
requirements of [RFC8085], consistent with the goals of the IP-Layer
Capacity Metric and Method, including the load rate adjustment
algorithm described in this section.
8.2. Measurement Qualification or Verification 8.2. Measurement Qualification or Verification
It is of course necessary to calibrate the equipment performing the 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. measurement range.
When assessing a Maximum rate as the metric specifies, artificially 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 un-sustainable 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 bi-modal service
rates (discussed under Reporting), which are characterized by a rates (discussed under Reporting), which are characterized by a
multi-second duration (much longer than the measured RTT) and multi-second duration (much longer than the measured RTT) and
repeatable behavior. repeatable behavior.
There are many ways that the Method of Measurement could handle this There are many ways that the Method of Measurement could handle this
false-max issue. The default value for measurement of singletons (dt false-max issue. The default value for measurement of singletons (dt
= 1 second) has proven to a be of practical value during tests of = 1 second) has proven to be of practical value during tests of this
this method, allows the bimodal service rates to be characterized, method, allows the bimodal service rates to be characterized, and it
and it has an obvious alignment with the reporting units (Mbps). has an obvious alignment with the reporting units (Mbps).
Another approach comes from Section 24 of RFC 2544[RFC2544] and its Another approach comes from Section 24 of [RFC2544] and its
discussion of Trial duration, where relatively short trials conducted discussion of Trial duration, where relatively short trials conducted
as part of the search are followed by longer trials to make the final as part of the search are followed by longer trials to make the final
determination. In the production network, measurements of singletons determination. In the production network, measurements of Singletons
and samples (the terms for trials and tests of Lab Benchmarking) must and Samples (the terms for trials and tests of Lab Benchmarking) must
be limited in duration because they may be service-affecting. But be limited in duration because they may be service-affecting. But
there is sufficient value in repeating a sample with a fixed sending there is sufficient value in repeating a Sample with a fixed sending
rate determined by the previous search for the Max IP-layer Capacity, rate determined by the previous search for the Maximum IP-Layer
to qualify the result in terms of the other performance metrics Capacity, to qualify the result in terms of the other performance
measured at the same time. metrics measured at the same time.
A qualification measurement for the search result is a subsequent A qualification measurement for the search result is a subsequent
measurement, sending at a fixed 99.x % of the Max IP-layer Capacity measurement, sending at a fixed 99.x % of the Maximum IP-Layer
for I, or an indefinite period. The same Max Capacity Metric is Capacity for I, or an indefinite period. The same Maximum Capacity
applied, and the Qualification for the result is a sample without Metric is applied, and the Qualification for the result is a Sample
packet loss or a growing minimum delay trend in subsequent singletons without packet loss or a growing minimum delay trend in subsequent
(or each dt of the measurement interval, I). Samples exhibiting singletons (or each dt of the measurement interval, I). Samples
losses or increasing queue occupation require a repeated search and/ exhibiting losses or increasing queue occupation require a repeated
or test at reduced fixed sender rate for qualification. search and/or test at reduced fixed sender rate for qualification.
Here, as with any Active Capacity test, the test duration must be 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. 10 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). In combination with a fast search method and user- 10 seconds. The combination of a fast and congestion-aware search
network coordination, the concerns raised in RFC 6815[RFC6815] are method and user-network coordination make a unique contribution to
alleviated. The method for assessing Max IP Capacity is different production testing. The Maximum IP Capacity metric and method for
from classic [RFC2544] methods: they use short term load adjustment assessing performance is very different from classic [RFC2544]
and are sensitive to loss and delay, like other congestion control Throughput metric and methods : it uses near-real-time load
algorithms used on the Internet every day. adjustments that are sensitive to loss and delay, similar to other
congestion control algorithms used on the Internet every day, along
with limited duration. On the other hand, [RFC2544] Throughput
measurements can produce sustained overload conditions for extended
periods of time. Individual trials in a test governed by a binary
search can last 60 seconds for each step, and the final confirmation
trial may be even longer. This is very different from "normal"
traffic levels, but overload conditions are not a concern in the
isolated test environment. The concerns raised in [RFC6815] were
that [RFC2544] methods would be let loose on production networks, and
instead the authors challenged the standards community to develop
metrics and methods like those described in this memo.
8.3. Measurement Considerations 8.3. Measurement Considerations
In general, the wide-spread measurements that this memo encourages In general, the wide-spread measurements that this memo encourages
will encounter wide-spread behaviors. The bimodal IP Capacity will encounter wide-spread behaviors. The bimodal IP Capacity
behaviors already discussed in Section 6.6 are good examples. behaviors already discussed in Section 6.6 are good examples.
In general, it is RECOMMENDED to locate test endpoints as close to In general, it is RECOMMENDED to locate test endpoints as close to
the intended measured link(s) as practical (this is not always the intended measured link(s) as practical (this is not always
possible for reasons of scale; there is a limit on number of test possible for reasons of scale; there is a limit on number of test
endpoints coming from many perspectives, management and measurement endpoints coming from many perspectives, management and measurement
traffic for example). The testing operator MUST set a value for the traffic for example). The testing operator MUST set a value for the
MaxHops parameter, based on the expected path length. This parameter MaxHops parameter, based on the expected path length. This parameter
can keep measurement traffic from straying too far beyond the can keep measurement traffic from straying too far beyond the
intended path. intended path.
The path measured may be state-full based on many factors, and the 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 the time from the
beginning of a measured flow, and how the flow is constructed 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. time or bytes sent or both. Both load packets and status feedback
messages MUST contain sequence numbers, which helps with measurements
based on those packets.
Many different traffic shapers and on-demand access technologies may Many different types of traffic shapers and on-demand communications
be encountered, as anticipated in [RFC7312], and play a key role in access technologies may be encountered, as anticipated in [RFC7312],
measurement results. Methods MUST be prepared to provide a short and play a key role in measurement results. Methods MUST be prepared
preamble transmission to activate on-demand access, and to discard to provide a short preamble transmission to activate on-demand
the preamble from subsequent test results. communications access, and to discard the preamble from subsequent
test results.
Conditions which might be encountered during measurement, where Conditions which might be encountered during measurement, where
packet losses may occur independently from the measurement sending packet losses may occur independently of the measurement sending
rate: rate:
1. Congestion of an interconnection or backbone interface may appear 1. Congestion of an interconnection or backbone interface may appear
as packet losses distributed over time in the test stream, due to as packet losses distributed over time in the test stream, due to
much higher rate interfaces in the backbone. much higher rate interfaces in the backbone.
2. Packet loss due to use of Random Early Detection (RED) or other 2. Packet loss due to use of Random Early Detection (RED) or other
active queue management may or may not affect the measurement active queue management may or may not affect the measurement
flow if competing background traffic (other flows) are flow if competing background traffic (other flows) are
simultaneously present. simultaneously present.
skipping to change at page 17, line 49 skipping to change at page 24, line 15
following reasons: following reasons:
1. the test hosts may be able to create higher load than with a 1. the test hosts may be able to create higher load than with a
single flow, or parallel test hosts may be used to generate 1 single flow, or parallel test hosts may be used to generate 1
flow each. flow each.
2. there may be link aggregation present (flow-based load balancing) 2. there may be link aggregation present (flow-based load balancing)
and multiple flows are needed to occupy each member of the and multiple flows are needed to occupy each member of the
aggregate. aggregate.
3. access policies may limit the IP-Layer Capacity depending on the 3. Internet access policies may limit the IP-Layer Capacity
Type-P of packets, possibly reserving capacity for various stream depending on the Type-P of packets, possibly reserving capacity
types. for various stream types.
Each flow would be controlled using its own implementation of the Each flow would be controlled using its own implementation of the
Load Adjustment (Search) Algorithm. load rate adjustment (search) algorithm.
It is obviously counter-productive to run more than one independent
and concurrent test (regardless of the number of flows in the test
stream) attempting to measure the *maximum* capacity on a single
path. The number of concurrent, independent tests of a path SHALL be
limited to one.
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
sent/received are both standard-formed, this should be allowed (and
the change in header size easily accounted for on a per-packet
basis).
As testing continues, implementers should expect some evolution in As testing continues, implementers should expect some evolution in
the methods. The ITU-T has published a Supplement (60) to the the methods. The ITU-T has published a Supplement (60) to the
Y-series of Recommendations, "Interpreting ITU-T Y.1540 maximum IP- Y-series of Recommendations, "Interpreting ITU-T Y.1540 Maximum IP-
layer capacity measurements", [Y.Sup60], which is the result of Layer Capacity measurements", [Y.Sup60], which is the result of
continued testing with the metric and method described here. continued testing with the metric, and those results have improved
the method described here.
8.4. Running Code 8.4. Running Code
This section is for the benefit of the Document Shepherd's form, and RFC Editor: This section is for the benefit of the Document
will be deleted prior to final review. Shepherd's form, and will be deleted prior to publication.
Much of the development of the method and comparisons with existing Much of the development of the method and comparisons with existing
methods conducted at IETF Hackathons and elsewhere have been based on methods conducted at IETF Hackathons and elsewhere have been based on
the example udpst Linux measurement tool (which is a working the example udpst Linux measurement tool (which is a working
reference for further development) [udpst]. The current project: reference for further development) [udpst]. The current project:
o is a utility that can function as a client or server daemon o is a utility that can function as a client or server daemon
o requires a successful client-initiated setup handshake between o requires a successful client-initiated setup handshake between
cooperating hosts and allows firewalls to control inbound cooperating hosts and allows firewalls to control inbound
unsolicited UDP which either go to a control port [expected and w/ unsolicited UDP which either go to a control port [expected and w/
authentication] or to ephemeral ports that are only created as authentication] or to ephemeral ports that are only created as
needed. Firewalls protecting each host can both continue to do needed. Firewalls protecting each host can both continue to do
their job normally. This aspect is similar to many other test their job normally. This aspect is similar to many other test
utilities available. utilities available.
o is written in C, and built with gcc (release 9.3) and its standard o is written in C, and built with gcc (release 9.3) and its standard
run-time libraries run-time libraries
o allows configuration of most of the parameters described in o allows configuration of most of the parameters described in
Sections 4 and 7. Sections 4 and 7.
o supports IPv4 and IPv6 address families. o supports IPv4 and IPv6 address families.
o supports IP-layer packet marking. o supports IP-Layer packet marking.
9. Reporting Formats 9. Reporting Formats
The singleton IP-Layer Capacity results SHOULD be accompanied by the The singleton IP-Layer Capacity results SHOULD be accompanied by the
context under which they were measured. context under which they were measured.
o timestamp (especially the time when the maximum was observed in o timestamp (especially the time when the maximum was observed in
dtn) dtn)
o source and destination (by IP or other meaningful ID) o Source and Destination (by IP or other meaningful ID)
o other inner parameters of the test case (Section 4) o other inner parameters of the test case (Section 4)
o outer parameters, such as "test conducted in motion" or other o outer parameters, such as "test conducted in motion" or other
factors belonging to the context of the measurement factors belonging to the context of the measurement
o result validity (indicating cases where the process was somehow o result validity (indicating cases where the process was somehow
interrupted or the attempt failed) interrupted or the attempt failed)
o a field where unusual circumstances could be documented, and o a field where unusual circumstances could be documented, and
another one for "ignore/mask out" purposes in further processing another one for "ignore/mask out" purposes in further processing
The Maximum IP-Layer Capacity results SHOULD be reported in the The Maximum IP-Layer Capacity results SHOULD be reported in the
format of a table with a row for each of the test Phases and Number 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 of Flows. There SHOULD be columns for the phases with number of
flows, and for the resultant Maximum IP-Layer Capacity results for flows, and for the resultant Maximum IP-Layer Capacity results for
the aggregate and each flow tested. the aggregate and each flow tested.
As mentioned in Section 6.6, bi-modal (or multi-modal) maxima SHALL As mentioned in Section 6.6, bi-modal (or multi-modal) maxima SHALL
be reported for each mode separately. be reported for each mode separately.
+--------------+----------------------+-----------+-----------------+ +-------------+-------------------------+----------+----------------+
| Phase, # | Max IP-Layer | Loss | RTT min, max, | | Phase, # | Maximum IP-Layer | Loss | RTT min, max, |
| Flows | Capacity, Mbps | Ratio | msec | | Flows | Capacity, Mbps | Ratio | msec |
+--------------+----------------------+-----------+-----------------+ +-------------+-------------------------+----------+----------------+
| Search,1 | 967.31 | 0.0002 | 30, 58 | | Search,1 | 967.31 | 0.0002 | 30, 58 |
| Verify,1 | 966.00 | 0.0000 | 30, 38 | +-------------+-------------------------+----------+----------------+
+--------------+----------------------+-----------+-----------------+ | Verify,1 | 966.00 | 0.0000 | 30, 38 |
+-------------+-------------------------+----------+----------------+
Maximum IP-layer Capacity Results Maximum IP-layer Capacity Results
Static and configuration parameters: Static and configuration parameters:
The sub-interval time, dt, MUST accompany a report of Maximum IP- The sub-interval time, dt, MUST accompany a report of Maximum IP-
Layer Capacity results, and the remaining Parameters from Section 4, Layer Capacity results, and the remaining Parameters from Section 4,
General Parameters. General Parameters.
The PM list metrics corresponding to the sub-interval where the 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 MUST accompany a report of Maximum IP-Layer
Capacity results, for each test phase. Capacity results, for each test phase.
The IP-Layer Sender Bit rate results SHOULD be reported in the format The IP-Layer Sender Bit rate results SHOULD be reported in the format
of a table with a row for each of the test Phases, sub-intervals (st) of a table with a row for each of the test phases, sub-intervals (st)
and Number of Flows. There SHOULD be columns for the phases with and number of flows. There SHOULD be columns for the phases with
number of flows, and for the resultant IP-Layer Sender Bit rate number of flows, and for the resultant IP-Layer Sender Bit rate
results for the aggregate and each flow tested. results for the aggregate and each flow tested.
+------------------------+-------------+-----------------------+----+ +--------------------------+-------------+----------------------+
| Phase, Flow or | st, sec | Sender Bit Rate, Mbps | ?? | | Phase, Flow or Aggregate | st, sec | Sender Bitrate, Mbps |
| Aggregate | | | | +--------------------------+-------------+----------------------+
+------------------------+-------------+-----------------------+----+ | Search,1 | 0.00 - 0.05 | 345 |
| Search,1 | 0.00 - 0.05 | 345 | __ | +--------------------------+-------------+----------------------+
| Search,2 | 0.00 - 0.05 | 289 | __ | | Search,2 | 0.00 - 0.05 | 289 |
| Search,Agg | 0.00 - 0.05 | 634 | __ | +--------------------------+-------------+----------------------+
+------------------------+-------------+-----------------------+----+ | Search,Agg | 0.00 - 0.05 | 634 |
+--------------------------+-------------+----------------------+
IP-layer Sender Bit Rate Results IP-layer Sender Bit Rate Results
Static and configuration parameters: Static and configuration parameters:
The subinterval time, st, MUST accompany a report of Sender IP-Layer The subinterval time, st, MUST accompany a report of Sender IP-Layer
Bit Rate results. Bit Rate results.
Also, the values of the remaining Parameters from Section 4, General Also, the values of the remaining Parameters from Section 4, General
Parameters, MUST be reported. Parameters, MUST be reported.
skipping to change at page 20, line 35 skipping to change at page 27, line 16
As a part of the multi-Standards Development Organization (SDO) 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 areas where the Broadband Forum (BBF) contributed its expertise was
in the definition of an information model and data model for in 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 is this memo.
[TR-471] provides the Information model that was used to prepare a [TR-471] provides the Information model that was used to prepare a
full data model in related BBF work. The BBF has also carefully full data model in related BBF work. The BBF has also carefully
considered topics within its purview, such as placement of considered topics within its purview, such as placement of
measurement systems within the access architecture. For example, measurement systems within the Internet access architecture. For
timestamp resolution requirements that influence the choice of the example, timestamp resolution requirements that influence the choice
test protocol are provided in Table 2 of [TR-471]. of the test protocol are provided in Table 2 of [TR-471].
10. Security Considerations 10. Security Considerations
Active metrics and measurements have a long history of security Active metrics and 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 [RFC4656] and measurement of live paths are relevant here. See [RFC4656] and
[RFC5357]. [RFC5357].
When considering privacy of those involved in measurement or those 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 which are within this scope of work. Passive observations of user
traffic for measurement purposes raise many privacy issues. We refer traffic for measurement purposes raise many privacy issues. We refer
the reader to the privacy considerations described in the Large Scale the reader to the privacy considerations described in the Large Scale
Measurement of Broadband Performance (LMAP) Framework [RFC7594], Measurement of Broadband Performance (LMAP) Framework [RFC7594],
which covers active and passive techniques. which covers active and passive techniques.
There are some new considerations for Capacity measurement as There are some new considerations for Capacity measurement as
described in this memo. described in this memo.
1. Cooperating source and destination hosts and agreements to test 1. Cooperating Source and Destination hosts and agreements to test
the path between the hosts are REQUIRED. Hosts perform in either the path between the hosts are REQUIRED. Hosts perform in either
the Src or Dst roles. the Src or Dst roles.
2. A REQUIRED user client-initiated setup handshake between 2. It is REQUIRED to have a user client-initiated setup handshake
cooperating hosts and allows firewalls to control inbound between cooperating hosts that allows firewalls to control
unsolicited UDP which either go to a control port [expected and inbound unsolicited UDP traffic which either goes to a control
w/authentication] or to ephemeral ports that are only created as port [expected and w/authentication] or to ephemeral ports that
needed. Firewalls protecting each host can both continue to do are only created as needed. Firewalls protecting each host can
their job normally. both continue to do their job normally.
3. Integrity protection for feedback messages conveying measurements 3. Client-server authentication and integrity protection for
is RECOMMENDED. feedback messages conveying measurements is RECOMMENDED.
4. Hosts MUST limit the number of simultaneous tests to avoid 4. Hosts MUST limit the number of simultaneous tests to avoid
resource exhaustion and inaccurate results. resource exhaustion and inaccurate results.
5. Senders MUST be rate-limited. This can be accomplished using the 5. Senders MUST be rate-limited. This can be accomplished 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 (Section 8.1). The recommended load-control search
algorithm results in "ramp up" from the lowest rate in the table. algorithm results in "ramp-up" from the lowest rate in the table.
6. Service subscribers with limited data volumes who conduct 6. Service subscribers with limited data volumes who conduct
extensive capacity testing might experience the effects of 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 Service Provider's measurement hosts SHOULD be limited in
frequency and/or overall volume of test traffic. frequency and/or overall volume of test traffic (for example, the
range of duration values, I, SHOULD be limited).
The exact specification of these features is left for the future The exact specification of these features is left for the future
protocol development. protocol development.
11. IANA Considerations 11. IANA Considerations
This memo makes no requests of IANA. This memo makes no requests of IANA.
12. Acknowledgments 12. Acknowledgments
Thanks to Joachim Fabini, Matt Mathis, J.Ignacio Alvarez-Hamelin, Thanks to Joachim Fabini, Matt Mathis, J.Ignacio Alvarez-Hamelin,
Wolfgang Balzer, Frank Brockners, Greg Mirsky and Martin Duke for Wolfgang Balzer, Frank Brockners, Greg Mirsky, Martin Duke, Murray
their extensive comments on the memo and related topics. Kucherawy, and Benjamin Kaduk for their extensive comments on the
memo and related topics. In a second round of reviews, we
acknowledge Magnus Westerlund, Lars Eggert, and Zahed Sarkar.
13. Appendix - Load Rate Adjustment Pseudo Code 13. Appendix A - Load Rate Adjustment Pseudo Code
The following is a pseudo-code implementation of the algorithm The following is a pseudo-code implementation of the algorithm
described in Section 8.1. described in Section 8.1.
Rx = 1 # The current sending rate (equivalent to a row of the table) Rx = 0 # The current sending rate (equivalent to a row of the table)
seqErr = 0 # Measured count of any of Loss or Reordering impairments seqErr = 0 # Measured count of any of Loss or Reordering impairments
delay = 0 # Measured Range of Round Trip Time, RTT, ms delay = 0 # Measured Range of Round Trip Delay, RTD, ms
lowThresh = 30 # Low threshold on the Range of RTT, ms lowThresh = 30 # Low threshold on the Range of RTD, ms
upperThresh = 90 # Upper threshold on the Range of RTT, ms upperThresh = 90 # Upper threshold on the Range of RTD, ms
hSpeedTresh = 1Gbps # Threshold for transition between sending rate step hSpeedTresh = 1 Gbps # Threshold for transition between sending rate step
sizes (such as 1 Mbps and 100 Mbps) sizes (such as 1 Mbps and 100 Mbps)
slowAdjCount = 0 # Measured Number of consecutive status reports slowAdjCount = 0 # Measured Number of consecutive status reports
indicating loss and/or delay variation above upperThresh indicating loss and/or delay variation above upperThresh
slowAdjThresh = 2 # Threshold on slowAdjCount used to infer congestion. slowAdjThresh = 2 # Threshold on slowAdjCount used to infer congestion.
Use values >1 to avoid misinterpreting transient loss Use values >1 to avoid misinterpreting transient loss
highSpeedDelta = 10 # The number of rows to move in a single adjustment highSpeedDelta = 10 # The number of rows to move in a single adjustment
when initially increasing offered load (to ramp-up quickly) 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 == 0 && delay < lowThresh ) {
if ( Rx < hSpeedTresh && slowAdjCount < slowAdjThresh ) { if ( Rx < hSpeedTresh && 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 > 0 || delay > upperThresh ) {
slowAdjCount++; slowAdjCount++;
if ( Rx < hSpeedTresh && c->slowAdjCount == slowAdjThresh ) { if ( Rx < hSpeedTresh && 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--;
} }
} }
14. References 14. Appendix B - RFC 8085 UDP Guidelines Check
14.1. Normative References
The BCP on UDP usage guidelines [RFC8085] focuses primarily on
congestion control in section 3.1. The Guidelines appear in
mandatory (MUST) and recommendation (SHOULD) categories.
14.1. Assessment of Mandatory Requirements
The mandatory requirements in Section 3 of [RFC8085] include:
Internet paths can have widely varying characteristics, ...
Consequently, applications that may be used on the Internet MUST
NOT make assumptions about specific path characteristics. They
MUST instead use mechanisms that let them operate safely under
very different path conditions. Typically, this requires
conservatively probing the current conditions of the Internet path
they communicate over to establish a transmission behavior that it
can sustain and that is reasonably fair to other traffic sharing
the path.
The purpose of the load rate adjustment algorithm in Section 8.1 is
to probe the network and enable Maximum IP-Layer Capacity
measurements with as few assumptions about the measured path as
possible, and within the range application described in Section 2.
The degree of probing conservatism is in tension with the need to
minimize both the traffic dedicated to testing (especially with
Gigabit rate measurements) and the duration of the test (which is one
contributing factor to the overall algorithm fairness).
The text of Section 3 of [RFC8085] goes on to recommend alternatives
to UDP to meet the mandatory requirements, but 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 measurement
accuracy repeatedly proven in comparison measurements with the
running code [LS-SG12-A] [LS-SG12-B] [Y.Sup60]. Also, the UDP aspect
of these methods is present primarily to support modern Internet
transmission where a transport protocol is required [copycat]; the
metric is based on the IP-Layer and UDP allows simple correlation to
the IP-Layer.
Section 3.1.1 of [RFC8085] discusses protocol timer guidelines:
Latency samples MUST NOT be derived from ambiguous transactions.
The canonical example is in a protocol that retransmits data, but
subsequently cannot determine which copy is being acknowledged.
Both load packets and status feedback messages MUST contain sequence
numbers, which helps with measurements based on those packets, and
there are no retransmissions needed.
When a latency estimate is used to arm a timer that provides loss
detection -- with or without retransmission -- expiry of the timer
MUST be interpreted as an indication of congestion in the network,
causing the sending rate to be adapted to a safe conservative
rate...
The method described in this memo uses timers for sending rate
backoff when status feedback messages are lost (Lost Status Backoff
timeout), and for stopping a test when connectivity is lost for a
longer interval (Feedback message or load packet timeouts).
There is no specific benefit foreseen by using Explicit Congestion
Notification (ECN) in this memo.
Section 3.2 of [RFC8085] discusses message size guidelines:
To determine an appropriate UDP payload size, applications MUST
subtract the size of the IP header (which includes any IPv4
optional headers or IPv6 extension headers) as well as the length
of the UDP header (8 bytes) from the PMTU size.
The method uses a sending rate table with a maximum UDP payload size
that anticipates significant header overhead and avoids
fragmentation.
Section 3.3 of [RFC8085] provides reliability guidelines:
Applications that do require reliable message delivery MUST
implement an appropriate mechanism themselves.
The IP-Layer Capacity Metric and Method do not require reliable
delivery.
Applications that require ordered delivery MUST reestablish
datagram ordering themselves.
The IP-Layer Capacity Metric and Method does not need to reestablish
packet order; it is preferred to measure packet reordering if it
occurs [RFC4737].
14.2. Assessment of Recommendations
The load rate adjustment algorithm's goal is to determine the Maximum
IP-Layer Capacity in the context of an infrequent, diagnostic, short
term measurement. This goal is a global exception to many [RFC8085]
SHOULD-level requirements, of which many are intended for long-lived
flows that must coexist with other traffic in more-or-less fair way.
However, the algorithm (as specified in Section 8.1 and Appendix A
above) reacts to indications of congestion in clearly defined ways.
A specific recommendation is provided as an example. Section 3.1.5
of [RFC8085] on implications of RTT and Loss Measurements on
Congestion Control says:
A congestion control designed for UDP SHOULD respond as quickly as
possible when it experiences congestion, and it SHOULD take into
account both the loss rate and the response time when choosing a
new rate.
The load rate adjustment algorithm responds to loss and RTT
measurements with a clear and concise rate reduction when warranted,
and the response makes use of direct measurements (more exact than
can be inferred from TCP ACKs).
Section 3.1.5 of [RFC8085] goes on to specify:
The implemented congestion control scheme SHOULD result in
bandwidth (capacity) use that is comparable to that of TCP within
an order of magnitude, so that it does not starve other flows
sharing a common bottleneck.
This is a requirement for coexistent streams, and not for diagnostic
and infrequent measurements using short durations. The rate
oscillations during short tests allow other packets to pass, and
don't starve other flows.
Ironically, ad hoc TCP-based measurements of "Internet Speed" are
also designed to work around this SHOULD-level requirement, by
launching many flows (9, for example) to increase the outstanding
data dedicated to testing.
The load rate adjustment algorithm cannot become a TCP-like
congestion control, or it will have the same weaknesses of TCP when
trying to make a Maximum IP-Layer Capacity measurement, and will not
achieve the goal. The results of the referenced testing [LS-SG12-A]
[LS-SG12-B] [Y.Sup60] supported this statement hundreds of times,
with comparisons to multi-connection TCP-based measurements.
A brief review of some other SHOULD-level requirements follows (Yes
or Not applicable = NA) :
+--+---------------------------------------------------------+---------+
|Y?| RFC 8085 Recommendation | Section |
+--+---------------------------------------------------------+---------+
Yes| MUST tolerate a wide range of Internet path conditions | 3 |
NA | SHOULD use a full-featured transport (e.g., TCP) | |
| | |
Yes| SHOULD control rate of transmission | 3.1 |
NA | SHOULD perform congestion control over all traffic | |
| | |
| for bulk transfers, | 3.1.2 |
NA | SHOULD consider implementing TFRC | |
NA | else, SHOULD in other ways use bandwidth similar to TCP | |
| | |
| for non-bulk transfers, | 3.1.3 |
NA | SHOULD measure RTT and transmit max. 1 datagram/RTT | 3.1.1 |
NA | else, SHOULD send at most 1 datagram every 3 seconds | |
NA | SHOULD back-off retransmission timers following loss | |
| | |
Yes| SHOULD provide mechanisms to regulate the bursts of | 3.1.6 |
| transmission | |
| | |
NA | MAY implement ECN; a specific set of application | 3.1.7 |
| mechanisms are REQUIRED if ECN is used. | |
| | |
Yes| for DiffServ, SHOULD NOT rely on implementation of PHBs | 3.1.8 |
| | |
Yes| for QoS-enabled paths, MAY choose not to use CC | 3.1.9 |
| | |
Yes| SHOULD NOT rely solely on QoS for their capacity | 3.1.10 |
| non-CC controlled flows SHOULD implement a transport | |
| circuit breaker | |
| MAY implement a circuit breaker for other applications | |
| | |
| for tunnels carrying IP traffic, | 3.1.11 |
NA | SHOULD NOT perform congestion control | |
NA | MUST correctly process the IP ECN field | |
| | |
| for non-IP tunnels or rate not determined by traffic, | |
NA | SHOULD perform CC or use circuit breaker | 3.1.11 |
NA | SHOULD restrict types of traffic transported by the | |
| tunnel | |
| | |
Yes| SHOULD NOT send datagrams that exceed the PMTU, i.e., | 3.2 |
Yes| SHOULD discover PMTU or send datagrams < minimum PMTU; | |
NA | Specific application mechanisms are REQUIRED if PLPMTUD | |
| is used. | |
| | |
Yes| SHOULD handle datagram loss, duplication, reordering | 3.3 |
NA | SHOULD be robust to delivery delays up to 2 minutes | |
| | |
Yes| SHOULD enable IPv4 UDP checksum | 3.4 |
Yes| SHOULD enable IPv6 UDP checksum; Specific application | 3.4.1 |
| mechanisms are REQUIRED if a zero IPv6 UDP checksum is | |
| used. | |
| | |
NA | SHOULD provide protection from off-path attacks | 5.1 |
| else, MAY use UDP-Lite with suitable checksum coverage | 3.4.2 |
| | |
NA | SHOULD NOT always send middlebox keep-alive messages | 3.5 |
NA | MAY use keep-alives when needed (min. interval 15 sec) | |
| | |
Yes| Applications specified for use in limited use (or | 3.6 |
| controlled environments) SHOULD identify equivalent | |
| mechanisms and describe their use case. | |
| | |
NA | Bulk-multicast apps SHOULD implement congestion control | 4.1.1 |
| | |
NA | Low volume multicast apps SHOULD implement congestion | 4.1.2 |
| control | |
| | |
NA | Multicast apps SHOULD use a safe PMTU | 4.2 |
| | |
Yes| SHOULD avoid using multiple ports | 5.1.2 |
Yes| MUST check received IP source address | |
| | |
NA | SHOULD validate payload in ICMP messages | 5.2 |
| | |
Yes| SHOULD use a randomized source port or equivalent | 6 |
| technique, and, for client/server applications, SHOULD | |
| send responses from source address matching request | |
| 5.1 | |
NA | SHOULD use standard IETF security protocols when needed | 6 |
+---------------------------------------------------------+---------+
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998, DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/info/rfc2330>. <https://www.rfc-editor.org/info/rfc2330>.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544,
DOI 10.17487/RFC2544, March 1999,
<https://www.rfc-editor.org/info/rfc2544>.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
September 1999, <https://www.rfc-editor.org/info/rfc2681>. September 1999, <https://www.rfc-editor.org/info/rfc2681>.
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining
Empirical Bulk Transfer Capacity Metrics", RFC 3148,
DOI 10.17487/RFC3148, July 2001,
<https://www.rfc-editor.org/info/rfc3148>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<https://www.rfc-editor.org/info/rfc4656>. <https://www.rfc-editor.org/info/rfc4656>.
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
RFC 5136, DOI 10.17487/RFC5136, February 2008, S., and J. Perser, "Packet Reordering Metrics", RFC 4737,
<https://www.rfc-editor.org/info/rfc5136>. DOI 10.17487/RFC4737, November 2006,
<https://www.rfc-editor.org/info/rfc4737>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008, RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/info/rfc5357>. <https://www.rfc-editor.org/info/rfc5357>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>. <https://www.rfc-editor.org/info/rfc6438>.
[RFC6815] Bradner, S., Dubray, K., McQuaid, J., and A. Morton, [RFC7497] Morton, A., "Rate Measurement Test Protocol Problem
"Applicability Statement for RFC 2544: Use on Production Statement and Requirements", RFC 7497,
Networks Considered Harmful", RFC 6815, DOI 10.17487/RFC7497, April 2015,
DOI 10.17487/RFC6815, November 2012, <https://www.rfc-editor.org/info/rfc7497>.
<https://www.rfc-editor.org/info/rfc6815>.
[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling
Framework for IP Performance Metrics (IPPM)", RFC 7312,
DOI 10.17487/RFC7312, August 2014,
<https://www.rfc-editor.org/info/rfc7312>.
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A Framework for Large-Scale
Measurement of Broadband Performance (LMAP)", RFC 7594,
DOI 10.17487/RFC7594, September 2015,
<https://www.rfc-editor.org/info/rfc7594>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <https://www.rfc-editor.org/info/rfc7680>. 2016, <https://www.rfc-editor.org/info/rfc7680>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8337] Mathis, M. and A. Morton, "Model-Based Metrics for Bulk
Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March
2018, <https://www.rfc-editor.org/info/rfc8337>.
[RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. [RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V.
Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for
the IP Performance Metrics (IPPM) Framework", RFC 8468, the IP Performance Metrics (IPPM) Framework", RFC 8468,
DOI 10.17487/RFC8468, November 2018, DOI 10.17487/RFC8468, November 2018,
<https://www.rfc-editor.org/info/rfc8468>. <https://www.rfc-editor.org/info/rfc8468>.
14.2. Informative References 15.2. Informative References
[copycat] Edleine, K., Kuhlewind, K., Trammell, B., and B. Donnet, [copycat] Edleine, K., Kuhlewind, K., Trammell, B., and B. Donnet,
"copycat: Testing Differential Treatment of New Transport "copycat: Testing Differential Treatment of New Transport
Protocols in the Wild (ANRW '17)", July 2017, Protocols in the Wild (ANRW '17)", July 2017,
<https://irtf.org/anrw/2017/anrw17-final5.pdf>. <https://irtf.org/anrw/2017/anrw17-final5.pdf>.
[LS-SG12-A] [LS-SG12-A]
12, I. S., "LS - Harmonization of IP Capacity and Latency 12, I. S., "LS - Harmonization of IP Capacity and Latency
Parameters: Revision of Draft Rec. Y.1540 on IP packet Parameters: Revision of Draft Rec. Y.1540 on IP packet
transfer performance parameters and New Annex A with Lab transfer performance parameters and New Annex A with Lab
Evaluation Plan", May 2019, Evaluation Plan", May 2019,
<https://datatracker.ietf.org/liaison/1632/>. <https://datatracker.ietf.org/liaison/1632/>.
[LS-SG12-B] [LS-SG12-B]
12, I. S., "LS on harmonization of IP Capacity and Latency 12, I. S., "LS on harmonization of IP Capacity and Latency
Parameters: Consent of Draft Rec. Y.1540 on IP packet Parameters: Consent of Draft Rec. Y.1540 on IP packet
transfer performance parameters and New Annex A with Lab & transfer performance parameters and New Annex A with Lab &
Field Evaluation Plans", March 2019, Field Evaluation Plans", March 2019,
<https://datatracker.ietf.org/liaison/1645/>. <https://datatracker.ietf.org/liaison/1645/>.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544,
DOI 10.17487/RFC2544, March 1999,
<https://www.rfc-editor.org/info/rfc2544>.
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining
Empirical Bulk Transfer Capacity Metrics", RFC 3148,
DOI 10.17487/RFC3148, July 2001,
<https://www.rfc-editor.org/info/rfc3148>.
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity",
RFC 5136, DOI 10.17487/RFC5136, February 2008,
<https://www.rfc-editor.org/info/rfc5136>.
[RFC6815] Bradner, S., Dubray, K., McQuaid, J., and A. Morton,
"Applicability Statement for RFC 2544: Use on Production
Networks Considered Harmful", RFC 6815,
DOI 10.17487/RFC6815, November 2012,
<https://www.rfc-editor.org/info/rfc6815>.
[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling
Framework for IP Performance Metrics (IPPM)", RFC 7312,
DOI 10.17487/RFC7312, August 2014,
<https://www.rfc-editor.org/info/rfc7312>.
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A Framework for Large-Scale
Measurement of Broadband Performance (LMAP)", RFC 7594,
DOI 10.17487/RFC7594, September 2015,
<https://www.rfc-editor.org/info/rfc7594>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8337] Mathis, M. and A. Morton, "Model-Based Metrics for Bulk
Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March
2018, <https://www.rfc-editor.org/info/rfc8337>.
[TR-471] Morton, A., "Broadband Forum TR-471: IP Layer Capacity [TR-471] Morton, A., "Broadband Forum TR-471: IP Layer Capacity
Metrics and Measurement", July 2020, Metrics and Measurement", July 2020,
<https://www.broadband-forum.org/technical/download/TR- <https://www.broadband-forum.org/technical/download/TR-
471.pdf>. 471.pdf>.
[udpst] AT&T, "UDP Speed Test Open Broadband project", August [udpst] udpst Project Collaborators, "UDP Speed Test Open
2020, <https://github.com/BroadbandForum <TBD>>. Broadband project", December 2020,
<https://github.com/BroadbandForum/obudpst>.
[Y.1540] Y.1540, I. R., "Internet protocol data communication [Y.1540] Y.1540, I. R., "Internet protocol data communication
service - IP packet transfer and availability performance service - IP packet transfer and availability performance
parameters", December 2019, parameters", December 2019,
<https://www.itu.int/rec/T-REC-Y.1540-201912-I/en>. <https://www.itu.int/rec/T-REC-Y.1540-201912-I/en>.
[Y.Sup60] Morton, A., "Recommendation Y.Sup60, (04/20) Interpreting [Y.Sup60] Morton, A., "Recommendation Y.Sup60, (09/20) Interpreting
ITU-T Y.1540 maximum IP-layer capacity measurements", June ITU-T Y.1540 maximum IP-layer capacity measurements, and
2020, <https://www.itu.int/rec/T-REC-Y.Sup60/en>. Errata", September 2020,
<https://www.itu.int/rec/T-REC-Y.Sup60/en>.
Authors' Addresses Authors' Addresses
Al Morton Al Morton
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
Middletown,, NJ 07748 Middletown, NJ 07748
USA USA
Phone: +1 732 420 1571 Phone: +1 732 420 1571
Fax: +1 732 368 1192 Fax: +1 732 368 1192
Email: acm@research.att.com Email: acm@research.att.com
Ruediger Geib Ruediger Geib
Deutsche Telekom Deutsche Telekom
Heinrich Hertz Str. 3-7 Heinrich Hertz Str. 3-7
Darmstadt 64295 Darmstadt 64295
Germany Germany
Phone: +49 6151 5812747 Phone: +49 6151 5812747
Email: Ruediger.Geib@telekom.de Email: Ruediger.Geib@telekom.de
Len Ciavattone Len Ciavattone
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
Middletown,, NJ 07748 Middletown, NJ 07748
USA USA
Email: lencia@att.com Email: lencia@att.com
 End of changes. 127 change blocks. 
337 lines changed or deleted 888 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/