--- 1/draft-ietf-ippm-capacity-metric-method-01.txt 2020-07-02 11:13:20.995996780 -0700 +++ 2/draft-ietf-ippm-capacity-metric-method-02.txt 2020-07-02 11:13:21.027997174 -0700 @@ -1,21 +1,21 @@ Network Working Group A. Morton Internet-Draft AT&T Labs Updates: ???? (if approved) R. Geib Intended status: Standards Track Deutsche Telekom -Expires: September 10, 2020 L. Ciavattone +Expires: December 31, 2020 L. Ciavattone AT&T Labs - March 9, 2020 + June 29, 2020 Metrics and Methods for IP Capacity - draft-ietf-ippm-capacity-metric-method-01 + draft-ietf-ippm-capacity-metric-method-02 Abstract This memo revisits the problem of Network Capacity metrics first examined in RFC 5136. The memo specifies a more practical Maximum IP-layer Capacity metric definition catering for measurement purposes, and outlines the corresponding methods of measurement. Requirements Language @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -80,28 +80,31 @@ 7. IP-Layer Sender Bit Rate Singleton Metric Definitions . . . . 11 7.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 12 7.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 12 7.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 12 7.5. Reporting the Metric . . . . . . . . . . . . . . . . . . 12 8. Method of Measurement . . . . . . . . . . . . . . . . . . . . 13 8.1. Load Rate Adjustment Algorithm . . . . . . . . . . . . . 13 8.2. Measurement Qualification or Verification . . . . . . . . 14 8.3. Measurement Considerations . . . . . . . . . . . . . . . 15 - 9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 16 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 - 13.2. Informative References . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + 8.4. Running Code . . . . . . . . . . . . . . . . . . . . . . 17 + 9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 17 + 9.1. Configuration and Reporting Data Formats . . . . . . . . 19 + + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 + 13.2. Informative References . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction The IETF's efforts to define Network and Bulk Transport Capacity have been chartered and progressed for over twenty years. Over that time, the performance community has seen development of Informative definitions in [RFC3148] for Framework for Bulk Transport Capacity (BTC), RFC 5136 for Network Capacity and Maximum IP-layer Capacity, and the Experimental metric definitions and methods in [RFC8337], Model-Based Metrics for BTC. @@ -151,21 +154,23 @@ communicated to achieve broad agreement, and possibly result in changes in the specifications of other Standards Development Organizations (SDO) (through the SDO's normal contribution process, or through liaison exchange). A local goal is to aid efficient test procedures where possible, and to recommend reporting with additional interpretation of the results. Also, to foster the development of protocol support for this metric and method of measurement (all active testing protocols currently 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 As with any problem that has been worked for many years in various SDOs without any special attempts at coordination, various solutions for metrics and methods have emerged. 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 requires features in the measurement design to account for the @@ -612,21 +617,22 @@ anomalies AND the delay variation was above the lower threshold, but below the upper threshold, the offered load rate is not changed. This allows time for recent changes in the offered load rate to stabilize, and the feedback to represent current conditions more accurately. Lastly, the method for confirming congestion is that there were sequence number anomalies OR the delay variation was above the upper threshold for two consecutive feedback intervals. The algorithm 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 When assessing a Maximum rate as the metric specifies, artificially high (optimistic) values might be measured until some buffer on the path is filled. Other causes include bursts of back-to-back packets with idle intervals delivered by a path, while the measurement interval (dt) is small and aligned with the bursts. The artificial values might result in an un-sustainable Maximum Capacity observed when the method of measurement is searching for the Maximum, and that @@ -725,25 +731,49 @@ following reasons: 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 flow each. 2. there may be link aggregation present (flow-based load balancing) and multiple flows are needed to occupy each member of the 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 Load Adjustment (Search) Algorithm. 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 The singleton IP-Layer Capacity results SHOULD be accompanied by the context under which they were measured. o timestamp (especially the time when the maximum was observed in dtn) o source and destination (by IP or other meaningful ID) @@ -806,20 +836,33 @@ IP-layer Sender Bit Rate Results Static and configuration parameters: The subinterval time, st, MUST accompany a report of Sender IP-Layer Bit Rate results. Also, the values of the remaining Parameters from Section 4, General 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 Active metrics and measurements have a long history of security considerations [add references to LMAP Framework, etc.]. 11. IANA Considerations This memo makes no requests of IANA. @@ -933,46 +976,40 @@ [copycat] Edleine, K., Kuhlewind, K., Trammell, B., and B. Donnet, "copycat: Testing Differential Treatment of New Transport Protocols in the Wild (ANRW '17)", July 2017, . [RFC8239] Avramov, L. and J. Rapp, "Data Center Benchmarking Methodology", RFC 8239, DOI 10.17487/RFC8239, August 2017, . + [TR-471] Morton, A., "Broadband Forum TR-471: IP Layer Capacity + Metrics and Measurement", July 2020, + . + [TST009] Morton, R. A., "ETSI GS NFV-TST 009 V3.1.1 (2018-10), "Network Functions Virtualisation (NFV) Release 3; Testing; Specification of Networking Benchmarks and Measurement Methods for NFVI"", October 2018, . - [VSPERF-b2b] - Morton, A., "Back2Back Testing Time Series (from CI)", - June 2017, . - - [VSPERF-BSLV] - Morton, A. and S. Rao, "Evolution of Repeatability in - Benchmarking: Fraser Plugfest (Summary for IETF BMWG)", - July 2018, - . - [Y.1540] Y.1540, I. R., "Internet protocol data communication service - IP packet transfer and availability performance parameters", January 2020, . + [Y.Sup60] Morton, A., "Recommendation Y.Sup60, (04/20) Interpreting + ITU-T Y.1540 maximum IP-layer capacity measurements", June + 2020, . + Authors' Addresses Al Morton AT&T Labs 200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: +1 732 420 1571 Fax: +1 732 368 1192