draft-ietf-ippm-capacity-metric-method-10.txt   draft-ietf-ippm-capacity-metric-method-11.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: October 28, 2021 Deutsche Telekom Expires: December 3, 2021 Deutsche Telekom
L. Ciavattone L. Ciavattone
AT&T Labs AT&T Labs
April 26, 2021 June 1, 2021
Metrics and Methods for One-way IP Capacity Metrics and Methods for One-way IP Capacity
draft-ietf-ippm-capacity-metric-method-10 draft-ietf-ippm-capacity-metric-method-11
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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 October 28, 2021. This Internet-Draft will expire on December 3, 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Scope, Goals, and Applicability . . . . . . . . . . . . . . . 4 2. Scope, Goals, and Applicability . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. General Parameters and Definitions . . . . . . . . . . . . . 6 4. General Parameters and Definitions . . . . . . . . . . . . . 6
5. IP-Layer Capacity Singleton Metric Definitions . . . . . . . 7 5. IP-Layer Capacity Singleton Metric Definitions . . . . . . . 7
5.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 8 5.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 8
5.4. Related Round-Trip Delay and One-way Loss Definitions . . 9 5.4. Related Round-Trip Delay and One-way Loss Definitions . . 9
5.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 10 5.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 10
5.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 10 5.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 10
6. Maximum IP-Layer Capacity Metric Definitions (Statistic) . . 10 6. Maximum IP-Layer Capacity Metric Definitions (Statistic) . . 10
6.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 10
6.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 10 6.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 11
6.4. Related Round-Trip Delay and One-way Loss Definitions . . 12 6.4. Related Round-Trip Delay and One-way Loss Definitions . . 12
6.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 12 6.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 12
6.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 13 6.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 13
7. IP-Layer Sender Bit Rate Singleton Metric Definitions . . . . 13 7. IP-Layer Sender Bit Rate Singleton Metric Definitions . . . . 13
7.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 14
7.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 14 7.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 14
7.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 15 7.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 15
7.5. Reporting the Metric . . . . . . . . . . . . . . . . . . 15 7.5. Reporting the Metric . . . . . . . . . . . . . . . . . . 15
8. Method of Measurement . . . . . . . . . . . . . . . . . . . . 15 8. Method of Measurement . . . . . . . . . . . . . . . . . . . . 15
8.1. Load Rate Adjustment Algorithm . . . . . . . . . . . . . 15 8.1. Load Rate Adjustment Algorithm . . . . . . . . . . . . . 15
8.2. Measurement Qualification or Verification . . . . . . . . 20 8.2. Measurement Qualification or Verification . . . . . . . . 20
8.3. Measurement Considerations . . . . . . . . . . . . . . . 22 8.3. Measurement Considerations . . . . . . . . . . . . . . . 22
8.4. Running Code . . . . . . . . . . . . . . . . . . . . . . 23 8.4. Running Code . . . . . . . . . . . . . . . . . . . . . . 24
9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 24 9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Configuration and Reporting Data Formats . . . . . . . . 26 9.1. Configuration and Reporting Data Formats . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
13. Appendix A - Load Rate Adjustment Pseudo Code . . . . . . . . 27 13. Appendix A - Load Rate Adjustment Pseudo Code . . . . . . . . 28
14. Appendix B - RFC 8085 UDP Guidelines Check . . . . . . . . . 28 14. Appendix B - RFC 8085 UDP Guidelines Check . . . . . . . . . 29
14.1. Assessment of Mandatory Requirements . . . . . . . . . . 28 14.1. Assessment of Mandatory Requirements . . . . . . . . . . 29
14.2. Assessment of Recommendations . . . . . . . . . . . . . 30 14.2. Assessment of Recommendations . . . . . . . . . . . . . 31
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
15.1. Normative References . . . . . . . . . . . . . . . . . . 33 15.1. Normative References . . . . . . . . . . . . . . . . . . 34
15.2. Informative References . . . . . . . . . . . . . . . . . 34 15.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 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.
skipping to change at page 4, line 15 skipping to change at page 4, line 19
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, Goals, and Applicability 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.
Another 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 that captures IETF the industry, and this memo is the vehicle that captures IETF
consensus, possibly resulting in changes to the specifications of consensus, possibly resulting in changes to the specifications of
other Standards Development Organizations (SDO) (through each SDO's other Standards Development Organizations (SDO) (through each SDO's
normal contribution process, or through liaison exchange). 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
Fostering the development of protocol support for this metric and identify cases where more testing is warranted, possibly with
method of measurement is also a goal of this memo (all active testing alternate configurations). Fostering the development of protocol
protocols currently defined by the IPPM WG are UDP-based, meeting a support for this metric and method of measurement is also a goal of
key requirement of these methods). The supporting protocol this memo (all active testing protocols currently defined by the IPPM
development to measure this metric according to the specified method WG are UDP-based, meeting a key requirement of these methods). The
is a key future contribution 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 The load rate adjustment algorithm's scope is limited to helping
determine the Maximum IP-Layer Capacity in the context of an determine the Maximum IP-Layer Capacity in the context of an
infrequent, diagnostic, short term measurement. It is RECOMMENDED to infrequent, diagnostic, short term measurement. It is RECOMMENDED to
discontinue non-measurement traffic that shares a subscriber's discontinue non-measurement traffic that shares a subscriber's
dedicated resources while testing: measurements may not be accurate dedicated resources while testing: measurements may not be accurate
and throughput of competing elastic traffic may be greatly reduced. and throughput of competing elastic traffic may be greatly reduced.
The primary application of the metric and method of measurement The primary application of the metric and method of measurement
described here is the same as in Section 2 of [RFC7497] where: 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 o The access portion of the network is the focus of this problem
statement. The user typically subscribes to a service with statement. The user typically subscribes to a service with
bidirectional access partly described by rates in bits per second. bidirectional Internet access partly described by rates in bits
per second.
In addition, the use of the load rate adjustment algorithm described In addition, the use of the load rate adjustment algorithm described
in section 8.1 has the following additional applicability in section 8.1 has the following additional applicability
limitations: limitations:
- MUST only be used in the application of diagnostic and operations - MUST only be used in the application of diagnostic and operations
measurements as described in this memo measurements as described in this memo
- MUST only be used in circumstances consistent with Section 10, - MUST only be used in circumstances consistent with Section 10,
Security Considerations Security Considerations
- If a network operator is certain of the access capacity to be - 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 validated, then testing MAY start with a fixed rate test at the IP-
access capacity and avoid activating the load adjustment algorithm. layer capacity and avoid activating the load adjustment algorithm.
However, the stimulus for a diagnostic test (such as a subscriber However, the stimulus for a diagnostic test (such as a subscriber
request) strongly implies that there is no certainty and the load request) strongly implies that there is no certainty and the load
adjustment algorithm will be needed. adjustment algorithm is RECOMMENDED.
Further, the metric and method of measurement are intended for use Further, the metric and method of measurement are intended for use
where specific exact path information is unknown within a range of where specific exact path information is unknown within a range of
possible values: possible values:
- the subscriber's exact Maximum IP-Layer Capacity is unknown (which - the subscriber's exact Maximum IP-Layer Capacity is unknown (which
is sometimes the case; service rates can be increased due to upgrades is sometimes the case; service rates can be increased due to upgrades
without a subscriber's request, or to provide a surplus to compensate without a subscriber's request, or to provide a surplus to compensate
for possible underestimates of TCP-based testing. for possible underestimates of TCP-based testing).
- the size of the access bottleneck buffer is unknown. - the size of the bottleneck buffer is unknown.
Finally, the measurement system's load rate adjustment algorithm Finally, the measurement system's load rate adjustment algorithm
SHALL NOT be provided with the exact capacity value to be validated a SHALL NOT be provided with the exact capacity value to be validated a
priori. This restriction fosters a fair result, and removes an priori. This restriction fosters a fair result, and removes an
opportunity for bad actors to operate with knowledge of the "right opportunity for bad actors to operate with knowledge of the "right
answer". 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 are moving physically closer to users. 4. Content and applications are moving physically closer to users.
5. There is less emphasis on ISP gateway measurements, possibly due 5. There is less emphasis on ISP gateway measurements, possibly due
to less 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, the address of a host (such as the globally routable IP
address). address).
o Dst, the address of a host (such as the globally routable IP o Dst, the address of a host (such as the globally routable IP
skipping to change at page 12, line 10 skipping to change at page 12, line 21
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 than the smallest of the links on the path MUST be higher than the smallest of the links on the path whose
whose Maximum_C(T,I,PM) is to 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
skipping to change at page 15, line 39 skipping to change at page 15, line 45
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
The algorithm described in this section MUST NOT be used as a general The algorithm described in this section MUST NOT be used as a general
Congestion Control Algorithm (CCA). As stated in the Scope Congestion Control Algorithm (CCA). As stated in the Scope
Section 2, the load rate adjustment algorithm's goal is to help Section 2, the load rate adjustment algorithm's goal is to help
determine the Maximum IP-Layer Capacity in the context of an determine the Maximum IP-Layer Capacity in the context of an
infrequent, diagnostic, short term measurement. There is a tradeoff infrequent, diagnostic, short term measurement. There is a tradeoff
between test duration (also the test data volume) and algorithm between test duration (also the test data volume) and algorithm
agressiveness (speed of ramp-up and down to the Maximum IP-Layer aggressiveness (speed of ramp-up and down to the Maximum IP-Layer
Capacity). The parameter values chosen below strike a well-tested Capacity). The parameter values chosen below strike a well-tested
balance among these factors. balance among these factors.
A table SHALL be pre-built defining all the offered load rates that A table SHALL be pre-built (by the test initiator) defining all the
will be supported (R1 through Rn, in ascending order, corresponding offered load rates that will be supported (R1 through Rn, in
to indexed rows in the table). It is RECOMMENDED that rates begin ascending order, corresponding to indexed rows in the table). It is
with 0.5 Mbps at index zero, use 1 Mbps at index one, and then RECOMMENDED that rates begin with 0.5 Mbps at index zero, use 1 Mbps
continue in 1 Mbps increments to 1 Gbps. Above 1 Gbps, and up to 10 at index one, and then continue in 1 Mbps increments to 1 Gbps.
Gbps, it is RECOMMENDED that 100 Mbps increments be used. Above 10 Above 1 Gbps, and up to 10 Gbps, it is RECOMMENDED that 100 Mbps
Gbps, increments of 1 Gbps are RECOMMENDED. A higher initial IP- increments be used. Above 10 Gbps, increments of 1 Gbps are
Layer Sender Bitrate might be configured when the test operator is RECOMMENDED. A higher initial IP-Layer Sender Bitrate might be
certain that the Maximum IP-Layer Capacity is well-above the initial configured when the test operator is certain that the Maximum IP-
IP-Layer Sender Bitrate and factors such as test duration and total Layer Capacity is well-above the initial IP-Layer Sender Bitrate and
test traffic play an important role. factors such as test duration and total test traffic play an
important role.
Each rate is defined as datagrams of size ss, sent as a burst of Each rate is defined as datagrams of size ss, sent as a burst of
count cc, each time interval tt (default for tt is 1ms, a likely count cc, each time interval tt (default for tt is 1ms, a likely
system tick-interval). While it is advantageous to use datagrams of 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 as large a size as possible, it may be prudent to use a slightly
smaller maximum that allows for secondary protocol headers and/or smaller maximum that allows for secondary protocol headers and/or
tunneling without resulting in IP-Layer fragmentation. Selection of tunneling without resulting in IP-Layer fragmentation. Selection of
a new rate is indicated by a calculation on the current row, Rx. For a new rate is indicated by a calculation on the current row, Rx. For
example: example:
skipping to change at page 16, line 35 skipping to change at page 16, line 41
information is accumulated until the feedback timer FT 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
However, if a rate threshold between high and very high sending rates offered load rate is only increased by one (Rx+1). However, if a
(such as 1 Gbps) is exceeded, the offered load rate is only increased rate threshold between high and very high sending rates (such as 1
by one (Rx+1) above the rate threshold in any congestion state. 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. The RECOMMENDED values are 0 for offered load rate is decreased. The RECOMMENDED threshold values are
sequence number gaps and 30 ms for lower and 90 ms for upper delay 0 for sequence number gaps and 30 ms for lower and 90 ms for upper
thresholds, respectively. Also, if congestion is now confirmed for delay thresholds, respectively. Also, if congestion is now confirmed
the first time by the current feedback message being processed, then for the first time by the current feedback message being processed,
the offered load rate is decreased by more than one rate (e.g., Rx- then the offered load rate is decreased by more than one rate (e.g.,
30). This one-time reduction is intended to compensate for the fast Rx-30). This one-time reduction is intended to compensate for the
initial ramp-up. In all other cases, the offered load rate is only fast initial ramp-up. In all other cases, the offered load rate is
decreased by one (Rx-1). 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
skipping to change at page 21, line 7 skipping to change at page 21, line 19
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 Maximum IP-Layer rate determined by the previous search for the Maximum IP-Layer
Capacity, to qualify the result in terms of the other performance Capacity, to qualify the result in terms of the other performance
metrics measured at the same time. metrics measured at the same time.
skipping to change at page 22, line 20 skipping to change at page 22, line 30
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. Both load packets and status feedback time or bytes sent or both. Both load packets and status feedback
messages MUST contain sequence numbers, which helps with measurements messages MUST contain sequence numbers, which helps with measurements
based on those packets. 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 23, line 33 skipping to change at page 23, line 45
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 rate adjustment (search) algorithm. load rate adjustment (search) algorithm.
It is obviously counter-productive to run more than one independent
test (regardless of the number of flows in the test stream)
attempting to measure the *maximum* capacity between the same Source
and Destination. The number of concurrent, independent tests between
the same Source and Destination SHALL be limited to one.
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 those results have improved continued testing with the metric, and those results have improved
the method described here. 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
skipping to change at page 26, line 22 skipping to change at page 26, line 39
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
skipping to change at page 27, line 23 skipping to change at page 27, line 41
5. Senders MUST be rate-limited. This can be accomplished using a 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 (for example, the frequency and/or overall volume of test traffic (for example, the
range of I duration values SHOULD be limited). 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, Martin Duke, Murray Wolfgang Balzer, Frank Brockners, Greg Mirsky, Martin Duke, Murray
Kucherawy, and Benjamin Kaduk for their extensive comments on the Kucherawy, and Benjamin Kaduk for their extensive comments on the
memo and related topics. memo and related topics. In a second round of reviews, we
acknowledge Magnus Westerlund, Lars Eggert, and Zahed Sarkar.
13. Appendix A - 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 = 0 # 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 Delay, RTD, ms delay = 0 # Measured Range of Round Trip Delay, RTD, ms
lowThresh = 30 # Low threshold on the Range of RTD, ms lowThresh = 30 # Low threshold on the Range of RTD, ms
skipping to change at page 30, line 4 skipping to change at page 31, line 4
there are no retransmissions needed. there are no retransmissions needed.
When a latency estimate is used to arm a timer that provides loss When a latency estimate is used to arm a timer that provides loss
detection -- with or without retransmission -- expiry of the timer detection -- with or without retransmission -- expiry of the timer
MUST be interpreted as an indication of congestion in the network, MUST be interpreted as an indication of congestion in the network,
causing the sending rate to be adapted to a safe conservative causing the sending rate to be adapted to a safe conservative
rate... rate...
The method described in this memo uses timers for sending rate The method described in this memo uses timers for sending rate
backoff when status feedback messages are lost (Lost Status Backoff backoff when status feedback messages are lost (Lost Status Backoff
timeout), and for stopping a test when connectivity is lost for an timeout), and for stopping a test when connectivity is lost for a
longer interval (Feedback message or load packet timeouts). longer interval (Feedback message or load packet timeouts).
There is no specific benefit foreseen by using Explicit Congestion There is no specific benefit foreseen by using Explicit Congestion
Notification (ECN) in this memo. Notification (ECN) in this memo.
Section 3.2 of [RFC8085] discusses message size guidelines: Section 3.2 of [RFC8085] discusses message size guidelines:
To determine an appropriate UDP payload size, applications MUST To determine an appropriate UDP payload size, applications MUST
subtract the size of the IP header (which includes any IPv4 subtract the size of the IP header (which includes any IPv4
optional headers or IPv6 extension headers) as well as the length optional headers or IPv6 extension headers) as well as the length
skipping to change at page 31, line 8 skipping to change at page 32, line 8
A specific recommendation is provided as an example. Section 3.1.5 A specific recommendation is provided as an example. Section 3.1.5
of [RFC8085] on implications of RTT and Loss Measurements on of [RFC8085] on implications of RTT and Loss Measurements on
Congestion Control says: Congestion Control says:
A congestion control designed for UDP SHOULD respond as quickly as A congestion control designed for UDP SHOULD respond as quickly as
possible when it experiences congestion, and it SHOULD take into possible when it experiences congestion, and it SHOULD take into
account both the loss rate and the response time when choosing a account both the loss rate and the response time when choosing a
new rate. new rate.
The load rate adjustment algorithm responds to loss and RTT The load rate adjustment algorithm responds to loss and RTT
measurements with a clear and concise rate reduction when warrented, measurements with a clear and concise rate reduction when warranted,
and the response makes use of direct measurements (more exact than and the response makes use of direct measurements (more exact than
can be inferred from TCP ACKs). can be inferred from TCP ACKs).
Section 3.1.5 of [RFC8085] goes on to specify: Section 3.1.5 of [RFC8085] goes on to specify:
The implemented congestion control scheme SHOULD result in The implemented congestion control scheme SHOULD result in
bandwidth (capacity) use that is comparable to that of TCP within bandwidth (capacity) use that is comparable to that of TCP within
an order of magnitude, so that it does not starve other flows an order of magnitude, so that it does not starve other flows
sharing a common bottleneck. sharing a common bottleneck.
skipping to change at page 31, line 36 skipping to change at page 32, line 36
launching many flows (9, for example) to increase the outstanding launching many flows (9, for example) to increase the outstanding
data dedicated to testing. data dedicated to testing.
The load rate adjustment algorithm cannot become a TCP-like The load rate adjustment algorithm cannot become a TCP-like
congestion control, or it will have the same weaknesses of TCP when congestion control, or it will have the same weaknesses of TCP when
trying to make a Maximum IP-Layer Capacity measurement, and will not trying to make a Maximum IP-Layer Capacity measurement, and will not
achieve the goal. The results of the referenced testing [LS-SG12-A] achieve the goal. The results of the referenced testing [LS-SG12-A]
[LS-SG12-B] [Y.Sup60] supported this statement hundreds of times, [LS-SG12-B] [Y.Sup60] supported this statement hundreds of times,
with comparisons to multi-connection TCP-based measurements. with comparisons to multi-connection TCP-based measurements.
A brief review of some of the other SHOULD-level requirements follows A brief review of some other SHOULD-level requirements follows (Yes
(Yes or Not applicable = NA) : or Not applicable = NA) :
+--+---------------------------------------------------------+---------+ +--+---------------------------------------------------------+---------+
|Y?| RFC 8085 Recommendation | Section | |Y?| RFC 8085 Recommendation | Section |
+--+---------------------------------------------------------+---------+ +--+---------------------------------------------------------+---------+
Yes| MUST tolerate a wide range of Internet path conditions | 3 | Yes| MUST tolerate a wide range of Internet path conditions | 3 |
NA | SHOULD use a full-featured transport (e.g., TCP) | | NA | SHOULD use a full-featured transport (e.g., TCP) | |
| | | | | |
Yes| SHOULD control rate of transmission | 3.1 | Yes| SHOULD control rate of transmission | 3.1 |
NA | SHOULD perform congestion control over all traffic | | NA | SHOULD perform congestion control over all traffic | |
| | | | | |
skipping to change at page 36, line 33 skipping to change at page 37, line 33
[Y.Sup60] Morton, A., "Recommendation Y.Sup60, (09/20) Interpreting [Y.Sup60] Morton, A., "Recommendation Y.Sup60, (09/20) Interpreting
ITU-T Y.1540 maximum IP-layer capacity measurements, and ITU-T Y.1540 maximum IP-layer capacity measurements, and
Errata", September 2020, Errata", September 2020,
<https://www.itu.int/rec/T-REC-Y.Sup60/en>. <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. 41 change blocks. 
102 lines changed or deleted 123 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/