idnits 2.17.1 draft-ietf-bmwg-mcast-02.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-26) 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 6 longer pages, the longest (page 3) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 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 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. 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 (July 1997) is 9782 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) == Unused Reference: '1' is defined on line 395, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 398, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 401, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. '1') ** Obsolete normative reference: RFC 1944 (ref. '2') (Obsoleted by RFC 2544) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Dubray 2 INTERNET-DRAFT Bay Networks 3 Expiration Date: January 1998 July 1997 5 Terminology for IP Multicast 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 view the entire list of current Internet-Drafts, please check 21 the "1id-abstracts.txt" listing contained in the Internet-Drafts 22 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 23 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 24 Coast), or ftp.isi.edu (US West Coast). 26 This memo provides information for the Internet community. This memo 27 does not specify an Internet standard of any kind. Distribution of 28 this memo is unlimited. 30 Abstract 32 The purpose of this draft is to add terminology specific to the 33 benchmarking of multicast IP forwarding devices. It builds upon the 34 tenets set forth in RFC 1242, RFC 1944, and other IETF Benchmarking 35 Methodology Working Group (BMWG) effort and extends them to the 36 multicast paradigm. 38 1. Introduction 40 Network forwarding devices are being required to take a single 41 frame and support delivery to a number of destinations having 42 membership to a particular group. As such, multicast support may 43 place a different burden on the resources of these network 44 forwarding devices than with unicast or broadcast traffic types. 46 By clearly identifying benchmarks and related terminology in this 47 document, it is hoped that detailed methodologies can be generated 48 in subsequent documents. Taken in tandem, these two efforts 49 endeavor to assist the clinical, empirical, and consistent 50 characterization of certain aspects of multicast technologies and 51 their individual implementations. 53 [While primarily directed towards intermediate IP multicast 54 forwarding devices on LANs, elements of this text may or may not be 55 applicable to other media as well.] 57 2. Definition Format 59 This section cites the template suggested by RFC 1242 in the 60 specification of a term to be defined. 62 Term to be defined. 64 Definition: 65 The specific definition for the term. 67 Discussion: 68 A brief discussion of the term, its application and any 69 restrictions on measurement procedures. 71 Measurement units: 72 Units used to record measurements of this term, if applicable. 74 [Issues:] 75 List of issues or conditions that effect this term. This 76 field is optional in this draft. 78 [See Also:] 79 List of other terms that are relevant to the discussion 80 of this term. This field is optional in this draft. 82 2.1 Existing Terminology 84 This document draws on existing terminology defined in other 85 BMWG work. Examples include, but are not limited to: 87 Throughput (RFC 1242, section 3.17) 88 Latency (RFC 1242, section 3.8) 89 Constant Load (RFC 1242, section 3.4) 90 Frame Loss Rate (RFC 1242, section 3.6) 91 Overhead behavior (RFC 1242, section 3.11) 92 Forwarding Rates ([4], section 3.6) 93 Loads ([4], section 3.5) 94 Devices ([4], section 3.1) 96 3. Table of Defined Terms 98 3.1 General Nomenclature 99 3.1.1 Traffic Class. 100 3.1.2 Group Class. 101 3.1.3 Service Class. 103 3.2 Forwarding and Throughput 104 3.2.1 Mixed Class Throughput (MCT). 105 3.2.2 Scaled Group Forwarding Matrix (SGFM). 107 3.2.3 Aggregated Multicast Throughput (AMT) 108 3.2.4 Translational Throughput (TT) 110 3.3 Fairness 112 3.4 Forwarding Latency 113 3.4.1 Multicast Latency 114 3.4.2 Min/Max Multicast Latency 116 3.5 Overhead 117 3.5.1 Group Join Delay. 118 3.5.2 Group Leave Delay. 120 3.6 Capacity 121 3.6.1 Multicast Group Capacity. 123 3.1 General Nomenclature 124 This section will present general terminology to be used in 125 this and other documents. 127 3.1.1 Traffic Class. 129 Definition: 130 An equivalence class of packets comprising one or more data 131 streams. 133 Discussion: 134 In the scope of this document, Traffic Class will be considered 135 a logical identifier used to discriminate between a set or sets 136 of packets offered the DUT. 138 For example, one Traffic Class may identify a set of unicast packets 139 offered to the DUT. Another Traffic Class may differentiate the 140 multicast packets destined to multicast group X. Yet another 141 Class may distinguish the set of multicast packets destined to 142 multicast group Y. 144 Unless otherwise qualified, the usage of the word "Class" in this 145 document will refer simply to a Traffic Class. 147 Measurement units: 148 Not applicable. 150 3.1.2 Group Class. 152 Definition: 153 A specific type of Traffic Class where the packets comprising the Class 154 are destined to a particular multicast group. 156 Discussion: 158 Measurement units: 159 Not applicable. 161 3.1.3 Service Class. 163 Definition: 164 A specific type of Traffic Class where the packets comprising the Class 165 require particular treatment or treatments by the network 166 forwarding devices along the path to the packets' destination(s). 168 Discussion: 170 Measurement units: 171 Not applicable. 173 3.2 Forwarding and Throughput. 175 This section presents terminology relating to the characterization of 176 the packet forwarding ability of a DUT/SUT in a multicast environment. 177 Some metrics extend the concept of throughput presented in RFC 1242. 179 3.2.1 Mixed Class Throughput (MCT). 181 Definition: 182 The maximum rate at which none of the offered frames, comprised 183 from a unicast Class and a multicast Class, to be forwarded are 184 dropped by the device. 186 Discussion: 187 Often times, throughput is collected on a homogenous traffic 188 type - though the packets' destinations may vary, the packets 189 follow the same packet forwarding path through the DUT. 191 Based on the RFC 1242 definition for throughput, the Mixed 192 Class Throughput benchmark attempts to characterize the DUT's 193 ability to process both unicast and multicast frames in the 194 same aggregated traffic stream. 196 Measurement units: 197 Frames per second 199 Issues: 200 Related methodology may have to address the ratio of unicast packets 201 to multicast packets. 203 3.2.2 Scaled Group Forwarding Matrix (SGFM). 205 Definition: 206 A table that demonstrates Forwarding Rate as a function of 207 tested multicast groups for a fixed number of tested 208 DUT/SUT ports. 210 Discussion: 211 A desirable attribute of many Internet mechanisms is the ability 212 to "scale." This benchmark seeks to demonstrate the ability 213 of a SUT to forward as the number of multicast groups is scaled 214 upwards. 216 Measurement units: 217 Packets per second, with corresponding tested multicast group 218 and port configurations. 220 Issues: 221 The corresponding methodology (or even the definition itself) may 222 have to reflect the impact that the pairing (source, group) has on 223 many multicast routing protocols. 225 Refers to the concept of Forwarding Rate originally defined in 226 this document. The definition of Forwarding Rate has been 227 moved to [4]. 229 3.2.3 Aggregated Multicast Throughput (AMT) 231 Definition: 232 The maximum rate at which none of the offered frames to be 233 forwarded through N destination interfaces of the same multicast 234 group are dropped. 236 Discussion: 237 Another "scaling" type of exercise, designed to identify the 238 DUT/SUT's ability to handle traffic as a function of the 239 multicast destination ports it is required to support. 241 Measurement units: 242 The ordered pair (N,t) where, 244 N = the number of destination ports of the multicast group. 245 t = the throughput, in frames per second, relative to the 246 source stream. 248 3.2.4 Translational Throughput (TT) 250 Definition: 251 The maximum rate at which none of the frames offered in an 252 transitional format to the SUT are dropped in the process of 253 converting those frames to their appropriate, final format and 254 subsequent correct delivery. 256 Discussion: 257 A popular technique in presenting frames to devices that may 258 not support a protocol feature is to encapsulate, or tunnel, 259 the packet containing the unsupported feature in a format that 260 is supported by that device. This benchmark attempts to 261 characterize the overhead behavior associated with that 262 transitional process. 264 Consideration may need to be given with respect to the impact 265 of different frame formats on usable bandwidth. 267 Measurement units: 268 Frames per second. 270 3.3 Fairness. 272 Definition: 273 The ability of a SUT to fulfill the requirements of a Traffic 274 Class without compromising the requirements, if any, of other 275 Classes. 277 Discussion: 279 Measurement units: 280 Not applicable. 282 3.4 Forwarding Latency. 284 This section presents terminology relating to the characterization of 285 the forwarding latency of a DUT/SUT in a multicast environment. 286 It extends the concept of latency presented in RFC 1242. 288 3.4.1 Multicast Latency. 290 Definition: 291 The set of individual latencies from a single input port on 292 the DUT or SUT to all tested ports belonging to the destination 293 multicast group. 295 Discussion: 296 This benchmark is based on the RFC 1242 definition of latency. 297 While it is useful to collect latency between a pair of source 298 and destination multicast ports, it may be insightful to collect 299 the same type of measurements across a range of ports supporting 300 that Group Class. 302 A variety of statistical exercises can be applied to the set of 303 latencies measurements. 305 Measurement units: 306 Time units with enough precision to reflect measurement. 308 3.4.2 Min/Max Multicast Latency. 310 Definition: 311 The difference between the maximum latency measurement and the 312 minimum latency measurement from the set of latencies produced by 313 the Multicast Latency benchmark. 315 Discussion: 316 This statistic may yield some insight into how a particular 317 implementation handles its multicast traffic. This may be useful 318 to users of multicast synchronization types of applications. 320 Measurement units: 321 Time units with enough precision to reflect measurement. 323 3.5 Overhead 325 This section presents terminology relating to the characterization of 326 the overhead delays associated with explicit operations found in 327 multicast environments. 329 3.5.1 Group Join Delay. 331 Definition: 332 The time duration it takes a DUT/SUT to start forwarding multicast 333 packets from the time a successful IGMP group membership report has 334 been issued to the DUT/SUT. 336 Discussion: 337 Many different factors can contribute to different results, such as 338 the number or type of multicast-related protocols configured 339 on the system under test. 341 A consideration for the related methodology: possible need to 342 differentiate a specifically-forwarded multicast frame from those 343 sprayed by protocols implementing a flooding tactic to solicit prune 344 feedback. 346 Measurement units: 347 Microseconds. 349 3.5.2 Group Leave Delay. 351 Definition: 352 The time duration it takes a DUT/SUT to cease forwarding multicast 353 packets after a corresponding IGMP "Leave Group" message has been 354 successfully offered to the DUT/SUT. 356 Discussion: 357 While it is important to understand how quickly a system can 358 process multicast frames; it may be beneficial to understand 359 how quickly that same system can stop the process as well. 361 Measurement units: 362 Microseconds. 364 Issues: Methodology may need to consider protocol-specific timeout 365 values. 367 3.6 Capacity 369 This section offers terms relating to the identification of multicast 370 group limits of a DUT/SUT. 372 3.6.1 Multicast Group Capacity. 374 Definition: 375 The maximum number of multicast groups a SUT/DUT can support 376 while maintaining the ability to forward multicast frames 377 to all multicast groups registered to that SUT/DUT. 379 Discussion: 381 Measurement units: 382 Multicast groups. 384 Issues: 385 The related methodology may have to consider the impact of multicast 386 sources per group on the ability of a SUT/DUT to "scale up" the 387 number of supportable multicast groups. 389 4. Security Considerations 391 Security issues are not addressed in this memo. 393 5. References 395 [1] Bradner, S. Benchmarking Terminology for Network 396 Interconnection Devices. RFC 1242. July, 1991. 398 [2] Bradner, S., McQuaid, J. Benchmarking Methodology for Network 399 Interconnect Devices. RFC 1944. May, 1996. 401 [3] Craig, R. Terminology for Cell/Call Benchmarking. March, 1997. Work in progress. 404 [4] Mandeville, R. Benchmarking Terminology for LAN Switching 405 Devices. July, 1997. 406 Work in progress. 408 5. Author's Address 410 Kevin Dubray 411 Bay Networks, Inc. 412 2 Federal Street 413 Billerica, MA 01984 414 (508) 916-3862 415 kdubray@baynetworks.com 417 or direct discussion to the Benchmarking Methodology Working Group: 418 bmwg@harvard.edu