| < draft-ietf-ippm-capacity-metric-method-05.txt | draft-ietf-ippm-capacity-metric-method-12.txt > | |||
|---|---|---|---|---|
| Network Working Group A. Morton | Network Working Group A. Morton | |||
| Internet-Draft AT&T Labs | Internet-Draft AT&T Labs | |||
| Intended status: Standards Track R. Geib | Intended status: Standards Track R. Geib | |||
| Expires: August 5, 2021 Deutsche Telekom | Expires: December 11, 2021 Deutsche Telekom | |||
| L. Ciavattone | L. Ciavattone | |||
| AT&T Labs | AT&T Labs | |||
| February 1, 2021 | June 9, 2021 | |||
| Metrics and Methods for One-way IP Capacity | Metrics and Methods for One-way IP Capacity | |||
| draft-ietf-ippm-capacity-metric-method-05 | draft-ietf-ippm-capacity-metric-method-12 | |||
| 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. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| 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 August 5, 2021. | This Internet-Draft will expire on December 11, 2021. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2021 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 | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 | |||
| 2. Scope and Goals . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Scope, Goals, and Applicability . . . . . . . . . . . . . . . 4 | |||
| 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4. General Parameters and Definitions . . . . . . . . . . . . . 5 | 4. General Parameters and Definitions . . . . . . . . . . . . . 6 | |||
| 5. IP-Layer Capacity Singleton Metric Definitions . . . . . . . 6 | 5. IP-Layer Capacity Singleton Metric Definitions . . . . . . . 8 | |||
| 5.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 6 | 5.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 | 5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 5.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 6 | 5.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 8 | |||
| 5.4. Related Round-Trip Delay and One-way Loss Definitions . . 8 | 5.4. Related Round-Trip Delay and One-way Loss Definitions . . 9 | |||
| 5.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 | 5.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 5.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 8 | 5.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 10 | |||
| 6. Maximum IP-Layer Capacity Metric Definitions (Statistic) . . 9 | 6. Maximum IP-Layer Capacity Metric Definitions (Statistic) . . 10 | |||
| 6.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 9 | 6.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 6.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 9 | 6.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 6.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 9 | 6.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 11 | |||
| 6.4. Related Round-Trip Delay and One-way Loss Definitions . . 11 | 6.4. Related Round-Trip Delay and One-way Loss Definitions . . 13 | |||
| 6.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 11 | 6.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 6.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 11 | 6.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 13 | |||
| 7. IP-Layer Sender Bit Rate Singleton Metric Definitions . . . . 12 | 7. IP-Layer Sender Bit Rate Singleton Metric Definitions . . . . 14 | |||
| 7.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 12 | 7.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 7.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 12 | 7.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 7.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 13 | 7.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 15 | |||
| 7.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 13 | 7.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 7.5. Reporting the Metric . . . . . . . . . . . . . . . . . . 13 | 7.5. Reporting the Metric . . . . . . . . . . . . . . . . . . 15 | |||
| 8. Method of Measurement . . . . . . . . . . . . . . . . . . . . 13 | 8. Method of Measurement . . . . . . . . . . . . . . . . . . . . 15 | |||
| 8.1. Load Rate Adjustment Algorithm . . . . . . . . . . . . . 13 | 8.1. Load Rate Adjustment Algorithm . . . . . . . . . . . . . 16 | |||
| 8.2. Measurement Qualification or Verification . . . . . . . . 15 | 8.2. Measurement Qualification or Verification . . . . . . . . 21 | |||
| 8.3. Measurement Considerations . . . . . . . . . . . . . . . 16 | 8.3. Measurement Considerations . . . . . . . . . . . . . . . 22 | |||
| 8.4. Running Code . . . . . . . . . . . . . . . . . . . . . . 18 | 8.4. Running Code . . . . . . . . . . . . . . . . . . . . . . 24 | |||
| 9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 18 | 9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 9.1. Configuration and Reporting Data Formats . . . . . . . . 20 | 9.1. Configuration and Reporting Data Formats . . . . . . . . 27 | |||
| 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | |||
| 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 13. Appendix - Load Rate Adjustment Pseudo Code . . . . . . . . . 22 | 13. Appendix A - Load Rate Adjustment Pseudo Code . . . . . . . . 28 | |||
| 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 14. Appendix B - RFC 8085 UDP Guidelines Check . . . . . . . . . 29 | |||
| 14.1. Normative References . . . . . . . . . . . . . . . . . . 23 | 14.1. Assessment of Mandatory Requirements . . . . . . . . . . 29 | |||
| 14.2. Informative References . . . . . . . . . . . . . . . . . 24 | 14.2. Assessment of Recommendations . . . . . . . . . . . . . 31 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 | 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
| 15.1. Normative References . . . . . . . . . . . . . . . . . . 34 | ||||
| 15.2. Informative References . . . . . . . . . . . . . . . . . 35 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 | ||||
| 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. | |||
| This memo revisits the problem of Network Capacity metrics examined | This memo revisits the problem of Network Capacity metrics examined | |||
| first in [RFC3148] and later in [RFC5136]. Maximum IP-Layer Capacity | first in [RFC3148] and later in [RFC5136]. Maximum IP-Layer Capacity | |||
| and [RFC3148] Bulk Transfer Capacity (goodput) are different metrics. | and [RFC3148] Bulk Transfer Capacity (goodput) are different metrics. | |||
| Maximum IP-layer Capacity is like the theoretical goal for goodput. | Maximum IP-Layer Capacity is like the theoretical goal for goodput. | |||
| There are many metrics in [RFC5136], such as Available Capacity. | There are many metrics in [RFC5136], such as Available Capacity. | |||
| Measurements depend on the network path under test and the use case. | 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 | Here, the main use case is to assess the maximum capacity of one or | |||
| access network, with specific performance criteria used in the | more networks where the subscriber receives specific performance | |||
| measurement. | 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- | This memo recognizes the importance of a definition of a Maximum IP- | |||
| layer Capacity Metric at a time when access speeds have increased | Layer Capacity Metric at a time when Internet subscription speeds | |||
| dramatically; a definition that is both practical and effective for | have increased dramatically; a definition that is both practical and | |||
| the performance community's needs, including Internet users. The | effective for the performance community's needs, including Internet | |||
| metric definition is intended to use Active Methods of Measurement | users. The metric definition is intended to use Active Methods of | |||
| [RFC7799], and a method of measurement is included. | Measurement [RFC7799], and a method of measurement is included. | |||
| The most direct active measurement of IP-layer Capacity would use IP | The most direct active measurement of IP-Layer Capacity would use IP | |||
| packets, but in practice a transport header is needed to traverse | packets, but in practice a transport header is needed to traverse | |||
| address and port translators. UDP offers the most direct assessment | address and port translators. UDP offers the most direct assessment | |||
| possibility, and in the [copycat] measurement study to investigate | possibility, and in the [copycat] measurement study to investigate | |||
| whether UDP is viable as a general Internet transport protocol, the | whether UDP is viable as a general Internet transport protocol, the | |||
| authors found that a high percentage of paths tested support UDP | authors found that a high percentage of paths tested support UDP | |||
| transport. A number of liaisons have been exchanged on this topic | transport. A number of liaisons have been exchanged on this topic | |||
| [LS-SG12-A] [LS-SG12-B], discussing the laboratory and field tests | [LS-SG12-A] [LS-SG12-B], discussing the laboratory and field tests | |||
| that support the UDP-based approach to IP-layer Capacity measurement. | that support the UDP-based approach to IP-Layer Capacity measurement. | |||
| This memo also recognizes the many updates to the IP Performance | This memo also recognizes the many updates to the IP Performance | |||
| Metrics Framework [RFC2330] published over twenty years, and makes | Metrics Framework [RFC2330] published over twenty years, and makes | |||
| use of [RFC7312] for Advanced Stream and Sampling Framework, and | use of [RFC7312] for Advanced Stream and Sampling Framework, and | |||
| [RFC8468] with IPv4, IPv6, and IPv4-IPv6 Coexistence Updates. | [RFC8468] with IPv4, IPv6, and IPv4-IPv6 Coexistence Updates. | |||
| Appendix A describes the load rate adjustment algorithm in pseudo- | ||||
| code. Appendix B discusses the algorithm's compliance with | ||||
| [RFC8085]. | ||||
| 1.1. Requirements Language | 1.1. Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14[RFC2119] [RFC8174] when, and only when, they appear in all | 14[RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 2. Scope and Goals | 2. Scope, Goals, and Applicability | |||
| The scope of this memo is to define a metric and corresponding method | The scope of this memo is to define Active Measurement metrics and | |||
| to unambiguously perform Active measurements of Maximum IP-Layer | corresponding methods to unambiguously determine Maximum IP-Layer | |||
| Capacity, along with related metrics and methods. | Capacity and useful secondary metrics. | |||
| The main goal is to harmonize the specified metric and method across | Another goal is to harmonize the specified metric and method across | |||
| the industry, and this memo is the vehicle through which working | the industry, and this memo is the vehicle that captures IETF | |||
| group (and eventually, IETF) consensus will be captured and | consensus, possibly resulting in changes to the specifications of | |||
| communicated to achieve broad agreement, and possibly result in | other Standards Development Organizations (SDO) (through each SDO's | |||
| changes in the specifications of other Standards Development | normal contribution process, or through liaison exchange). | |||
| 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 | Secondary goals are to add considerations for test procedures, and to | |||
| to recommend reporting with additional interpretation of the results. | provide interpretation of the Maximum IP-Layer Capacity results (to | |||
| Also, to foster the development of protocol support for this metric | identify cases where more testing is warranted, possibly with | |||
| and method of measurement (all active testing protocols currently | alternate configurations). Fostering the development of protocol | |||
| defined by the IPPM WG are UDP-based, meeting a key requirement of | support for this metric and method of measurement is also a goal of | |||
| these methods). The supporting protocol development to measure this | this memo (all active testing protocols currently defined by the IPPM | |||
| metric according to the specified method is a key future contribution | WG are UDP-based, meeting a key requirement of these methods). The | |||
| to Internet measurement. | 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 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 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 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). | ||||
| - 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 | 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 | |||
| changes: | 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 | 2. Both transfer rate and latency are important to user's | |||
| satisfaction. | satisfaction. | |||
| 3. UDP's growing role in Transport, in areas where TCP once | 3. UDP's growing role in Transport, in areas where TCP once | |||
| dominated. | dominated. | |||
| 4. Content and applications moving physically closer to users. | 4. Content and applications are moving physically closer to users. | |||
| 5. Less emphasis on ISP gateway measurements, possibly due to less | 5. There is less emphasis on ISP gateway measurements, possibly due | |||
| traffic crossing ISP gateways in future. | to less traffic crossing ISP gateways in the future. | |||
| 4. General Parameters and Definitions | 4. General Parameters and Definitions | |||
| This section lists the REQUIRED input factors to specify a Sender or | This section lists the REQUIRED input factors to specify a Sender or | |||
| Receiver metric. | Receiver metric. | |||
| o Src, the address of a host (such as the globally routable IP | o Src, one of the addresses of a host (such as a globally routable | |||
| address). | IP address). | |||
| o Dst, the address of a host (such as the globally routable IP | o Dst, one of the addresses of a host (such as a globally routable | |||
| address). | IP address). | |||
| o MaxHops, the limit on the number of Hops a specific packet may | 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 | visit as it traverses from the host at Src to the host at Dst | |||
| (implemented in the TTL or Hop Limit). | (implemented in the TTL or Hop Limit). | |||
| o T, the time at the start of measurement interval, when packets are | o T0, the time at the start of measurement interval, when packets | |||
| first transmitted from the Source. | are first transmitted from the Source. | |||
| o I, the nominal duration of a measurement interval at the | o I, the nominal duration of a measurement interval at the | |||
| destination (default 10 sec) | destination (default 10 sec) | |||
| o dt, the nominal duration of m equal sub-intervals in I at the | o dt, the nominal duration of m equal sub-intervals in I at the | |||
| destination (default 1 sec) | destination (default 1 sec) | |||
| o dtn, a specific sub-interval, n, one of m sub-intervals in I | o dtn, the beginning boundary of a specific sub-interval, n, one of | |||
| m sub-intervals in I | ||||
| o FT, the feedback time interval between status feedback messages | ||||
| communicating measurement results, sent from the receiver to | ||||
| control the sender. The results are evaluated throughout the test | ||||
| to determine how to adjust the current offered load rate at the | ||||
| sender (default 50ms) | ||||
| o Tmax, a maximum waiting time for test packets to arrive at the | o Tmax, a maximum waiting time for test packets to arrive at the | |||
| destination, set sufficiently long to disambiguate packets with | destination, set sufficiently long to disambiguate packets with | |||
| long delays from packets that are discarded (lost), such that the | long delays from packets that are discarded (lost), such that the | |||
| distribution of one-way delay is not truncated. | distribution of one-way delay is not truncated. | |||
| o F, the number of different flows synthesized by the method | o F, the number of different flows synthesized by the method | |||
| (default 1 flow) | (default 1 flow) | |||
| o flow, the stream of packets with the same n-tuple of designated | o flow, the stream of packets with the same n-tuple of designated | |||
| header fields that (when held constant) result in identical | header fields that (when held constant) result in identical | |||
| treatment in a multi-path decision (such as the decision taken in | treatment in a multi-path decision (such as the decision taken in | |||
| load balancing). Note: The IPv6 flow label MAY be included in the | load balancing). Note: The IPv6 flow label SHOULD be included in | |||
| flow definition when routers have complied with [RFC6438] | the flow definition when routers have complied with [RFC6438] | |||
| guidelines at the Tunnel End Points (TEP), and the source of the | guidelines. | |||
| measurement is a TEP. | ||||
| o Type-P, the complete description of the test packets for which | o Type-P, the complete description of the test packets for which | |||
| this assessment applies (including the flow-defining fields). | this assessment applies (including the flow-defining fields). | |||
| Note that the UDP transport layer is one requirement for test | Note that the UDP transport layer is one requirement for test | |||
| packets specified below. Type-P is a parallel concept to | packets specified below. Type-P is a parallel concept to | |||
| "population of interest" defined in clause 6.1.1 of[Y.1540]. | "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 | o PM, a list of fundamental metrics, such as loss, delay, and | |||
| reordering, and corresponding target performance threshold. At | reordering, and corresponding target performance threshold. At | |||
| least one fundamental metric and target performance threshold MUST | least one fundamental metric and target performance threshold MUST | |||
| be supplied (such as One-way IP Packet Loss [RFC7680] equal to | be supplied (such as One-way IP Packet Loss [RFC7680] equal to | |||
| zero). | zero). | |||
| A non-Parameter which is required for several metrics is defined | A non-Parameter which is required for several metrics is defined | |||
| below: | below: | |||
| o T, the host time of the *first* test packet's *arrival* as | o T, the host time of the *first* test packet's *arrival* as | |||
| measured at the destination Measurement Point, or MP(Dst). There | measured at the destination Measurement Point, or MP(Dst). There | |||
| may be other packets sent between source and destination hosts | may be other packets sent between Source and Destination hosts | |||
| that are excluded, so this is the time of arrival of the first | that are excluded, so this is the time of arrival of the first | |||
| packet used for measurement of the metric. | packet used for measurement of the metric. | |||
| Note that time stamp format and resolution, sequence numbers, etc. | Note that time stamp format and resolution, sequence numbers, etc. | |||
| will be established by the chosen test protocol standard or | will be established by the chosen test protocol standard or | |||
| implementation. | implementation. | |||
| 5. IP-Layer Capacity Singleton Metric Definitions | 5. IP-Layer Capacity Singleton Metric Definitions | |||
| This section sets requirements for the following components to | This section sets requirements for the singleton metric that supports | |||
| support the Maximum IP-layer Capacity Metric. | the Maximum IP-Layer Capacity Metric definition in Section 6. | |||
| 5.1. Formal Name | 5.1. Formal Name | |||
| Type-P-One-way-IP-Capacity, or informally called IP-layer Capacity. | Type-P-One-way-IP-Capacity, or informally called IP-Layer Capacity. | |||
| Note that Type-P depends on the chosen method. | Note that Type-P depends on the chosen method. | |||
| 5.2. Parameters | 5.2. Parameters | |||
| This section lists the REQUIRED input factors to specify the metric, | This section lists the REQUIRED input factors to specify the metric, | |||
| beyond those listed in Section 4. | beyond those listed in Section 4. | |||
| No additional Parameters are needed. | No additional Parameters are needed. | |||
| 5.3. Metric Definitions | 5.3. Metric Definitions | |||
| This section defines the REQUIRED aspects of the measurable IP-layer | This section defines the REQUIRED aspects of the measurable IP-Layer | |||
| Capacity metric (unless otherwise indicated) for measurements between | Capacity metric (unless otherwise indicated) for measurements between | |||
| specified Source and Destination hosts: | specified Source and Destination hosts: | |||
| Define the IP-layer capacity, C(T,dt,PM), to be the number of IP- | Define the IP-Layer Capacity, C(T,dt,PM), to be the number of IP- | |||
| layer bits (including header and data fields) in packets that can be | Layer bits (including header and data fields) in packets that can be | |||
| transmitted from the Src host and correctly received by the Dst host | transmitted from the Src host and correctly received by the Dst host | |||
| during one contiguous sub-interval, dt in length. The IP-layer | during one contiguous sub-interval, dt in length. The IP-Layer | |||
| capacity depends on the Src and Dst hosts, the host addresses, and | Capacity depends on the Src and Dst hosts, the host addresses, and | |||
| the path between the hosts. | the path between the hosts. | |||
| The number of these IP-layer bits is designated n0[dtn,dtn+1] for a | The number of these IP-Layer bits is designated n0[dtn,dtn+1] for a | |||
| specific dt. | specific dt. | |||
| When the packet size is known and of fixed size, the packet count | When the packet size is known and of fixed size, the packet count | |||
| during a single sub-interval dt multiplied by the total bits in IP | during a single sub-interval dt multiplied by the total bits in IP | |||
| header and data fields is equal to n0[dtn,dtn+1]. | header and data fields is equal to n0[dtn,dtn+1]. | |||
| Anticipating a Sample of Singletons, the interval dt SHOULD be set to | Anticipating a Sample of Singletons, the number of sub-intervals with | |||
| a natural number m so that T+I = T + m*dt with dtn+1 - dtn = dt and | duration dt MUST be set to a natural number m, so that T+I = T + m*dt | |||
| with 1 <= n <= m. | with dtn+1 - dtn = dt for 1 <= n <= m. | |||
| Parameter PM represents other performance metrics [see section 5.4 | Parameter PM represents other performance metrics [see section 5.4 | |||
| below]; their measurement results SHALL be collected during | below]; their measurement results SHALL be collected during | |||
| measurement of IP-layer Capacity and associated with the | measurement of IP-Layer Capacity and associated with the | |||
| corresponding dtn for further evaluation and reporting. Users SHALL | corresponding dtn for further evaluation and reporting. Users SHALL | |||
| specify the parameter Tmax as required by each metric's reference | specify the parameter Tmax as required by each metric's reference | |||
| definition. | definition. | |||
| Mathematically, this definition can be represented as: | Mathematically, this definition is represented as (for each n): | |||
| ( n0[dtn,dtn+1] ) | ( n0[dtn,dtn+1] ) | |||
| C(T,dt,PM) = ------------------------- | C(T,dt,PM) = ------------------------- | |||
| dt | dt | |||
| Equation for IP-Layer Capacity | Equation for IP-Layer Capacity | |||
| and: | and: | |||
| o n0 is the total number of IP-layer header and payload bits that | o n0 is the total number of IP-Layer header and payload bits that | |||
| can be transmitted in Standard Formed packets [RFC8468] from the | can be transmitted in standard-formed packets [RFC8468] from the | |||
| Src host and correctly received by the Dst host during one | Src host and correctly received by the Dst host during one | |||
| contiguous sub-interval, dt in length, during the interval [T, | contiguous sub-interval, dt in length, during the interval [T, | |||
| T+I], | T+I], | |||
| o C(T,dt,PM) the IP-Layer Capacity, corresponds to the value of n0 | o C(T,dt,PM) the IP-Layer Capacity, corresponds to the value of n0 | |||
| measured in any sub-interval ending at dtn (meaning T + n*dt), | measured in any sub-interval beginning at dtn, divided by the | |||
| divided by the length of sub-interval, dt. | length of sub-interval, dt. | |||
| o PM represents other performance metrics [see section 5.4 below]; | o PM represents other performance metrics [see section 5.4 below]; | |||
| their measurement results SHALL be collected during measurement of | their measurement results SHALL be collected during measurement of | |||
| IP-layer Capacity and associated with the corresponding dtn for | IP-Layer Capacity and associated with the corresponding dtn for | |||
| further evaluation and reporting. | further evaluation and reporting. | |||
| o all sub-intervals MUST be of equal duration. Choosing dt as non- | o all sub-intervals MUST be of equal duration. Choosing dt as non- | |||
| overlapping consecutive time intervals allows for a simple | overlapping consecutive time intervals allows for a simple | |||
| implementation. | implementation. | |||
| o The bit rate of the physical interface of the measurement device | o The bit rate of the physical interface of the measurement devices | |||
| must be higher than that of the link whose C(T,I,PM) is to be | MUST be higher than the smallest of the links on the path whose | |||
| measured. | C(T,I,PM) is to be measured (the bottleneck link). | |||
| Measurements according to these definitions SHALL use the UDP | Measurements according to these definitions SHALL use the UDP | |||
| transport layer. Standard Formed packets are specified in Section 5 | transport layer. Standard-formed packets are specified in Section 5 | |||
| of [RFC8468]. Some compression affects on measurement are discussed | of [RFC8468]. The measurement SHOULD use a randomized Source port or | |||
| in Section 6 of [RFC8468], as well. | equivalent technique, and SHOULD send responses from the Source | |||
| address matching the test packet destination address. | ||||
| Some compression affects on measurement are discussed in Section 6 of | ||||
| [RFC8468]. | ||||
| 5.4. Related Round-Trip Delay and One-way Loss Definitions | 5.4. Related Round-Trip Delay and One-way Loss Definitions | |||
| RTD[dtn-1,dtn] is defined as a sample of the [RFC2681] Round-trip | RTD[dtn,dtn+1] is defined as a Sample of the [RFC2681] Round-trip | |||
| Delay between the Src host and the Dst host over the interval [T,T+I] | Delay between the Src host and the Dst host over the interval [T,T+I] | |||
| (that contains equal non-overlapping intervals of dt). The | (that contains equal non-overlapping intervals of dt). The | |||
| "reasonable period of time" in [RFC2681] is the parameter Tmax in | "reasonable period of time" in [RFC2681] is the parameter Tmax in | |||
| this memo. The statistics used to to summarize RTD[dtn-1,dtn] MAY | this memo. The statistics used to summarize RTD[dtn,dtn+1] MAY | |||
| include the minimum, maximum, median, and mean, and the range = | include the minimum, maximum, median, and mean, and the range = | |||
| (maximum - minimum) is referred to below in Section 8.1 for load | (maximum - minimum) is referred to below in Section 8.1 for load | |||
| adjustment purposes. | adjustment purposes. | |||
| OWL[dtn-1,dtn] is defined as a sample of the [RFC7680] One-way Loss | OWL[dtn,dtn+1] is defined as a Sample of the [RFC7680] One-way Loss | |||
| between the Src host and the Dst host over the interval [T,T+I] (that | between the Src host and the Dst host over the interval [T,T+I] (that | |||
| contains equal non-overlapping intervals of dt). The statistics used | contains equal non-overlapping intervals of dt). The statistics used | |||
| to to summarize OWL[dtn-1,dtn] MAY include the lost packet count and | to summarize OWL[dtn,dtn+1] MAY include the lost packet count and the | |||
| the lost packet ratio. | lost packet ratio. | |||
| Other metrics MAY be measured: one-way reordering, duplication, and | Other metrics MAY be measured: one-way reordering, duplication, and | |||
| delay variation. | delay variation. | |||
| 5.5. Discussion | 5.5. Discussion | |||
| See the corresponding section for Maximum IP-Layer Capacity. | See the corresponding section for Maximum IP-Layer Capacity. | |||
| 5.6. Reporting the Metric | 5.6. Reporting the Metric | |||
| The IP-Layer Capacity SHOULD be reported with at least single Megabit | The IP-Layer Capacity SHOULD be reported with at least single Megabit | |||
| resolution, in units of Megabits per second (Mbps). | resolution, in units of Megabits per second (Mbps), (which is | |||
| 1,000,000 bits per second to avoid any confusion). | ||||
| The Related Round Trip Delay and/or Loss metric measurements for the | The related One-way Loss metric and Round Trip Delay measurements for | |||
| same Singleton SHALL be reported, also with meaningful resolution for | the same Singleton SHALL be reported, also with meaningful resolution | |||
| the values measured. | for the values measured. | |||
| Individual Capacity measurements MAY be reported in a manner | Individual Capacity measurements MAY be reported in a manner | |||
| consistent with the Maximum IP-Layer Capacity, see Section 9. | consistent with the Maximum IP-Layer Capacity, see Section 9. | |||
| 6. Maximum IP-Layer Capacity Metric Definitions (Statistic) | 6. Maximum IP-Layer Capacity Metric Definitions (Statistic) | |||
| This section sets requirements for the following components to | This section sets requirements for the following components to | |||
| support the Maximum IP-layer Capacity Metric. | support the Maximum IP-Layer Capacity Metric. | |||
| 6.1. Formal Name | 6.1. Formal Name | |||
| Type-P-One-way-Max-IP-Capacity, or informally called Maximum IP-layer | Type-P-One-way-Max-IP-Capacity, or informally called Maximum IP-Layer | |||
| Capacity. | Capacity. | |||
| Note that Type-P depends on the chosen method. | Note that Type-P depends on the chosen method. | |||
| 6.2. Parameters | 6.2. Parameters | |||
| This section lists the REQUIRED input factors to specify the metric, | This section lists the REQUIRED input factors to specify the metric, | |||
| beyond those listed in Section 4. | beyond those listed in Section 4. | |||
| No additional Parameters or definitions are needed. | No additional Parameters or definitions are needed. | |||
| 6.3. Metric Definitions | 6.3. Metric Definitions | |||
| This section defines the REQUIRED aspects of the Maximum IP-layer | This section defines the REQUIRED aspects of the Maximum IP-Layer | |||
| Capacity metric (unless otherwise indicated) for measurements between | Capacity metric (unless otherwise indicated) for measurements between | |||
| specified Source and Destination hosts: | specified Source and Destination hosts: | |||
| Define the Maximum IP-layer capacity, Maximum_C(T,I,PM), to be the | Define the Maximum IP-Layer Capacity, Maximum_C(T,I,PM), to be the | |||
| maximum number of IP-layer bits n0[dtn,dtn+1] that can be transmitted | maximum number of IP-Layer bits n0[dtn,dtn+1] divided by dt that can | |||
| in packets from the Src host and correctly received by the Dst host, | be transmitted in packets from the Src host and correctly received by | |||
| over all dt length intervals in [T, T+I], and meeting the PM | the Dst host, over all dt length intervals in [T, T+I], and meeting | |||
| criteria. Equivalently the Maximum of a Sample of size m of | the PM criteria. Equivalently the Maximum of a Sample of size m of | |||
| C(T,I,PM) collected during the interval [T, T+I] and meeting the PM | C(T,I,PM) collected during the interval [T, T+I] and meeting the PM | |||
| criteria. | criteria. | |||
| The interval dt SHOULD be set to a natural number m so that T+I = T + | The number of sub-intervals with duration dt MUST be set to a natural | |||
| m*dt with dtn+1 - dtn = dt and with 1 <= n <= m. | number m, so that T+I = T + m*dt with dtn+1 - dtn = dt for 1 <= n <= | |||
| m. | ||||
| Parameter PM represents the other performance metrics (see | Parameter PM represents the other performance metrics (see | |||
| Section 6.4 below) and their measurement results for the maximum IP- | Section 6.4 below) and their measurement results for the Maximum IP- | |||
| layer capacity. At least one target performance threshold (PM | Layer Capacity. At least one target performance threshold (PM | |||
| criterion) MUST be defined. If more than one metric and target | criterion) MUST be defined. If more than one metric and target | |||
| performance threshold are defined, then the sub-interval with maximum | performance threshold are defined, then the sub-interval with maximum | |||
| number of bits transmitted MUST meet all the target performance | number of bits transmitted MUST meet all the target performance | |||
| thresholds. Users SHALL specify the parameter Tmax as required by | thresholds. Users SHALL specify the parameter Tmax as required by | |||
| each metric's reference definition. | each metric's reference definition. | |||
| Mathematically, this definition can be represented as: | Mathematically, this definition can be represented as: | |||
| max ( n0[dtn,dtn+1] ) | max ( n0[dtn,dtn+1] ) | |||
| [T,T+I] | [T,T+I] | |||
| skipping to change at page 10, line 20 ¶ | skipping to change at page 12, line 20 ¶ | |||
| T T+I | T T+I | |||
| _________________________________________ | _________________________________________ | |||
| | | | | | | | | | | | | | | | | | | | | | | | | |||
| dtn=1 2 3 4 5 6 7 8 9 10 n+1 | dtn=1 2 3 4 5 6 7 8 9 10 n+1 | |||
| n=m | n=m | |||
| Equation for Maximum Capacity | Equation for Maximum Capacity | |||
| and: | and: | |||
| o n0 is the total number of IP-layer header and payload bits that | o n0 is the total number of IP-Layer header and payload bits that | |||
| can be transmitted in Standard Formed packets from the Src host | can be transmitted in standard-formed packets from the Src host | |||
| and correctly received by the Dst host during one contiguous sub- | and correctly received by the Dst host during one contiguous sub- | |||
| interval, dt in length, during the interval [T, T+I], | interval, dt in length, during the interval [T, T+I], | |||
| o Maximum_C(T,I,PM) the Maximum IP-Layer Capacity, corresponds to | o Maximum_C(T,I,PM) the Maximum IP-Layer Capacity, corresponds to | |||
| the maximum value of n0 measured in any sub-interval ending at dtn | the maximum value of n0 measured in any sub-interval beginning at | |||
| (meaning T + n*dt), divided by the constant length of all sub- | dtn, divided by the constant length of all sub-intervals, dt. | |||
| intervals, dt. | ||||
| o PM represents the other performance metrics (see Section 5.4) and | o PM represents the other performance metrics (see Section 5.4) and | |||
| their measurement results for the maximum IP-layer capacity. At | their measurement results for the Maximum IP-Layer Capacity. At | |||
| least one target performance threshold (PM criterion) MUST be | least one target performance threshold (PM criterion) MUST be | |||
| defined. | defined. | |||
| o all sub-intervals MUST be of equal duration. Choosing dt as non- | o all sub-intervals MUST be of equal duration. Choosing dt as non- | |||
| overlapping consecutive time intervals allows for a simple | overlapping consecutive time intervals allows for a simple | |||
| implementation. | implementation. | |||
| o The bit rate of the physical interface of the measurement systems | o The bit rate of the physical interface of the measurement systems | |||
| must be higher than that of the link whose Maximum_C(T,I,PM) is to | MUST be higher than the smallest of the links on the path whose | |||
| be measured (the bottleneck link). | 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 | In this definition, the m sub-intervals can be viewed as trials when | |||
| the Src host varies the transmitted packet rate, searching for the | 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 | 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 | 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 | 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 | trials to evaluate the stability of n0 and metric(s) in the PM list | |||
| over all dt-length intervals in I. | over all dt-length intervals in I. | |||
| Measurements according to these definitions SHALL use the UDP | Measurements according to these definitions SHALL use the UDP | |||
| transport layer. | transport layer. | |||
| 6.4. Related Round-Trip Delay and One-way Loss Definitions | 6.4. Related Round-Trip Delay and One-way Loss Definitions | |||
| RTD[dtn,dtn+1] and OWL[dtn,dtn+1] are defined in Section 5.4. Here, | RTD[dtn,dtn+1] and OWL[dtn,dtn+1] are defined in Section 5.4. Here, | |||
| the test intervals are increased to match the capacity samples, | the test intervals are increased to match the capacity Samples, | |||
| RTD[T,I] and OWL[T,I]. | RTD[T,I] and OWL[T,I]. | |||
| The interval dtn,dtn+1 where Maximum_C[T,I,PM] occurs is the | The interval dtn,dtn+1 where Maximum_C[T,I,PM] occurs is the | |||
| reporting sub-interval for RTD[T,I] and OWL[T,I]. | reporting sub-interval within RTD[T,I] and OWL[T,I]. | |||
| Other metrics MAY be measured: one-way reordering, duplication, and | Other metrics MAY be measured: one-way reordering, duplication, and | |||
| delay variation. | delay variation. | |||
| 6.5. Discussion | 6.5. Discussion | |||
| If traffic conditioning (e.g., shaping, policing) applies along a | If traffic conditioning (e.g., shaping, policing) applies along a | |||
| path for which Maximum_C(T,I,PM) is to be determined, different | path for which Maximum_C(T,I,PM) is to be determined, different | |||
| values for dt SHOULD be picked and measurements be executed during | values for dt SHOULD be picked and measurements be executed during | |||
| multiple intervals [T, T+I]. A single constant interval dt SHOULD be | multiple intervals [T, T+I]. Each duration dt SHOULD be chosen so | |||
| chosen so that is an integer multiple of increasing values k times | that it is an integer multiple of increasing values k times | |||
| serialisation delay of a path MTU at the physical interface speed | serialization delay of a path MTU at the physical interface speed | |||
| where traffic conditioning is expected. This should avoid taking | where traffic conditioning is expected. This should avoid taking | |||
| configured burst tolerance singletons as a valid Maximum_C(T,I,PM) | configured burst tolerance singletons as a valid Maximum_C(T,I,PM) | |||
| result. | result. | |||
| A Maximum_C(T,I,PM) without any indication of bottleneck congestion, | A Maximum_C(T,I,PM) without any indication of bottleneck congestion, | |||
| be that an increasing latency, packet loss or ECN marks during a | be that an increasing latency, packet loss or ECN marks during a | |||
| measurement interval I, is likely to underestimate Maximum_C(T,I,PM). | measurement interval I, is likely to underestimate Maximum_C(T,I,PM). | |||
| 6.6. Reporting the Metric | 6.6. Reporting the Metric | |||
| The IP-Layer Capacity SHOULD be reported with at least single Megabit | The IP-Layer Capacity SHOULD be reported with at least single Megabit | |||
| resolution, in units of Megabits per second (Mbps) (which is | resolution, in units of Megabits per second (Mbps) (which is | |||
| 1,000,000 bits per second to avoid any confusion). | 1,000,000 bits per second to avoid any confusion). | |||
| The Related Round Trip Delay and/or Loss metric measurements for the | The related One-way Loss metric and Round Trip Delay measurements for | |||
| same Singleton SHALL be reported, also with meaningful resolution for | the same Singleton SHALL be reported, also with meaningful resolution | |||
| the values measured. | for the values measured. | |||
| When there are demonstrated and repeatable Capacity modes in the | When there are demonstrated and repeatable Capacity modes in the | |||
| Sample, then the Maximum IP-Layer Capacity SHALL be reported for each | Sample, then the Maximum IP-Layer Capacity SHALL be reported for each | |||
| mode, along with the relative time from the beginning of the stream | mode, along with the relative time from the beginning of the stream | |||
| that the mode was observed to be present. Bimodal Maxima have been | that the mode was observed to be present. Bimodal Maximum IP-Layer | |||
| observed with some services, sometimes called a "turbo mode" | Capacities have been observed with some services, sometimes called a | |||
| intending to deliver short transfers more quickly, or reduce the | "turbo mode" intending to deliver short transfers more quickly, or | |||
| initial buffering time for some video streams. Note that modes | reduce the initial buffering time for some video streams. Note that | |||
| lasting less than dt duration will not be detected. | modes lasting less than dt duration will not be detected. | |||
| Some transmission technologies have multiple methods of operation | Some transmission technologies have multiple methods of operation | |||
| that may be activated when channel conditions degrade or improve, and | that may be activated when channel conditions degrade or improve, and | |||
| these transmission methods may determine the Maximum IP-Layer | these transmission methods may determine the Maximum IP-Layer | |||
| Capacity. Examples include line-of-sight microwave modulator | Capacity. Examples include line-of-sight microwave modulator | |||
| constellations, or cellular modem technologies where the changes may | constellations, or cellular modem technologies where the changes may | |||
| be initiated by a user moving from one coverage area to another. | be initiated by a user moving from one coverage area to another. | |||
| Operation in the different transmission methods may be observed over | Operation in the different transmission methods may be observed over | |||
| time, but the modes of Maximum IP-Layer Capacity will not be | time, but the modes of Maximum IP-Layer Capacity will not be | |||
| activated deterministically as with the "turbo mode" described in the | activated deterministically as with the "turbo mode" described in the | |||
| paragraph above. | paragraph above. | |||
| 7. IP-Layer Sender Bit Rate Singleton Metric Definitions | 7. IP-Layer Sender Bit Rate Singleton Metric Definitions | |||
| This section sets requirements for the following components to | This section sets requirements for the following components to | |||
| support the IP-layer Sender Bitrate Metric. This metric helps to | support the IP-Layer Sender Bitrate Metric. This metric helps to | |||
| check that the sender actually generated the desired rates during a | check that the sender actually generated the desired rates during a | |||
| test, and measurement takes place at the Src host to network path | test, and measurement takes place at the Src host to network path | |||
| interface (or as close as practical). It is not a metric for path | interface (or as close as practical within the Src host). It is not | |||
| performance. | a metric for path performance. | |||
| 7.1. Formal Name | 7.1. Formal Name | |||
| Type-P-IP-Sender-Bit-Rate, or informally called IP-layer Sender | Type-P-IP-Sender-Bit-Rate, or informally called IP-Layer Sender | |||
| Bitrate. | Bitrate. | |||
| Note that Type-P depends on the chosen method. | Note that Type-P depends on the chosen method. | |||
| 7.2. Parameters | 7.2. Parameters | |||
| This section lists the REQUIRED input factors to specify the metric, | This section lists the REQUIRED input factors to specify the metric, | |||
| beyond those listed in Section 4. | beyond those listed in Section 4. | |||
| o S, the duration of the measurement interval at the Source | o S, the duration of the measurement interval at the Source | |||
| o st, the nominal duration of N sub-intervals in S (default = 0.05 | o st, the nominal duration of N sub-intervals in S (default st = | |||
| seconds) | 0.05 seconds) | |||
| o stn, the beginning boundary of a specific sub-interval, n, one of | ||||
| N sub-intervals in S | ||||
| S SHALL be longer than I, primarily to account for on-demand | S SHALL be longer than I, primarily to account for on-demand | |||
| activation of the path, or any preamble to testing required, and the | activation of the path, or any preamble to testing required, and the | |||
| delay of the path. | delay of the path. | |||
| st SHOULD be much smaller than the sub-interval dt. The st parameter | st SHOULD be much smaller than the sub-interval dt and on the same | |||
| does not have relevance when the Source is transmitting at a fixed | order as FT, otherwise the rate measurement will include many rate | |||
| rate throughout S. | adjustments and include more time smoothing, thus missing the Maximum | |||
| IP-Layer Capacity. The st parameter does not have relevance when the | ||||
| Source is transmitting at a fixed rate throughout S. | ||||
| 7.3. Metric Definition | 7.3. Metric Definition | |||
| This section defines the REQUIRED aspects of the IP-layer Sender | This section defines the REQUIRED aspects of the IP-Layer Sender | |||
| Bitrate metric (unless otherwise indicated) for measurements at the | Bitrate metric (unless otherwise indicated) for measurements at the | |||
| specified Source on packets addressed for the intended Destination | specified Source on packets addressed for the intended Destination | |||
| host and matching the required Type-P: | host and matching the required Type-P: | |||
| Define the IP-layer Sender Bit Rate, B(S,st), to be the number of IP- | Define the IP-Layer Sender Bit Rate, B(S,st), to be the number of IP- | |||
| layer bits (including header and data fields) that are transmitted | Layer bits (including header and data fields) that are transmitted | |||
| from the Source during one contiguous sub-interval, st, during the | from the Source with address pair Src and Dst during one contiguous | |||
| test interval S (where S SHALL be longer than I), and where the | sub-interval, st, during the test interval S (where S SHALL be longer | |||
| fixed-size packet count during that single sub-interval st also | than I), and where the fixed-size packet count during that single | |||
| provides the number of IP-layer bits in any interval: n0[stn-1,stn]. | sub-interval st also provides the number of IP-Layer bits in any | |||
| interval, [stn,stn+1]. | ||||
| Measurements according to these definitions SHALL use the UDP | Measurements according to these definitions SHALL use the UDP | |||
| transport layer. Any feedback from Dst host to Src host received by | transport layer. Any feedback from Dst host to Src host received by | |||
| Src host during an interval [stn-1,stn] MUST NOT result in an | Src host during an interval [stn,stn+1] SHOULD NOT result in an | |||
| adaptation of the Src host traffic conditioning during this interval | adaptation of the Src host traffic conditioning during this interval | |||
| (rate adjustment occurs on st boundaries). | (rate adjustment occurs on st interval boundaries). | |||
| 7.4. Discussion | 7.4. Discussion | |||
| Both the Sender and Receiver or (source and destination) bit rates | Both the Sender and Receiver or (Source and Destination) bit rates | |||
| SHOULD be assessed as part of an IP-layer Capacity measurement. | SHOULD be assessed as part of an IP-Layer Capacity measurement. | |||
| Otherwise, an unexpected sending rate limitation could produce an | ||||
| erroneous Maximum IP-Layer Capacity measurement. | ||||
| 7.5. Reporting the Metric | 7.5. Reporting the Metric | |||
| The IP-Layer Sender Bit Rate SHALL be reported with meaningful | The IP-Layer Sender Bit Rate SHALL be reported with meaningful | |||
| resolution, in units of Megabits per second. | resolution, in units of Megabits per second (which is 1,000,000 bits | |||
| per second to avoid any confusion). | ||||
| Individual IP-Layer Sender Bit Rate measurements are discussed | Individual IP-Layer Sender Bit Rate measurements are discussed | |||
| further in Section 9. | further in Section 9. | |||
| 8. Method of Measurement | 8. Method of Measurement | |||
| The architecture of the method REQUIRES two cooperating hosts | The architecture of the method REQUIRES two cooperating hosts | |||
| operating in the roles of Src (test packet sender) and Dst | operating in the roles of Src (test packet sender) and Dst | |||
| (receiver), with a measured path and return path between them. | (receiver), with a measured path and return path between them. | |||
| The duration of a test, parameter I, MUST be constrained in a | The duration of a test, parameter I, MUST be constrained in a | |||
| production network, since this is an active test method and it will | 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. | likely cause congestion on the Src to Dst host path during a test. | |||
| 8.1. Load Rate Adjustment Algorithm | 8.1. Load Rate Adjustment Algorithm | |||
| A table SHALL be pre-built defining all the offered load rates that | The algorithm described in this section MUST NOT be used as a general | |||
| will be supported (R1 through Rn, in ascending order, corresponding | Congestion Control Algorithm (CCA). As stated in the Scope | |||
| to indexed rows in the table). Each rate is defined as datagrams of | Section 2, the load rate adjustment algorithm's goal is to help | |||
| size ss, sent as a burst of count cc, every time interval tt (default | determine the Maximum IP-Layer Capacity in the context of an | |||
| for tt is 1ms, a likely system tick-interval). While it is | infrequent, diagnostic, short term measurement. There is a tradeoff | |||
| advantageous to use datagrams of as large a size as possible, it may | between test duration (also the test data volume) and algorithm | |||
| be prudent to use a slightly smaller maximum that allows for | aggressiveness (speed of ramp-up and down to the Maximum IP-Layer | |||
| secondary protocol headers and/or tunneling without resulting in IP- | Capacity). The parameter values chosen below strike a well-tested | |||
| layer fragmentation. Selection of a new rate is indicated by a | balance among these factors. | |||
| calculation on the current row, Rx. For example: | ||||
| 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. 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: | ||||
| "Rx+1": the sender uses the next higher rate in the table. | "Rx+1": the sender uses the next higher rate in the table. | |||
| "Rx-10": the sender uses the rate 10 rows lower in the table. | "Rx-10": the sender uses the rate 10 rows lower in the table. | |||
| At the beginning of a test, the sender begins sending at rate R1 and | 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 | the receiver starts a feedback timer of duration FT (while awaiting | |||
| inbound datagrams). As datagrams are received they are checked for | inbound datagrams). As datagrams are received they are checked for | |||
| sequence number anomalies (loss, out-of-order, duplication, etc.) and | sequence number anomalies (loss, out-of-order, duplication, etc.) and | |||
| the delay range is measured (one-way or round-trip). This | the delay range is measured (one-way or round-trip). This | |||
| information is accumulated until the feedback timer F expires and a | information is accumulated until the feedback timer FT expires and a | |||
| status feedback message is sent from the receiver back to the sender, | status feedback message is sent from the receiver back to the sender, | |||
| to communicate this information. The accumulated statistics are then | to communicate this information. The accumulated statistics are then | |||
| reset by the receiver for the next feedback interval. As feedback | reset by the receiver for the next feedback interval. As feedback | |||
| messages are received back at the sender, they are evaluated to | messages are received back at the sender, they are evaluated to | |||
| determine how to adjust the current offered load rate (Rx). | determine how to adjust the current offered load rate (Rx). | |||
| If the feedback indicates that no sequence number anomalies were | If the feedback indicates that no sequence number anomalies were | |||
| detected AND the delay range was below the lower threshold, the | detected AND the delay range was below the lower threshold, the | |||
| offered load rate is increased. If congestion has not been confirmed | 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 | up to this point (see below for the method to declare congestion), | |||
| rate (e.g., Rx+10). This allows the offered load to quickly reach a | the offered load rate is increased by more than one rate (e.g., | |||
| near-maximum rate. Conversely, if congestion has been previously | Rx+10). This allows the offered load to quickly reach a near-maximum | |||
| confirmed, the offered load rate is only increased by one (Rx+1). | 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 | If the feedback indicates that sequence number anomalies were | |||
| detected OR the delay range was above the upper threshold, the | detected OR the delay range was above the upper threshold, the | |||
| offered load rate is decreased. Also, if congestion is now confirmed | offered load rate is decreased. The RECOMMENDED threshold values are | |||
| by the current feedback message being processed, then the offered | 0 for sequence number gaps and 30 ms for lower and 90 ms for upper | |||
| load rate is decreased by more than one rate (e.g., Rx-30). This | delay thresholds, respectively. Also, if congestion is now confirmed | |||
| one-time reduction is intended to compensate for the fast initial | for the first time by the current feedback message being processed, | |||
| ramp-up. In all other cases, the offered load rate is only decreased | then the offered load rate is decreased by more than one rate (e.g., | |||
| by one (Rx-1). | 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 | If the feedback indicates that there were no sequence number | |||
| anomalies AND the delay range was above the lower threshold, but | anomalies AND the delay range 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 inferring congestion is that there were | Lastly, the method for inferring congestion is that there were | |||
| sequence number anomalies AND/OR the delay range was above the upper | sequence number anomalies AND/OR the delay range was above the upper | |||
| threshold for two consecutive feedback intervals. The algorithm | threshold for two consecutive feedback intervals. The algorithm | |||
| described above is also illustrated in ITU-T Rec. Y.1540, 2020 | described above is also illustrated in ITU-T Rec. Y.1540, 2020 | |||
| version[Y.1540], in Annex B, and implemented in the Appendix on Load | version[Y.1540], in Annex B, and implemented in the Appendix on Load | |||
| Rate Adjustment Pseudo Code in this memo. | Rate Adjustment Pseudo Code in this memo. | |||
| All the values used above are relevant to searches in the 1 Mbps to | The load rate adjustment algorithm MUST include timers that stop the | |||
| 10 Gbps capacity range. Searches can accommodate higher rate | test when received packet streams cease unexpectedly. The timeout | |||
| capacities by changing the rates in the pre-built table. | thresholds are provided in the table below, along with values for all | |||
| other parameters and variables described in this section. Operation | ||||
| of non-obvious parameters appear below: | ||||
| load packet timeout Operation: The load packet timeout SHALL be | ||||
| reset to the configured value each time a load packet received. | ||||
| If the timeout expires, the receiver SHALL be closed and no | ||||
| 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 | | ||||
| | | | | 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 | | ||||
| | (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 | | ||||
| | 1 | | | | | ||||
| +-------------+-------------+---------------+-----------------------+ | ||||
| | table index | 1Mbps | 1Mbps<=rate<= | same as tested | | ||||
| | (step) size | | 1Gbps | | | ||||
| +-------------+-------------+---------------+-----------------------+ | ||||
| | table index | 100Mbps | 1Gbps<=rate<= | same as tested | | ||||
| | (step) | | 10Gbps | | | ||||
| | size, | | | | | ||||
| | 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. | | ||||
| +-------------+-------------+---------------+-----------------------+ | ||||
| | 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. | | ||||
| +-------------+-------------+---------------+-----------------------+ | ||||
| | 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 | | ||||
| | range | | | | | ||||
| | threshold | | | | | ||||
| +-------------+-------------+---------------+-----------------------+ | ||||
| | sequence | 0 | 0, 100 | same as tested | | ||||
| | error | | | | | ||||
| | threshold | | | | | ||||
| +-------------+-------------+---------------+-----------------------+ | ||||
| | consecutive | 2 | 2 | Use values >1 to | | ||||
| | errored | | | avoid misinterpreting | | ||||
| | status | | | transient loss | | ||||
| | report | | | | | ||||
| | threshold | | | | | ||||
| +-------------+-------------+---------------+-----------------------+ | ||||
| | Fast mode | 10 | 10 | 2 <= steps <= 30 | | ||||
| | increase, | | | | | ||||
| | in table | | | | | ||||
| | index steps | | | | | ||||
| +-------------+-------------+---------------+-----------------------+ | ||||
| | Fast mode | 3 * Fast | 3 * Fast mode | same as tested | | ||||
| | decrease, | mode | increase | | | ||||
| | in table | increase | | | | ||||
| | index steps | | | | | ||||
| +-------------+-------------+---------------+-----------------------+ | ||||
| Parameters for Load Rate Adjustment Algorithm | ||||
| As a consequence of default parameterization, the Number of table | ||||
| steps in total for rates <10Gbps is 2000 (excluding index 0). | ||||
| A related sender backoff response to network conditions occurs when | ||||
| one or more status feedback messages fail to arrive at the sender. | ||||
| If no status feedback messages arrive at the sender for the interval | ||||
| greater than the Lost Status Backoff timeout: | ||||
| UDRT + (2+w)*FT = Lost Status Backoff timeout | ||||
| where: | ||||
| UDRT = upper delay range threshold (default 90ms) | ||||
| FT = feedback time interval (default 50ms) | ||||
| w = number of repeated timeouts (w=0 initially, w++ on each | ||||
| timeout, and reset to 0 when a message is received) | ||||
| beginning when the last message (of any type) was successfully | ||||
| received at the sender: | ||||
| Then the offered load SHALL be decreased, following the same process | ||||
| as when the feedback indicates presence of one or more sequence | ||||
| number anomalies OR the delay range was above the upper threshold (as | ||||
| described above), with the same load rate adjustment algorithm | ||||
| variables in their current state. This means that rate reduction and | ||||
| congestion confirmation can result from a three-way OR that includes | ||||
| lost status feedback messages, sequence errors, or delay variation. | ||||
| The RECOMMENDED initial value for w is 0, taking Round Trip Time | ||||
| (RTT) less than FT into account. A test with RTT longer than FT is a | ||||
| valid reason to increase the initial value of w appropriately. | ||||
| Variable w SHALL be incremented by 1 whenever the Lost Status Backoff | ||||
| timeout is exceeded. So with FT = 50ms and UDRT = 90ms, a status | ||||
| feedback message loss would be declared at 190ms following a | ||||
| successful message, again at 50ms after that (240ms total), and so | ||||
| on. | ||||
| Also, if congestion is now confirmed for the first time by a Lost | ||||
| Status Backoff timeout, 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). | ||||
| Appendix B discusses compliance with the applicable mandatory | ||||
| requirements of [RFC8085], consistent with the goals of the IP-Layer | ||||
| Capacity Metric and Method, including the load rate adjustment | ||||
| algorithm described in this section. | ||||
| 8.2. Measurement Qualification or Verification | 8.2. Measurement Qualification or Verification | |||
| It is of course necessary to calibrate the equipment performing the | It is of course necessary to calibrate the equipment performing the | |||
| IP-layer Capacity measurement, to ensure that the expected capacity | IP-Layer Capacity measurement, to ensure that the expected capacity | |||
| can be measured accurately, and that equipment choices (processing | can be measured accurately, and that equipment choices (processing | |||
| speed, interface bandwidth, etc.) are suitably matched to the | speed, interface bandwidth, etc.) are suitably matched to the | |||
| measurement range. | measurement range. | |||
| 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 | |||
| would not do. This situation is different from the bi-modal service | would not do. This situation is different from the bi-modal service | |||
| rates (discussed under Reporting), which are characterized by a | rates (discussed under Reporting), which are characterized by a | |||
| multi-second duration (much longer than the measured RTT) and | multi-second duration (much longer than the measured RTT) and | |||
| repeatable behavior. | repeatable behavior. | |||
| There are many ways that the Method of Measurement could handle this | There are many ways that the Method of Measurement could handle this | |||
| false-max issue. The default value for measurement of singletons (dt | false-max issue. The default value for measurement of singletons (dt | |||
| = 1 second) has proven to a be of practical value during tests of | = 1 second) has proven to be of practical value during tests of this | |||
| this method, allows the bimodal service rates to be characterized, | method, allows the bimodal service rates to be characterized, and it | |||
| and it has an obvious alignment with the reporting units (Mbps). | 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 | discussion of Trial duration, where relatively short trials conducted | |||
| as part of the search are followed by longer trials to make the final | as part of the search are followed by longer trials to make the final | |||
| determination. In the production network, measurements of singletons | determination. In the production network, measurements of Singletons | |||
| and samples (the terms for trials and tests of Lab Benchmarking) must | and Samples (the terms for trials and tests of Lab Benchmarking) must | |||
| be limited in duration because they may be service-affecting. But | be limited in duration because they may be service-affecting. But | |||
| there is sufficient value in repeating a sample with a fixed sending | there is sufficient value in repeating a Sample with a fixed sending | |||
| rate determined by the previous search for the Max IP-layer Capacity, | rate determined by the previous search for the Maximum IP-Layer | |||
| to qualify the result in terms of the other performance metrics | Capacity, to qualify the result in terms of the other performance | |||
| measured at the same time. | metrics measured at the same time. | |||
| A qualification measurement for the search result is a subsequent | A qualification measurement for the search result is a subsequent | |||
| measurement, sending at a fixed 99.x % of the Max IP-layer Capacity | measurement, sending at a fixed 99.x % of the Maximum IP-Layer | |||
| for I, or an indefinite period. The same Max Capacity Metric is | Capacity for I, or an indefinite period. The same Maximum Capacity | |||
| applied, and the Qualification for the result is a sample without | Metric is applied, and the Qualification for the result is a Sample | |||
| packet loss or a growing minimum delay trend in subsequent singletons | without packet loss or a growing minimum delay trend in subsequent | |||
| (or each dt of the measurement interval, I). Samples exhibiting | singletons (or each dt of the measurement interval, I). Samples | |||
| losses or increasing queue occupation require a repeated search and/ | exhibiting losses or increasing queue occupation require a repeated | |||
| or test at reduced fixed sender rate for qualification. | search and/or test at reduced fixed sender rate for qualification. | |||
| Here, as with any Active Capacity test, the test duration must be | Here, as with any Active Capacity test, the test duration must be | |||
| kept short. 10 second tests for each direction of transmission are | kept short. 10 second tests for each direction of transmission are | |||
| common today. The default measurement interval specified here is I = | common today. The default measurement interval specified here is I = | |||
| 10 seconds). In combination with a fast search method and user- | 10 seconds. The combination of a fast and congestion-aware search | |||
| network coordination, the concerns raised in RFC 6815[RFC6815] are | method and user-network coordination make a unique contribution to | |||
| alleviated. The method for assessing Max IP Capacity is different | production testing. The Maximum IP Capacity metric and method for | |||
| from classic [RFC2544] methods: they use short term load adjustment | assessing performance is very different from classic [RFC2544] | |||
| and are sensitive to loss and delay, like other congestion control | Throughput metric and methods : it uses near-real-time load | |||
| algorithms used on the Internet every day. | adjustments that are sensitive to loss and delay, similar to other | |||
| congestion control algorithms used on the Internet every day, along | ||||
| with limited duration. On the other hand, [RFC2544] Throughput | ||||
| measurements can produce sustained overload conditions for extended | ||||
| periods of time. Individual trials in a test governed by a binary | ||||
| search can last 60 seconds for each step, and the final confirmation | ||||
| trial may be even longer. This is very different from "normal" | ||||
| traffic levels, but overload conditions are not a concern in the | ||||
| isolated test environment. The concerns raised in [RFC6815] were | ||||
| that [RFC2544] methods would be let loose on production networks, and | ||||
| instead the authors challenged the standards community to develop | ||||
| metrics and methods like those described in this memo. | ||||
| 8.3. Measurement Considerations | 8.3. Measurement Considerations | |||
| In general, the wide-spread measurements that this memo encourages | In general, the wide-spread measurements that this memo encourages | |||
| will encounter wide-spread behaviors. The bimodal IP Capacity | will encounter wide-spread behaviors. The bimodal IP Capacity | |||
| behaviors already discussed in Section 6.6 are good examples. | behaviors already discussed in Section 6.6 are good examples. | |||
| In general, it is RECOMMENDED to locate test endpoints as close to | In general, it is RECOMMENDED to locate test endpoints as close to | |||
| the intended measured link(s) as practical (this is not always | the intended measured link(s) as practical (this is not always | |||
| possible for reasons of scale; there is a limit on number of test | possible for reasons of scale; there is a limit on number of test | |||
| endpoints coming from many perspectives, management and measurement | endpoints coming from many perspectives, management and measurement | |||
| traffic for example). The testing operator MUST set a value for the | traffic for example). The testing operator MUST set a value for the | |||
| MaxHops parameter, based on the expected path length. This parameter | MaxHops parameter, based on the expected path length. This parameter | |||
| can keep measurement traffic from straying too far beyond the | can keep measurement traffic from straying too far beyond the | |||
| intended path. | 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 | Parameter "Time of day" when a test starts may not be enough | |||
| information. Repeatable testing may require the time from the | information. Repeatable testing may require the time from the | |||
| beginning of a measured flow, and how the flow is constructed | beginning of a measured flow, and how the flow is constructed | |||
| including how much traffic has already been sent on that flow when a | 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 | state-change is observed, because the state-change may be based on | |||
| time or bytes sent or both. | 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 | Many different types of traffic shapers and on-demand communications | |||
| be encountered, as anticipated in [RFC7312], and play a key role in | access technologies may be encountered, as anticipated in [RFC7312], | |||
| measurement results. Methods MUST be prepared to provide a short | and play a key role in measurement results. Methods MUST be prepared | |||
| preamble transmission to activate on-demand access, and to discard | to provide a short preamble transmission to activate on-demand | |||
| the preamble from subsequent test results. | communications access, and to discard the preamble from subsequent | |||
| test results. | ||||
| Conditions which might be encountered during measurement, where | 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: | rate: | |||
| 1. Congestion of an interconnection or backbone interface may appear | 1. Congestion of an interconnection or backbone interface may appear | |||
| as packet losses distributed over time in the test stream, due to | as packet losses distributed over time in the test stream, due to | |||
| much higher rate interfaces in the backbone. | much higher rate interfaces in the backbone. | |||
| 2. Packet loss due to use of Random Early Detection (RED) or other | 2. Packet loss due to use of Random Early Detection (RED) or other | |||
| active queue management may or may not affect the measurement | active queue management may or may not affect the measurement | |||
| flow if competing background traffic (other flows) are | flow if competing background traffic (other flows) are | |||
| simultaneously present. | simultaneously present. | |||
| skipping to change at page 17, line 49 ¶ | skipping to change at page 24, line 15 ¶ | |||
| 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 | 3. Internet access policies may limit the IP-Layer Capacity | |||
| Type-P of packets, possibly reserving capacity for various stream | depending on the Type-P of packets, possibly reserving capacity | |||
| types. | 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 rate adjustment (search) algorithm. | |||
| It is obviously counter-productive to run more than one independent | ||||
| 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 | As testing continues, implementers should expect some evolution in | |||
| the methods. The ITU-T has published a Supplement (60) to the | the methods. The ITU-T has published a Supplement (60) to the | |||
| Y-series of Recommendations, "Interpreting ITU-T Y.1540 maximum IP- | Y-series of Recommendations, "Interpreting ITU-T Y.1540 Maximum IP- | |||
| layer capacity measurements", [Y.Sup60], which is the result of | Layer Capacity measurements", [Y.Sup60], which is the result of | |||
| continued testing with the metric and method described here. | continued testing with the metric, and those results have improved | |||
| the method described here. | ||||
| 8.4. Running Code | 8.4. Running Code | |||
| This section is for the benefit of the Document Shepherd's form, and | RFC Editor: This section is for the benefit of the Document | |||
| will be deleted prior to final review. | Shepherd's form, and will be deleted prior to publication. | |||
| Much of the development of the method and comparisons with existing | Much of the development of the method and comparisons with existing | |||
| methods conducted at IETF Hackathons and elsewhere have been based on | methods conducted at IETF Hackathons and elsewhere have been based on | |||
| the example udpst Linux measurement tool (which is a working | the example udpst Linux measurement tool (which is a working | |||
| reference for further development) [udpst]. 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 a utility that can function as a client or server daemon | |||
| o requires a successful client-initiated setup handshake between | o requires a successful client-initiated setup handshake between | |||
| cooperating hosts and allows firewalls to control inbound | cooperating hosts and allows firewalls to control inbound | |||
| unsolicited UDP which either go to a control port [expected and w/ | unsolicited UDP which either go to a control port [expected and w/ | |||
| authentication] or to ephemeral ports that are only created as | authentication] or to ephemeral ports that are only created as | |||
| needed. Firewalls protecting each host can both continue to do | needed. Firewalls protecting each host can both continue to do | |||
| their job normally. This aspect is similar to many other test | their job normally. This aspect is similar to many other test | |||
| utilities available. | utilities available. | |||
| o is written in C, and built with gcc (release 9.3) and its standard | o is written in C, and built with gcc (release 9.3) and its standard | |||
| run-time libraries | run-time libraries | |||
| o allows configuration of most of the parameters described in | o allows configuration of most of the parameters described in | |||
| Sections 4 and 7. | Sections 4 and 7. | |||
| o supports IPv4 and IPv6 address families. | o supports IPv4 and IPv6 address families. | |||
| o supports IP-layer packet marking. | o supports IP-Layer packet marking. | |||
| 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) | |||
| o other inner parameters of the test case (Section 4) | o other inner parameters of the test case (Section 4) | |||
| o outer parameters, such as "test conducted in motion" or other | o outer parameters, such as "test conducted in motion" or other | |||
| factors belonging to the context of the measurement | factors belonging to the context of the measurement | |||
| o result validity (indicating cases where the process was somehow | o result validity (indicating cases where the process was somehow | |||
| interrupted or the attempt failed) | interrupted or the attempt failed) | |||
| o a field where unusual circumstances could be documented, and | o a field where unusual circumstances could be documented, and | |||
| another one for "ignore/mask out" purposes in further processing | another one for "ignore/mask out" purposes in further processing | |||
| The Maximum IP-Layer Capacity results SHOULD be reported in the | The Maximum IP-Layer Capacity results SHOULD be reported in the | |||
| format of a table with a row for each of the test Phases and Number | format of a table with a row for each of the test Phases and Number | |||
| of Flows. There SHOULD be columns for the phases with number of | of Flows. There SHOULD be columns for the phases with number of | |||
| flows, and for the resultant Maximum IP-Layer Capacity results for | flows, and for the resultant Maximum IP-Layer Capacity results for | |||
| the aggregate and each flow tested. | the aggregate and each flow tested. | |||
| As mentioned in Section 6.6, bi-modal (or multi-modal) maxima SHALL | As mentioned in Section 6.6, bi-modal (or multi-modal) maxima SHALL | |||
| be reported for each mode separately. | be reported for each mode separately. | |||
| +--------------+----------------------+-----------+-----------------+ | +-------------+-------------------------+----------+----------------+ | |||
| | Phase, # | Max IP-Layer | Loss | RTT min, max, | | | Phase, # | Maximum IP-Layer | Loss | RTT min, max, | | |||
| | Flows | Capacity, Mbps | Ratio | msec | | | Flows | Capacity, Mbps | Ratio | msec | | |||
| +--------------+----------------------+-----------+-----------------+ | +-------------+-------------------------+----------+----------------+ | |||
| | Search,1 | 967.31 | 0.0002 | 30, 58 | | | Search,1 | 967.31 | 0.0002 | 30, 58 | | |||
| | Verify,1 | 966.00 | 0.0000 | 30, 38 | | +-------------+-------------------------+----------+----------------+ | |||
| +--------------+----------------------+-----------+-----------------+ | | Verify,1 | 966.00 | 0.0000 | 30, 38 | | |||
| +-------------+-------------------------+----------+----------------+ | ||||
| Maximum IP-layer Capacity Results | Maximum IP-layer Capacity Results | |||
| Static and configuration parameters: | Static and configuration parameters: | |||
| The sub-interval time, dt, MUST accompany a report of Maximum IP- | The sub-interval time, dt, MUST accompany a report of Maximum IP- | |||
| Layer Capacity results, and the remaining Parameters from Section 4, | Layer Capacity results, and the remaining Parameters from Section 4, | |||
| General Parameters. | General Parameters. | |||
| The PM list metrics corresponding to the sub-interval where the | The PM list metrics corresponding to the sub-interval where the | |||
| Maximum Capacity occurred MUST accompany a report of Maximum IP-Layer | Maximum Capacity occurred MUST accompany a report of Maximum IP-Layer | |||
| Capacity results, for each test phase. | Capacity results, for each test phase. | |||
| The IP-Layer Sender Bit rate results SHOULD be reported in the format | The IP-Layer Sender Bit rate results SHOULD be reported in the format | |||
| of a table with a row for each of the test Phases, sub-intervals (st) | of a table with a row for each of the test phases, sub-intervals (st) | |||
| and Number of Flows. There SHOULD be columns for the phases with | and number of flows. There SHOULD be columns for the phases with | |||
| number of flows, and for the resultant IP-Layer Sender Bit rate | number of flows, and for the resultant IP-Layer Sender Bit rate | |||
| results for the aggregate and each flow tested. | results for the aggregate and each flow tested. | |||
| +------------------------+-------------+-----------------------+----+ | +--------------------------+-------------+----------------------+ | |||
| | Phase, Flow or | st, sec | Sender Bit Rate, Mbps | ?? | | | Phase, Flow or Aggregate | st, sec | Sender Bitrate, Mbps | | |||
| | Aggregate | | | | | +--------------------------+-------------+----------------------+ | |||
| +------------------------+-------------+-----------------------+----+ | | Search,1 | 0.00 - 0.05 | 345 | | |||
| | Search,1 | 0.00 - 0.05 | 345 | __ | | +--------------------------+-------------+----------------------+ | |||
| | Search,2 | 0.00 - 0.05 | 289 | __ | | | Search,2 | 0.00 - 0.05 | 289 | | |||
| | Search,Agg | 0.00 - 0.05 | 634 | __ | | +--------------------------+-------------+----------------------+ | |||
| +------------------------+-------------+-----------------------+----+ | | Search,Agg | 0.00 - 0.05 | 634 | | |||
| +--------------------------+-------------+----------------------+ | ||||
| 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. | |||
| skipping to change at page 20, line 35 ¶ | skipping to change at page 27, line 16 ¶ | |||
| As a part of the multi-Standards Development Organization (SDO) | As a part of the multi-Standards Development Organization (SDO) | |||
| harmonization of this metric and method of measurement, one of the | harmonization of this metric and method of measurement, one of the | |||
| areas where the Broadband Forum (BBF) contributed its expertise was | areas where the Broadband Forum (BBF) contributed its expertise was | |||
| in the definition of an information model and data model for | in the definition of an information model and data model for | |||
| configuration and reporting. These models are consistent with the | configuration and reporting. These models are consistent with the | |||
| metric parameters and default values specified as lists is this memo. | metric parameters and default values specified as lists is this memo. | |||
| [TR-471] provides the Information model that was used to prepare a | [TR-471] provides the Information model that was used to prepare a | |||
| full data model in related BBF work. The BBF has also carefully | full data model in related BBF work. The BBF has also carefully | |||
| considered topics within its purview, such as placement of | considered topics within its purview, such as placement of | |||
| measurement systems within the access architecture. For example, | measurement systems within the Internet access architecture. For | |||
| timestamp resolution requirements that influence the choice of the | example, timestamp resolution requirements that influence the choice | |||
| test protocol are provided in Table 2 of [TR-471]. | of the test protocol are provided in Table 2 of [TR-471]. | |||
| 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. The security considerations that apply to any active | considerations. The security considerations that apply to any active | |||
| measurement of live paths are relevant here. See [RFC4656] and | measurement of live paths are relevant here. See [RFC4656] and | |||
| [RFC5357]. | [RFC5357]. | |||
| When considering privacy of those involved in measurement or those | When considering privacy of those involved in measurement or those | |||
| whose traffic is measured, the sensitive information available to | whose traffic is measured, the sensitive information available to | |||
| potential observers is greatly reduced when using active techniques | potential observers is greatly reduced when using active techniques | |||
| which are within this scope of work. Passive observations of user | which are within this scope of work. Passive observations of user | |||
| traffic for measurement purposes raise many privacy issues. We refer | traffic for measurement purposes raise many privacy issues. We refer | |||
| the reader to the privacy considerations described in the Large Scale | the reader to the privacy considerations described in the Large Scale | |||
| Measurement of Broadband Performance (LMAP) Framework [RFC7594], | Measurement of Broadband Performance (LMAP) Framework [RFC7594], | |||
| which covers active and passive techniques. | which covers active and passive techniques. | |||
| There are some new considerations for Capacity measurement as | There are some new considerations for Capacity measurement as | |||
| described in this memo. | described in this memo. | |||
| 1. Cooperating source and destination hosts and agreements to test | 1. Cooperating Source and Destination hosts and agreements to test | |||
| the path between the hosts are REQUIRED. Hosts perform in either | the path between the hosts are REQUIRED. Hosts perform in either | |||
| the Src or Dst roles. | the Src or Dst roles. | |||
| 2. A REQUIRED user client-initiated setup handshake between | 2. It is REQUIRED to have a user client-initiated setup handshake | |||
| cooperating hosts and allows firewalls to control inbound | between cooperating hosts that allows firewalls to control | |||
| unsolicited UDP which either go to a control port [expected and | inbound unsolicited UDP traffic which either goes to a control | |||
| w/authentication] or to ephemeral ports that are only created as | port [expected and w/authentication] or to ephemeral ports that | |||
| needed. Firewalls protecting each host can both continue to do | are only created as needed. Firewalls protecting each host can | |||
| their job normally. | both continue to do their job normally. | |||
| 3. Integrity protection for feedback messages conveying measurements | 3. Client-server authentication and integrity protection for | |||
| is RECOMMENDED. | feedback messages conveying measurements is RECOMMENDED. | |||
| 4. Hosts MUST limit the number of simultaneous tests to avoid | 4. Hosts MUST limit the number of simultaneous tests to avoid | |||
| resource exhaustion and inaccurate results. | resource exhaustion and inaccurate results. | |||
| 5. Senders MUST be rate-limited. This can be accomplished using the | 5. Senders MUST be rate-limited. This can be accomplished using a | |||
| pre-built table defining all the offered load rates that will be | pre-built table defining all the offered load rates that will be | |||
| supported (Section 8.1). The recommended load-control search | supported (Section 8.1). The recommended load-control search | |||
| algorithm results in "ramp up" from the lowest rate in the table. | algorithm results in "ramp-up" from the lowest rate in the table. | |||
| 6. Service subscribers with limited data volumes who conduct | 6. Service subscribers with limited data volumes who conduct | |||
| extensive capacity testing might experience the effects of | extensive capacity testing might experience the effects of | |||
| Service Provider controls on their service. Testing with the | Service Provider controls on their service. Testing with the | |||
| Service Provider's measurement hosts SHOULD be limited in | Service Provider's measurement hosts SHOULD be limited in | |||
| frequency and/or overall volume of test traffic. | frequency and/or overall volume of test traffic (for example, the | |||
| range of duration values, I, SHOULD be limited). | ||||
| The exact specification of these features is left for the future | The exact specification of these features is left for the future | |||
| protocol development. | protocol development. | |||
| 11. IANA Considerations | 11. IANA Considerations | |||
| This memo makes no requests of IANA. | This memo makes no requests of IANA. | |||
| 12. Acknowledgments | 12. Acknowledgments | |||
| Thanks to Joachim Fabini, Matt Mathis, J.Ignacio Alvarez-Hamelin, | Thanks to Joachim Fabini, Matt Mathis, J.Ignacio Alvarez-Hamelin, | |||
| Wolfgang Balzer, Frank Brockners, Greg Mirsky and Martin Duke for | Wolfgang Balzer, Frank Brockners, Greg Mirsky, Martin Duke, Murray | |||
| their extensive comments on the memo and related topics. | Kucherawy, and Benjamin Kaduk for their extensive comments on the | |||
| memo and related topics. In a second round of reviews, we | ||||
| acknowledge Magnus Westerlund, Lars Eggert, and Zahed Sarkar. | ||||
| 13. Appendix - Load Rate Adjustment Pseudo Code | 13. Appendix A - Load Rate Adjustment Pseudo Code | |||
| The following is a pseudo-code implementation of the algorithm | The following is a pseudo-code implementation of the algorithm | |||
| described in Section 8.1. | described in Section 8.1. | |||
| Rx = 1 # The current sending rate (equivalent to a row of the table) | Rx = 0 # The current sending rate (equivalent to a row of the table) | |||
| seqErr = 0 # Measured count of any of Loss or Reordering impairments | seqErr = 0 # Measured count of any of Loss or Reordering impairments | |||
| delay = 0 # Measured Range of Round Trip Time, RTT, ms | delay = 0 # Measured Range of Round Trip Delay, RTD, ms | |||
| lowThresh = 30 # Low threshold on the Range of RTT, ms | lowThresh = 30 # Low threshold on the Range of RTD, ms | |||
| upperThresh = 90 # Upper threshold on the Range of RTT, ms | upperThresh = 90 # Upper threshold on the Range of RTD, ms | |||
| hSpeedTresh = 1Gbps # Threshold for transition between sending rate step | hSpeedTresh = 1 Gbps # Threshold for transition between sending rate step | |||
| sizes (such as 1 Mbps and 100 Mbps) | sizes (such as 1 Mbps and 100 Mbps) | |||
| slowAdjCount = 0 # Measured Number of consecutive status reports | slowAdjCount = 0 # Measured Number of consecutive status reports | |||
| indicating loss and/or delay variation above upperThresh | indicating loss and/or delay variation above upperThresh | |||
| slowAdjThresh = 2 # Threshold on slowAdjCount used to infer congestion. | slowAdjThresh = 2 # Threshold on slowAdjCount used to infer congestion. | |||
| Use values >1 to avoid misinterpreting transient loss | Use values >1 to avoid misinterpreting transient loss | |||
| highSpeedDelta = 10 # The number of rows to move in a single adjustment | highSpeedDelta = 10 # The number of rows to move in a single adjustment | |||
| when initially increasing offered load (to ramp-up quickly) | when initially increasing offered load (to ramp-up quickly) | |||
| maxLoadRates = 2000 # Maximum table index (rows) | maxLoadRates = 2000 # Maximum table index (rows) | |||
| if ( seqErr == 0 && delay < lowThresh ) { | if ( seqErr == 0 && delay < lowThresh ) { | |||
| if ( Rx < hSpeedTresh && slowAdjCount < slowAdjThresh ) { | if ( Rx < hSpeedTresh && slowAdjCount < slowAdjThresh ) { | |||
| Rx += highSpeedDelta; | Rx += highSpeedDelta; | |||
| slowAdjCount = 0; | slowAdjCount = 0; | |||
| } else { | } else { | |||
| if ( Rx < maxLoadRates - 1 ) | if ( Rx < maxLoadRates - 1 ) | |||
| Rx++; | Rx++; | |||
| } | } | |||
| } else if ( seqErr > 0 || delay > upperThresh ) { | } else if ( seqErr > 0 || delay > upperThresh ) { | |||
| slowAdjCount++; | slowAdjCount++; | |||
| if ( Rx < hSpeedTresh && c->slowAdjCount == slowAdjThresh ) { | if ( Rx < hSpeedTresh && slowAdjCount == slowAdjThresh ) { | |||
| if ( Rx > highSpeedDelta * 3 ) | if ( Rx > highSpeedDelta * 3 ) | |||
| Rx -= highSpeedDelta * 3; | Rx -= highSpeedDelta * 3; | |||
| else | else | |||
| Rx = 0; | Rx = 0; | |||
| } else { | } else { | |||
| if ( Rx > 0 ) | if ( Rx > 0 ) | |||
| Rx--; | Rx--; | |||
| } | } | |||
| } | } | |||
| 14. References | 14. Appendix B - RFC 8085 UDP Guidelines Check | |||
| 14.1. Normative References | ||||
| The BCP on UDP usage guidelines [RFC8085] focuses primarily on | ||||
| congestion control in section 3.1. The Guidelines appear in | ||||
| mandatory (MUST) and recommendation (SHOULD) categories. | ||||
| 14.1. Assessment of Mandatory Requirements | ||||
| The mandatory requirements in Section 3 of [RFC8085] include: | ||||
| Internet paths can have widely varying characteristics, ... | ||||
| Consequently, applications that may be used on the Internet MUST | ||||
| NOT make assumptions about specific path characteristics. They | ||||
| MUST instead use mechanisms that let them operate safely under | ||||
| very different path conditions. Typically, this requires | ||||
| conservatively probing the current conditions of the Internet path | ||||
| they communicate over to establish a transmission behavior that it | ||||
| can sustain and that is reasonably fair to other traffic sharing | ||||
| the path. | ||||
| The purpose of the load rate adjustment algorithm in Section 8.1 is | ||||
| to probe the network and enable Maximum IP-Layer Capacity | ||||
| measurements with as few assumptions about the measured path as | ||||
| possible, and within the range application described in Section 2. | ||||
| The degree of probing conservatism is in tension with the need to | ||||
| minimize both the traffic dedicated to testing (especially with | ||||
| Gigabit rate measurements) and the duration of the test (which is one | ||||
| contributing factor to the overall algorithm fairness). | ||||
| The text of Section 3 of [RFC8085] goes on to recommend alternatives | ||||
| to UDP to meet the mandatory requirements, but none are suitable for | ||||
| the scope and purpose of the metrics and methods in this memo. In | ||||
| fact, ad hoc TCP-based methods fail to achieve the measurement | ||||
| accuracy repeatedly proven in comparison measurements with the | ||||
| running code [LS-SG12-A] [LS-SG12-B] [Y.Sup60]. Also, the UDP aspect | ||||
| of these methods is present primarily to support modern Internet | ||||
| transmission where a transport protocol is required [copycat]; the | ||||
| metric is based on the IP-Layer and UDP allows simple correlation to | ||||
| the IP-Layer. | ||||
| Section 3.1.1 of [RFC8085] discusses protocol timer guidelines: | ||||
| Latency samples MUST NOT be derived from ambiguous transactions. | ||||
| The canonical example is in a protocol that retransmits data, but | ||||
| subsequently cannot determine which copy is being acknowledged. | ||||
| Both load packets and status feedback messages MUST contain sequence | ||||
| numbers, which helps with measurements based on those packets, and | ||||
| 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 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 | ||||
| of the UDP header (8 bytes) from the PMTU size. | ||||
| The method uses a sending rate table with a maximum UDP payload size | ||||
| that anticipates significant header overhead and avoids | ||||
| fragmentation. | ||||
| Section 3.3 of [RFC8085] provides reliability guidelines: | ||||
| Applications that do require reliable message delivery MUST | ||||
| implement an appropriate mechanism themselves. | ||||
| The IP-Layer Capacity Metric and Method do not require reliable | ||||
| delivery. | ||||
| Applications that require ordered delivery MUST reestablish | ||||
| datagram ordering themselves. | ||||
| The IP-Layer Capacity Metric and Method does not need to reestablish | ||||
| packet order; it is preferred to measure packet reordering if it | ||||
| occurs [RFC4737]. | ||||
| 14.2. Assessment of Recommendations | ||||
| The load rate adjustment algorithm's goal is to determine the Maximum | ||||
| IP-Layer Capacity in the context of an infrequent, diagnostic, short | ||||
| term measurement. This goal is a global exception to many [RFC8085] | ||||
| SHOULD-level requirements, of which many are intended for long-lived | ||||
| flows that must coexist with other traffic in more-or-less fair way. | ||||
| However, the algorithm (as specified in Section 8.1 and Appendix A | ||||
| above) reacts to indications of congestion in clearly defined ways. | ||||
| 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 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. | ||||
| This is a requirement for coexistent streams, and not for diagnostic | ||||
| and infrequent measurements using short durations. The rate | ||||
| oscillations during short tests allow other packets to pass, and | ||||
| don't starve other flows. | ||||
| Ironically, ad hoc TCP-based measurements of "Internet Speed" are | ||||
| also designed to work around this SHOULD-level requirement, by | ||||
| 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 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 | | | ||||
| | | | | ||||
| | for bulk transfers, | 3.1.2 | | ||||
| NA | SHOULD consider implementing TFRC | | | ||||
| NA | else, SHOULD in other ways use bandwidth similar to TCP | | | ||||
| | | | | ||||
| | for non-bulk transfers, | 3.1.3 | | ||||
| NA | SHOULD measure RTT and transmit max. 1 datagram/RTT | 3.1.1 | | ||||
| NA | else, SHOULD send at most 1 datagram every 3 seconds | | | ||||
| NA | SHOULD back-off retransmission timers following loss | | | ||||
| | | | | ||||
| Yes| SHOULD provide mechanisms to regulate the bursts of | 3.1.6 | | ||||
| | transmission | | | ||||
| | | | | ||||
| NA | MAY implement ECN; a specific set of application | 3.1.7 | | ||||
| | mechanisms are REQUIRED if ECN is used. | | | ||||
| | | | | ||||
| Yes| for DiffServ, SHOULD NOT rely on implementation of PHBs | 3.1.8 | | ||||
| | | | | ||||
| Yes| for QoS-enabled paths, MAY choose not to use CC | 3.1.9 | | ||||
| | | | | ||||
| Yes| SHOULD NOT rely solely on QoS for their capacity | 3.1.10 | | ||||
| | non-CC controlled flows SHOULD implement a transport | | | ||||
| | circuit breaker | | | ||||
| | MAY implement a circuit breaker for other applications | | | ||||
| | | | | ||||
| | for tunnels carrying IP traffic, | 3.1.11 | | ||||
| NA | SHOULD NOT perform congestion control | | | ||||
| NA | MUST correctly process the IP ECN field | | | ||||
| | | | | ||||
| | for non-IP tunnels or rate not determined by traffic, | | | ||||
| NA | SHOULD perform CC or use circuit breaker | 3.1.11 | | ||||
| NA | SHOULD restrict types of traffic transported by the | | | ||||
| | tunnel | | | ||||
| | | | | ||||
| Yes| SHOULD NOT send datagrams that exceed the PMTU, i.e., | 3.2 | | ||||
| Yes| SHOULD discover PMTU or send datagrams < minimum PMTU; | | | ||||
| NA | Specific application mechanisms are REQUIRED if PLPMTUD | | | ||||
| | is used. | | | ||||
| | | | | ||||
| Yes| SHOULD handle datagram loss, duplication, reordering | 3.3 | | ||||
| NA | SHOULD be robust to delivery delays up to 2 minutes | | | ||||
| | | | | ||||
| Yes| SHOULD enable IPv4 UDP checksum | 3.4 | | ||||
| Yes| SHOULD enable IPv6 UDP checksum; Specific application | 3.4.1 | | ||||
| | mechanisms are REQUIRED if a zero IPv6 UDP checksum is | | | ||||
| | used. | | | ||||
| | | | | ||||
| NA | SHOULD provide protection from off-path attacks | 5.1 | | ||||
| | else, MAY use UDP-Lite with suitable checksum coverage | 3.4.2 | | ||||
| | | | | ||||
| NA | SHOULD NOT always send middlebox keep-alive messages | 3.5 | | ||||
| NA | MAY use keep-alives when needed (min. interval 15 sec) | | | ||||
| | | | | ||||
| Yes| Applications specified for use in limited use (or | 3.6 | | ||||
| | controlled environments) SHOULD identify equivalent | | | ||||
| | mechanisms and describe their use case. | | | ||||
| | | | | ||||
| NA | Bulk-multicast apps SHOULD implement congestion control | 4.1.1 | | ||||
| | | | | ||||
| NA | Low volume multicast apps SHOULD implement congestion | 4.1.2 | | ||||
| | control | | | ||||
| | | | | ||||
| NA | Multicast apps SHOULD use a safe PMTU | 4.2 | | ||||
| | | | | ||||
| Yes| SHOULD avoid using multiple ports | 5.1.2 | | ||||
| Yes| MUST check received IP source address | | | ||||
| | | | | ||||
| NA | SHOULD validate payload in ICMP messages | 5.2 | | ||||
| | | | | ||||
| Yes| SHOULD use a randomized source port or equivalent | 6 | | ||||
| | technique, and, for client/server applications, SHOULD | | | ||||
| | send responses from source address matching request | | | ||||
| | 5.1 | | | ||||
| NA | SHOULD use standard IETF security protocols when needed | 6 | | ||||
| +---------------------------------------------------------+---------+ | ||||
| 15. References | ||||
| 15.1. Normative References | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, | [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, | |||
| "Framework for IP Performance Metrics", RFC 2330, | "Framework for IP Performance Metrics", RFC 2330, | |||
| DOI 10.17487/RFC2330, May 1998, | DOI 10.17487/RFC2330, May 1998, | |||
| <https://www.rfc-editor.org/info/rfc2330>. | <https://www.rfc-editor.org/info/rfc2330>. | |||
| [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for | ||||
| Network Interconnect Devices", RFC 2544, | ||||
| DOI 10.17487/RFC2544, March 1999, | ||||
| <https://www.rfc-editor.org/info/rfc2544>. | ||||
| [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip | [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip | |||
| Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, | Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, | |||
| September 1999, <https://www.rfc-editor.org/info/rfc2681>. | September 1999, <https://www.rfc-editor.org/info/rfc2681>. | |||
| [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining | ||||
| Empirical Bulk Transfer Capacity Metrics", RFC 3148, | ||||
| DOI 10.17487/RFC3148, July 2001, | ||||
| <https://www.rfc-editor.org/info/rfc3148>. | ||||
| [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. | [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. | |||
| Zekauskas, "A One-way Active Measurement Protocol | Zekauskas, "A One-way Active Measurement Protocol | |||
| (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, | (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, | |||
| <https://www.rfc-editor.org/info/rfc4656>. | <https://www.rfc-editor.org/info/rfc4656>. | |||
| [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", | [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, | |||
| RFC 5136, DOI 10.17487/RFC5136, February 2008, | S., and J. Perser, "Packet Reordering Metrics", RFC 4737, | |||
| <https://www.rfc-editor.org/info/rfc5136>. | DOI 10.17487/RFC4737, November 2006, | |||
| <https://www.rfc-editor.org/info/rfc4737>. | ||||
| [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. | [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. | |||
| Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", | Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", | |||
| RFC 5357, DOI 10.17487/RFC5357, October 2008, | RFC 5357, DOI 10.17487/RFC5357, October 2008, | |||
| <https://www.rfc-editor.org/info/rfc5357>. | <https://www.rfc-editor.org/info/rfc5357>. | |||
| [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label | [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label | |||
| for Equal Cost Multipath Routing and Link Aggregation in | for Equal Cost Multipath Routing and Link Aggregation in | |||
| Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, | Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, | |||
| <https://www.rfc-editor.org/info/rfc6438>. | <https://www.rfc-editor.org/info/rfc6438>. | |||
| [RFC6815] Bradner, S., Dubray, K., McQuaid, J., and A. Morton, | [RFC7497] Morton, A., "Rate Measurement Test Protocol Problem | |||
| "Applicability Statement for RFC 2544: Use on Production | Statement and Requirements", RFC 7497, | |||
| Networks Considered Harmful", RFC 6815, | DOI 10.17487/RFC7497, April 2015, | |||
| DOI 10.17487/RFC6815, November 2012, | <https://www.rfc-editor.org/info/rfc7497>. | |||
| <https://www.rfc-editor.org/info/rfc6815>. | ||||
| [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling | ||||
| Framework for IP Performance Metrics (IPPM)", RFC 7312, | ||||
| DOI 10.17487/RFC7312, August 2014, | ||||
| <https://www.rfc-editor.org/info/rfc7312>. | ||||
| [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, | ||||
| <https://www.rfc-editor.org/info/rfc7594>. | ||||
| [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, | [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, | |||
| Ed., "A One-Way Loss Metric for IP Performance Metrics | Ed., "A One-Way Loss Metric for IP Performance Metrics | |||
| (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January | (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January | |||
| 2016, <https://www.rfc-editor.org/info/rfc7680>. | 2016, <https://www.rfc-editor.org/info/rfc7680>. | |||
| [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with | ||||
| Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, | ||||
| May 2016, <https://www.rfc-editor.org/info/rfc7799>. | ||||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| [RFC8337] Mathis, M. and A. Morton, "Model-Based Metrics for Bulk | ||||
| Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March | ||||
| 2018, <https://www.rfc-editor.org/info/rfc8337>. | ||||
| [RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. | [RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. | |||
| Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for | Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for | |||
| the IP Performance Metrics (IPPM) Framework", RFC 8468, | the IP Performance Metrics (IPPM) Framework", RFC 8468, | |||
| DOI 10.17487/RFC8468, November 2018, | DOI 10.17487/RFC8468, November 2018, | |||
| <https://www.rfc-editor.org/info/rfc8468>. | <https://www.rfc-editor.org/info/rfc8468>. | |||
| 14.2. Informative References | 15.2. Informative References | |||
| [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>. | |||
| [LS-SG12-A] | [LS-SG12-A] | |||
| 12, I. S., "LS - Harmonization of IP Capacity and Latency | 12, I. S., "LS - Harmonization of IP Capacity and Latency | |||
| Parameters: Revision of Draft Rec. Y.1540 on IP packet | Parameters: Revision of Draft Rec. Y.1540 on IP packet | |||
| transfer performance parameters and New Annex A with Lab | transfer performance parameters and New Annex A with Lab | |||
| Evaluation Plan", May 2019, | Evaluation Plan", May 2019, | |||
| <https://datatracker.ietf.org/liaison/1632/>. | <https://datatracker.ietf.org/liaison/1632/>. | |||
| [LS-SG12-B] | [LS-SG12-B] | |||
| 12, I. S., "LS on harmonization of IP Capacity and Latency | 12, I. S., "LS on harmonization of IP Capacity and Latency | |||
| Parameters: Consent of Draft Rec. Y.1540 on IP packet | Parameters: Consent of Draft Rec. Y.1540 on IP packet | |||
| transfer performance parameters and New Annex A with Lab & | transfer performance parameters and New Annex A with Lab & | |||
| Field Evaluation Plans", March 2019, | Field Evaluation Plans", March 2019, | |||
| <https://datatracker.ietf.org/liaison/1645/>. | <https://datatracker.ietf.org/liaison/1645/>. | |||
| [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for | ||||
| Network Interconnect Devices", RFC 2544, | ||||
| DOI 10.17487/RFC2544, March 1999, | ||||
| <https://www.rfc-editor.org/info/rfc2544>. | ||||
| [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining | ||||
| Empirical Bulk Transfer Capacity Metrics", RFC 3148, | ||||
| DOI 10.17487/RFC3148, July 2001, | ||||
| <https://www.rfc-editor.org/info/rfc3148>. | ||||
| [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", | ||||
| RFC 5136, DOI 10.17487/RFC5136, February 2008, | ||||
| <https://www.rfc-editor.org/info/rfc5136>. | ||||
| [RFC6815] Bradner, S., Dubray, K., McQuaid, J., and A. Morton, | ||||
| "Applicability Statement for RFC 2544: Use on Production | ||||
| Networks Considered Harmful", RFC 6815, | ||||
| DOI 10.17487/RFC6815, November 2012, | ||||
| <https://www.rfc-editor.org/info/rfc6815>. | ||||
| [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling | ||||
| Framework for IP Performance Metrics (IPPM)", RFC 7312, | ||||
| DOI 10.17487/RFC7312, August 2014, | ||||
| <https://www.rfc-editor.org/info/rfc7312>. | ||||
| [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, | ||||
| <https://www.rfc-editor.org/info/rfc7594>. | ||||
| [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with | ||||
| Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, | ||||
| May 2016, <https://www.rfc-editor.org/info/rfc7799>. | ||||
| [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage | ||||
| Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, | ||||
| March 2017, <https://www.rfc-editor.org/info/rfc8085>. | ||||
| [RFC8337] Mathis, M. and A. Morton, "Model-Based Metrics for Bulk | ||||
| Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March | ||||
| 2018, <https://www.rfc-editor.org/info/rfc8337>. | ||||
| [TR-471] Morton, A., "Broadband Forum TR-471: IP Layer Capacity | [TR-471] Morton, A., "Broadband Forum TR-471: IP Layer Capacity | |||
| Metrics and Measurement", July 2020, | Metrics and Measurement", July 2020, | |||
| <https://www.broadband-forum.org/technical/download/TR- | <https://www.broadband-forum.org/technical/download/TR- | |||
| 471.pdf>. | 471.pdf>. | |||
| [udpst] AT&T, "UDP Speed Test Open Broadband project", August | [udpst] udpst Project Collaborators, "UDP Speed Test Open | |||
| 2020, <https://github.com/BroadbandForum <TBD>>. | Broadband project", December 2020, | |||
| <https://github.com/BroadbandForum/obudpst>. | ||||
| [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", December 2019, | parameters", December 2019, | |||
| <https://www.itu.int/rec/T-REC-Y.1540-201912-I/en>. | <https://www.itu.int/rec/T-REC-Y.1540-201912-I/en>. | |||
| [Y.Sup60] Morton, A., "Recommendation Y.Sup60, (04/20) Interpreting | [Y.Sup60] Morton, A., "Recommendation Y.Sup60, (09/20) Interpreting | |||
| ITU-T Y.1540 maximum IP-layer capacity measurements", June | ITU-T Y.1540 maximum IP-layer capacity measurements, and | |||
| 2020, <https://www.itu.int/rec/T-REC-Y.Sup60/en>. | Errata", September 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 | |||
| Email: acm@research.att.com | Email: acm@research.att.com | |||
| Ruediger Geib | Ruediger Geib | |||
| Deutsche Telekom | Deutsche Telekom | |||
| Heinrich Hertz Str. 3-7 | Heinrich Hertz Str. 3-7 | |||
| Darmstadt 64295 | Darmstadt 64295 | |||
| Germany | Germany | |||
| Phone: +49 6151 5812747 | Phone: +49 6151 5812747 | |||
| Email: Ruediger.Geib@telekom.de | Email: Ruediger.Geib@telekom.de | |||
| Len Ciavattone | Len Ciavattone | |||
| AT&T Labs | AT&T Labs | |||
| 200 Laurel Avenue South | 200 Laurel Avenue South | |||
| Middletown,, NJ 07748 | Middletown, NJ 07748 | |||
| USA | USA | |||
| Email: lencia@att.com | Email: lencia@att.com | |||
| End of changes. 127 change blocks. | ||||
| 337 lines changed or deleted | 888 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||