draft-ietf-ippm-capacity-metric-method-01.txt   draft-ietf-ippm-capacity-metric-method-02.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: September 10, 2020 L. Ciavattone Expires: December 31, 2020 L. Ciavattone
AT&T Labs AT&T Labs
March 9, 2020 June 29, 2020
Metrics and Methods for IP Capacity Metrics and Methods for IP Capacity
draft-ietf-ippm-capacity-metric-method-01 draft-ietf-ippm-capacity-metric-method-02
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 Requirements Language
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 10, 2020. This Internet-Draft will expire on December 31, 2020.
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
skipping to change at page 2, line 50 skipping to change at page 2, line 50
7. IP-Layer Sender Bit Rate Singleton Metric Definitions . . . . 11 7. IP-Layer Sender Bit Rate Singleton Metric Definitions . . . . 11
7.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 12
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
9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 16 8.4. Running Code . . . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9.1. Configuration and Reporting Data Formats . . . . . . . . 19
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . 20 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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 24 skipping to change at page 4, line 26
communicated to achieve broad agreement, and possibly result in communicated to achieve broad agreement, and possibly result in
changes in the specifications of other Standards Development changes in the specifications of other Standards Development
Organizations (SDO) (through the SDO's normal contribution process, Organizations (SDO) (through the SDO's normal contribution process,
or through liaison exchange). or through liaison exchange).
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.
Also, to foster the development of protocol support for this metric Also, to foster the development of protocol support for this metric
and method of measurement (all active testing protocols currently and method of measurement (all active testing protocols currently
defined by the IPPM WG are UDP-based, meeting a key requirement of defined by the IPPM WG are UDP-based, meeting a key requirement of
these methods). these methods). The supporting protocol development to measure this
metric according to the specified method is a key future contribution
to Internet measurement.
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
skipping to change at page 14, line 16 skipping to change at page 14, line 16
anomalies AND the delay variation was above the lower threshold, but anomalies AND the delay variation 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 confirming congestion is that there were Lastly, the method for confirming congestion is that there were
sequence number anomalies OR the delay variation was above the upper sequence number anomalies OR the delay variation was above the upper
threshold for two consecutive feedback intervals. The algorithm threshold for two consecutive feedback intervals. The algorithm
described above is also presented in ITU-T Rec. Y.1540, 2020 described above is also presented in ITU-T Rec. Y.1540, 2020
version[Y.1540], in Annexes A and B. version[Y.1540], in Annexes A and B, and implemented in the reference
for Section 8.4, Running Code.
8.2. Measurement Qualification or Verification 8.2. Measurement Qualification or Verification
When assessing a Maximum rate as the metric specifies, artificially When assessing a Maximum rate as the metric specifies, artificially
high (optimistic) values might be measured until some buffer on the high (optimistic) values might be measured until some buffer on the
path is filled. Other causes include bursts of back-to-back packets path is filled. Other causes include bursts of back-to-back packets
with idle intervals delivered by a path, while the measurement with idle intervals delivered by a path, while the measurement
interval (dt) is small and aligned with the bursts. The artificial interval (dt) is small and aligned with the bursts. The artificial
values might result in an un-sustainable Maximum Capacity observed values might result in an un-sustainable Maximum Capacity observed
when the method of measurement is searching for the Maximum, and that when the method of measurement is searching for the Maximum, and that
skipping to change at page 16, line 32 skipping to change at page 16, line 36
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
Type-P of packets, possibly reserving capacity for various stream
types.
Each flow would be controlled using its own implementation of the Each flow would be controlled using its own implementation of the
Load Adjustment (Search) Algorithm. Load Adjustment (Search) Algorithm.
As testing continues, implementers should expect some evolution in As testing continues, implementers should expect some evolution in
the methods. the methods. The ITU-T has published a Supplement (60) to the
Y-series of Recommendations, "Interpreting ITU-T Y.1540 maximum IP-
layer capacity measurements", [Y.Sup60], which is the result of
continued testing with the metric and method described here.
8.4. Running Code
Much of the development of the method and comparisons with existing
methods conducted at IETF Hackathons and elsewhere have been based on
the example udpst Linux measurement tool (which is a working
reference for further development). The current project:
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
run-time libraries
o allows configuration of most of the parameters described in
Sections 4 and 7.
Watch this space for the URL to the opensource project.
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 18, line 24 skipping to change at page 19, line 5
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.
9.1. Configuration and Reporting Data Formats
As a part of the multi-Standards Development Organization (SDO)
harmonization of this metric and method of measurement, one of the
areas where the Broadband Forum (BBF) contributed its expertise was
in the definition of an information model and data model for
configuration and reporting. These models are consistent with the
metric parameters and default values specified as lists is this memo.
[TR-471] provides the Information model that was used to prepare a
full data model in related BBF work. The BBF has als carefully
considered topics within its purvue, such as placement of measurement
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 [add references to LMAP Framework, etc.].
<There are certainly some new ones for Capacity testing> <There are certainly some new ones for Capacity testing>
11. IANA Considerations 11. IANA Considerations
This memo makes no requests of IANA. This memo makes no requests of IANA.
skipping to change at page 21, line 5 skipping to change at page 21, line 50
[copycat] Edleine, K., Kuhlewind, K., Trammell, B., and B. Donnet, [copycat] Edleine, K., Kuhlewind, K., Trammell, B., and B. Donnet,
"copycat: Testing Differential Treatment of New Transport "copycat: Testing Differential Treatment of New Transport
Protocols in the Wild (ANRW '17)", July 2017, Protocols in the Wild (ANRW '17)", July 2017,
<https://irtf.org/anrw/2017/anrw17-final5.pdf>. <https://irtf.org/anrw/2017/anrw17-final5.pdf>.
[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
Metrics and Measurement", July 2020,
<https://not.yet.available>.
[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>.
[VSPERF-b2b]
Morton, A., "Back2Back Testing Time Series (from CI)",
June 2017, <https://wiki.opnfv.org/display/vsperf/
Traffic+Generator+Testing#TrafficGeneratorTesting-
AppendixB:Back2BackTestingTimeSeries(fromCI)>.
[VSPERF-BSLV]
Morton, A. and S. Rao, "Evolution of Repeatability in
Benchmarking: Fraser Plugfest (Summary for IETF BMWG)",
July 2018,
<https://datatracker.ietf.org/meeting/102/materials/
slides-102-bmwg-evolution-of-repeatability-in-
benchmarking-fraser-plugfest-summary-for-ietf-bmwg-00>.
[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", January 2020,
<https://www.itu.int/rec/T-REC-Y.1540-201103-I/en>. <https://www.itu.int/rec/T-REC-Y.1540-201103-I/en>.
[Y.Sup60] Morton, A., "Recommendation Y.Sup60, (04/20) Interpreting
ITU-T Y.1540 maximum IP-layer capacity measurements", June
2020, <https://www.itu.int/rec/T-REC-Y.Sup60/en>.
Authors' Addresses Authors' Addresses
Al Morton Al Morton
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
Middletown,, NJ 07748 Middletown,, NJ 07748
USA USA
Phone: +1 732 420 1571 Phone: +1 732 420 1571
Fax: +1 732 368 1192 Fax: +1 732 368 1192
 End of changes. 13 change blocks. 
29 lines changed or deleted 66 lines changed or added

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