idnits 2.17.1 draft-ietf-bmwg-call-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (March 1997) is 9896 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) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Craig 2 INTERNET-DRAFT Cisco Systems 3 Expires in six months March 1997 5 Terminology for Cell/Call Benchmarking 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 22 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 The purpose of this draft is to add terminology specific to the cell 29 and call-based switch environment to that defined by the Benchmarking 30 Methodology Working Group (BMWG) of the Internet Engineering Task 31 Force (IETF) in RFC1242. 33 While primarily directed towards wide area switches, portions of the 34 document may be useful for benchmarking other devices such as ADSU's. 36 1. Introduction 38 In light of the increasing use of cell-based and/or circuit-switched 39 transport layers in building networks, it would be useful to develop 40 a set of benchmarks with which to compare technologies, 41 implementation strategies, and products. 43 1.1 Terminology Brought Forward 45 The terminology defined in RFC 1242 applies equally well to this 46 memo. There is also a certain amount of overlap with terms 47 defined in draft-ietf-bmwg-lanswitch-00.txt. 49 2. Definition Format (from RFC1242) 51 Term to be defined. 53 Definition: 54 The specific definition for the term. 56 Discussion: 57 A brief discussion of the term, its application and any 58 restrictions on measurement procedures. 60 Measurement units: 61 Units used to record measurements of this term, if applicable. 63 3. Term Definitions 65 3.1 Virtual Circuit 67 This group applies to those switches that are connection-oriented. 69 3.1.1 Call setup time 71 Definition: the length of time for the virtual circuit to be 72 established. 74 Discussion: as measured from the initiation of the signalling to 75 circuit establishment. 77 Measurement units: fractional seconds 79 Issues: 81 See also: 83 3.1.2 Call setup rate (sustained) 85 Definition: the maximum sustained rate of successful connection 86 establishment. 88 Discussion: without loss of existing calls. 90 Measurement units: calls per second 92 Issues: 94 See also: 96 3.1.3 Call maintenance overhead 97 Definition: the amount of work required to maintain the calls 98 that have been established. 100 Discussion: a method to obtain the desired result would be to 101 benchmark with PVC's in place, then with SVC's. The difference in 102 results would be the overhead. 104 Measurement units: 106 Issues: 108 See also: 110 3.1.4 Call teardown time 112 Definition: the length of time for the virtual circuit to be torn 113 down. 115 Discussion: measured from the start of the signalling to the 116 freeing of the resources associated with that call (end to end, if 117 applicable). 119 Measurement units: fractional seconds 121 Issues: 123 See also: 125 3.1.5 Call teardown rate (sustained) 127 Definition: the maximum rate at which calls can be successfully 128 torn down. 130 Discussion: without loss of existing calls, and without failure 131 to tear down any calls that have been signalled to be destroyed. 133 Measurement units: teardowns per second 135 Issues: 137 See also: 139 3.1.6 Impact of Signalling on Forwarding 141 Definition: cells per second versus calls per second 143 Discussion: some devices use the same engine for cell forwarding 144 and call maintenance. In this case, interaction between the two 145 functions will be inevitable. More interesting, however, would be 146 the case where the two processing functions are clearly separate, 147 yet still interact. 149 Measurement units: cells per second versus calls per second 151 Issues: 153 See also: 155 3.2 Cell/Packet Interaction 157 This group applies to cell-based switches, connection-oriented or 158 not. 160 3.2.1 Packet disassembly/reassembly time (peak) 162 Definition: the length of time to disassemble a layer 3 packet 163 into layer 2 cells, or reassemble cells into a packet. 165 Discussion: with no packet or cell loss or corruption. To arrive 166 at a baseline, one could measure the switching rate for cells 167 derived from ~1440 byte frames which are flowing across the switch 168 as cells, then forward those same frames into the switch from an 169 interface which would require them to be disassembled. For 170 example, the baseline measurement is taken while switching cells 171 OC3-OC3. Then switch FDDI or POS-OC3 and take the delta in 172 performance as the SAR overhead. 174 Measurement units: the appropriate fraction of a second 176 Issues: 178 See also: 180 3.2.2 Packet disassembly/reassembly rate (sustained) 182 Definition: the maximum sustained rate at which packets can be 183 disassembled/reassembled into/from cells. 185 Discussion: without loss or corruption. 187 Measurement units: packets per second 189 Issues: 191 See also: 193 3.2.3 Full packet drop rate (on cell loss) 195 Definition: the rate at which cell loss triggering full packet 196 drop can be detected/sustained. 198 Discussion: When a packet is disassembled into cells, typically 199 many cells result. When these cells are transmitted, they are 200 subject to loss or corruption. The device should recognize at the 201 cell/packet boundary that a cell or cells belonging to a given 202 packet has been lost and should drop that packet, immediately 203 freeing those resources. A couple of things are of interest here: 204 whether the switch is able to detect very small amounts of cell 205 loss and correctly drop the associated packets and whether large 206 amounts of cell loss perturb this ability in any way. 208 Measurement units: (dropped) packets per second 210 Issues: 212 See also: 214 3.2.4 End to end data integrity 216 Definition: the percentage of packets (post-reassembly) that 217 actually contain undetected data link layer corruption. 219 Discussion: some network devices have been known to regenerate 220 CRC's over the re-assembled packet (i.e., the CRC is not carried 221 end to end), resulting in undetected data link layer corruption or 222 re-ordering of cells in a packet. 224 Measurement units: percentage 226 Issues: production of a stream of traffic containing internal 227 checksums sufficiently strong to detect cell re-ordering (the IP 228 checksum is not). The ISIS LSP checksum is. 230 See also: 232 3.3 Switch Fabric 234 This group applies to all switches. 236 3.3.2 Topology Table Size 238 Definition: number of network elements supported. 240 Discussion: switches may support a limited topology due to static 241 table sizes or processing limitations. This is true whether it's 242 a "LAN" switch running spanning tree or a "WAN" switch running 243 OSPF. The effect of a limited topology table on a switch in a 244 real-world environment can be disastrous. 246 A similar metric (2.14 Address handling) is mentioned in "draft- 247 ietf-bmwg-lanswitch-00.txt". Here, a more general metric is 248 intended. 250 Measurement units: number 252 Issues: Measuring the effects of an overflow is probably 253 meaningless, since in the multi-switch case, there is no longer 254 any network to speak of, hence, nothing to measure. 256 If a device handles table overflow gracefully, this should be 257 noted. Similarly, if a device crashes and burns on table 258 overflow, this should be noted. 260 See also: 262 3.3.3 Topology Table Learning Rate 264 Definition: the rate at which the topology table can be filled or 265 updated. 267 Discussion: a single switch in isolation learning MAC addresses 268 will flood frames when the rate exceeds its learning capability. 269 This metric is covered in "2.15 Address learning speed" of 270 "draft-ietf-bmwg-lanswitch-00.txt". We generalize the metric here 271 to include the topological databases of routing protocols used in 272 switched networks (among the switches themselves) as well as the 273 spanning tree recalculation among multiple LAN switches. 275 Measurement units: frames per second 1) with maximum diversity of 276 addresses, 2) with routing instability introduced. 278 Issues: 280 See also: 282 3.3.5 Throughput (from RFC1242) (Cell forwarding rate) 284 Definition: The maximum rate at which none of the offered frames 285 are dropped by the device. 287 Discussion: This metric probably overlaps work being done in the 288 ATM Forum. 290 Measurement units: cells per second 292 Issues: 294 See also: 296 3.3.6 Blocking Probability 298 Definition: likelihood of successful simultaneous communication 299 amongst multiple ports. 301 Discussion: a switch is termed "non-blocking" if multiple ports 302 are able to communicate across the switch fabric at the same time. 303 We are interested in the probability of blocking occurring in the 304 1:1, N:1, and N:M scenarios. 306 One may calculate the "ideal" throughput in the absence of 307 blocking, then take the delta with the experimental case and treat 308 that as an empirical measurement of blocking probability, if 309 enough samples are taken. 311 Measurement units: percentage likelihood of blocking. 313 Issues: 315 See also: 317 3.5 Congestion Control 319 This group applies to all switches. 321 3.5.1 Congestion avoidance 323 Definition: effectiveness of measures taken by the switch to 324 avoid congestion. 326 Discussion: connections that are bursting above their committed 327 rate may have cells buffered at the ingress, in order to avoid 328 congestion in the trunks and impact on other connections, or they 329 may simply be marked "discard-eligible" and forwarded into the 330 network, hoping for the best. 332 Distinguishing between these two approaches should be relatively 333 simple. In the first case, latency for the bursting session 334 increases, but there is no cell loss. Other sessions are 335 unaffected. In the second case, there may be cell loss across any 336 of the sessions, and latency may increase across all. 338 Measurement units: dropped cells, latency 340 Issues: 342 See also: 344 3.5.2 Congestion management 346 Definition: effectiveness of measures taken by the switch to deal 347 with congestion. 349 Discussion: in the face of sustained traffic above committed rate 350 on multiple sessions, a switch has little choice but to begin 351 discarding cells, since buffering cannot be infinite. This case 352 might arise if one were wildly profligate in over-subscribing 353 trunk bandwidth, or if one had neglected to analyze the network 354 applications to be run over the network and they were found to be 355 network-hostile (UDP, IPX, AT, NetBIOS, for example). 357 The switch has some discretion in deciding which cells to drop. 358 Presumably, the strategy should involve something resembling 359 "fairness". 361 The basic idea is that ill-behaved connections should not starve 362 others for resources. 364 Measurement units: latency, cell drops 366 Issues: 368 See also: 370 3.6 Inter-switch protocols 372 This group applies to all switches. 374 3.6.1 Impact of Routing on Forwarding 376 Definition: interaction between routing protocol and data 377 forwarding operations. 379 Discussion: No amount of routing fluctuation should have an 380 impact on data forwarding for unaffected destinations. Similarly, 381 no amount of data forwarding should cause the routing to become 382 unstable. 384 Measurement units: route flaps per second versus cells per 385 second, cells per second versus route stability (table fluctuation 386 or peer loss). 388 Issues: 390 See also: 392 3.6.2 Impact of Congestion Control 394 Definition: interaction between congestion control and data 395 forwarding operations. 397 Discussion: switches may share views of congestion in-band 398 through the network. Should these feedback messages be delayed or 399 lost, the potential exists for an incorrect picture of current 400 network conditions, which may exacerbate congestion and lead to 401 cell loss. Worse, it is possible to enter a stable oscillation 402 state, where ever-increasing waves of congestion overwhelm the 403 switches. 405 Measurement units: 407 Issues: 409 See also: 411 3.7 Quality of Service 413 This group applies to all switches. 415 3.7.1 Traffic Management Policing 417 Definition: impact of misbehaving class on others, for example 418 data forwarding on voice or video frames and vice versa. 420 Discussion: we wish to quantify the potential interaction amongst 421 the various classes of service. Constant bit rate (CBR), variable 422 bit rate (VBR) (real and non-real time?), and available bit rate 423 (ABR) streams are established, within their respective service 424 levels, but sufficient to subscribe the trunk to 90%. The bit 425 rate of each is increased until it has exceeded its allocation by 426 a degree which should cause loss or delay in the other streams. 428 Measurement units: cells (lost) per second, latency 430 Issues: some switches perform compression and silence 431 suppression. Should these features be disabled? 433 See also: 435 3.8 Multicast 437 3.8.1 Cell replication 439 Definition: the device's ability to forward a cell to multiple 440 ports simultaneously (multicast). 442 Discussion: 444 Measurement units: replication factor 1:N and cells per second 445 measured at ingress versus cells per second measured at the 446 egresses. 448 Issues: 450 See also: 452 3.8.2 Impact of multicast on unicast 454 Definition: switch's ability to insulate unicast traffic from the 455 effects of multicast. 457 Discussion: a poorly-designed replication scheme could easily 458 swamp unicast traffic. Yet, multicast traffic often has QoS 459 needs. How does one reconcile the competing requirements? 461 Measurement units: cell loss, delay 463 Issues: 465 See also: 467 Security Considerations 469 Security issues are not addressed in this memo. 471 Editor's Address 473 Robert Craig 474 Cisco Systems 475 7025 Kit Creek Road 476 PO Box 14987 477 Research Triangle Park, NC 27709 478 (919) 472-2886 479 rcraig@cisco.com