Network Working Group J. Dunn Request for Comments: 2761 C. Martin Category: Informational ANC, Inc. February 2000 Terminology for ATM Benchmarking Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractThis memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices. The terms defined in this memo will be used in addition to terms defined in RFCs 1242, 2285, and 2544. This memo is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF). Introduction This document provides terminology for benchmarking ATM based switching devices. It extends terminology already defined for benchmarking network interconnect devices in RFCs 1242, 2285, and 2544. Although some of the definitions in this memo may be applicable to a broader group of network interconnect devices, the primary focus of the terminology in this memo is on ATM cell relay and signaling. This memo contains two major sections: Background and Definitions. Within the definitions section is a formal definitions subsection, provided as a courtesy to the reader, and a measurement definitions sub-section, that contains performance metrics with inherent units. The divisions of the measurement sub-section follow the BISDN model.
The BISDN model comprises four layers and two planes. This document addresses the interactions between these layers and how they effect IP and TCP throughput. A schematic of the B-ISDN model follows: ---------|--------------------------|------------------------------- | User Plane | Control Plane ---------|--------------------------|-------------------------------- Services | IP | ILMI | UNI, PNNI ---------|--------------------------|----------|--------------------- AAL | AAL1, AAL2, AAL3/4, AAL5 | AAL5 | SAAL ---------|--------------------------|----------|--------------------- ATM | Cell Relay | OAM, RM ---------|--------------------------|-------------------------------- | Convergence | Physical |--------------------------|-------------------------------- | Media | ---------|--------------------------|-------------------------------- This document assumes that necessary services are available and active. For example, IP connectivity requires SSCOP connectivity between signaling entities. Further, it is assumed that the SUT has the ability to configure ATM addresses (via hard coded addresses, ILMI or PNNI neighbor discovery), has the ability to run SSCOP, and has the ability to perform signaled call setups (via UNI or PNNI signaling). This document covers only CBR, VBR and UBR traffic types. ABR will be handled in a separate document. Finally, this document presents only the terminology associated with benchmarking IP performance over ATM; therefore, it does not represent a total compilation of ATM test terminology. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. Existing Definitions RFC 1242, "Benchmarking Terminology for Network Interconnect Devices" should be consulted before attempting to make use of this document. RFC 2544, "Benchmarking Methodology for Network Interconnect Devices" contains discussions of a number of terms relevant to the benchmarking of switching devices and should be consulted. RFC 2285, "Benchmarking Terminology for LAN Switching Devices" contains a number of terms pertaining to traffic distributions and datagram interarrival. For the sake of clarity and continuity, this RFC adopts the template for definitions set out in Section 2 of RFC 1242. Definitions are indexed and grouped together in sections for ease of
reference. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" go in this document are to be interpreted as described in RFC 2119. Definitions The definitions presented in this section have been divided into two groups. The first group is formal definitions, which are required in the definitions of the performance metrics but are not themselves strictly metrics. These definitions are subsumed from other work done in other working groups both inside and outside the IETF. They are provided as a courtesy to the reader.
These AAL types are not measurements, but it is possible to measure the time required for Segmentation and Reassembly (SAR). Specification: I.363
SAR). Specification: I.363.5
Discussion: The effects of each traffic parameter will be discussed individually. Specification: AF-UNI3.1
Discussion: CAC is based on the ATM traffic descriptor (see ATM traffic descriptor) associated with the call as well as the presented and existing load. It may also be based on administrative policies such as calling party number required or access limitations. The effect on performance of these policies is beyond the scope of this document and will be handled in the BMWG document: Benchmarking Terminology for Firewall Performance. Specification: AF-UNI3.1
MBS, PCR and SCR). Specification: AF-TM4.0
produce only a small, constant delay; however, in core computation will produce variable delay, which will negatively effect TCP RTT computations. This situation is further complicated by the location of the CRC-32 calculation. Given an in core CRC-32 calculation, bus contention may cause on board SAR to be slower than in core SAR. Clearly, on board CRC-32 calculation and SAR will produce the most favorable performance results. SAR performance will also be effected by ATM layer impairments. Cell error (CE), cell loss(CL), cell mis-insertion (CM) and cell delay variation (CDV) will all negatively effect SAR. CE will cause an AAL5 PDU to fail the CRC-32 check and be discarded, thus discarding the packet which the PDU contained. CL and CM will both cause an AAL5 PDU to fail the length check and be discarded. CL can have other effects depending on whether the cell which was lost is the final cell (PTI=1) of the AAL5 PDU. The following discussion enumerates the possibilities. 1. PTI=0 cell is lost. In this case, re-assembly registers a length discrepancy and discards the PDU. 2. PTI=1 cell is lost. 2. A. The AAL5 re-assembly timer expires before the first cell, PTI=0, of the next AAL5 PDU arrives. The AAL5 PDU with the missing PTI=1 cell is discarded due to re-assembly timeout and one packet is lost. 2. B. The first cell of the next AAL5 PDU arrives before the re- assembly timer expires. The AAL5 with the missing PTI=1 cell is prepended to the next AAL5 PDU in the SAR engine. This yields two possibilities: 2. B. i. The AAL5 re-assembly timer expires before the last cell, PTI=1, of the next AAL5 PDU arrives. The AAL5 PDU with the missing PTI=1 cell and the next AAL5 PDU are discarded due to re-assembly timeout and two packets are lost. 2. B. ii. The last cell of the next AAL5 PDU arrives before the re- assembly timer expires. In this case, AAL5 registers a length discrepancy and discards the PDU; therefore, the AAL5 PDU with the missing PTI=1 cell and the next AAL5 PDU are discarded due to their concatenation and two packets are lost.
2. C. Coupled with re-assembly, there exists some mechanism for identifying the start of a higher layer PDU, e.g., IP, and the cells associated with the first incomplete AAL5 PDU are discarded, resulting in the loss of one packet. Specification: AF-UNI3.1
actions taken by the network to minimize the intensity, spread and duration of congestion. The following functions form a framework for managing and controlling traffic and congestion in ATM networks and may be used in appropriate combinations. Connection Admission Control Feedback Control Usage Parameter Control Priority Control Traffic Shaping Network Resource Management Frame Discard ABR Flow Control Discussion: See CAC and traffic shaping. Specification: AF-TM4.0
Discussion: TC is not a measurement, but the speed in which TC can occur on a bit stream can be measured. This measurement will not be discussed in this document; however, its value should be constant and small with respect to cell inter-arrival at the maximum data rate. Specification: AF-UNI3.1 RFC 2331 specifies UBR service class for IP over ATM. UBR service models the "best effort" service type specified in RFC 791; however, UBR has specific drawbacks with respect to TCP service. Since UBR makes no guarantee with respect to cell loss (CL), cell delay variation (CDV) or cell mis-insertion(CM), TCP RTT estimates will be highly variable. Further, all negatively impact AAL5 re- assembly, which in turn may cause packet loss. See discussions under CDV and SAR. Specification: AF-TM4.0
Discussion: none. Specification: AF-UNI3.1
Measurement units: Intrinsic units used to quantify this metric. This includes subsidiary units; e.g., microseconds are acceptable if the intrinsic unit is seconds.
2. Multiple cells in the AAL5 PDU contain payload errors. In this case, there is not a one-to-one correspondence between cell payload errors and the number of corrupted AAL5 PDUs. Measurement Units: dimensionless.
1. Only one cell is mis-inserted into an AAL5 PDU. In this case, there is a one-to-one correspondence between cell mis-insertion and the number of corrupted AAL5 PDUs. 2. Multiple cells are mis-inserted into an AAL5. In this case, there is not a one-to-one correspondence between cell mis-insertion and the number of corrupted AAL5 PDUs. Measurement Units: dimensionless.
Discussion: The cell transfer delay between two measurement points is the sum of the total inter-ATM node transmission delay and the total ATM node processing delay. While this number is a constant and should not adversely effect performance, it is a component in RTT. Measurement units: seconds
See discussion under SVC. Measurement Units: seconds
[AF-ILMI4.0] ATM Forum Integrated Local Management Interface Version 4.0, af-ilmi-0065.000, September 1996. [AF-TEST-0022] Introduction to ATM Forum Test Specifications, af- test-0022.00, December 1994. [AF-TM4.0] ATM Forum, Traffic Management Specification Version 4.0, af-tm-0056.00, April 1996. [AF-TM4.1] ATM Forum, Traffic Management Specification Version 4.1 (final ballot), btd-tm-01.02, July 1998. [AF-UNI3.1] ATM Forum, User Network Interface Specification Version 3.1, September 1994. [AF-UNI4.0] ATM Forum, User Network Interface Specification Version 4.0, July 1996.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.