--- 1/draft-ietf-ippm-capacity-metric-method-11.txt 2021-06-09 12:13:09.956620578 -0700 +++ 2/draft-ietf-ippm-capacity-metric-method-12.txt 2021-06-09 12:13:10.036622559 -0700 @@ -1,21 +1,21 @@ Network Working Group A. Morton Internet-Draft AT&T Labs Intended status: Standards Track R. Geib -Expires: December 3, 2021 Deutsche Telekom +Expires: December 11, 2021 Deutsche Telekom L. Ciavattone AT&T Labs - June 1, 2021 + June 9, 2021 Metrics and Methods for One-way IP Capacity - draft-ietf-ippm-capacity-metric-method-11 + draft-ietf-ippm-capacity-metric-method-12 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. Status of This Memo @@ -25,21 +25,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 December 3, 2021. + This Internet-Draft will expire on December 11, 2021. Copyright Notice Copyright (c) 2021 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 @@ -49,49 +49,49 @@ 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 . . . . . . . . . . . . . . . . . . 4 2. Scope, Goals, and Applicability . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. General Parameters and Definitions . . . . . . . . . . . . . 6 - 5. IP-Layer Capacity Singleton Metric Definitions . . . . . . . 7 + 5. IP-Layer Capacity Singleton Metric Definitions . . . . . . . 8 5.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 8 5.4. Related Round-Trip Delay and One-way Loss Definitions . . 9 5.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 10 5.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 10 6. Maximum IP-Layer Capacity Metric Definitions (Statistic) . . 10 6.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 10 - 6.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 11 - 6.4. Related Round-Trip Delay and One-way Loss Definitions . . 12 - 6.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 12 + 6.4. Related Round-Trip Delay and One-way Loss Definitions . . 13 + 6.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . 14 7.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 14 - 7.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 14 + 7.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 15 7.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 15 7.5. Reporting the Metric . . . . . . . . . . . . . . . . . . 15 8. Method of Measurement . . . . . . . . . . . . . . . . . . . . 15 - 8.1. Load Rate Adjustment Algorithm . . . . . . . . . . . . . 15 - 8.2. Measurement Qualification or Verification . . . . . . . . 20 + 8.1. Load Rate Adjustment Algorithm . . . . . . . . . . . . . 16 + 8.2. Measurement Qualification or Verification . . . . . . . . 21 8.3. Measurement Considerations . . . . . . . . . . . . . . . 22 8.4. Running Code . . . . . . . . . . . . . . . . . . . . . . 24 - 9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 24 - 9.1. Configuration and Reporting Data Formats . . . . . . . . 26 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 25 + 9.1. Configuration and Reporting Data Formats . . . . . . . . 27 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 13. Appendix A - Load Rate Adjustment Pseudo Code . . . . . . . . 28 14. Appendix B - RFC 8085 UDP Guidelines Check . . . . . . . . . 29 14.1. Assessment of Mandatory Requirements . . . . . . . . . . 29 14.2. Assessment of Recommendations . . . . . . . . . . . . . 31 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 15.1. Normative References . . . . . . . . . . . . . . . . . . 34 15.2. Informative References . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 @@ -251,25 +251,25 @@ 4. Content and applications are moving physically closer to users. 5. There is less emphasis on ISP gateway measurements, possibly due to less traffic crossing ISP gateways in the future. 4. General Parameters and Definitions This section lists the REQUIRED input factors to specify a Sender or Receiver metric. - o Src, the address of a host (such as the globally routable IP - address). + o Src, one of the addresses of a host (such as a globally routable + IP address). - o Dst, the address of a host (such as the globally routable IP - address). + o Dst, one of the addresses of a host (such as a globally routable + IP address). o MaxHops, the limit on the number of Hops a specific packet may visit as it traverses from the host at Src to the host at Dst (implemented in the TTL or Hop Limit). o T0, the time at the start of measurement interval, when packets are first transmitted from the Source. o I, the nominal duration of a measurement interval at the destination (default 10 sec) @@ -290,30 +290,39 @@ destination, set sufficiently long to disambiguate packets with long delays from packets that are discarded (lost), such that the distribution of one-way delay is not truncated. o F, the number of different flows synthesized by the method (default 1 flow) o flow, the stream of packets with the same n-tuple of designated header fields that (when held constant) result in identical treatment in a multi-path decision (such as the decision taken in - load balancing). Note: The IPv6 flow label MAY be included in the - flow definition when routers have complied with [RFC6438] + load balancing). Note: The IPv6 flow label SHOULD be included in + the flow definition when routers have complied with [RFC6438] guidelines. o Type-P, the complete description of the test packets for which this assessment applies (including the flow-defining fields). Note that the UDP transport layer is one requirement for test packets specified below. Type-P is a parallel concept to "population of interest" defined in clause 6.1.1 of[Y.1540]. + o Payload Content, this IPPM Framework-conforming metric and method + includes packet payload content as an aspect of the Type-P + parameter, which can help to improve measurement determinism. If + there is payload compression in the path and tests intend to + characterize a possible advantage due to compression, then payload + content SHOULD be supplied by a pseudo-random sequence generator, + by using part of a compressed file, or by other means. See + Section 3.1.2 of [RFC7312]. + o PM, a list of fundamental metrics, such as loss, delay, and reordering, and corresponding target performance threshold. At least one fundamental metric and target performance threshold MUST be supplied (such as One-way IP Packet Loss [RFC7680] equal to zero). A non-Parameter which is required for several metrics is defined below: o T, the host time of the *first* test packet's *arrival* as @@ -710,21 +719,23 @@ offered load rates that will be supported (R1 through Rn, in ascending order, corresponding 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 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, increments of 1 Gbps are RECOMMENDED. A higher initial IP-Layer Sender Bitrate might be configured when the test operator is certain that the Maximum IP- Layer Capacity is well-above the initial IP-Layer Sender Bitrate and factors such as test duration and total test traffic play an - important role. + important role. The sending rate table SHOULD backet the maximum + capacity where it will make measurements, including constrained rates + less than 500kbps if applicable. Each rate is defined as datagrams of size ss, sent as a burst of count cc, each time interval tt (default for tt is 1ms, a likely system tick-interval). 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. Selection of a new rate is indicated by a calculation on the current row, Rx. For example: @@ -793,33 +804,34 @@ further feedback sent. feedback message timeout Operation: The feedback message timeout SHALL be reset to the configured value each time a feedback message is received. If the timeout expires, the sender SHALL be closed and no further load packets sent. +-------------+-------------+---------------+-----------------------+ | Parameter | Default | Tested Range | Expected Safe Range | | | | or values | (not entirely tested, | - | | | | other values NOT | + | | | | other | + | | | | values NOT | | | | | RECOMMENDED) | +-------------+-------------+---------------+-----------------------+ | FT, | 50ms | 20ms, 50ms, | 20ms <= FT <= 250ms | | feedback | | 100ms | Larger values may | | time | | | slow the rate | | interval | | | increase and fail to | | | | | find the max | +-------------+-------------+---------------+-----------------------+ | Feedback | L*FT, L=20 | L=100 with | 0.5sec <= L*FT <= | | message | (1sec with | FT=50ms | 30sec Upper limit for | - | timeout | FT=50ms) | (5sec) | very unreliable test | - | (stop test) | | | paths only | + | timeout | FT=50ms) | (5sec) | very unreliable | + | (stop test) | | | test paths only | +-------------+-------------+---------------+-----------------------+ | load packet | 1sec | 5sec | 0.250sec - 30sec | | timeout | | | Upper limit for very | | (stop test) | | | unreliable test paths | | | | | only | +-------------+-------------+---------------+-----------------------+ | table index | 0.5Mbps | 0.5Mbps | when testing <=10Gbps | | 0 | | | | +-------------+-------------+---------------+-----------------------+ | table index | 1Mbps | 1Mbps | when testing <=10Gbps | @@ -834,32 +846,33 @@ | rate>1Gbps | | | | +-------------+-------------+---------------+-----------------------+ | table index | 1Gbps | untested | >10Gbps | | (step) | | | | | size, | | | | | rate>10Gbps | | | | +-------------+-------------+---------------+-----------------------+ | ss, UDP | none | <=1222 | Recommend max at | | payload | | | largest value that | | size, bytes | | | avoids fragmentation; | - | | | | use of too-small | - | | | | payload size might | - | | | | result in unexpected | - | | | | sender limitations. | + | | | | use of too- | + | | | | small payload size | + | | | | might result in | + | | | | unexpected sender | + | | | | limitations. | +-------------+-------------+---------------+-----------------------+ | cc, burst | none | 1<=cc<= 100 | same as tested. Vary | | count | | | cc as needed to | | | | | create the desired | - | | | | maximum sending rate. | - | | | | Sender buffer size | - | | | | may limit cc in | - | | | | implementation. | + | | | | maximum | + | | | | sending rate. Sender | + | | | | buffer size may limit | + | | | | cc in implementation. | +-------------+-------------+---------------+-----------------------+ | tt, burst | 100microsec | 100microsec, | available range of | | interval | | 1msec | "tick" values (HZ | | | | | param) | +-------------+-------------+---------------+-----------------------+ | low delay | 30ms | 5ms, 30ms | same as tested | | range | | | | | threshold | | | | +-------------+-------------+---------------+-----------------------+ | high delay | 90ms | 10ms, 90ms | same as tested | @@ -1081,24 +1094,30 @@ aggregate. 3. Internet 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 rate adjustment (search) algorithm. It is obviously counter-productive to run more than one independent - test (regardless of the number of flows in the test stream) - attempting to measure the *maximum* capacity between the same Source - and Destination. The number of concurrent, independent tests between - the same Source and Destination SHALL be limited to one. + and concurrent test (regardless of the number of flows in the test + stream) attempting to measure the *maximum* capacity on a single + path. The number of concurrent, independent tests of a path SHALL be + limited to one. + + Tests of a v4-v6 transition mechanism might well be the intended + subject of a capacity test. As long as the IPv4 and IPv6 packets + sent/received are both standard-formed, this should be allowed (and + the change in header size easily accounted for on a per-packet + basis). As testing continues, implementers should expect some evolution in 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 those results have improved the method described here. 8.4. Running Code