--- 1/draft-ietf-ippm-capacity-metric-method-02.txt 2020-08-14 15:13:43.889298631 -0700 +++ 2/draft-ietf-ippm-capacity-metric-method-03.txt 2020-08-14 15:13:44.005300259 -0700 @@ -1,72 +1,65 @@ Network Working Group A. Morton Internet-Draft AT&T Labs Updates: ???? (if approved) R. Geib Intended status: Standards Track Deutsche Telekom -Expires: December 31, 2020 L. Ciavattone +Expires: February 15, 2021 L. Ciavattone AT&T Labs - June 29, 2020 + August 14, 2020 Metrics and Methods for IP Capacity - draft-ietf-ippm-capacity-metric-method-02 + draft-ietf-ippm-capacity-metric-method-03 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 - - 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 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 December 31, 2020. + This Internet-Draft will expire on February 15, 2021. 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Scope and Goals . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. General Parameters and Definitions . . . . . . . . . . . . . 5 5. IP-Layer Capacity Singleton Metric Definitions . . . . . . . 6 5.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 6 5.4. Related Round-Trip Delay and Loss Definitions . . . . . . 8 5.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 5.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 8 @@ -83,28 +76,27 @@ 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 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 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 + 13.2. Informative References . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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. @@ -135,20 +127,28 @@ support UDP transport. A number of liaisons have been exchanged on this topic [ refs to ITU-T SG12, ETSI STQ, BBF liaisons ], discussing the laboratory and field tests that support the UDP-based approach to IP-layer Capacity measurement. This memo also recognizes the many updates to the IP Performance Metrics Framework [RFC2330] published over twenty years, and makes use of [RFC7312] for Advanced Stream and Sampling Framework, and RFC 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 The scope of this memo is to define a metric and corresponding method to unambiguously perform Active measurements of Maximum IP-Layer Capacity, along with related metrics and methods. The main goal is to harmonize the specified metric and method across the industry, and this memo is the vehicle through which working group (and eventually, IETF) consensus will be captured and communicated to achieve broad agreement, and possibly result in @@ -569,27 +569,27 @@ 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 congestion on the Src to Dst host path during a test. Additional Test methods and configurations may be provided in this section, after review and further testing. 8.1. Load Rate Adjustment Algorithm - A table is pre-built defining all the offered load rates that will be - supported (R1 - Rn, in ascending order). Each rate is defined as - datagrams of size S, sent as a burst of count C, every time interval - T. While it is advantageous to use datagrams of as large a size as - possible, it may be prudent to use a slightly smaller maximum that - allows for secondary protocol headers and/or tunneling without - resulting in IP-layer fragmentation. + A table SHALL be pre-built defining all the offered load rates that + will be supported (R1 - Rn, in ascending order). Each rate is + defined as datagrams of size S, sent as a burst of count C, every + time interval T. While it is advantageous to use datagrams of as + large a size as possible, it may be prudent to use a slightly smaller + maximum that allows for secondary protocol headers and/or tunneling + without resulting in IP-layer fragmentation. 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 inbound datagrams). As datagrams are received they are checked for sequence number anomalies (loss, out-of-order, duplication, etc.) and the delay variation is measured (one-way or round-trip). This information is accumulated until the feedback timer F expires and a status feedback message is sent from the receiver back to the sender, to communicate this information. The accumulated statistics are then reset by the receiver for the next feedback interval. As feedback @@ -749,31 +749,33 @@ 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: + reference for further development) [udpst]. 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. + o Supports IPv4 and IPv6 address families. + + o 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) @@ -852,23 +854,58 @@ 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.]. + considerations. The security considerations that apply to any active + measurement of live paths are relevant here. See [RFC4656] and + [RFC5357]. - + 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 This memo makes no requests of IANA. 12. Acknowledgements Thanks to Joachim Fabini, Matt Mathis, Ignacio Alvarez-Hamelin, and Wolfgang Balzer for their extensive comments on the memo and related topics. @@ -903,29 +940,39 @@ [RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology for LAN Switching Devices", RFC 2889, DOI 10.17487/RFC2889, August 2000, . [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, DOI 10.17487/RFC3148, July 2001, . + [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, + . + [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, DOI 10.17487/RFC5136, February 2008, . [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin, "IPv6 Benchmarking Methodology for Network Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May 2008, . + [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, + . + [RFC6201] Asati, R., Pignataro, C., Calabria, F., and C. Olvera, "Device Reset Characterization", RFC 6201, DOI 10.17487/RFC6201, March 2011, . [RFC6412] Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence", RFC 6412, DOI 10.17487/RFC6412, November 2011, . @@ -947,20 +994,26 @@ [RFC6985] Morton, A., "IMIX Genome: Specification of Variable Packet Sizes for Additional Testing", RFC 6985, DOI 10.17487/RFC6985, July 2013, . [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)", RFC 7312, DOI 10.17487/RFC7312, August 2014, . + [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, + . + [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8337] Mathis, M. and A. Morton, "Model-Based Metrics for Bulk Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March @@ -978,33 +1031,37 @@ "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, . + [udpst] AT&T, "UDP Speed Test Open Broadband project", August + 2020, >. + [Y.1540] Y.1540, I. R., "Internet protocol data communication service - IP packet transfer and availability performance - parameters", January 2020, - . + parameters", December 2019, + . [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