--- 1/draft-ietf-ippm-capacity-metric-method-10.txt 2021-06-01 16:13:10.557172381 -0700 +++ 2/draft-ietf-ippm-capacity-metric-method-11.txt 2021-06-01 16:13:10.601173003 -0700 @@ -1,21 +1,21 @@ Network Working Group A. Morton Internet-Draft AT&T Labs Intended status: Standards Track R. Geib -Expires: October 28, 2021 Deutsche Telekom +Expires: December 3, 2021 Deutsche Telekom L. Ciavattone AT&T Labs - April 26, 2021 + June 1, 2021 Metrics and Methods for One-way IP Capacity - draft-ietf-ippm-capacity-metric-method-10 + draft-ietf-ippm-capacity-metric-method-11 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 October 28, 2021. + This Internet-Draft will expire on December 3, 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 @@ -50,84 +50,90 @@ 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.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 7 - 5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 7 + 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.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 10 + 6.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 11 6.4. Related Round-Trip Delay and One-way Loss Definitions . . 12 6.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 12 6.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 13 7. IP-Layer Sender Bit Rate Singleton Metric Definitions . . . . 13 - 7.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 13 + 7.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 14 7.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 14 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.3. Measurement Considerations . . . . . . . . . . . . . . . 22 - 8.4. Running Code . . . . . . . . . . . . . . . . . . . . . . 23 + 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 - 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 - 13. Appendix A - Load Rate Adjustment Pseudo Code . . . . . . . . 27 - 14. Appendix B - RFC 8085 UDP Guidelines Check . . . . . . . . . 28 - 14.1. Assessment of Mandatory Requirements . . . . . . . . . . 28 - 14.2. Assessment of Recommendations . . . . . . . . . . . . . 30 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 - 15.1. Normative References . . . . . . . . . . . . . . . . . . 33 - 15.2. Informative References . . . . . . . . . . . . . . . . . 34 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 + 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 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. This memo revisits the problem of Network Capacity metrics examined first in [RFC3148] and later in [RFC5136]. Maximum IP-Layer Capacity and [RFC3148] Bulk Transfer Capacity (goodput) are different metrics. Maximum IP-Layer Capacity is like the theoretical goal for goodput. There are many metrics in [RFC5136], such as Available Capacity. Measurements depend on the network path under test and the use case. - Here, the main use case is to assess the maximum capacity of the - access network, with specific performance criteria used in the - measurement. + Here, the main use case is to assess the maximum capacity of one or + more networks where the subscriber receives specific performance + assurances, sometimes referred to as the Internet access, or where a + limit of the technology used on a path is being tested. For example, + when a user subscribes to a 1 Gbps service, then the user, the + service provider, and possibly other parties want to assure that + performance level is delivered. When a test confirms the subscribed + performance level, then a tester can seek the location of a + bottleneck elsewhere. This memo recognizes the importance of a definition of a Maximum IP- - Layer Capacity Metric at a time when access speeds have increased - dramatically; a definition that is both practical and effective for - the performance community's needs, including Internet users. The - metric definition is intended to use Active Methods of Measurement - [RFC7799], and a method of measurement is included. + Layer Capacity Metric at a time when Internet subscription speeds + have increased dramatically; a definition that is both practical and + effective for the performance community's needs, including Internet + users. The metric definition is intended to use Active Methods of + Measurement [RFC7799], and a method of measurement is included. The most direct active measurement of IP-Layer Capacity would use IP packets, but in practice a transport header is needed to traverse address and port translators. UDP offers the most direct assessment possibility, and in the [copycat] measurement study to investigate whether UDP is viable as a general Internet transport protocol, the authors found that a high percentage of paths tested support UDP transport. A number of liaisons have been exchanged on this topic [LS-SG12-A] [LS-SG12-B], discussing the laboratory and field tests that support the UDP-based approach to IP-Layer Capacity measurement. @@ -144,110 +150,115 @@ 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, Goals, and Applicability - 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 scope of this memo is to define Active Measurement metrics and + corresponding methods to unambiguously determine Maximum IP-Layer + Capacity and useful secondary metrics. Another goal is to harmonize the specified metric and method across the industry, and this memo is the vehicle that captures IETF consensus, possibly resulting in changes to the specifications of other Standards Development Organizations (SDO) (through each 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. - Fostering the development of protocol support for this metric and - method of measurement is also a goal of this memo (all active testing - protocols currently defined by the IPPM WG are UDP-based, meeting a - key requirement of these methods). The supporting protocol - development to measure this metric according to the specified method - is a key future contribution to Internet measurement. + Secondary goals are to add considerations for test procedures, and to + provide interpretation of the Maximum IP-Layer Capacity results (to + identify cases where more testing is warranted, possibly with + alternate configurations). Fostering the development of protocol + support for this metric and method of measurement is also a goal of + this memo (all active testing protocols currently defined by the IPPM + WG are UDP-based, meeting a key requirement of these methods). The + supporting protocol development to measure this metric according to + the specified method is a key future contribution to Internet + measurement. The load rate adjustment algorithm's scope is limited to helping determine the Maximum IP-Layer Capacity in the context of an infrequent, diagnostic, short term measurement. It is RECOMMENDED to discontinue non-measurement traffic that shares a subscriber's dedicated resources while testing: measurements may not be accurate and throughput of competing elastic traffic may be greatly reduced. The primary application of the metric and method of measurement described here is the same as in Section 2 of [RFC7497] where: o The access portion of the network is the focus of this problem statement. The user typically subscribes to a service with - bidirectional access partly described by rates in bits per second. + bidirectional Internet access partly described by rates in bits + per second. In addition, the use of the load rate adjustment algorithm described in section 8.1 has the following additional applicability limitations: - MUST only be used in the application of diagnostic and operations measurements as described in this memo - MUST only be used in circumstances consistent with Section 10, Security Considerations - - If a network operator is certain of the access capacity to be - validated, then testing MAY start with a fixed rate test at the - access capacity and avoid activating the load adjustment algorithm. + - If a network operator is certain of the IP-layer capacity to be + validated, then testing MAY start with a fixed rate test at the IP- + layer capacity and avoid activating the load adjustment algorithm. However, the stimulus for a diagnostic test (such as a subscriber request) strongly implies that there is no certainty and the load - adjustment algorithm will be needed. + adjustment algorithm is RECOMMENDED. Further, the metric and method of measurement are intended for use where specific exact path information is unknown within a range of possible values: - the subscriber's exact Maximum IP-Layer Capacity is unknown (which is sometimes the case; service rates can be increased due to upgrades without a subscriber's request, or to provide a surplus to compensate - for possible underestimates of TCP-based testing. + for possible underestimates of TCP-based testing). - - the size of the access bottleneck buffer is unknown. + - the size of the bottleneck buffer is unknown. Finally, the measurement system's load rate adjustment algorithm SHALL NOT be provided with the exact capacity value to be validated a priori. This restriction fosters a fair result, and removes an opportunity for bad actors to operate with knowledge of the "right answer". 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 changes: - 1. Internet access is no longer the bottleneck for many users. + 1. Internet access is no longer the bottleneck for many users (but + subscribers expect network providers to honor contracted + performance). 2. Both transfer rate and latency are important to user's satisfaction. 3. UDP's growing role in Transport, in areas where TCP once dominated. 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 future. + 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 Dst, the address of a host (such as the globally routable IP @@ -518,22 +529,22 @@ o PM represents the other performance metrics (see Section 5.4) and their measurement results for the Maximum IP-Layer Capacity. At least one target performance threshold (PM criterion) MUST be defined. o all sub-intervals MUST be of equal duration. Choosing dt as non- overlapping consecutive time intervals allows for a simple implementation. o The bit rate of the physical interface of the measurement systems - MUST be higher than than the smallest of the links on the path - whose Maximum_C(T,I,PM) is to be measured (the bottleneck link). + MUST be higher than the smallest of the links on the path whose + Maximum_C(T,I,PM) is to be measured (the bottleneck link). In this definition, the m sub-intervals can be viewed as trials when the Src host varies the transmitted packet rate, searching for the maximum n0 that meets the PM criteria measured at the Dst host in a test of duration, I. When the transmitted packet rate is held constant at the Src host, the m sub-intervals may also be viewed as trials to evaluate the stability of n0 and metric(s) in the PM list over all dt-length intervals in I. Measurements according to these definitions SHALL use the UDP @@ -684,35 +695,36 @@ likely cause congestion on the Src to Dst host path during a test. 8.1. Load Rate Adjustment Algorithm The algorithm described in this section MUST NOT be used as a general Congestion Control Algorithm (CCA). As stated in the Scope Section 2, the load rate adjustment algorithm's goal is to help determine the Maximum IP-Layer Capacity in the context of an infrequent, diagnostic, short term measurement. There is a tradeoff between test duration (also the test data volume) and algorithm - agressiveness (speed of ramp-up and down to the Maximum IP-Layer + aggressiveness (speed of ramp-up and down to the Maximum IP-Layer Capacity). The parameter values chosen below strike a well-tested balance among these factors. - A table SHALL be pre-built defining all the 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. + A table SHALL be pre-built (by the test initiator) defining all the + 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. 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: @@ -728,38 +740,39 @@ information is accumulated until the feedback timer FT 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 messages are received back at the sender, they are evaluated to determine how to adjust the current offered load rate (Rx). If the feedback indicates that no sequence number anomalies were detected AND the delay range was below the lower threshold, the offered load rate is increased. If congestion has not been confirmed - up to this point, the offered load rate is increased by more than one - rate (e.g., Rx+10). This allows the offered load to quickly reach a - near-maximum rate. Conversely, if congestion has been previously - confirmed, the offered load rate is only increased by one (Rx+1). - However, if a rate threshold between high and very high sending rates - (such as 1 Gbps) is exceeded, the offered load rate is only increased - by one (Rx+1) above the rate threshold in any congestion state. + up to this point (see below for the method to declare congestion), + the offered load rate is increased by more than one rate (e.g., + Rx+10). This allows the offered load to quickly reach a near-maximum + rate. Conversely, if congestion has been previously confirmed, the + offered load rate is only increased by one (Rx+1). However, if a + rate threshold between high and very high sending rates (such as 1 + Gbps) is exceeded, the offered load rate is only increased by one + (Rx+1) above the rate threshold in any congestion state. If the feedback indicates that sequence number anomalies were detected OR the delay range was above the upper threshold, the - offered load rate is decreased. The RECOMMENDED values are 0 for - sequence number gaps and 30 ms for lower and 90 ms for upper delay - thresholds, respectively. Also, if congestion is now confirmed for - the first time by the current feedback message being processed, then - the offered load rate is decreased by more than one rate (e.g., Rx- - 30). This one-time reduction is intended to compensate for the fast - initial ramp-up. In all other cases, the offered load rate is only - decreased by one (Rx-1). + offered load rate is decreased. The RECOMMENDED threshold values are + 0 for sequence number gaps and 30 ms for lower and 90 ms for upper + delay thresholds, respectively. Also, if congestion is now confirmed + for the first time by the current feedback message being processed, + then the offered load rate is decreased by more than one rate (e.g., + Rx-30). This one-time reduction is intended to compensate for the + fast initial ramp-up. In all other cases, the offered load rate is + only decreased by one (Rx-1). If the feedback indicates that there were no sequence number anomalies AND the delay range 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 inferring congestion is that there were sequence number anomalies AND/OR the delay range was above the upper @@ -939,25 +952,25 @@ 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 would not do. This situation is different from the bi-modal service rates (discussed under Reporting), which are characterized by a multi-second duration (much longer than the measured RTT) and repeatable behavior. There are many ways that the Method of Measurement could handle this false-max issue. The default value for measurement of singletons (dt - = 1 second) has proven to a be of practical value during tests of - this method, allows the bimodal service rates to be characterized, - and it has an obvious alignment with the reporting units (Mbps). + = 1 second) has proven to be of practical value during tests of this + method, allows the bimodal service rates to be characterized, and it + has an obvious alignment with the reporting units (Mbps). - Another approach comes from Section 24 of RFC 2544[RFC2544] and its + Another approach comes from Section 24 of [RFC2544] and its discussion of Trial duration, where relatively short trials conducted as part of the search are followed by longer trials to make the final determination. In the production network, measurements of Singletons and Samples (the terms for trials and tests of Lab Benchmarking) must be limited in duration because they may be service-affecting. But there is sufficient value in repeating a Sample with a fixed sending rate determined by the previous search for the Maximum IP-Layer Capacity, to qualify the result in terms of the other performance metrics measured at the same time. @@ -999,38 +1012,39 @@ In general, it is RECOMMENDED to locate test endpoints as close to the intended measured link(s) as practical (this is not always possible for reasons of scale; there is a limit on number of test endpoints coming from many perspectives, management and measurement traffic for example). The testing operator MUST set a value for the MaxHops parameter, based on the expected path length. This parameter can keep measurement traffic from straying too far beyond the intended path. - The path measured may be state-full based on many factors, and the + The path measured may be stateful based on many factors, and the Parameter "Time of day" when a test starts may not be enough information. Repeatable testing may require the time from the beginning of a measured flow, and how the flow is constructed including how much traffic has already been sent on that flow when a state-change is observed, because the state-change may be based on time or bytes sent or both. Both load packets and status feedback messages MUST contain sequence numbers, which helps with measurements based on those packets. - Many different traffic shapers and on-demand access technologies may - be encountered, as anticipated in [RFC7312], and play a key role in - measurement results. Methods MUST be prepared to provide a short - preamble transmission to activate on-demand access, and to discard - the preamble from subsequent test results. + Many different types of traffic shapers and on-demand communications + access technologies may be encountered, as anticipated in [RFC7312], + and play a key role in measurement results. Methods MUST be prepared + to provide a short preamble transmission to activate on-demand + communications access, and to discard the preamble from subsequent + test results. Conditions which might be encountered during measurement, where - packet losses may occur independently from the measurement sending + packet losses may occur independently of the measurement sending rate: 1. Congestion of an interconnection or backbone interface may appear as packet losses distributed over time in the test stream, due to much higher rate interfaces in the backbone. 2. Packet loss due to use of Random Early Detection (RED) or other active queue management may or may not affect the measurement flow if competing background traffic (other flows) are simultaneously present. @@ -1059,38 +1073,44 @@ 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. + 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. + 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 - This section is for the benefit of the Document Shepherd's form, and - will be deleted prior to final review. + RFC Editor: This section is for the benefit of the Document + Shepherd's form, and will be deleted prior to publication. 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) [udpst]. The current project: o is a utility that can function as a client or server daemon o requires a successful client-initiated setup handshake between cooperating hosts and allows firewalls to control inbound @@ -1191,23 +1211,23 @@ 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 also carefully considered topics within its purview, such as placement of - measurement systems within the access architecture. For example, - timestamp resolution requirements that influence the choice of the - test protocol are provided in Table 2 of [TR-471]. + measurement systems within the Internet access architecture. For + example, timestamp resolution requirements that influence the choice + of the test protocol are provided in Table 2 of [TR-471]. 10. Security Considerations Active metrics and measurements have a long history of security 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 @@ -1241,35 +1261,36 @@ 5. Senders MUST be rate-limited. This can be accomplished using a 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. 6. 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 (for example, the - range of I duration values SHOULD be limited). + range of duration values, I, SHOULD be limited). The exact specification of these features is left for the future protocol development. 11. IANA Considerations This memo makes no requests of IANA. 12. Acknowledgments Thanks to Joachim Fabini, Matt Mathis, J.Ignacio Alvarez-Hamelin, Wolfgang Balzer, Frank Brockners, Greg Mirsky, Martin Duke, Murray Kucherawy, and Benjamin Kaduk for their extensive comments on the - memo and related topics. + memo and related topics. In a second round of reviews, we + acknowledge Magnus Westerlund, Lars Eggert, and Zahed Sarkar. 13. Appendix A - Load Rate Adjustment Pseudo Code The following is a pseudo-code implementation of the algorithm described in Section 8.1. Rx = 0 # The current sending rate (equivalent to a row of the table) seqErr = 0 # Measured count of any of Loss or Reordering impairments delay = 0 # Measured Range of Round Trip Delay, RTD, ms lowThresh = 30 # Low threshold on the Range of RTD, ms @@ -1356,21 +1377,21 @@ there are no retransmissions needed. When a latency estimate is used to arm a timer that provides loss detection -- with or without retransmission -- expiry of the timer MUST be interpreted as an indication of congestion in the network, causing the sending rate to be adapted to a safe conservative rate... The method described in this memo uses timers for sending rate backoff when status feedback messages are lost (Lost Status Backoff - timeout), and for stopping a test when connectivity is lost for an + timeout), and for stopping a test when connectivity is lost for a longer interval (Feedback message or load packet timeouts). There is no specific benefit foreseen by using Explicit Congestion Notification (ECN) in this memo. Section 3.2 of [RFC8085] discusses message size guidelines: To determine an appropriate UDP payload size, applications MUST subtract the size of the IP header (which includes any IPv4 optional headers or IPv6 extension headers) as well as the length @@ -1408,21 +1429,21 @@ A specific recommendation is provided as an example. Section 3.1.5 of [RFC8085] on implications of RTT and Loss Measurements on Congestion Control says: A congestion control designed for UDP SHOULD respond as quickly as possible when it experiences congestion, and it SHOULD take into account both the loss rate and the response time when choosing a new rate. The load rate adjustment algorithm responds to loss and RTT - measurements with a clear and concise rate reduction when warrented, + measurements with a clear and concise rate reduction when warranted, and the response makes use of direct measurements (more exact than can be inferred from TCP ACKs). Section 3.1.5 of [RFC8085] goes on to specify: The implemented congestion control scheme SHOULD result in bandwidth (capacity) use that is comparable to that of TCP within an order of magnitude, so that it does not starve other flows sharing a common bottleneck. @@ -1436,22 +1457,22 @@ launching many flows (9, for example) to increase the outstanding data dedicated to testing. The load rate adjustment algorithm cannot become a TCP-like congestion control, or it will have the same weaknesses of TCP when trying to make a Maximum IP-Layer Capacity measurement, and will not achieve the goal. The results of the referenced testing [LS-SG12-A] [LS-SG12-B] [Y.Sup60] supported this statement hundreds of times, with comparisons to multi-connection TCP-based measurements. - A brief review of some of the other SHOULD-level requirements follows - (Yes or Not applicable = NA) : + A brief review of some other SHOULD-level requirements follows (Yes + or Not applicable = NA) : +--+---------------------------------------------------------+---------+ |Y?| RFC 8085 Recommendation | Section | +--+---------------------------------------------------------+---------+ Yes| MUST tolerate a wide range of Internet path conditions | 3 | NA | SHOULD use a full-featured transport (e.g., TCP) | | | | | Yes| SHOULD control rate of transmission | 3.1 | NA | SHOULD perform congestion control over all traffic | | | | | @@ -1670,32 +1691,32 @@ [Y.Sup60] Morton, A., "Recommendation Y.Sup60, (09/20) Interpreting ITU-T Y.1540 maximum IP-layer capacity measurements, and Errata", September 2020, . Authors' Addresses Al Morton AT&T Labs 200 Laurel Avenue South - Middletown,, NJ 07748 + Middletown, NJ 07748 USA Phone: +1 732 420 1571 Fax: +1 732 368 1192 Email: acm@research.att.com Ruediger Geib Deutsche Telekom Heinrich Hertz Str. 3-7 Darmstadt 64295 Germany Phone: +49 6151 5812747 Email: Ruediger.Geib@telekom.de Len Ciavattone AT&T Labs 200 Laurel Avenue South - Middletown,, NJ 07748 + Middletown, NJ 07748 USA Email: lencia@att.com