idnits 2.17.1 draft-ietf-ippm-capacity-metric-method-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 8, 2021) is 1117 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'T' is mentioned on line 505, but not defined == Missing Reference: 'I' is mentioned on line 505, but not defined == Missing Reference: 'PM' is mentioned on line 504, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Downref: Normative reference to an Informational RFC: RFC 7479 ** Downref: Normative reference to an Informational RFC: RFC 8468 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft AT&T Labs 4 Intended status: Standards Track R. Geib 5 Expires: September 9, 2021 Deutsche Telekom 6 L. Ciavattone 7 AT&T Labs 8 March 8, 2021 10 Metrics and Methods for One-way IP Capacity 11 draft-ietf-ippm-capacity-metric-method-07 13 Abstract 15 This memo revisits the problem of Network Capacity metrics first 16 examined in RFC 5136. The memo specifies a more practical Maximum 17 IP-layer Capacity metric definition catering for measurement 18 purposes, and outlines the corresponding methods of measurement. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 9, 2021. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Scope, Goals, and Applicability . . . . . . . . . . . . . . . 4 57 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. General Parameters and Definitions . . . . . . . . . . . . . 5 59 5. IP-Layer Capacity Singleton Metric Definitions . . . . . . . 6 60 5.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 7 61 5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 7 62 5.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 7 63 5.4. Related Round-Trip Delay and One-way Loss Definitions . . 8 64 5.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 9 65 5.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 9 66 6. Maximum IP-Layer Capacity Metric Definitions (Statistic) . . 9 67 6.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 10 70 6.4. Related Round-Trip Delay and One-way Loss Definitions . . 11 71 6.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 11 72 6.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 12 73 7. IP-Layer Sender Bit Rate Singleton Metric Definitions . . . . 12 74 7.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 13 75 7.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 13 76 7.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 13 77 7.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 14 78 7.5. Reporting the Metric . . . . . . . . . . . . . . . . . . 14 79 8. Method of Measurement . . . . . . . . . . . . . . . . . . . . 14 80 8.1. Load Rate Adjustment Algorithm . . . . . . . . . . . . . 14 81 8.2. Measurement Qualification or Verification . . . . . . . . 18 82 8.3. Measurement Considerations . . . . . . . . . . . . . . . 19 83 8.4. Running Code . . . . . . . . . . . . . . . . . . . . . . 21 84 9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 21 85 9.1. Configuration and Reporting Data Formats . . . . . . . . 23 86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 87 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 88 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 89 13. Appendix - Load Rate Adjustment Pseudo Code . . . . . . . . . 25 90 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 14.1. Normative References . . . . . . . . . . . . . . . . . . 26 92 14.2. Informative References . . . . . . . . . . . . . . . . . 27 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 95 1. Introduction 97 The IETF's efforts to define Network and Bulk Transport Capacity have 98 been chartered and progressed for over twenty years. Over that time, 99 the performance community has seen development of Informative 100 definitions in [RFC3148] for Framework for Bulk Transport Capacity 101 (BTC), RFC 5136 for Network Capacity and Maximum IP-layer Capacity, 102 and the Experimental metric definitions and methods in [RFC8337], 103 Model-Based Metrics for BTC. 105 This memo revisits the problem of Network Capacity metrics examined 106 first in [RFC3148] and later in [RFC5136]. Maximum IP-Layer Capacity 107 and [RFC3148] Bulk Transfer Capacity (goodput) are different metrics. 108 Maximum IP-layer Capacity is like the theoretical goal for goodput. 109 There are many metrics in [RFC5136], such as Available Capacity. 110 Measurements depend on the network path under test and the use case. 111 Here, the main use case is to assess the maximum capacity of the 112 access network, with specific performance criteria used in the 113 measurement. 115 This memo recognizes the importance of a definition of a Maximum IP- 116 layer Capacity Metric at a time when access speeds have increased 117 dramatically; a definition that is both practical and effective for 118 the performance community's needs, including Internet users. The 119 metric definition is intended to use Active Methods of Measurement 120 [RFC7799], and a method of measurement is included. 122 The most direct active measurement of IP-layer Capacity would use IP 123 packets, but in practice a transport header is needed to traverse 124 address and port translators. UDP offers the most direct assessment 125 possibility, and in the [copycat] measurement study to investigate 126 whether UDP is viable as a general Internet transport protocol, the 127 authors found that a high percentage of paths tested support UDP 128 transport. A number of liaisons have been exchanged on this topic 129 [LS-SG12-A] [LS-SG12-B], discussing the laboratory and field tests 130 that support the UDP-based approach to IP-layer Capacity measurement. 132 This memo also recognizes the many updates to the IP Performance 133 Metrics Framework [RFC2330] published over twenty years, and makes 134 use of [RFC7312] for Advanced Stream and Sampling Framework, and 135 [RFC8468] with IPv4, IPv6, and IPv4-IPv6 Coexistence Updates. 137 1.1. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14[RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 2. Scope, Goals, and Applicability 147 The scope of this memo is to define a metric and corresponding method 148 to unambiguously perform Active measurements of Maximum IP-Layer 149 Capacity, along with related metrics and methods. 151 The main goal is to harmonize the specified metric and method across 152 the industry, and this memo is the vehicle that captures IETF 153 consensus, possibly resulting in changes to the specifications of 154 other Standards Development Organizations (SDO) (through each SDO's 155 normal contribution process, or through liaison exchange). 157 A local goal is to aid efficient test procedures where possible, and 158 to recommend reporting with additional interpretation of the results. 159 Fostering the development of protocol support for this metric and 160 method of measurement is also a goal of this memo (all active testing 161 protocols currently defined by the IPPM WG are UDP-based, meeting a 162 key requirement of these methods). The supporting protocol 163 development to measure this metric according to the specified method 164 is a key future contribution to Internet measurement. 166 The primary application of the metric and method of measurement 167 described here is the same as in Section 2 of [RFC7479] where: 169 o The access portion of the network is the focus of this problem 170 statement. The user typically subscribes to a service with 171 bidirectional access partly described by rates in bits per second. 173 In addition, the use of the load adjustment algorithm described in 174 section 8.1 has the following additional applicability limitations: 176 - MUST only be used in the application of diagnostic and operations 177 measurements as described in this memo 179 - MUST only be used in circumstances consistent with Section 10, 180 Security Considerations 182 3. Motivation 184 As with any problem that has been worked for many years in various 185 SDOs without any special attempts at coordination, various solutions 186 for metrics and methods have emerged. 188 There are five factors that have changed (or begun to change) in the 189 2013-2019 time frame, and the presence of any one of them on the path 190 requires features in the measurement design to account for the 191 changes: 193 1. Internet access is no longer the bottleneck for many users. 195 2. Both transfer rate and latency are important to user's 196 satisfaction. 198 3. UDP's growing role in Transport, in areas where TCP once 199 dominated. 201 4. Content and applications are moving physically closer to users. 203 5. There is less emphasis on ISP gateway measurements, possibly due 204 to less traffic crossing ISP gateways in future. 206 4. General Parameters and Definitions 208 This section lists the REQUIRED input factors to specify a Sender or 209 Receiver metric. 211 o Src, the address of a host (such as the globally routable IP 212 address). 214 o Dst, the address of a host (such as the globally routable IP 215 address). 217 o MaxHops, the limit on the number of Hops a specific packet may 218 visit as it traverses from the host at Src to the host at Dst 219 (implemented in the TTL or Hop Limit). 221 o T0, the time at the start of measurement interval, when packets 222 are first transmitted from the Source. 224 o I, the nominal duration of a measurement interval at the 225 destination (default 10 sec) 227 o dt, the nominal duration of m equal sub-intervals in I at the 228 destination (default 1 sec) 230 o dtn, the beginning boundary of a specific sub-interval, n, one of 231 m sub-intervals in I 233 o FT, the feedback time interval between status feedback messages 234 communicating measurement results, sent from the receiver to 235 control the sender. The results are evaluated to determine how to 236 adjust the current offered load rate at the sender (default 50ms) 238 o Tmax, a maximum waiting time for test packets to arrive at the 239 destination, set sufficiently long to disambiguate packets with 240 long delays from packets that are discarded (lost), such that the 241 distribution of one-way delay is not truncated. 243 o F, the number of different flows synthesized by the method 244 (default 1 flow) 246 o flow, the stream of packets with the same n-tuple of designated 247 header fields that (when held constant) result in identical 248 treatment in a multi-path decision (such as the decision taken in 249 load balancing). Note: The IPv6 flow label MAY be included in the 250 flow definition when routers have complied with [RFC6438] 251 guidelines. 253 o Type-P, the complete description of the test packets for which 254 this assessment applies (including the flow-defining fields). 255 Note that the UDP transport layer is one requirement for test 256 packets specified below. Type-P is a parallel concept to 257 "population of interest" defined in clause 6.1.1 of[Y.1540]. 259 o PM, a list of fundamental metrics, such as loss, delay, and 260 reordering, and corresponding target performance threshold. At 261 least one fundamental metric and target performance threshold MUST 262 be supplied (such as One-way IP Packet Loss [RFC7680] equal to 263 zero). 265 A non-Parameter which is required for several metrics is defined 266 below: 268 o T, the host time of the *first* test packet's *arrival* as 269 measured at the destination Measurement Point, or MP(Dst). There 270 may be other packets sent between source and destination hosts 271 that are excluded, so this is the time of arrival of the first 272 packet used for measurement of the metric. 274 Note that time stamp format and resolution, sequence numbers, etc. 275 will be established by the chosen test protocol standard or 276 implementation. 278 5. IP-Layer Capacity Singleton Metric Definitions 280 This section sets requirements for the singleton metric that supports 281 the Maximum IP-layer Capacity Metric definition in Section 6. 283 5.1. Formal Name 285 Type-P-One-way-IP-Capacity, or informally called IP-layer Capacity. 287 Note that Type-P depends on the chosen method. 289 5.2. Parameters 291 This section lists the REQUIRED input factors to specify the metric, 292 beyond those listed in Section 4. 294 No additional Parameters are needed. 296 5.3. Metric Definitions 298 This section defines the REQUIRED aspects of the measurable IP-layer 299 Capacity metric (unless otherwise indicated) for measurements between 300 specified Source and Destination hosts: 302 Define the IP-layer capacity, C(T,dt,PM), to be the number of IP- 303 layer bits (including header and data fields) in packets that can be 304 transmitted from the Src host and correctly received by the Dst host 305 during one contiguous sub-interval, dt in length. The IP-layer 306 capacity depends on the Src and Dst hosts, the host addresses, and 307 the path between the hosts. 309 The number of these IP-layer bits is designated n0[dtn,dtn+1] for a 310 specific dt. 312 When the packet size is known and of fixed size, the packet count 313 during a single sub-interval dt multiplied by the total bits in IP 314 header and data fields is equal to n0[dtn,dtn+1]. 316 Anticipating a Sample of Singletons, the number of sub-intervals with 317 duration dt MUST be set to a natural number m, so that T+I = T + m*dt 318 with dtn+1 - dtn = dt for 1 <= n <= m. 320 Parameter PM represents other performance metrics [see section 5.4 321 below]; their measurement results SHALL be collected during 322 measurement of IP-layer Capacity and associated with the 323 corresponding dtn for further evaluation and reporting. Users SHALL 324 specify the parameter Tmax as required by each metric's reference 325 definition. 327 Mathematically, this definition is represented as (for each n): 329 ( n0[dtn,dtn+1] ) 330 C(T,dt,PM) = ------------------------- 331 dt 333 Equation for IP-Layer Capacity 335 and: 337 o n0 is the total number of IP-layer header and payload bits that 338 can be transmitted in standard-formed packets [RFC8468] from the 339 Src host and correctly received by the Dst host during one 340 contiguous sub-interval, dt in length, during the interval [T, 341 T+I], 343 o C(T,dt,PM) the IP-Layer Capacity, corresponds to the value of n0 344 measured in any sub-interval beginning at dtn, divided by the 345 length of sub-interval, dt. 347 o PM represents other performance metrics [see section 5.4 below]; 348 their measurement results SHALL be collected during measurement of 349 IP-layer Capacity and associated with the corresponding dtn for 350 further evaluation and reporting. 352 o all sub-intervals MUST be of equal duration. Choosing dt as non- 353 overlapping consecutive time intervals allows for a simple 354 implementation. 356 o The bit rate of the physical interface of the measurement devices 357 must be higher than the smallest of the links on the path whose 358 C(T,I,PM) is to be measured (the bottleneck link). 360 Measurements according to these definitions SHALL use the UDP 361 transport layer. Standard-formed packets are specified in Section 5 362 of [RFC8468]. Some compression affects on measurement are discussed 363 in Section 6 of [RFC8468], as well. 365 5.4. Related Round-Trip Delay and One-way Loss Definitions 367 RTD[dtn,dtn+1] is defined as a sample of the [RFC2681] Round-trip 368 Delay between the Src host and the Dst host over the interval [T,T+I] 369 (that contains equal non-overlapping intervals of dt). The 370 "reasonable period of time" in [RFC2681] is the parameter Tmax in 371 this memo. The statistics used to summarize RTD[dtn,dtn+1] MAY 372 include the minimum, maximum, median, and mean, and the range = 373 (maximum - minimum) is referred to below in Section 8.1 for load 374 adjustment purposes. 376 OWL[dtn,dtn+1] is defined as a sample of the [RFC7680] One-way Loss 377 between the Src host and the Dst host over the interval [T,T+I] (that 378 contains equal non-overlapping intervals of dt). The statistics used 379 to summarize OWL[dtn,dtn+1] MAY include the lost packet count and the 380 lost packet ratio. 382 Other metrics MAY be measured: one-way reordering, duplication, and 383 delay variation. 385 5.5. Discussion 387 See the corresponding section for Maximum IP-Layer Capacity. 389 5.6. Reporting the Metric 391 The IP-Layer Capacity SHOULD be reported with at least single Megabit 392 resolution, in units of Megabits per second (Mbps), (which is 393 1,000,000 bits per second to avoid any confusion). 395 The Related Round Trip Delay and/or Loss metric measurements for the 396 same Singleton SHALL be reported, also with meaningful resolution for 397 the values measured. 399 Individual Capacity measurements MAY be reported in a manner 400 consistent with the Maximum IP-Layer Capacity, see Section 9. 402 6. Maximum IP-Layer Capacity Metric Definitions (Statistic) 404 This section sets requirements for the following components to 405 support the Maximum IP-layer Capacity Metric. 407 6.1. Formal Name 409 Type-P-One-way-Max-IP-Capacity, or informally called Maximum IP-layer 410 Capacity. 412 Note that Type-P depends on the chosen method. 414 6.2. Parameters 416 This section lists the REQUIRED input factors to specify the metric, 417 beyond those listed in Section 4. 419 No additional Parameters or definitions are needed. 421 6.3. Metric Definitions 423 This section defines the REQUIRED aspects of the Maximum IP-layer 424 Capacity metric (unless otherwise indicated) for measurements between 425 specified Source and Destination hosts: 427 Define the Maximum IP-layer capacity, Maximum_C(T,I,PM), to be the 428 maximum number of IP-layer bits n0[dtn,dtn+1] divided by dt that can 429 be transmitted in packets from the Src host and correctly received by 430 the Dst host, over all dt length intervals in [T, T+I], and meeting 431 the PM criteria. Equivalently the Maximum of a Sample of size m of 432 C(T,I,PM) collected during the interval [T, T+I] and meeting the PM 433 criteria. 435 The number of sub-intervals with duration dt MUST be set to a natural 436 number m, so that T+I = T + m*dt with dtn+1 - dtn = dt for 1 <= n <= 437 m. 439 Parameter PM represents the other performance metrics (see 440 Section 6.4 below) and their measurement results for the maximum IP- 441 layer capacity. At least one target performance threshold (PM 442 criterion) MUST be defined. If more than one metric and target 443 performance threshold are defined, then the sub-interval with maximum 444 number of bits transmitted MUST meet all the target performance 445 thresholds. Users SHALL specify the parameter Tmax as required by 446 each metric's reference definition. 448 Mathematically, this definition can be represented as: 450 max ( n0[dtn,dtn+1] ) 451 [T,T+I] 452 Maximum_C(T,I,PM) = ------------------------- 453 dt 454 where: 455 T T+I 456 _________________________________________ 457 | | | | | | | | | | | 458 dtn=1 2 3 4 5 6 7 8 9 10 n+1 459 n=m 461 Equation for Maximum Capacity 463 and: 465 o n0 is the total number of IP-layer header and payload bits that 466 can be transmitted in standard-formed packets from the Src host 467 and correctly received by the Dst host during one contiguous sub- 468 interval, dt in length, during the interval [T, T+I], 470 o Maximum_C(T,I,PM) the Maximum IP-Layer Capacity, corresponds to 471 the maximum value of n0 measured in any sub-interval beginning at 472 dtn, divided by the constant length of all sub-intervals, dt. 474 o PM represents the other performance metrics (see Section 5.4) and 475 their measurement results for the maximum IP-layer capacity. At 476 least one target performance threshold (PM criterion) MUST be 477 defined. 479 o all sub-intervals MUST be of equal duration. Choosing dt as non- 480 overlapping consecutive time intervals allows for a simple 481 implementation. 483 o The bit rate of the physical interface of the measurement systems 484 must be higher than than the smallest of the links on the path 485 whose Maximum_C(T,I,PM) is to be measured (the bottleneck link). 487 In this definition, the m sub-intervals can be viewed as trials when 488 the Src host varies the transmitted packet rate, searching for the 489 maximum n0 that meets the PM criteria measured at the Dst host in a 490 test of duration, I. When the transmitted packet rate is held 491 constant at the Src host, the m sub-intervals may also be viewed as 492 trials to evaluate the stability of n0 and metric(s) in the PM list 493 over all dt-length intervals in I. 495 Measurements according to these definitions SHALL use the UDP 496 transport layer. 498 6.4. Related Round-Trip Delay and One-way Loss Definitions 500 RTD[dtn,dtn+1] and OWL[dtn,dtn+1] are defined in Section 5.4. Here, 501 the test intervals are increased to match the capacity samples, 502 RTD[T,I] and OWL[T,I]. 504 The interval dtn,dtn+1 where Maximum_C[T,I,PM] occurs is the 505 reporting sub-interval within RTD[T,I] and OWL[T,I]. 507 Other metrics MAY be measured: one-way reordering, duplication, and 508 delay variation. 510 6.5. Discussion 512 If traffic conditioning (e.g., shaping, policing) applies along a 513 path for which Maximum_C(T,I,PM) is to be determined, different 514 values for dt SHOULD be picked and measurements be executed during 515 multiple intervals [T, T+I]. Each duration dt SHOULD be chosen so 516 that it is an integer multiple of increasing values k times 517 serialization delay of a path MTU at the physical interface speed 518 where traffic conditioning is expected. This should avoid taking 519 configured burst tolerance singletons as a valid Maximum_C(T,I,PM) 520 result. 522 A Maximum_C(T,I,PM) without any indication of bottleneck congestion, 523 be that an increasing latency, packet loss or ECN marks during a 524 measurement interval I, is likely to underestimate Maximum_C(T,I,PM). 526 6.6. Reporting the Metric 528 The IP-Layer Capacity SHOULD be reported with at least single Megabit 529 resolution, in units of Megabits per second (Mbps) (which is 530 1,000,000 bits per second to avoid any confusion). 532 The Related Round Trip Delay and/or Loss metric measurements for the 533 same Singleton SHALL be reported, also with meaningful resolution for 534 the values measured. 536 When there are demonstrated and repeatable Capacity modes in the 537 Sample, then the Maximum IP-Layer Capacity SHALL be reported for each 538 mode, along with the relative time from the beginning of the stream 539 that the mode was observed to be present. Bimodal Maxima have been 540 observed with some services, sometimes called a "turbo mode" 541 intending to deliver short transfers more quickly, or reduce the 542 initial buffering time for some video streams. Note that modes 543 lasting less than dt duration will not be detected. 545 Some transmission technologies have multiple methods of operation 546 that may be activated when channel conditions degrade or improve, and 547 these transmission methods may determine the Maximum IP-Layer 548 Capacity. Examples include line-of-sight microwave modulator 549 constellations, or cellular modem technologies where the changes may 550 be initiated by a user moving from one coverage area to another. 551 Operation in the different transmission methods may be observed over 552 time, but the modes of Maximum IP-Layer Capacity will not be 553 activated deterministically as with the "turbo mode" described in the 554 paragraph above. 556 7. IP-Layer Sender Bit Rate Singleton Metric Definitions 558 This section sets requirements for the following components to 559 support the IP-layer Sender Bitrate Metric. This metric helps to 560 check that the sender actually generated the desired rates during a 561 test, and measurement takes place at the Src host to network path 562 interface (or as close as practical within the Src host). It is not 563 a metric for path performance. 565 7.1. Formal Name 567 Type-P-IP-Sender-Bit-Rate, or informally called IP-layer Sender 568 Bitrate. 570 Note that Type-P depends on the chosen method. 572 7.2. Parameters 574 This section lists the REQUIRED input factors to specify the metric, 575 beyond those listed in Section 4. 577 o S, the duration of the measurement interval at the Source 579 o st, the nominal duration of N sub-intervals in S (default st = 580 0.05 seconds) 582 o stn, the beginning boundary of a specific sub-interval, n, one of 583 N sub-intervals in S 585 S SHALL be longer than I, primarily to account for on-demand 586 activation of the path, or any preamble to testing required, and the 587 delay of the path. 589 st SHOULD be much smaller than the sub-interval dtand on the same 590 order as FT, otherwise the rate measurement will include many rate 591 adjustments and include more time smoothing, thus missing the maximum 592 rate. The st parameter does not have relevance when the Source is 593 transmitting at a fixed rate throughout S. 595 7.3. Metric Definition 597 This section defines the REQUIRED aspects of the IP-layer Sender 598 Bitrate metric (unless otherwise indicated) for measurements at the 599 specified Source on packets addressed for the intended Destination 600 host and matching the required Type-P: 602 Define the IP-layer Sender Bit Rate, B(S,st), to be the number of IP- 603 layer bits (including header and data fields) that are transmitted 604 from the Source with address pair Src and Dst during one contiguous 605 sub-interval, st, during the test interval S (where S SHALL be longer 606 than I), and where the fixed-size packet count during that single 607 sub-interval st also provides the number of IP-layer bits in any 608 interval, [stn,stn+1]. 610 Measurements according to these definitions SHALL use the UDP 611 transport layer. Any feedback from Dst host to Src host received by 612 Src host during an interval [stn,stn+1] SHOULD NOT result in an 613 adaptation of the Src host traffic conditioning during this interval 614 (rate adjustment occurs on st interval boundaries). 616 7.4. Discussion 618 Both the Sender and Receiver or (source and destination) bit rates 619 SHOULD be assessed as part of an IP-layer Capacity measurement. 620 Otherwise, an unexpected sending rate limitation could produce an 621 erroneous Maximum IP-Layer Capacity measurement. 623 7.5. Reporting the Metric 625 The IP-Layer Sender Bit Rate SHALL be reported with meaningful 626 resolution, in units of Megabits per second (which is 1,000,000 bits 627 per second to avoid any confusion). 629 Individual IP-Layer Sender Bit Rate measurements are discussed 630 further in Section 9. 632 8. Method of Measurement 634 The architecture of the method REQUIRES two cooperating hosts 635 operating in the roles of Src (test packet sender) and Dst 636 (receiver), with a measured path and return path between them. 638 The duration of a test, parameter I, MUST be constrained in a 639 production network, since this is an active test method and it will 640 likely cause congestion on the Src to Dst host path during a test. 642 8.1. Load Rate Adjustment Algorithm 644 A table SHALL be pre-built defining all the offered load rates that 645 will be supported (R1 through Rn, in ascending order, corresponding 646 to indexed rows in the table). It is RECOMMENDED that rates begin 647 with 0.5 Mbps at index zero, use 1 Mbps at index one, and then 648 continue in 1 Mbps increments to 1 Gbps. Above 1 Gbps, and up to 10 649 Gbps, it is RECOMMENDED that 100 Mbps increments be used. Above 10 650 Gbps, increments of 1 Gbps are RECOMMENDED. Each rate is defined as 651 datagrams of size ss, sent as a burst of count cc, each time interval 652 tt (default for tt is 1ms, a likely system tick-interval). While it 653 is advantageous to use datagrams of as large a size as possible, it 654 may be prudent to use a slightly smaller maximum that allows for 655 secondary protocol headers and/or tunneling without resulting in IP- 656 layer fragmentation. Selection of a new rate is indicated by a 657 calculation on the current row, Rx. For example: 659 "Rx+1": the sender uses the next higher rate in the table. 661 "Rx-10": the sender uses the rate 10 rows lower in the table. 663 At the beginning of a test, the sender begins sending at rate R1 and 664 the receiver starts a feedback timer of duration FT (while awaiting 665 inbound datagrams). As datagrams are received they are checked for 666 sequence number anomalies (loss, out-of-order, duplication, etc.) and 667 the delay range is measured (one-way or round-trip). This 668 information is accumulated until the feedback timer FT expires and a 669 status feedback message is sent from the receiver back to the sender, 670 to communicate this information. The accumulated statistics are then 671 reset by the receiver for the next feedback interval. As feedback 672 messages are received back at the sender, they are evaluated to 673 determine how to adjust the current offered load rate (Rx). 675 If the feedback indicates that no sequence number anomalies were 676 detected AND the delay range was below the lower threshold, the 677 offered load rate is increased. If congestion has not been confirmed 678 up to this point, the offered load rate is increased by more than one 679 rate (e.g., Rx+10). This allows the offered load to quickly reach a 680 near-maximum rate. Conversely, if congestion has been previously 681 confirmed, the offered load rate is only increased by one (Rx+1). 682 However, if a rate threshold between high and very high sending rates 683 (such as 1Gbps) is exceeded, the offered load rate is only increased 684 by one (Rx+1) above the rate threshold in any congestion state. 686 If the feedback indicates that sequence number anomalies were 687 detected OR the delay range was above the upper threshold, the 688 offered load rate is decreased. The RECOMMENDED values are 0 for 689 sequence number gaps and 30-90 ms for lower and upper delay 690 thresholds, respectively. Also, if congestion is now confirmed for 691 the first time by the current feedback message being processed, then 692 the offered load rate is decreased by more than one rate (e.g., Rx- 693 30). This one-time reduction is intended to compensate for the fast 694 initial ramp-up. In all other cases, the offered load rate is only 695 decreased by one (Rx-1). 697 If the feedback indicates that there were no sequence number 698 anomalies AND the delay range was above the lower threshold, but 699 below the upper threshold, the offered load rate is not changed. 700 This allows time for recent changes in the offered load rate to 701 stabilize, and the feedback to represent current conditions more 702 accurately. 704 Lastly, the method for inferring congestion is that there were 705 sequence number anomalies AND/OR the delay range was above the upper 706 threshold for two consecutive feedback intervals. The algorithm 707 described above is also illustrated in ITU-T Rec. Y.1540, 2020 708 version[Y.1540], in Annex B, and implemented in the Appendix on Load 709 Rate Adjustment Pseudo Code in this memo. 711 The Load Rate Adjustment Algorithm MUST include timers that stop the 712 test when received packet streams cease unexpectedly. The timeout 713 thresholds are provided in the table below, along with values for all 714 other parameters and variables described in this section. 716 +--------------+-------------+--------------+-----------------------+ 717 | Parameter | Default | Tested Range | Expected Safe Range | 718 | | | or values | (not entirely tested, | 719 | | | | other values NOT | 720 | | | | RECOMMENDED) | 721 +--------------+-------------+--------------+-----------------------+ 722 | FT, feedback | 50ms | 20ms, 100ms | 5ms <= FT <= 250ms | 723 | time | | | Larger values may | 724 | interval | | | slow the rate | 725 | | | | increase and fail to | 726 | | | | find the max | 727 +--------------+-------------+--------------+-----------------------+ 728 | Feedback | L*FT, L=10 | L=100 with | 0.5sec <= L*FT <= | 729 | message | (500ms) | FT=50ms | 30sec Upper limit for | 730 | timeout | | (5sec) | very unreliable test | 731 | (stop test) | | | paths only | 732 +--------------+-------------+--------------+-----------------------+ 733 | load packet | 1sec | 5sec | 0.250sec - 30sec | 734 | timeout | | | Upper limit for very | 735 | (stop test) | | | unreliable test paths | 736 | | | | only | 737 +--------------+-------------+--------------+-----------------------+ 738 | table index | 0.5Mbps | 0.5Mbps | when testing <=10Gbps | 739 | 0 | | | | 740 +--------------+-------------+--------------+-----------------------+ 741 | table index | 1Mbps | 1Mbps | when testing <=10Gbps | 742 | 1 | | | | 743 +--------------+-------------+--------------+-----------------------+ 744 | table index | 1Mbps | 1Mbps - | same as tested | 745 | (step) size | | 1Gbps | | 746 +--------------+-------------+--------------+-----------------------+ 747 | table index | 100Mbps | 1Gbps - | same as tested | 748 | (step) size, | | 10Gbps | | 749 | rate>1Gbps | | | | 750 +--------------+-------------+--------------+-----------------------+ 751 | table index | 1Gbps | untested | >10Gbps | 752 | (step) size, | | | | 753 | rate>10Gbps | | | | 754 +--------------+-------------+--------------+-----------------------+ 755 | ss, UDP | none | <=1222 | Recommend max at | 756 | payload | | | largest value that | 757 | size, bytes | | | avoids fragmentation | 758 +--------------+-------------+--------------+-----------------------+ 759 | cc, burst | none | 1 - 100 | same as tested | 760 | count | | | | 761 +--------------+-------------+--------------+-----------------------+ 762 | tt, burst | 100microsec | 100microsec, | available range of | 763 | interval | | 1msec | "tick" values (HZ | 764 | | | | param) | 765 +--------------+-------------+--------------+-----------------------+ 766 | low delay | 30ms | 5ms, 30ms | same as tested | 767 | range | | | | 768 | threshold | | | | 769 +--------------+-------------+--------------+-----------------------+ 770 | high delay | 90ms | 10ms, 90ms | same as tested | 771 | range | | | | 772 | threshold | | | | 773 +--------------+-------------+--------------+-----------------------+ 774 | sequence | 0 | 0, 100 | same as tested | 775 | error | | | | 776 | threshold | | | | 777 +--------------+-------------+--------------+-----------------------+ 778 | consecutive | 2 | 2 | Use values >1 to | 779 | errored | | | avoid misinterpreting | 780 | status | | | transient loss | 781 | report | | | | 782 | threshold | | | | 783 +--------------+-------------+--------------+-----------------------+ 784 | Fast mode | 10 | 10 | 2 <= steps <= 30 | 785 | increase, in | | | | 786 | table index | | | | 787 | steps | | | | 788 +--------------+-------------+--------------+-----------------------+ 789 | Fast mode | 30 | 3 * Fast | same as tested | 790 | decrease, in | | mode | | 791 | table index | | increase | | 792 | steps | | | | 793 +--------------+-------------+--------------+-----------------------+ 794 | Number of | 2000 | 2000 | same as tested | 795 | table steps | | | | 796 | in total, | | | | 797 | <10Gbps | | | | 798 +--------------+-------------+--------------+-----------------------+ 800 Parameters for Load Rate Adjustment Algorithm 802 8.2. Measurement Qualification or Verification 804 It is of course necessary to calibrate the equipment performing the 805 IP-layer Capacity measurement, to ensure that the expected capacity 806 can be measured accurately, and that equipment choices (processing 807 speed, interface bandwidth, etc.) are suitably matched to the 808 measurement range. 810 When assessing a Maximum rate as the metric specifies, artificially 811 high (optimistic) values might be measured until some buffer on the 812 path is filled. Other causes include bursts of back-to-back packets 813 with idle intervals delivered by a path, while the measurement 814 interval (dt) is small and aligned with the bursts. The artificial 815 values might result in an un-sustainable Maximum Capacity observed 816 when the method of measurement is searching for the Maximum, and that 817 would not do. This situation is different from the bi-modal service 818 rates (discussed under Reporting), which are characterized by a 819 multi-second duration (much longer than the measured RTT) and 820 repeatable behavior. 822 There are many ways that the Method of Measurement could handle this 823 false-max issue. The default value for measurement of singletons (dt 824 = 1 second) has proven to a be of practical value during tests of 825 this method, allows the bimodal service rates to be characterized, 826 and it has an obvious alignment with the reporting units (Mbps). 828 Another approach comes from Section 24 of RFC 2544[RFC2544] and its 829 discussion of Trial duration, where relatively short trials conducted 830 as part of the search are followed by longer trials to make the final 831 determination. In the production network, measurements of singletons 832 and samples (the terms for trials and tests of Lab Benchmarking) must 833 be limited in duration because they may be service-affecting. But 834 there is sufficient value in repeating a sample with a fixed sending 835 rate determined by the previous search for the Max IP-layer Capacity, 836 to qualify the result in terms of the other performance metrics 837 measured at the same time. 839 A qualification measurement for the search result is a subsequent 840 measurement, sending at a fixed 99.x % of the Max IP-layer Capacity 841 for I, or an indefinite period. The same Max Capacity Metric is 842 applied, and the Qualification for the result is a sample without 843 packet loss or a growing minimum delay trend in subsequent singletons 844 (or each dt of the measurement interval, I). Samples exhibiting 845 losses or increasing queue occupation require a repeated search and/ 846 or test at reduced fixed sender rate for qualification. 848 Here, as with any Active Capacity test, the test duration must be 849 kept short. 10 second tests for each direction of transmission are 850 common today. The default measurement interval specified here is I = 851 10 seconds. The combination of a fast and congestion-aware search 852 method and user-network coordination make a unique contribution to 853 production testing. The Max IP Capacity metric and method for 854 assessing performance is very different from classic [RFC2544] 855 Throughput metric and methods : it uses near-real-time load 856 adjustments that are sensitive to loss and delay, similar to other 857 congestion control algorithms used on the Internet every day, along 858 with limited duration. On the other hand, [RFC2544] Throughput 859 measurements can produce sustained overload conditions for extended 860 periods of time. Individual trials in a test governed by a binary 861 search can last 60 seconds for each step, and the final confirmation 862 trial may be even longer. This is very different from "normal" 863 traffic levels, but overload conditions are not a concern in the 864 isolated test environment. The concerns raised in [RFC6815] were 865 that [RFC2544] methods would be let loose on production networks, and 866 instead the authors challenged the standards community to develop 867 metrics and methods like those described in this memo. 869 8.3. Measurement Considerations 871 In general, the wide-spread measurements that this memo encourages 872 will encounter wide-spread behaviors. The bimodal IP Capacity 873 behaviors already discussed in Section 6.6 are good examples. 875 In general, it is RECOMMENDED to locate test endpoints as close to 876 the intended measured link(s) as practical (this is not always 877 possible for reasons of scale; there is a limit on number of test 878 endpoints coming from many perspectives, management and measurement 879 traffic for example). The testing operator MUST set a value for the 880 MaxHops parameter, based on the expected path length. This parameter 881 can keep measurement traffic from straying too far beyond the 882 intended path. 884 The path measured may be state-full based on many factors, and the 885 Parameter "Time of day" when a test starts may not be enough 886 information. Repeatable testing may require the time from the 887 beginning of a measured flow, and how the flow is constructed 888 including how much traffic has already been sent on that flow when a 889 state-change is observed, because the state-change may be based on 890 time or bytes sent or both. 892 Many different traffic shapers and on-demand access technologies may 893 be encountered, as anticipated in [RFC7312], and play a key role in 894 measurement results. Methods MUST be prepared to provide a short 895 preamble transmission to activate on-demand access, and to discard 896 the preamble from subsequent test results. 898 Conditions which might be encountered during measurement, where 899 packet losses may occur independently from the measurement sending 900 rate: 902 1. Congestion of an interconnection or backbone interface may appear 903 as packet losses distributed over time in the test stream, due to 904 much higher rate interfaces in the backbone. 906 2. Packet loss due to use of Random Early Detection (RED) or other 907 active queue management may or may not affect the measurement 908 flow if competing background traffic (other flows) are 909 simultaneously present. 911 3. There may be only small delay variation independent of sending 912 rate under these conditions, too. 914 4. Persistent competing traffic on measurement paths that include 915 shared transmission media may cause random packet losses in the 916 test stream. 918 It is possible to mitigate these conditions using the flexibility of 919 the load-rate adjusting algorithm described in Section 8.1 above 920 (tuning specific parameters). 922 If the measurement flow burst duration happens to be on the order of 923 or smaller than the burst size of a shaper or a policer in the path, 924 then the line rate might be measured rather than the bandwidth limit 925 imposed by the shaper or policer. If this condition is suspected, 926 alternate configurations SHOULD be used. 928 In general, results depend on the sending stream characteristics; the 929 measurement community has known this for a long time, and needs to 930 keep it front of mind. Although the default is a single flow (F=1) 931 for testing, use of multiple flows may be advantageous for the 932 following reasons: 934 1. the test hosts may be able to create higher load than with a 935 single flow, or parallel test hosts may be used to generate 1 936 flow each. 938 2. there may be link aggregation present (flow-based load balancing) 939 and multiple flows are needed to occupy each member of the 940 aggregate. 942 3. access policies may limit the IP-Layer Capacity depending on the 943 Type-P of packets, possibly reserving capacity for various stream 944 types. 946 Each flow would be controlled using its own implementation of the 947 Load Adjustment (Search) Algorithm. 949 As testing continues, implementers should expect some evolution in 950 the methods. The ITU-T has published a Supplement (60) to the 951 Y-series of Recommendations, "Interpreting ITU-T Y.1540 maximum IP- 952 layer capacity measurements", [Y.Sup60], which is the result of 953 continued testing with the metric, and those results have improved 954 the method described here. 956 8.4. Running Code 958 This section is for the benefit of the Document Shepherd's form, and 959 will be deleted prior to final review. 961 Much of the development of the method and comparisons with existing 962 methods conducted at IETF Hackathons and elsewhere have been based on 963 the example udpst Linux measurement tool (which is a working 964 reference for further development) [udpst]. The current project: 966 o is a utility that can function as a client or server daemon 968 o requires a successful client-initiated setup handshake between 969 cooperating hosts and allows firewalls to control inbound 970 unsolicited UDP which either go to a control port [expected and w/ 971 authentication] or to ephemeral ports that are only created as 972 needed. Firewalls protecting each host can both continue to do 973 their job normally. This aspect is similar to many other test 974 utilities available. 976 o is written in C, and built with gcc (release 9.3) and its standard 977 run-time libraries 979 o allows configuration of most of the parameters described in 980 Sections 4 and 7. 982 o supports IPv4 and IPv6 address families. 984 o supports IP-layer packet marking. 986 9. Reporting Formats 988 The singleton IP-Layer Capacity results SHOULD be accompanied by the 989 context under which they were measured. 991 o timestamp (especially the time when the maximum was observed in 992 dtn) 994 o source and destination (by IP or other meaningful ID) 996 o other inner parameters of the test case (Section 4) 998 o outer parameters, such as "test conducted in motion" or other 999 factors belonging to the context of the measurement 1001 o result validity (indicating cases where the process was somehow 1002 interrupted or the attempt failed) 1004 o a field where unusual circumstances could be documented, and 1005 another one for "ignore/mask out" purposes in further processing 1007 The Maximum IP-Layer Capacity results SHOULD be reported in the 1008 format of a table with a row for each of the test Phases and Number 1009 of Flows. There SHOULD be columns for the phases with number of 1010 flows, and for the resultant Maximum IP-Layer Capacity results for 1011 the aggregate and each flow tested. 1013 As mentioned in Section 6.6, bi-modal (or multi-modal) maxima SHALL 1014 be reported for each mode separately. 1016 +--------------+----------------------+-----------+-----------------+ 1017 | Phase, # | Max IP-Layer | Loss | RTT min, max, | 1018 | Flows | Capacity, Mbps | Ratio | msec | 1019 +--------------+----------------------+-----------+-----------------+ 1020 | Search,1 | 967.31 | 0.0002 | 30, 58 | 1021 +--------------+----------------------+-----------+-----------------+ 1022 | Verify,1 | 966.00 | 0.0000 | 30, 38 | 1023 +--------------+----------------------+-----------+-----------------+ 1025 Maximum IP-layer Capacity Results 1027 Static and configuration parameters: 1029 The sub-interval time, dt, MUST accompany a report of Maximum IP- 1030 Layer Capacity results, and the remaining Parameters from Section 4, 1031 General Parameters. 1033 The PM list metrics corresponding to the sub-interval where the 1034 Maximum Capacity occurred MUST accompany a report of Maximum IP-Layer 1035 Capacity results, for each test phase. 1037 The IP-Layer Sender Bit rate results SHOULD be reported in the format 1038 of a table with a row for each of the test Phases, sub-intervals (st) 1039 and Number of Flows. There SHOULD be columns for the phases with 1040 number of flows, and for the resultant IP-Layer Sender Bit rate 1041 results for the aggregate and each flow tested. 1043 +------------------------+-------------+-----------------------+----+ 1044 | Phase, Flow or | st, sec | Sender Bit Rate, Mbps | ?? | 1045 | Aggregate | | | | 1046 +------------------------+-------------+-----------------------+----+ 1047 | Search,1 | 0.00 - 0.05 | 345 | __ | 1048 +------------------------+-------------+-----------------------+----+ 1049 | Search,2 | 0.00 - 0.05 | 289 | __ | 1050 +------------------------+-------------+-----------------------+----+ 1051 | Search,Agg | 0.00 - 0.05 | 634 | __ | 1052 +------------------------+-------------+-----------------------+----+ 1054 IP-layer Sender Bit Rate Results 1056 Static and configuration parameters: 1058 The subinterval time, st, MUST accompany a report of Sender IP-Layer 1059 Bit Rate results. 1061 Also, the values of the remaining Parameters from Section 4, General 1062 Parameters, MUST be reported. 1064 9.1. Configuration and Reporting Data Formats 1066 As a part of the multi-Standards Development Organization (SDO) 1067 harmonization of this metric and method of measurement, one of the 1068 areas where the Broadband Forum (BBF) contributed its expertise was 1069 in the definition of an information model and data model for 1070 configuration and reporting. These models are consistent with the 1071 metric parameters and default values specified as lists is this memo. 1072 [TR-471] provides the Information model that was used to prepare a 1073 full data model in related BBF work. The BBF has also carefully 1074 considered topics within its purview, such as placement of 1075 measurement systems within the access architecture. For example, 1076 timestamp resolution requirements that influence the choice of the 1077 test protocol are provided in Table 2 of [TR-471]. 1079 10. Security Considerations 1081 Active metrics and measurements have a long history of security 1082 considerations. The security considerations that apply to any active 1083 measurement of live paths are relevant here. See [RFC4656] and 1084 [RFC5357]. 1086 When considering privacy of those involved in measurement or those 1087 whose traffic is measured, the sensitive information available to 1088 potential observers is greatly reduced when using active techniques 1089 which are within this scope of work. Passive observations of user 1090 traffic for measurement purposes raise many privacy issues. We refer 1091 the reader to the privacy considerations described in the Large Scale 1092 Measurement of Broadband Performance (LMAP) Framework [RFC7594], 1093 which covers active and passive techniques. 1095 There are some new considerations for Capacity measurement as 1096 described in this memo. 1098 1. Cooperating source and destination hosts and agreements to test 1099 the path between the hosts are REQUIRED. Hosts perform in either 1100 the Src or Dst roles. 1102 2. It is REQUIRED to have a user client-initiated setup handshake 1103 between cooperating hosts that allows firewalls to control 1104 inbound unsolicited UDP traffic which either goes to a control 1105 port [expected and w/authentication] or to ephemeral ports that 1106 are only created as needed. Firewalls protecting each host can 1107 both continue to do their job normally. 1109 3. Client-server authentication and integrity protection for 1110 feedback messages conveying measurements is RECOMMENDED. 1112 4. Hosts MUST limit the number of simultaneous tests to avoid 1113 resource exhaustion and inaccurate results. 1115 5. Senders MUST be rate-limited. This can be accomplished using a 1116 pre-built table defining all the offered load rates that will be 1117 supported (Section 8.1). The recommended load-control search 1118 algorithm results in "ramp up" from the lowest rate in the table. 1120 6. Service subscribers with limited data volumes who conduct 1121 extensive capacity testing might experience the effects of 1122 Service Provider controls on their service. Testing with the 1123 Service Provider's measurement hosts SHOULD be limited in 1124 frequency and/or overall volume of test traffic (for example, the 1125 range of I duration values SHOULD be limited). 1127 The exact specification of these features is left for the future 1128 protocol development. 1130 11. IANA Considerations 1132 This memo makes no requests of IANA. 1134 12. Acknowledgments 1136 Thanks to Joachim Fabini, Matt Mathis, J.Ignacio Alvarez-Hamelin, 1137 Wolfgang Balzer, Frank Brockners, Greg Mirsky, Martin Duke, Murray 1138 Kucherawy, and Benjamin Kaduk for their extensive comments on the 1139 memo and related topics. 1141 13. Appendix - Load Rate Adjustment Pseudo Code 1143 The following is a pseudo-code implementation of the algorithm 1144 described in Section 8.1. 1146 Rx = 0 # The current sending rate (equivalent to a row of the table) 1147 seqErr = 0 # Measured count of any of Loss or Reordering impairments 1148 delay = 0 # Measured Range of Round Trip Time, RTT, ms 1149 lowThresh = 30 # Low threshold on the Range of RTT, ms 1150 upperThresh = 90 # Upper threshold on the Range of RTT, ms 1151 hSpeedTresh = 1Gbps # Threshold for transition between sending rate step 1152 sizes (such as 1 Mbps and 100 Mbps) 1153 slowAdjCount = 0 # Measured Number of consecutive status reports 1154 indicating loss and/or delay variation above upperThresh 1155 slowAdjThresh = 2 # Threshold on slowAdjCount used to infer congestion. 1156 Use values >1 to avoid misinterpreting transient loss 1157 highSpeedDelta = 10 # The number of rows to move in a single adjustment 1158 when initially increasing offered load (to ramp-up quickly) 1159 maxLoadRates = 2000 # Maximum table index (rows) 1161 if ( seqErr == 0 && delay < lowThresh ) { 1162 if ( Rx < hSpeedTresh && slowAdjCount < slowAdjThresh ) { 1163 Rx += highSpeedDelta; 1164 slowAdjCount = 0; 1165 } else { 1166 if ( Rx < maxLoadRates - 1 ) 1167 Rx++; 1168 } 1169 } else if ( seqErr > 0 || delay > upperThresh ) { 1170 slowAdjCount++; 1171 if ( Rx < hSpeedTresh && slowAdjCount == slowAdjThresh ) { 1172 if ( Rx > highSpeedDelta * 3 ) 1173 Rx -= highSpeedDelta * 3; 1174 else 1175 Rx = 0; 1176 } else { 1177 if ( Rx > 0 ) 1178 Rx--; 1179 } 1180 } 1181 14. References 1183 14.1. Normative References 1185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1186 Requirement Levels", BCP 14, RFC 2119, 1187 DOI 10.17487/RFC2119, March 1997, 1188 . 1190 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1191 "Framework for IP Performance Metrics", RFC 2330, 1192 DOI 10.17487/RFC2330, May 1998, 1193 . 1195 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1196 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1197 September 1999, . 1199 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 1200 Zekauskas, "A One-way Active Measurement Protocol 1201 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 1202 . 1204 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1205 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1206 RFC 5357, DOI 10.17487/RFC5357, October 2008, 1207 . 1209 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1210 for Equal Cost Multipath Routing and Link Aggregation in 1211 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1212 . 1214 [RFC7479] Moonesamy, S., "Using Ed25519 in SSHFP Resource Records", 1215 RFC 7479, DOI 10.17487/RFC7479, March 2015, 1216 . 1218 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1219 Ed., "A One-Way Loss Metric for IP Performance Metrics 1220 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1221 2016, . 1223 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1224 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1225 May 2017, . 1227 [RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. 1228 Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for 1229 the IP Performance Metrics (IPPM) Framework", RFC 8468, 1230 DOI 10.17487/RFC8468, November 2018, 1231 . 1233 14.2. Informative References 1235 [copycat] Edleine, K., Kuhlewind, K., Trammell, B., and B. Donnet, 1236 "copycat: Testing Differential Treatment of New Transport 1237 Protocols in the Wild (ANRW '17)", July 2017, 1238 . 1240 [LS-SG12-A] 1241 12, I. S., "LS - Harmonization of IP Capacity and Latency 1242 Parameters: Revision of Draft Rec. Y.1540 on IP packet 1243 transfer performance parameters and New Annex A with Lab 1244 Evaluation Plan", May 2019, 1245 . 1247 [LS-SG12-B] 1248 12, I. S., "LS on harmonization of IP Capacity and Latency 1249 Parameters: Consent of Draft Rec. Y.1540 on IP packet 1250 transfer performance parameters and New Annex A with Lab & 1251 Field Evaluation Plans", March 2019, 1252 . 1254 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 1255 Network Interconnect Devices", RFC 2544, 1256 DOI 10.17487/RFC2544, March 1999, 1257 . 1259 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 1260 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 1261 DOI 10.17487/RFC3148, July 2001, 1262 . 1264 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 1265 RFC 5136, DOI 10.17487/RFC5136, February 2008, 1266 . 1268 [RFC6815] Bradner, S., Dubray, K., McQuaid, J., and A. Morton, 1269 "Applicability Statement for RFC 2544: Use on Production 1270 Networks Considered Harmful", RFC 6815, 1271 DOI 10.17487/RFC6815, November 2012, 1272 . 1274 [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling 1275 Framework for IP Performance Metrics (IPPM)", RFC 7312, 1276 DOI 10.17487/RFC7312, August 2014, 1277 . 1279 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 1280 Aitken, P., and A. Akhter, "A Framework for Large-Scale 1281 Measurement of Broadband Performance (LMAP)", RFC 7594, 1282 DOI 10.17487/RFC7594, September 2015, 1283 . 1285 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 1286 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 1287 May 2016, . 1289 [RFC8337] Mathis, M. and A. Morton, "Model-Based Metrics for Bulk 1290 Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March 1291 2018, . 1293 [TR-471] Morton, A., "Broadband Forum TR-471: IP Layer Capacity 1294 Metrics and Measurement", July 2020, 1295 . 1298 [udpst] udpst Project Collaborators, "UDP Speed Test Open 1299 Broadband project", December 2020, 1300 . 1302 [Y.1540] Y.1540, I. R., "Internet protocol data communication 1303 service - IP packet transfer and availability performance 1304 parameters", December 2019, 1305 . 1307 [Y.Sup60] Morton, A., "Recommendation Y.Sup60, (09/20) Interpreting 1308 ITU-T Y.1540 maximum IP-layer capacity measurements", 1309 September 2020, 1310 . 1312 Authors' Addresses 1313 Al Morton 1314 AT&T Labs 1315 200 Laurel Avenue South 1316 Middletown,, NJ 07748 1317 USA 1319 Phone: +1 732 420 1571 1320 Fax: +1 732 368 1192 1321 Email: acm@research.att.com 1323 Ruediger Geib 1324 Deutsche Telekom 1325 Heinrich Hertz Str. 3-7 1326 Darmstadt 64295 1327 Germany 1329 Phone: +49 6151 5812747 1330 Email: Ruediger.Geib@telekom.de 1332 Len Ciavattone 1333 AT&T Labs 1334 200 Laurel Avenue South 1335 Middletown,, NJ 07748 1336 USA 1338 Email: lencia@att.com