idnits 2.17.1 draft-ietf-bmwg-atm-term-abr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 1) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 132 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 200 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 114: '... the MUST requirements for t...' RFC 2119 keyword, line 115: '...sfies all the MUST and all the ...' RFC 2119 keyword, line 117: '...atisfies all the MUST requirements but...' RFC 2119 keyword, line 118: '... SHOULD requirements for its pro...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 14 has weird spacing: '... This docu...' == Line 16 has weird spacing: '... its workin...' == Line 20 has weird spacing: '... and may b...' == Line 21 has weird spacing: '...ference mater...' == Line 30 has weird spacing: '... To view t...' == (127 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 379 -- Looks like a reference, but probably isn't: '1' on line 379 == Unused Reference: 'AF-TEST-0022' is defined on line 517, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AF-TEST-0022' Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. H. Dunn 2 INTERNET-DRAFT C. E. Martin 3 Expires: May, 2000 ANC, Inc. 5 November, 1999 6 Terminology for ATM ABR Benchmarking 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as work in progress. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 To view the entire list of current Internet-Drafts, please check the 31 1id- abstracts.txt listing contained in the Internet-Drafts Shadow 32 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 33 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 34 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 36 Copyright Notice 38 Copyright (C) The Internet Society (1999). All Rights Reserved. 40 Abstract 42 This memo discusses and defines terms associated with performance 43 benchmarking tests and the results of these tests in the context of 44 Asynchronous Transfer Mode (ATM) based switching devices supporting ABR. 45 The terms defined in this memo will be used in addition to terms defined 46 in RFCs 1242, 2285, and 2544 and in ID Terminology for ATM Benchmarking. 47 This memo is a product of the Benchmarking Methodology Working Group 48 (BMWG) of the Internet Engineering Task Force (IETF). 50 1. Introduction. 52 This document provides terminology for benchmarking ATM based switching 53 devices supporting ABR. It extends terminology already defined for 54 benchmarking network interconnect devices in RFC's 1242, 2285, and 2544 55 and in ID Terminology for ATM Benchmarking. Although some of the 56 definitions in this memo may be applicable to a broader group of network 57 interconnect devices, the primary focus of the terminology in this memo 58 is on ATM ABR. 60 This memo contains two major sections: Background and Definitions. The 61 background section provides the reader with an overview of the 62 technology and IETF formalisms. The definitions section is split into 63 two sub- sections. The formal definitions sub-section is provided as a 64 courtesy to the reader. The measurement definitions sub-section 65 contains performance metrics with inherent units. 67 This document assumes that necessary services are available and active. 68 For example, IP connectivity requires SSCOP connectivity between 69 signaling entities. Further, it is assumed that the SUT has the ability 70 to configure ATM addresses (via hard coded addresses, ILMI or PNNI 71 neighbor discovery), has the ability to run SSCOP, and has the ability 72 to perform signaled call setups (via UNI or PNNI signaling). Finally, 73 this document presents only the terminology associated with benchmarking 74 IP performance over ATM; therefore, it does not represent a total 75 compilation of ATM test terminology. 77 The BMWG produces two major classes of documents: Benchmarking 78 Terminology documents and Benchmarking Methodology documents. The 79 Terminology documents present the benchmarks and other related terms. 80 The Methodology documents define the procedures required to collect the 81 benchmarks cited in the corresponding Terminology documents. 83 2. Existing Definitions. 85 RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" 86 should be consulted before attempting to make use of this document. RFC 87 2544 "Benchmarking Methodology for Network Interconnect Devices" 88 contains discussions of a number of terms relevant to the benchmarking 89 of switching devices and should be consulted. RFC 2285 "Benchmarking 90 Terminology for LAN Switching Devices" contains a number of terms 91 pertaining to traffic distributions and datagram interarrival. For the 92 sake of clarity and continuity, this RFC adopts the template for 93 definitions set out in Section 2 of RFC 1242. 95 3. Requirements 97 In this document, the words that are used to define the significance of 98 each particular requirement are capitalized. These words are: 100 * "MUST" This word, or the words "REQUIRED" and "SHALL" mean that the 101 item is an absolute requirement of the specification. 103 * "SHOULD" This word or the adjective "RECOMMENDED" means that there may 104 exist valid reasons in particular circumstances to ignore this item, but 105 the full implications should be understood and the case carefully 106 weighed before choosing a different course. 108 * "MAY" This word or the adjective "OPTIONAL" means that this item is 109 truly optional. One vendor may choose to include the item because a 110 particular marketplace requires it or because it enhances the product, 111 for example; another vendor may omit the same item. 113 An implementation is not compliant if it fails to satisfy one or more of 114 the MUST requirements for the protocols it implements. An 115 implementation that satisfies all the MUST and all the SHOULD 116 requirements for its protocols is said to be "unconditionally 117 compliant"; one that satisfies all the MUST requirements but not all the 118 SHOULD requirements for its protocols is said to be "conditionally 119 compliant". 121 II. Definitions 123 The definitions presented in this section have been divided into two 124 groups. The first group is formal definitions, which are required in 125 the definitions of the performance metrics but are not themselves 126 strictly metrics. These definitions are subsumed from other work done 127 in other working groups both inside and outside the IETF. They are 128 provided as a courtesy to the reader. 130 1. Formal Definitions 132 1.1. Definition Format (from RFC 1242) 134 Term to be defined. 136 Definition: The specific definition for the term. 138 Discussion: A brief discussion of the term, its application and any 139 restrictions on measurement procedures. 141 Specification: The working group and document in which the terms are 142 specified and are listed in the references section. 144 1.2. Related Definitions. 146 1.2.1. Allowed Cell Rate (ACR) 148 Definition: An ABR service parameter, ACR is the current rate 149 (cells/second) at which a source is allowed to send. 151 Discussion: For ABR traffic, ACR constitutes the actual data throughput 152 for a particular VC. The time change of this value effects TCP round 153 trip time calculations, which in turn effects TCP throughput. 155 Specification: AF-TM4.0 157 1.2.2. ACR Decrease Time Factor (ADTF) 159 Definition: This is the time permitted between sending RM-cells before 160 the rate is decreased to ICR (Initial Cell Rate). The time units are 161 .01 to 10.23 seconds 163 with a granularity of 10 ms. 165 Discussion: For ABR traffic, ADTF constitutes the time rate of the ACR. 166 This value effects TCP round trip time calculations, which in turn 167 effects TCP throughput. 169 Specification: AF-TM4.0 171 1.2.3. Additive Increase Rate (AIR) 173 Definition: An ABR service parameter, AIR controls the rate at which the 174 cell transmission rate increases. It is signaled as AIRF, where 175 AIRF = AIR*Nrm/PCR. 177 Discussion: For ABR traffic, AIR effects the time rate of change of the 178 ACR. This value effects TCP round trip time calculations, which in turn 179 effects TCP throughput. 181 Specification: AF-TM4.0 183 1.2.4. Additive Increase Rate Factor (AIRF) 185 Definition: Refer to AIR. 187 Discussion: Refer to AIR. 189 Specification: AF-TM4.0 191 1.2.5. Available Bit Rate (ABR) 193 Definition: ABR is an ATM layer service category for which the limiting 194 ATM layer transfer characteristics provided by the network may change 195 subsequent to connection establishment. A flow control mechanism is 196 specified which supports several types of feedback to control the source 197 rate in response to changing ATM layer transfer characteristics. 199 Discussion: It is expected that an end-system that adapts its traffic in 200 accordance with the feedback will experience a low cell loss ratio and 201 obtain a fair share of the available bandwidth according to a network 202 specific allocation policy. Cell delay variation is not controlled in 203 this service, although admitted cells are not delayed unnecessarily. 205 Specification: AF-TM4.0 207 1.2.6. Cutoff Decrease Factor (CDF) 209 Definition: CDF controls the decrease in ACR (Allowed Cell Rate) 210 associated with CRM (missing RM cell count). 212 Discussion: For ABR traffic, CDF effects the time rate of change of the 213 ACR. This value effects TCP round trip time calculations, which in turn 214 effects TCP throughput. 216 Specification: AF-TM4.0 218 1.2.7. Initial Cell Rate (ICR) 220 Definition: An ABR service parameter, in cells/sec, that is the rate at 221 which a source should send initially and after an idle period. 223 Discussion: none. 225 Specification: AF-TM4.0 227 1.2.8. Minimum Cell Rate (MCR) 229 Definition: An ABR service traffic descriptor, in cells/sec, that is the 230 rate at which the source is always allowed to send. 232 Discussion: none. 234 Specification: AF-TM4.0 236 1.2.9. Mrm 238 Definition: An ABR service parameter that controls allocation of 239 bandwidth between forward W-cells, backward RM-cells, and data cells. 241 Discussion: none. 243 Specification: AF-TM4.0 245 1.2.10. Nrm 247 Definition: An ABR service parameter, Nrm is the maximum number of cells 248 a source may send for each forward RM-cell. 250 Discussion: none. 252 Specification: AF-TM4.0 254 1.2.11. Rate Decrease Factor (RDF) 256 Definition: An ABR service parameter, RDF controls the decrease in the 257 cell transmission rate. RDF is a power of 2 from 1/32,768 to 1. 259 Discussion: For ABR traffic, RDF effects the time rate of change of the 260 ACR. This value effects TCP round trip time calculations, which in turn 261 effects TCP throughput. 263 Specification: AF-TM4.0 265 1.2.12. Rate Increase Factor (RIF) 267 Definition: This controls the amount by which the cell transmission rate 268 may increase upon receipt of a RM-cell. The additive increase rate 269 AIR=PCR*RIF. RIF is a power of 2, ranging from 1/32,768 to 1. 271 Discussion: For ABR traffic, RIF effects the time rate of change of the 272 ACR. This value effects TCP round trip time calculations, which in turn 273 effects TCP throughput. 275 Specification: AF-TM4.0 277 1.2.13. Resource Management (RM) Cells 279 Definition: RM cells are used to convey network status (available 280 bandwidth, congestion levels) and request peak cell rates for ATM 281 blocks. The RM cell has the following format: 283 Header: 5 bytes, same as the ATM cell header 284 Protocol ID: 3 bytes, value is ID1 285 Function specific field: 45 bytes, data required for the specific protocol 286 Rsvd: 6 bytes, reserved for future specification 287 EDC: 10 bytes, CRC-10 error detection code computed over the cell payload 288 (except the CRC-10 field) and used to check for data corruption 290 Discussion: RM information can exist at the VP and/or VC level. VP level 291 cells are identified with a VCI value of 6. VC level cells are 292 identified with a PT of 6. 294 Specification: AF-TM4.0 296 1.2.14. Tagged Cell Rate (TCR) 298 Definition: An ABR service parameter, TCR limits the rate at which a 299 source may send out-of-rate forward RM-cells. TCR is a constant fixed at 300 10 cells/second. 302 Discussion: none. 304 Specification: AF-TM4.0 306 1.2.15. TDF 308 Definition: An ABR service parameter, TDF controls the decrease in ACR 309 associated with TOF. TDF is signaled as TDFF, where TDF=TDFF/RDF times 310 the smallest power of 2 greater or equal to PCR. TDF is in units of 311 1/seconds. 313 Discussion: For ABR traffic, TDF effects the time rate of change of the 314 ACR. This value effects TCP round trip time calculations, which in turn 315 effects TCP throughput. 317 Specification: AF-TM4.0 319 1.2.16. TDFF 321 Definition: Refer to TDF. TDFF is either zero or a power of two in the 322 range 1/64 to 1 in units of 1 /cells. 324 Discussion: Refer to TDF. 326 Specification: AF-TM4.0 328 1.2.17. Time Out Factor (TOF) 330 Definition: An ABR service parameter, TOF controls the maximum time 331 permitted between sending forward RM-cells before a rate decrease is 332 required. It is signaled as TOFF where TOF=TOFF+1. TOFF is a power of 2 333 in the range: 1/8 to 4,096. 335 Discussion: For ABR traffic, TOF effects the time rate of change of the 336 ACR. This value effects TCP round trip time calculations, which in turn 337 effects TCP throughput. 339 Specification: AF-TM4.0 341 1.2.18. Time Out Factor (TOFF) 343 Definition: Refer to TOF. 345 Discussion: none. 347 Specification: AF-TM4.0 348 1.2.19. Trm 350 Definition: An ABR service parameter that provides an upper bound on the 351 time between forward RM-cells for an active source. It is 100 times a 352 power of two with a range of 100*2-7 to 100*20 354 Discussion: For ABR traffic, Trm effects the time rate of change of the 355 ACR. This value effects TCP round trip time calculations, which in turn 356 effects TCP throughput. 358 Specification: AF-TM4.0 360 1.2.20. Virtual Source/Virtual Destination (VSND) 362 Definition: An ABR connection may be divided into two or more separately 363 controlled ABR segments. Each ABR control segment, except the first, is 364 sourced by a virtual source. A virtual source implements the behavior of 365 an ABR source endpoint. Backward RM-cells received by a virtual source 366 are removed from the connection. Each ABR control segment, except the 367 last, is terminated by a virtual destination. A virtual destination 368 assumes the behavior of an ABR destination endpoint. Forward RM-cells 369 received by a virtual destination are turned around and not forwarded to 370 the next segment of the connection. 372 Discussion: none. 374 Specification: AF-TM4.0 376 1.2.21. Xrm Decrease Factor (XDM) 378 Definition: An ABR service parameter, XDF controls the decrease in ACR 379 associated with Xrm. It is a power of two in range: [0, 1]. 381 Discussion: For ABR traffic, XDM effects the time rate of change of the 382 ACR. This value effects TCP round trip time calculations, which in turn 383 effects TCP throughput. 385 Specification: AF-TM4.0 387 1.2.22. Xrm 389 Definition: An ABR service parameter, Xrm limits the number of forward 390 RM- cells which may be sent in the absence of received backward PM- 391 cells. The range is 0-255. 393 Discussion: For ABR traffic, Xrm effects the time rate of change of the 394 ACR. This value effects TCP round trip time calculations, which in turn 395 effects TCP throughput. 397 Specification: AF-TM4.0 399 2. Performance Metrics 401 2. 1. Definition Format (from RFC 1242) 403 Metric to be defined. 405 Definition: The specific definition for the metric. 407 Discussion: A brief discussion of the metric, its application and any 408 restrictions on measurement procedures. 410 Measurement units: Intrinsic units used to quantify this metric. This 411 includes subsidiary units; e.g., microseconds are acceptable if the 412 intrinsic unit is seconds. 414 2.2. Definitions 416 2.2.1. ABR Rate Decrease Response Time (ARDRT) 418 Definition: The amount of time required by the SUT to adjust its 419 transmission rate based on an ABR rate decrease request. 421 Discussion: During the ARDRT, cells transmitted by the SUT may be 422 dropped by the network due to traffic policing. These dropped cells may 423 contain a portion of an IP datagram. This may cause IP and TCP packet 424 loss. 426 Measurement Units: seconds 428 2.2.2. ABR Rate Increase Response Time (ARIRT) 430 Definition: The amount of time required by the SUT to adjust its 431 transmission rate based on an ABR rate increase request. 433 Discussion: During the ARIRT, the SUT will not fully utilize the 434 available bandwidth. This will negatively impact IP and TCP throughput. 436 Measurement Units: seconds 438 2.2.3. RM Cell Loss Ratio (RM-CLR) 440 Definition: The ratio of lost RM cells in a transmission in relation to 441 the total RM cells sent in a transmission associated with a given 442 traffic load, orientation and distribution, as well as an integration 443 period. 445 RM-CLR = Lost RM Cells / Total RM Cells Transmitted. 447 Discussion: RM-CLR may cause the SUT to transmit data cells at a rate 448 larger than the available bandwidth. These data cells may be dropped by 449 the network due to traffic policing. These dropped cells may contain a 450 portion of an IP datagram. This may cause IP and TCP packet loss. 452 It is expressed as an order of magnitude, having a range of 10^-1 to 453 10^- 15 and unspecified. 455 Measurement Units: dimensionless. 457 3. Security Considerations. 459 As this document is solely for providing terminology and describes 460 neither a protocol nor an implementation, there are no security 461 considerations associated with this document. 463 4. Notices 465 Internet Engineering Task Force 467 The IETF takes no position regarding the validity or scope of any 468 intellectual property or other rights that might be claimed to pertain 469 to the implementation or use of the technology described in this 470 document or the extent to which any license under such rights might or 471 might not be available; neither does it represent that it has made any 472 effort to identify any such rights. Information on the IETFs procedures 473 with respect to rights in standards-track and standards-related 474 documentation can be found in BCP-11. Copies of claims of rights made 475 available for publication and any assurances of licenses to be made 476 available, or the result of an attempt made to obtain a general license 477 or permission for the use of such proprietary rights by implementors or 478 users of this specification can be obtained from the IETF Secretariat. 480 The IETF invites any interested party to bring to its attention any 481 copyrights, patents or patent applications, or other proprietary rights, 482 which may cover technology that may be required to practice this 483 standard. Please address the information to the IETF Executive 484 Director. 486 5. Disclaimer 488 Copyright (C) The Internet Society (1999). All Rights Reserved. 490 This document and translations of it may be copied and furnished to 491 others, and derivative works that comment on or otherwise explain it or 492 assist in its implementation may be prepared, copied, published and 493 distributed, in whole or in part, without restriction of any kind, 494 provided that the above copyright notice and this paragraph are included 495 on all such copies and derivative works. However, this document itself 496 may not be modified in any way, such as by removing the copyright notice 497 or references to the Internet Society or other Internet organizations, 498 except as needed for the purpose of developing Internet standards in 499 which case the procedures for copyrights defined in the Internet 500 Standards process must be followed, or as required to translate it into 501 languages other than English. 503 The limited permissions granted above are perpetual and will not be 504 revoked by the Internet Society or its successors or assigns. This 505 document and the information contained herein is provided on an "AS IS" 506 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 507 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 508 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 509 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 510 PARTICULAR PURPOSE. 512 6. References 514 [AF-ILMI4.0] ATM Forum Integrated Local Management Interface Version 515 4.0, af-ilmi-0065.000, September 1996. 517 [AF-TEST-0022] Introduction to ATM Forum Test Specifications, af-test- 518 0022.00, December 1994. 520 [AF-TM4.0] ATM Forum, Traffic Management Specification Version 4.0, af- 521 tm- 0056.00, April 1996. 523 [AF-TM4.1] ATM Forum, Traffic Management Specification Version 4.1 524 (final ballot), btd-tm-01.02, July 1998. 526 [AF-UNI3.1] ATM Forum, User Network Interface Specification Version 3.1, 527 September 1994. 529 [AF-UNI4.0] ATM Forum, User Network Interface Specification Version 4.0, 530 July 1996. 532 7. Editors Addresses 534 Jeffrey Dunn 535 Advanced Network Consultants, Inc. 536 4214 Crest Place, Ellicott City, MD 21043 USA 537 Phone: +1 (410) 750-1700, E-mail: Jeffrey.Dunn@worldnet.att.net 539 Cynthia Martin 540 Advanced Network Consultants, Inc. 541 4214 Crest Place, Ellicott City, MD 21043 USA 542 Phone: +1 (410) 750-1700, E-mail: Cynthia.E.Martin@worldnet.att.net