draft-ietf-ippm-capacity-metric-method-08.txt   draft-ietf-ippm-capacity-metric-method-09.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: September 30, 2021 Deutsche Telekom Expires: October 2, 2021 Deutsche Telekom
L. Ciavattone L. Ciavattone
AT&T Labs AT&T Labs
March 29, 2021 March 31, 2021
Metrics and Methods for One-way IP Capacity Metrics and Methods for One-way IP Capacity
draft-ietf-ippm-capacity-metric-method-08 draft-ietf-ippm-capacity-metric-method-09
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 September 30, 2021. This Internet-Draft will expire on October 2, 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 37 skipping to change at page 2, line 37
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 . . . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . 21 8.3. Measurement Considerations . . . . . . . . . . . . . . . 22
8.4. Running Code . . . . . . . . . . . . . . . . . . . . . . 23 8.4. Running Code . . . . . . . . . . . . . . . . . . . . . . 23
9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 24 9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Configuration and Reporting Data Formats . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . . . 27
13. Appendix A - Load Rate Adjustment Pseudo Code . . . . . . . . 27 13. Appendix A - Load Rate Adjustment Pseudo Code . . . . . . . . 27
14. Appendix B - RFC 8085 UDP Guidelines Check . . . . . . . . . 28 14. Appendix B - RFC 8085 UDP Guidelines Check . . . . . . . . . 28
14.1. Assessment of Mandatory Requirements . . . . . . . . . . 28 14.1. Assessment of Mandatory Requirements . . . . . . . . . . 28
14.2. Assessment of Recommendations . . . . . . . . . . . . . 30 14.2. Assessment of Recommendations . . . . . . . . . . . . . 30
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
15.1. Normative References . . . . . . . . . . . . . . . . . . 33 15.1. Normative References . . . . . . . . . . . . . . . . . . 33
15.2. Informative References . . . . . . . . . . . . . . . . . 34 15.2. Informative References . . . . . . . . . . . . . . . . . 34
skipping to change at page 4, line 34 skipping to change at page 4, line 34
A local goal is to aid efficient test procedures where possible, and A local goal is to aid efficient test procedures where possible, and
to recommend reporting with additional interpretation of the results. to recommend reporting with additional interpretation of the results.
Fostering the development of protocol support for this metric and Fostering the development of protocol support for this metric and
method of measurement is also a goal of this memo (all active testing method of measurement is also a goal of this memo (all active testing
protocols currently defined by the IPPM WG are UDP-based, meeting a protocols currently defined by the IPPM WG are UDP-based, meeting a
key requirement of these methods). The supporting protocol key requirement of these methods). The supporting protocol
development to measure this metric according to the specified method development to measure this metric according to the specified method
is a key future contribution to Internet measurement. is a key future contribution to Internet measurement.
The load rate adjustment algorithm's goal is to determine the Maximum The load rate adjustment algorithm's scope is limited to helping
IP-Layer Capacity in the context of an infrequent, diagnostic, short determine the Maximum IP-Layer Capacity in the context of an
term measurement. It is RECOMMENDED to discontinue non-measurement infrequent, diagnostic, short term measurement. It is RECOMMENDED to
traffic that shares a subscriber's dedicated resources while testing. 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 The primary application of the metric and method of measurement
described here is the same as in Section 2 of [RFC7479] where: described here is the same as in Section 2 of [RFC7479] 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 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
skipping to change at page 15, line 33 skipping to change at page 15, line 33
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
The algorithm described in this section MUST NOT be used as a as a
general Congestion Control Algorithm (CCA). As stated in the Scope
Section 2, the load rate adjustment algorithm's goal is to help
determine the Maximum IP-Layer Capacity in the context of an
infrequent, diagnostic, short term measurement. There is a tradeoff
between test duration (also the test data volume) and algorithm
agressiveness (speed of ramp-up and down to the Maximum Capacity).
The parameter values chosen below strike a well-tested balance among
these factors.
A table SHALL be pre-built defining all the offered load rates that A table SHALL be pre-built defining all the offered load rates that
will be supported (R1 through Rn, in ascending order, corresponding will be supported (R1 through Rn, in ascending order, corresponding
to indexed rows in the table). It is RECOMMENDED that rates begin 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 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 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, it is RECOMMENDED that 100 Mbps increments be used. Above 10
Gbps, increments of 1 Gbps are RECOMMENDED. A higher starting rate Gbps, increments of 1 Gbps are RECOMMENDED. A higher starting rate
might be configured when the test operator is certain that the might be configured when the test operator is certain that the
Maximum is well-above the starting rate and factors such as test Maximum is well-above the starting rate and factors such as test
duration and total test traffic play an important role. duration and total test traffic play an important role.
skipping to change at page 19, line 27 skipping to change at page 19, line 37
Parameters for Load Rate Adjustment Algorithm Parameters for Load Rate Adjustment Algorithm
As a consequence of default parameterization, the Number of table As a consequence of default parameterization, the Number of table
steps in total for rates <10Gbps is 2000 (excluding index 0). steps in total for rates <10Gbps is 2000 (excluding index 0).
A related sender backoff response to network conditions occurs when A related sender backoff response to network conditions occurs when
one or more status feedback messages fail to arrive at the sender. one or more status feedback messages fail to arrive at the sender.
If no status feedback messages arrive at the sender for the interval If no status feedback messages arrive at the sender for the interval
greater than the Lost Status Backoff timeout = w*FT, beginning when greater than the Lost Status Backoff timeout:
the last message (of any type) was successfully received at the
sender: HDRT + (2+w)*FT = Lost Status Backoff timeout
where:
HDRT = high 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 Then the offered load SHALL be decreased, following the same process
as when the feedback indicates presence of one or more sequence as when the feedback indicates presence of one or more sequence
number anomalies OR the delay range was above the upper threshold (as number anomalies OR the delay range was above the upper threshold (as
described above), with the same Load Rate Adjustment algorithm described above), with the same Load Rate Adjustment algorithm
variables in their current state. This means that rate reduction and variables in their current state. This means that rate reduction and
congestion confirmation can result from a three-way OR that includes congestion confirmation can result from a three-way OR that includes
lost status feedback messages, sequence errors, or delay variation. lost status feedback messages, sequence errors, or delay variation.
The RECOMMENDED initial value for w is 3, taking Round Trip Time 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 (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. valid reason to increase the initial value of w appropriately.
Variable w SHALL be incremented by 1 whenever the Lost Status Backoff Variable w SHALL be incremented by 1 whenever the Lost Status Backoff
timeout is exceeded. So with FT = 50ms, a status feedback message timeout is exceeded. So with FT = 50ms and HDRT = 90ms, a status
loss would be declared at 150ms following a successful message, again feedback message loss would be declared at 190ms following a
at 50ms after that (200ms total), and so on. 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 Also, if congestion is now confirmed for the first time by a Lost
Status Backoff timeout, then the offered load rate is decreased by Status Backoff timeout, then the offered load rate is decreased by
more than one rate (e.g., Rx-30). This one-time reduction is 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 intended to compensate for the fast initial ramp-up. In all other
cases, the offered load rate is only decreased by one (Rx-1). cases, the offered load rate is only decreased by one (Rx-1).
Appendix B discusses compliance with the applicable mandatory Appendix B discusses compliance with the applicable mandatory
requirements of [RFC8085], consistent with the goals of the IP-Layer requirements of [RFC8085], consistent with the goals of the IP-Layer
Capacity Metric and Method, including the load rate adjustment Capacity Metric and Method, including the load rate adjustment
skipping to change at page 25, line 15 skipping to change at page 25, line 38
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 Bit Rate, 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 29, line 26 skipping to change at page 29, line 26
to probe the network and enable Maximum IP-Layer Capacity to probe the network and enable Maximum IP-Layer Capacity
measurements with as few assumptions about the measured path as measurements with as few assumptions about the measured path as
possible, and within the range application described in Section 2. possible, and within the range application described in Section 2.
The degree of probing conservatism is in tension with the need to The degree of probing conservatism is in tension with the need to
minimize both the traffic dedicated to testing (especially with minimize both the traffic dedicated to testing (especially with
Gigabit rate measurements) and the duration of the test (which is one Gigabit rate measurements) and the duration of the test (which is one
contributing factor to the overall algorithm fairness). contributing factor to the overall algorithm fairness).
The text of Section 3 of [RFC8085] goes on to recommend alternatives The text of Section 3 of [RFC8085] goes on to recommend alternatives
to UDP to meet the mandatory requirements, but none are suitable for to UDP to meet the mandatory requirements, but none are suitable for
this scope and purpose of the metrics and methods in this memo. In the scope and purpose of the metrics and methods in this memo. In
fact, ad hoc TCP-based methods fail to achieve the measurement fact, ad hoc TCP-based methods fail to achieve the measurement
accuracy repeatedly proven in comparison measurements with the accuracy repeatedly proven in comparison measurements with the
running code [LS-SG12-A] [LS-SG12-B] [Y.Sup60]. Also, the UDP aspect running code [LS-SG12-A] [LS-SG12-B] [Y.Sup60]. Also, the UDP aspect
of these methods is present primarily to support modern Internet of these methods is present primarily to support modern Internet
transmission where a transport protocol is required [copycat]; the transmission where a transport protocol is required [copycat]; the
metric is based on the IP-layer and UDP allows simple correlation to metric is based on the IP-layer and UDP allows simple correlation to
the IP-layer. the IP-layer.
Section 3.1.1 of [RFC8085] discusses protocol timer guidelines: Section 3.1.1 of [RFC8085] discusses protocol timer guidelines:
skipping to change at page 30, line 33 skipping to change at page 30, line 33
Applications that do require reliable message delivery MUST Applications that do require reliable message delivery MUST
implement an appropriate mechanism themselves. implement an appropriate mechanism themselves.
The IP-Layer Capacity Metric and Method do not require reliable The IP-Layer Capacity Metric and Method do not require reliable
delivery. delivery.
Applications that require ordered delivery MUST reestablish Applications that require ordered delivery MUST reestablish
datagram ordering themselves. datagram ordering themselves.
The IP-Layer Capacity Metric and Method does not need to reestablish The IP-Layer Capacity Metric and Method does not need to reestablish
packet order, it is preferred to measure packet reordering if it packet order; it is preferred to measure packet reordering if it
occurs [RFC4737]. occurs [RFC4737].
14.2. Assessment of Recommendations 14.2. Assessment of Recommendations
The load rate adjustment algorithm's goal is to determine the Maximum The load rate adjustment algorithm's goal is to determine the Maximum
IP-Layer Capacity in the context of an infrequent, diagnostic, short IP-Layer Capacity in the context of an infrequent, diagnostic, short
term measurement. This goal is a global exception to many [RFC8085] term measurement. This goal is a global exception to many [RFC8085]
SHOULD-level requirements, of which many are intended for long-lived SHOULD-level requirements, of which many are intended for long-lived
flows that must coexist with other traffic in more-or-less fair way. 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 However, the algorithm (as specified in Section 8.1 and Appendix A
above) reacts to indications of congestion i clearly defined ways. above) reacts to indications of congestion in clearly defined ways.
A specific example is provided as an example. Section 3.1.5 of A specific recommendation is provided as an example. Section 3.1.5
[RFC8085] on implications of RTT and Loss Measurements on COngestion of [RFC8085] on implications of RTT and Loss Measurements on
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 warrented,
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).
skipping to change at page 31, line 30 skipping to change at page 31, line 30
and infrequent measurements using short durations. The rate and infrequent measurements using short durations. The rate
oscillations during short tests allow other packets to pass, and oscillations during short tests allow other packets to pass, and
don't starve other flows. don't starve other flows.
Ironically, ad hoc TCP-based measurements of "Internet Speed" are Ironically, ad hoc TCP-based measurements of "Internet Speed" are
also designed to work around this SHOULD-level requirement, by also designed to work around this SHOULD-level requirement, by
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 has congestion control, or it will have the same weaknesses of TCP when
when trying to make a Maximum IP-Layer Capacity measurement, and will trying to make a Maximum IP-Layer Capacity measurement, and will not
not achieve the goal. The results of the referenced testing achieve the goal. The results of the referenced testing [LS-SG12-A]
[LS-SG12-A] [LS-SG12-B] [Y.Sup60] supported this statement hundreds [LS-SG12-B] [Y.Sup60] supported this statement hundreds of times,
of times, with comparisons to multi-connection TCP-based with comparisons to multi-connection TCP-based measurements.
measurements.
A brief review of some of the other SHOULD-level requirements follows A brief review of some of the other SHOULD-level requirements follows
(Yes or Not applicable = NA) : (Yes 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) | |
| | | | | |
 End of changes. 17 change blocks. 
39 lines changed or deleted 59 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/