draft-ietf-ippm-capacity-metric-method-02.txt   draft-ietf-ippm-capacity-metric-method-03.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Updates: ???? (if approved) R. Geib Updates: ???? (if approved) R. Geib
Intended status: Standards Track Deutsche Telekom Intended status: Standards Track Deutsche Telekom
Expires: December 31, 2020 L. Ciavattone Expires: February 15, 2021 L. Ciavattone
AT&T Labs AT&T Labs
June 29, 2020 August 14, 2020
Metrics and Methods for IP Capacity Metrics and Methods for IP Capacity
draft-ietf-ippm-capacity-metric-method-02 draft-ietf-ippm-capacity-metric-method-03
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.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14[RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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 December 31, 2020. This Internet-Draft will expire on February 15, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
2. Scope and Goals . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope and Goals . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. General Parameters and Definitions . . . . . . . . . . . . . 5 4. General Parameters and Definitions . . . . . . . . . . . . . 5
5. IP-Layer Capacity Singleton Metric Definitions . . . . . . . 6 5. IP-Layer Capacity Singleton Metric Definitions . . . . . . . 6
5.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 6 5.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 6
5.4. Related Round-Trip Delay and Loss Definitions . . . . . . 8 5.4. Related Round-Trip Delay and Loss Definitions . . . . . . 8
5.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 5.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8
5.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 8 5.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 8
skipping to change at page 3, line 4 skipping to change at page 2, line 41
7.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 12 7.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 12
7.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 12 7.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 12
7.5. Reporting the Metric . . . . . . . . . . . . . . . . . . 12 7.5. Reporting the Metric . . . . . . . . . . . . . . . . . . 12
8. Method of Measurement . . . . . . . . . . . . . . . . . . . . 13 8. Method of Measurement . . . . . . . . . . . . . . . . . . . . 13
8.1. Load Rate Adjustment Algorithm . . . . . . . . . . . . . 13 8.1. Load Rate Adjustment Algorithm . . . . . . . . . . . . . 13
8.2. Measurement Qualification or Verification . . . . . . . . 14 8.2. Measurement Qualification or Verification . . . . . . . . 14
8.3. Measurement Considerations . . . . . . . . . . . . . . . 15 8.3. Measurement Considerations . . . . . . . . . . . . . . . 15
8.4. Running Code . . . . . . . . . . . . . . . . . . . . . . 17 8.4. Running Code . . . . . . . . . . . . . . . . . . . . . . 17
9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 17 9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Configuration and Reporting Data Formats . . . . . . . . 19 9.1. Configuration and Reporting Data Formats . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . 21 13.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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.
skipping to change at page 4, line 7 skipping to change at page 3, line 48
support UDP transport. A number of liaisons have been exchanged on support UDP transport. A number of liaisons have been exchanged on
this topic [ refs to ITU-T SG12, ETSI STQ, BBF liaisons ], discussing this topic [ refs to ITU-T SG12, ETSI STQ, BBF liaisons ], discussing
the laboratory and field tests that support the UDP-based approach to the laboratory and field tests that support the UDP-based approach to
IP-layer Capacity measurement. 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 RFC use of [RFC7312] for Advanced Stream and Sampling Framework, and RFC
8468 [RFC8468]IPv4, IPv6, and IPv4-IPv6 Coexistence Updates. 8468 [RFC8468]IPv4, IPv6, and IPv4-IPv6 Coexistence Updates.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14[RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Scope and Goals 2. Scope and Goals
The scope of this memo is to define a metric and corresponding method The scope of this memo is to define a metric and corresponding method
to unambiguously perform Active measurements of Maximum IP-Layer to unambiguously perform Active measurements of Maximum IP-Layer
Capacity, along with related metrics and methods. Capacity, along with related metrics and methods.
The main goal is to harmonize the specified metric and method across The main 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 through which working
group (and eventually, IETF) consensus will be captured and group (and eventually, IETF) consensus will be captured and
communicated to achieve broad agreement, and possibly result in communicated to achieve broad agreement, and possibly result in
skipping to change at page 13, line 16 skipping to change at page 13, line 16
The duration of a test, I, MUST be constrained in a production The duration of a test, I, MUST be constrained in a production
network, since this is an active test method and it will likely cause network, since this is an active test method and it will likely cause
congestion on the Src to Dst host path during a test. congestion on the Src to Dst host path during a test.
Additional Test methods and configurations may be provided in this Additional Test methods and configurations may be provided in this
section, after review and further testing. section, after review and further testing.
8.1. Load Rate Adjustment Algorithm 8.1. Load Rate Adjustment Algorithm
A table is pre-built defining all the offered load rates that will be A table SHALL be pre-built defining all the offered load rates that
supported (R1 - Rn, in ascending order). Each rate is defined as will be supported (R1 - Rn, in ascending order). Each rate is
datagrams of size S, sent as a burst of count C, every time interval defined as datagrams of size S, sent as a burst of count C, every
T. While it is advantageous to use datagrams of as large a size as time interval T. While it is advantageous to use datagrams of as
possible, it may be prudent to use a slightly smaller maximum that large a size as possible, it may be prudent to use a slightly smaller
allows for secondary protocol headers and/or tunneling without maximum that allows for secondary protocol headers and/or tunneling
resulting in IP-layer fragmentation. without resulting in IP-layer fragmentation.
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 at interval F (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 variation is measured (one-way or round-trip). This the delay variation 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 F 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
skipping to change at page 17, line 10 skipping to change at page 17, line 10
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 method described here.
8.4. Running Code 8.4. Running Code
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). 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 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.
Watch this space for the URL to the opensource project. o Supports IPv4 and IPv6 address families.
o
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)
skipping to change at page 19, line 21 skipping to change at page 19, line 21
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 als carefully full data model in related BBF work. The BBF has als carefully
considered topics within its purvue, such as placement of measurement considered topics within its purvue, such as placement of measurement
systems within the access archtecture. systems within the access archtecture.
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 [add references to LMAP Framework, etc.]. considerations. The security considerations that apply to any active
measurement of live paths are relevant here. See [RFC4656] and
[RFC5357].
<There are certainly some new ones for Capacity testing> When considering privacy of those involved in measurement or those
whose traffic is measured, the sensitive information available to
potential observers is greatly reduced when using active techniques
which are within this scope of work. Passive observations of user
traffic for measurement purposes raise many privacy issues. We refer
the reader to the privacy considerations described in the Large Scale
Measurement of Broadband Performance (LMAP) Framework [RFC7594],
which covers active and passive techniques.
There are some new considerations for Capacity measurement as
described in this memo.
1. Cooperating Source and Destination hosts and agreements to test
the path between the hosts are REQUIRED.
2. Integrity protection for feedback messages conveying measurements
is RECOMMENDED.
3. Hosts SHOULD limit the number of simultaneous tests to avoid
resource exhaust and inaccuate results.
4. Senders MUST be rate-limited. This can be accomplished using the
pre-built table defining all the offered load rates that will be
supported (Section 8.1). The recommended load-control search
algorithm results in "ramp up" from the lowest rate in the table.
5. Service subscribers with limited data volumes who conduct
extensive capacity testing might experience the effects of
Service Provider controls on their service. Testing with the
Service Provider's measurement hosts SHOULD be limited in
frequency and/or overall volume of test traffic.
The exact specification of these features is left for the future
protocol development.
11. IANA Considerations 11. IANA Considerations
This memo makes no requests of IANA. This memo makes no requests of IANA.
12. Acknowledgements 12. Acknowledgements
Thanks to Joachim Fabini, Matt Mathis, Ignacio Alvarez-Hamelin, and Thanks to Joachim Fabini, Matt Mathis, Ignacio Alvarez-Hamelin, and
Wolfgang Balzer for their extensive comments on the memo and related Wolfgang Balzer for their extensive comments on the memo and related
topics. topics.
skipping to change at page 20, line 24 skipping to change at page 21, line 10
[RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology [RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology
for LAN Switching Devices", RFC 2889, for LAN Switching Devices", RFC 2889,
DOI 10.17487/RFC2889, August 2000, DOI 10.17487/RFC2889, August 2000,
<https://www.rfc-editor.org/info/rfc2889>. <https://www.rfc-editor.org/info/rfc2889>.
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining
Empirical Bulk Transfer Capacity Metrics", RFC 3148, Empirical Bulk Transfer Capacity Metrics", RFC 3148,
DOI 10.17487/RFC3148, July 2001, DOI 10.17487/RFC3148, July 2001,
<https://www.rfc-editor.org/info/rfc3148>. <https://www.rfc-editor.org/info/rfc3148>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<https://www.rfc-editor.org/info/rfc4656>.
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity",
RFC 5136, DOI 10.17487/RFC5136, February 2008, RFC 5136, DOI 10.17487/RFC5136, February 2008,
<https://www.rfc-editor.org/info/rfc5136>. <https://www.rfc-editor.org/info/rfc5136>.
[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D.
Dugatkin, "IPv6 Benchmarking Methodology for Network Dugatkin, "IPv6 Benchmarking Methodology for Network
Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May
2008, <https://www.rfc-editor.org/info/rfc5180>. 2008, <https://www.rfc-editor.org/info/rfc5180>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/info/rfc5357>.
[RFC6201] Asati, R., Pignataro, C., Calabria, F., and C. Olvera, [RFC6201] Asati, R., Pignataro, C., Calabria, F., and C. Olvera,
"Device Reset Characterization", RFC 6201, "Device Reset Characterization", RFC 6201,
DOI 10.17487/RFC6201, March 2011, DOI 10.17487/RFC6201, March 2011,
<https://www.rfc-editor.org/info/rfc6201>. <https://www.rfc-editor.org/info/rfc6201>.
[RFC6412] Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology [RFC6412] Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology
for Benchmarking Link-State IGP Data-Plane Route for Benchmarking Link-State IGP Data-Plane Route
Convergence", RFC 6412, DOI 10.17487/RFC6412, November Convergence", RFC 6412, DOI 10.17487/RFC6412, November
2011, <https://www.rfc-editor.org/info/rfc6412>. 2011, <https://www.rfc-editor.org/info/rfc6412>.
skipping to change at page 21, line 21 skipping to change at page 22, line 15
[RFC6985] Morton, A., "IMIX Genome: Specification of Variable Packet [RFC6985] Morton, A., "IMIX Genome: Specification of Variable Packet
Sizes for Additional Testing", RFC 6985, Sizes for Additional Testing", RFC 6985,
DOI 10.17487/RFC6985, July 2013, DOI 10.17487/RFC6985, July 2013,
<https://www.rfc-editor.org/info/rfc6985>. <https://www.rfc-editor.org/info/rfc6985>.
[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling
Framework for IP Performance Metrics (IPPM)", RFC 7312, Framework for IP Performance Metrics (IPPM)", RFC 7312,
DOI 10.17487/RFC7312, August 2014, DOI 10.17487/RFC7312, August 2014,
<https://www.rfc-editor.org/info/rfc7312>. <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 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/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 [RFC8337] Mathis, M. and A. Morton, "Model-Based Metrics for Bulk
Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March
skipping to change at page 21, line 52 skipping to change at page 23, line 7
"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>.
[RFC8239] Avramov, L. and J. Rapp, "Data Center Benchmarking [RFC8239] Avramov, L. and J. Rapp, "Data Center Benchmarking
Methodology", RFC 8239, DOI 10.17487/RFC8239, August 2017, Methodology", RFC 8239, DOI 10.17487/RFC8239, August 2017,
<https://www.rfc-editor.org/info/rfc8239>. <https://www.rfc-editor.org/info/rfc8239>.
[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://not.yet.available>. <https://www.broadband-forum.org/technical/download/TR-
471.pdf>.
[TST009] Morton, R. A., "ETSI GS NFV-TST 009 V3.1.1 (2018-10), [TST009] Morton, R. A., "ETSI GS NFV-TST 009 V3.1.1 (2018-10),
"Network Functions Virtualisation (NFV) Release 3; "Network Functions Virtualisation (NFV) Release 3;
Testing; Specification of Networking Benchmarks and Testing; Specification of Networking Benchmarks and
Measurement Methods for NFVI"", October 2018, Measurement Methods for NFVI"", October 2018,
<https://www.etsi.org/deliver/etsi_gs/NFV- <https://www.etsi.org/deliver/etsi_gs/NFV-
TST/001_099/009/03.01.01_60/gs_NFV-TST009v030101p.pdf>. TST/001_099/009/03.01.01_60/gs_NFV-TST009v030101p.pdf>.
[udpst] AT&T, "UDP Speed Test Open Broadband project", August
2020, <https://github.com/BroadbandForum <TBD>>.
[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", January 2020, parameters", December 2019,
<https://www.itu.int/rec/T-REC-Y.1540-201103-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, (04/20) Interpreting
ITU-T Y.1540 maximum IP-layer capacity measurements", June ITU-T Y.1540 maximum IP-layer capacity measurements", June
2020, <https://www.itu.int/rec/T-REC-Y.Sup60/en>. 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
 End of changes. 20 change blocks. 
33 lines changed or deleted 90 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/