idnits 2.17.1 draft-ietf-bmwg-atm-term-abr-01.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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 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 194 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 277 instances of too long lines in the document, the longest one being 3 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 115: '... the MUST requirements for t...' RFC 2119 keyword, line 116: '...sfies all the MUST and all the ...' RFC 2119 keyword, line 118: '...atisfies all the MUST requirements but...' RFC 2119 keyword, line 119: '... 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 11 has weird spacing: '... This docum...' == Line 12 has weird spacing: '...-Drafts are ...' == Line 13 has weird spacing: '...cuments of th...' == Line 14 has weird spacing: '...tribute worki...' == Line 18 has weird spacing: '...eted by other...' == (189 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) -- Missing reference section? '0' on line 519 looks like a reference -- Missing reference section? '1' on line 519 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 4 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: September, 2000 ANC, Inc. 5 March, 2000 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. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as work in progress. 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 To view the entire list of current Internet-Drafts, please check the 29 1id- abstracts.txt listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 31 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 32 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 Copyright Notice 36 Copyright (C) The Internet Society (1999). All Rights Reserved. 38 Abstract 40 This memo discusses and defines terms associated with performance 41 benchmarking tests and the results of these tests in the context of 42 Asynchronous Transfer Mode (ATM) based switching devices supporting ABR. 43 The terms defined in this memo will be used in addition to terms defined 44 in RFCs 1242, 2285, and 2544 and 2761. This memo is a product of the 45 Benchmarking Methodology Working Group (BMWG) of the Internet 46 Engineering Task Force (IETF). 48 1. Introduction. 50 This document provides terminology for benchmarking ATM based switching 51 devices supporting ABR. It extends terminology already defined for 52 benchmarking network interconnect devices in RFC's 1242, 2285, and 2544 53 and 2761. Although some of the definitions in this memo may be 54 applicable to a broader group of network interconnect devices, the 55 primary focus of the terminology in this memo is on ATM ABR. 57 This memo contains two major sections: Background and Definitions. The 58 background section provides the reader with an overview of the 59 technology and IETF formalisms. The definitions section is split into 60 two sub- sections. The formal definitions sub-section is provided as a 61 courtesy to the reader. The measurement definitions sub-section 62 contains performance metrics with inherent units. 64 This document assumes that necessary services are available and active. 65 For example, IP connectivity requires SSCOP connectivity between 66 signaling entities. Further, it is assumed that the SUT has the ability 67 to configure ATM addresses (via hard coded addresses, ILMI or PNNI 68 neighbor discovery), has the ability to run SSCOP, and has the ability 69 to perform signaled call setups (via UNI or PNNI signaling). Finally, 70 this document presents only the terminology associated with benchmarking 71 IP performance over ATM; therefore, it does not represent a total 72 compilation of ATM test terminology. 74 The BMWG produces two major classes of documents: Benchmarking 75 Terminology documents and Benchmarking Methodology documents. The 76 Terminology documents present the benchmarks and other related terms. 77 The Methodology documents define the procedures required to collect the 78 benchmarks cited in the corresponding Terminology documents. 80 2. Existing Definitions. 82 RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" 83 should be consulted before attempting to make use of this document. RFC 84 2544 "Benchmarking Methodology for Network Interconnect Devices" 85 contains discussions of a number of terms relevant to the benchmarking 86 of switching devices and should be consulted. RFC 2285 "Benchmarking 87 Terminology for LAN Switching Devices" contains a number of terms 88 pertaining to traffic distributions and datagram interarrival. RFC 2761 89 " Terminology for ATM Benchmarking" contains a number terms pertaining 90 to traffic management [TM4.0, TM4.1]. Many of the metrics defined in 91 RFC 2761 (e.g. CDV, CER, CLR, CMR, and CTD) also apply to ABR 92 performance benchmarking. These metrics will not be redefined in this 93 document. For the sake of clarity and continuity, this RFC adopts the 94 template for definitions set out in Section 2 of RFC 1242. 96 3. Requirements 98 In this document, the words that are used to define the significance of 99 each particular requirement are capitalized. These words are: 101 * "MUST" This word, or the words "REQUIRED" and "SHALL" mean that the 102 item is an absolute requirement of the specification. 104 * "SHOULD" This word or the adjective "RECOMMENDED" means that there may 105 exist valid reasons in particular circumstances to ignore this item, but 106 the full implications should be understood and the case carefully 107 weighed before choosing a different course. 109 * "MAY" This word or the adjective "OPTIONAL" means that this item is 110 truly optional. One vendor may choose to include the item because a 111 particular marketplace requires it or because it enhances the product, 112 for example; another vendor may omit the same item. 114 An implementation is not compliant if it fails to satisfy one or more of 115 the MUST requirements for the protocols it implements. An 116 implementation that satisfies all the MUST and all the SHOULD 117 requirements for its protocols is said to be "unconditionally 118 compliant"; one that satisfies all the MUST requirements but not all the 119 SHOULD requirements for its protocols is said to be "conditionally 120 compliant". 122 II. Definitions 124 The definitions presented in this section have been divided into two 125 groups. The first group is formal definitions, which are required in 126 the definitions of the performance metrics but are not themselves 127 strictly metrics. These definitions are subsumed from other work done 128 in other working groups both inside and outside the IETF. They are 129 provided as a courtesy to the reader. 131 1. Formal Definitions 133 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 trip 153 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 the 160 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 effects 167 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 ATM 194 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 this 203 service, although admitted cells are not delayed unnecessarily. 205 Specification: AF-TM4.1 207 1.2.6. Available Bit Rate (ABR) Compliance (Conformance) 209 Definition: ABR connection conformance refers to the behavior specified for 210 ABR destination and switches, but allows for delays between the source and 211 the UNI [UNI3.1, UNI4.0], which may perturb the traffic flow. 213 Discussion: The cells on an ABR connection applies to CLP=0 cells, which 214 are tested upon arrival. At the arrival point, each cell is identified as 215 conforming or non-conforming. The minimal conformance definition for ABR 216 is GCRA((1/PCR),t1), where PCR is defined for CLP=0 flow. 218 Specification: AF-TM4.1 219 1.2.7. BN 221 Definition: The BN bit in the RM-cell indicated wheather the RM-cell is a 222 BECN cell or not. 224 Discussion: If BN=0, the RM cells were generated by the source. If BN=1, 225 the RM cells were generated by the destination or a switch. 227 Specification: AF-TM4.1 229 1.2.8. CCR 231 Definition: The CCR field in the RM-cell is set by the source to its 232 current ACR. CCR is formatted as a rate. 234 Discussion: For BECN cells, CCR=0. 236 Specification: AF-TM4.1 238 1.2.9. Cell Blocks (CB) 240 Definition: Cell blocks are a sequence of N cells transmitted consecutively 241 on a given connection. 243 Discussion: A cell block will normally correspond to the number of 244 information cells transmitted between successive OAM cells. 246 Specification: AF-TM4.1 248 1.2.10. Congestion Indication (CI) 250 Definition: The CI bit in the RM-cell allows a network element to indicate 251 that there is congestion in the network. 253 Discussion: When the source receives a backward RM-cell with CI=1, ACR is 254 decreased. When the destination turns around a forward RM-cell, the CI is 255 set to 1 to indicate that the previously received data cell had the EFCI 256 state set. 258 Specification: AF-TM4.1 260 1.2.11. Cutoff Decrease Factor (CDF) 261 Definition: CDF controls the decrease in ACR (Allowed Cell Rate) associated 262 with CRM (missing RM cell count). 264 Discussion: For ABR traffic, CDF effects the time rate of change of the 265 ACR. This value effects TCP round trip time calculations, which in turn 266 effects TCP throughput. 268 Specification: AF-TM4.0 270 1.2.12. DIR 272 Definition: The DIR bit in the RM-cell indicates which direction of data 273 flow is associated with the RM-cell. DIR is changed from 0 to 1 when an 274 RM-cell is turned around at the destination. 276 Discussion: A forward RM-cell is indicated by DIR=0 and is associated with 277 data cells flowing in the same direction. A backward RM-cell is indicated 278 by DIR=1 and is associated with data cells flowing in the opposite 279 direction. 281 Specification: AF-TM4.1 283 1.2.13. Explicit Rate (ER) 285 Definition: The ER field in the RM-cell is used to limit the source ACR to 286 a specific value. For each RM-cell, ER is set by the source to a requested 287 rate (e.g. PCR). It may be reduced by any network element in the path to a 288 value that the element can sustain. ER is formatted as a rate. 290 Discussion: None. 292 Specification: AF-TM4.1 294 1.2.14. Feedback 296 Definition: Information carried in the backward RM-cells provided by the 297 network elements and/or the destination back to the source. 299 Discussion: Feedback may include information in the ER field, or the CI or 300 NI bits of each backward RM-cell. 302 Specification: AF-TM4.1 303 1.2.15. Ideal Transmission Time (ITT) 305 Definition: The transmission time for ABR CLP=0 cells, if the difference 306 between itself and the transmission time for the previous CLP=0 cell on the 307 connection is greater than or equal to the minimum: a) the inverse of the 308 ACR in effect immediately after the transmission time of the first of the 309 two cells b) the inverse of the ACR in effect immediately before the 310 transmission time of the second of the two cells. 312 Discussion: The transmission time for the first cell on the connection is 313 automatically an ITT. 315 Specification: AF-TM4.1 317 1.2.16. Initial Cell Rate (ICR) 319 Definition: An ABR service parameter, in cells/sec, that is the rate at 320 which a source should send initially and after an idle period. 322 Discussion: none. 324 Specification: AF-TM4.0 326 1.2.17. In-Rate Cells 328 Definition: In-Rate ABR cells are sent with CLP=0. 330 Discussion: ABR RM-cells shall be sent with CLP=0 except in certain 331 circumstances, See Out-of-Rate Cells. All other ABR cells shall be sent 332 with CLP=0. 334 Specification: AF-TM4.1 336 1.2.18. Minimum Cell Rate (MCR) 338 Definition: An ABR service traffic descriptor, in cells/sec, that is the 339 rate at which the source is always allowed to send. 341 Discussion: MCR may be set to zero. The bandwidth available from the 342 network may vary, but shall not become less than MCR. 344 Specification: AF-TM4.1 345 1.2.19. Mrm 347 Definition: An ABR service parameter that controls allocation of bandwidth 348 between forward W-cells, backward RM-cells, and data cells. 350 Discussion: none. 352 Specification: AF-TM4.0 354 1.2.20. No Increase (NI) 356 Definition: The NI bit in the RM-cell is used to prevent a source from 357 increasing its ACR. NI does not require any decrease in value. 359 Discussion: None. 361 Specification: AF-TM4.0 363 1.2.21. Nrm 365 Definition: An ABR service parameter, Nrm is the maximum number of cells a 366 source may send for each forward RM-cell. 368 Discussion: none. 370 Specification: AF-TM4.0 372 1.2.22. Out-of-Rate Cells 374 Definition: Out-of-Rate ABR cells are sent with CLP=1. 376 Discussion: This may be used to enable a rate increate for a connection 377 that has an ACR=0. The source would generate out-of-rate cells to probe 378 the network to learn when it may increase its rate. 380 Specification: AF-TM4.1 382 1.2.23. Rate Decrease Factor (RDF) 384 Definition: An ABR service parameter, RDF controls the decrease in the cell 385 transmission rate. RDF is a power of 2 from 1/32,768 to 1. 387 Discussion: For ABR traffic, RDF effects the time rate of change of the 388 ACR. This value effects TCP round trip time calculations, which in turn 389 effects TCP throughput. 391 Specification: AF-TM4.0 393 1.2.24. Rate Increase Factor (RIF) 395 Definition: This controls the amount by which the cell transmission rate 396 may increase upon receipt of a RM-cell. The additive increase rate 397 AIR=PCR*RIF. RIF is a power of 2, ranging from 1/32,768 to 1. 399 Discussion: For ABR traffic, RIF effects the time rate of change of the 400 ACR. This value effects TCP round trip time calculations, which in turn 401 effects TCP throughput. 403 Specification: AF-TM4.0 405 1.2.25. Resource Management (RM) Cells 407 Definition: RM cells are used to convey network status (available 408 bandwidth, congestion levels) and request peak cell rates for ATM blocks. 409 The RM cell has the following format: 411 Header: 5 bytes, same as the ATM cell header 412 Protocol ID: 3 bytes, protocol ID value is 1 for ABR service 413 Function specific field: 45 bytes, data required for the specific protocol 414 (See DIR, BN, CI, NI, ER, CCR, and MCR for field information.) 415 Rsvd: 6 bytes, reserved for future specification 416 EDC: 10 bytes, CRC-10 error detection code computed over the cell payload 417 (except the CRC-10 field) and used to check for data corruption 419 Discussion: RM information can exist at the VP and/or VC level. VP level 420 cells are identified with a VCI value of 6. VC level cells are identified 421 with a PT of 6. See DIR, BN, CI, NI, ER, CCR, and MCR for additional 422 protocol field information. 424 Specification: AF-TM4.0 426 1.2.26. Severely Errored Cell Block (SECB) 428 Definition: A severely cell block outcome occurs when more than M errored 429 cells, lost cells, or misinserted cell outcomes are observed in a received 430 cell block. 432 Discussion: none. 434 Specification: AF-TM4.1 436 1.2.27. Tagged Cell Rate (TCR) 438 Definition: An ABR service parameter, TCR limits the rate at which a source 439 may send out-of-rate forward RM-cells. TCR is a constant fixed at 10 440 cells/second. 442 Discussion: none. 444 Specification: AF-TM4.0 446 1.2.28. TDF 448 Definition: An ABR service parameter, TDF controls the decrease in ACR 449 associated with TOF. TDF is signaled as TDFF, where TDF=TDFF/RDF times the 450 smallest power of 2 greater or equal to PCR. TDF is in units of 1/seconds. 452 Discussion: For ABR traffic, TDF effects the time rate of change of the 453 ACR. This value effects TCP round trip time calculations, which in turn 454 effects TCP throughput. 456 Specification: AF-TM4.0 458 1.2.29. TDFF 460 Definition: Refer to TDF. TDFF is either zero or a power of two in the 461 range 1/64 to 1 in units of 1 /cells. 463 Discussion: Refer to TDF. 465 Specification: AF-TM4.0 467 1.2.30. Time Out Factor (TOF) 469 Definition: An ABR service parameter, TOF controls the maximum time 470 permitted between sending forward RM-cells before a rate decrease is 471 required. It is signaled as TOFF where TOF=TOFF+1. TOFF is a power of 2 in 472 the range: 1/8 to 4,096. 474 Discussion: For ABR traffic, TOF effects the time rate of change of the 475 ACR. This value effects TCP round trip time calculations, which in turn 476 effects TCP throughput. 478 Specification: AF-TM4.0 480 1.2.31. Time Out Factor (TOFF) 482 Definition: Refer to TOF. 484 Discussion: none. 486 Specification: AF-TM4.0 488 1.2.32. Trm 490 Definition: An ABR service parameter that provides an upper bound on the 491 time between forward RM-cells for an active source. It is 100 times a power 492 of two with a range of 100*2-7 to 100*20 494 Discussion: For ABR traffic, Trm effects the time rate of change of the 495 ACR. This value effects TCP round trip time calculations, which in turn 496 effects TCP throughput. 498 Specification: AF-TM4.0 500 1.2.33. Virtual Source/Virtual Destination (VSND) 502 Definition: An ABR connection may be divided into two or more separately 503 controlled ABR segments. Each ABR control segment, except the first, is 504 sourced by a virtual source. A virtual source implements the behavior of an 505 ABR source endpoint. Backward RM-cells received by a virtual source are 506 removed from the connection. Each ABR control segment, except the last, is 507 terminated by a virtual destination. A virtual destination assumes the 508 behavior of an ABR destination endpoint. Forward RM-cells received by a 509 virtual destination are turned around and not forwarded to the next segment 510 of the connection. 512 Discussion: none. 514 Specification: AF-TM4.0 516 1.2.34. Xrm Decrease Factor (XDM) 518 Definition: An ABR service parameter, XDF controls the decrease in ACR 519 associated with Xrm. It is a power of two in range: [0, 1]. 521 Discussion: For ABR traffic, XDM effects the time rate of change of the 522 ACR. This value effects TCP round trip time calculations, which in turn 523 effects TCP throughput. 525 Specification: AF-TM4.0 527 1.2.35. Xrm 529 Definition: An ABR service parameter, Xrm limits the number of forward RM- 530 cells which may be sent in the absence of received backward PM-cells. The 531 range is 0-255. 533 Discussion: For ABR traffic, Xrm effects the time rate of change of the 534 ACR. This value effects TCP round trip time calculations, which in turn 535 effects TCP throughput. 537 Specification: AF-TM4.0 539 2. Performance Metrics 541 2. 1. Definition Format (from RFC 1242) 543 Metric to be defined. 545 Definition: The specific definition for the metric. 547 Discussion: A brief discussion of the metric, its application and any 548 restrictions on measurement procedures. 550 Measurement units: Intrinsic units used to quantify this metric. This 551 includes subsidiary units; e.g., microseconds are acceptable if the 552 intrinsic unit is seconds. 554 2.2. Definitions 555 2.2.1. ABR Rate Decrease Response Time (ARDRT) 557 Definition: The amount of time required by the SUT to adjust its 558 transmission rate based on an ABR rate decrease request. 560 Discussion: During the ARDRT, cells transmitted by the SUT may be dropped 561 by the network due to traffic policing. These dropped cells may contain a 562 portion of an IP datagram. This may cause IP and TCP packet loss. 564 Measurement Units: seconds 566 2.2.2. ABR Rate Increase Response Time (ARIRT) 568 Definition: The amount of time required by the SUT to adjust its 569 transmission rate based on an ABR rate increase request. 571 Discussion: During the ARIRT, the SUT will not fully utilize the available 572 bandwidth. This will negatively impact IP and TCP throughput. 574 Measurement Units: seconds 576 2.2.3. RM-Cell Delay Variation (RM-CDV) 578 Definition: The variation in RM-cell transfer delay (RM-CTD) of RM-cells 579 associated with a given traffic load, orientation and distribution, as well 580 as an integration period. RM-CDV = max (RM-CTD) - min (RM-CTD) where max 581 and min indicate the maximum and minimum over the integration period, 582 respectively. 584 Discussion: RM-CDV is a component of RM-cell transfer delay, induced by 585 buffering and RM-cell scheduling. 587 RM-CDV effects the time required to notify the source of a change in the 588 condition of the network. This in turn effects TCP round trip time 589 calculations. Large values of RM-CDV will adversely effect TCP throughput 590 and cause SAR timeout. 592 Measurement Units: seconds 594 2.2.4. RM-Cell Error Ratio (RM-CER) 596 Definition: The ratio of RM-cells with payload errors in a transmission in 597 relation to the total number of RM-cells sent in a transmission associated 598 with a given traffic load, orientation and distribution, as well as an 599 integration period. Note that errors occurring in the RM-cell header will 600 cause RM-cell loss at the ATM layer. Note further that multiple errors in 601 a payload will only be counted as one cell payload error. 603 RM-CER = RM-Cells with payload errors / Total RM-Cells Transmitted. 605 Discussion: The measurement is taken over a time interval and is desirable 606 to be measured on an in-service circuit. RM-CER effects the time required 607 to notify the source of a change in the condition of the network. This in 608 turn effects TCP round trip time calculations. Large values of RM-CER will 609 adversely effect TCP throughput and cause SAR timeout. 611 Measurement Units: dimensionless. 613 2.2.5. RM-Cell Loss Ratio (RM-CLR) 615 Definition: The ratio of lost RM-cells in a transmission in relation to the 616 total RM-cells sent in a transmission associated with a given traffic load, 617 orientation and distribution, as well as an integration period. 619 RM-CLR = Lost RM-Cells / Total RM-Cells Transmitted. 621 Discussion: The objective is to minimize RM-CLR. It is expressed as an 622 order of magnitude, having a range of 10^-1 to 10^-15 and unspecified. 624 RM-CLR effects the time required to notify the source of a change in the 625 condition of the network. This in turn effects TCP round trip time 626 calculations. Large values of RM-CLR will adversely effect TCP throughput 627 and cause SAR timeout. 629 Measurement Units: dimensionless. 631 2.2.6. RM-Cell Misinsertion Ratio (RM-CMR) 633 Definition: The ratio of RM-cells received at an endpoint that were not 634 originally transmitted by the source end in relation to the total number of 635 RM-cells properly transmitted associated with a given traffic load, 636 orientation and distribution, as well as an integration period. 638 RM-CMR = Misinserted RM-Cells / Total RM-Cells Transmitted. 640 Discussion: The measurement is taken over a time interval and is desirable 641 to be measured on an in-service circuit. 643 RM-CMR effects the time required to notify the source of a change in the 644 condition of the network. This in turn effects TCP round trip time 645 calculations. Large values of RM-CMR will adversely effect TCP throughput 646 and cause SAR timeout. 648 Measurement Units: dimensionless. 650 2.2.7. RM-CRC Error Ratio 652 Definition: The ratio of RM-cells received at an endpoint which contain an 653 invalid CRC in relation to the total number of RM-cells properly 654 transmitted associated with a given traffic load, orientation and 655 distribution, as well as an integration period. 657 Discussion: RM-CRC errors cause ATM RM-cells to be lost. 659 RM-CRC effects the time required to notify the source of a change in the 660 condition of the network. This in turn effects TCP round trip time 661 calculations. Large values of RM-CRC will adversely effect TCP throughput 662 and cause SAR timeout. 664 Measurement Units: dimensionless 666 2.2.8. RM-Cell Transfer Delay (RM-CTD) 668 Definition: The elapsed time between a RM-cell exit event at the 669 measurement point 1 (e.g., at the source UNI) and the corresponding RM- 670 cell entry event at a measurement point 2 (e.g., the destination UNI) for a 671 particular connection. 673 Discussion: The RM-cell transfer delay between two measurement points is 674 the sum of the total inter-ATM node transmission delay and the total ATM 675 node processing delay. This number is a constant and should not adversely 676 effect performance. 678 Measurement units: seconds 679 2.2.9. Severely Errored Cell Block Ratio (SECBR) 681 Definition: The ratio of severely errored cell blocks in a transmission in 682 relation to the total cell blocks sent in a transmission associated with a 683 given traffic load, orientation and distribution, as well as an integration 684 period. 686 SECBR = Severely Errored Cell Blocks/Total Transmitted Cell Blocks 688 Discussion: SECBR may cause the SUT to drop cells that may contain a 689 portion of an IP datagram. This may cause IP and TCP packet loss. 691 Measurement Units: dimensionless. 693 3. Security Considerations. 695 As this document is solely for providing terminology and describes 696 neither a protocol nor an implementation, there are no security 697 considerations associated with this document. 699 4. Notices 701 Internet Engineering Task Force 703 The IETF takes no position regarding the validity or scope of any 704 intellectual property or other rights that might be claimed to pertain 705 to the implementation or use of the technology described in this 706 document or the extent to which any license under such rights might or 707 might not be available; neither does it represent that it has made any 708 effort to identify any such rights. Information on the IETFs procedures 709 with respect to rights in standards-track and standards-related 710 documentation can be found in BCP-11. Copies of claims of rights made 711 available for publication and any assurances of licenses to be made 712 available, or the result of an attempt made to obtain a general license 713 or permission for the use of such proprietary rights by implementors or 714 users of this specification can be obtained from the IETF Secretariat. 716 The IETF invites any interested party to bring to its attention any 717 copyrights, patents or patent applications, or other proprietary rights, 718 which may cover technology that may be required to practice this 719 standard. Please address the information to the IETF Executive 720 Director. 722 5. Disclaimer 724 Copyright (C) The Internet Society (1999). All Rights Reserved. 726 This document and translations of it may be copied and furnished to 727 others, and derivative works that comment on or otherwise explain it or 728 assist in its implementation may be prepared, copied, published and 729 distributed, in whole or in part, without restriction of any kind, 730 provided that the above copyright notice and this paragraph are included 731 on all such copies and derivative works. However, this document itself 732 may not be modified in any way, such as by removing the copyright notice 733 or references to the Internet Society or other Internet organizations, 734 except as needed for the purpose of developing Internet standards in 735 which case the procedures for copyrights defined in the Internet 736 Standards process must be followed, or as required to translate it into 737 languages other than English. 739 The limited permissions granted above are perpetual and will not be 740 revoked by the Internet Society or its successors or assigns. This 741 document and the information contained herein is provided on an "AS IS" 742 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 743 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 744 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 745 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 746 PARTICULAR PURPOSE. 748 6. References 750 [AF-TM4.0] ATM Forum, Traffic Management Specification Version 4.0, af- 751 tm-0056.00, April 1996. 753 [AF-TM4.1] ATM Forum, Traffic Management Specification Version 4.1, af- 754 tm- 0121.000, March 1999. 756 [AF-UNI3.1] ATM Forum, User Network Interface Specification Version 3.1, 757 September 1994. 759 [AF-UNI4.0] ATM Forum, User Network Interface Specification Version 4.0, 760 July 1996. 762 7. Editors Addresses 763 Jeffrey Dunn 764 Advanced Network Consultants, Inc. 765 4214 Crest Place, Ellicott City, MD 21043 USA 766 Phone: +1 (410) 750-1700, E-mail: Jeffrey.Dunn@worldnet.att.net 768 Cynthia Martin 769 Advanced Network Consultants, Inc. 770 4214 Crest Place, Ellicott City, MD 21043 USA 771 Phone: +1 (410) 750-1700, E-mail: Cynthia.E.Martin@worldnet.att.net