idnits 2.17.1 draft-ietf-bmwg-dsmmeth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 482. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 9) being 67 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of lines with control characters in the document. ** The abstract seems to contain references ([Pp06]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (August 2006) is 6456 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) -- Looks like a reference, but probably isn't: '5' on line 164 -- Looks like a reference, but probably isn't: '6' on line 164 == Unused Reference: 'Br91' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'Br98' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'Ma98' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'Ni98' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'Bl98' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'Br99' is defined on line 408, but no explicit reference was found in the text == Unused Reference: 'Fl93' is defined on line 411, but no explicit reference was found in the text == Unused Reference: 'Ja99' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'Ma91' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'Sc96' is defined on line 422, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. 'Br91') ** Obsolete normative reference: RFC 2309 (ref. 'Br98') (Obsoleted by RFC 7567) ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. 'Ma98') -- No information found for draft-ieft-bwmg-dsmterm - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Pp06' -- Obsolete informational reference (is this intentional?): RFC 2598 (ref. 'Ja99') (Obsoleted by RFC 3246) -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. 'Sc96') (Obsoleted by RFC 3550) Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 INTERNET-DRAFT 3 Expires in: August 2006 4 Scott Poretsky 5 Reef Point Systems 7 Pierre-Yves Geay 8 Alcatel 10 February 2006 12 Methodology for Benchmarking Network-layer 13 Traffic Control Mechanisms 15 17 Intellectual Property Rights (IPR) statement: 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Status of this Memo 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 45 This document describes the methodology for the benchmarking of 46 devices that implement traffic control based on IP precedence or 47 diff-serv code point criteria. The methodology is to be applied 48 to measurements made on the data plane to evaluate the 49 performance of the traffic control mechanisms. The methodology 50 permits the specific traffic control mechanisms and 51 configuration commands to vary between DUTs. The methodology 52 uses much of the Terminology defined in [Pp06]. 54 Network-layer Traffic Control Mechanisms 56 Table of Contents 57 1. Introduction ...............................................2 58 2. Existing definitions .......................................2 59 3. Test Setup..................................................3 60 3.1 Test Topologies............................................3 61 3.2 Test Considerations........................................4 62 3.3 Reporting Format...........................................5 63 4. Test Cases..................................................6 64 4.1 Undifferentiated Response..................................6 65 4.2 Traffic Control Baseline Performance.......................6 66 4.3 Traffic Control Performance with Forwarding Congestion.....7 67 5. IANA Considerations.........................................7 68 6. Security Considerations.....................................7 69 7. References..................................................8 70 8. Author's Address............................................9 71 9. Full Copyright Statement....................................9 73 1. Introduction 75 This document describes the methodology for the benchmarking of 76 devices that implement traffic control based on IP precedence or 77 diff-serv code point criteria. The methodology is to be applied 78 to measurements made on the data plane to evaluate the 79 performance of the traffic control mechanisms. The methodology 80 permits the specific traffic control mechanisms and 81 configuration commands to vary between DUTs. The methodology 82 uses much of the Terminology defined in [Pp06]. 84 2. Existing definitions 86 For the sake of clarity and continuity this RFC adopts the 87 template for definitions set out in Section 2 of RFC 1242. 88 Definitions are indexed and grouped together in sections for ease 89 of reference. Reference [Pp06] for benchmarking terminology. 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in BCP 14, RFC 2119 94 [Br97]. RFC 2119 defines the use of these key words to help make the 95 intent of standards track documents as clear as possible. While this 96 document uses these keywords, this document is not a standards track 97 document. 99 Network-layer Traffic Control Mechanisms 101 3. Test Setup 102 3.1 Test Topologies 104 Figure 1 shows the Test Topology for benchmarking performance 105 when Forwarding Congestion does not exist on the egress link. 106 This topology is to be used when benchmarking the Undifferentiated 107 Response and the Traffic Control without Forwarding Congestion 108 Figure 2 shows the Test Topology for benchmarking performance 109 when Forwarding Congestion does not exist on the egress link. 110 This topology is to be used when benchmarking the Traffic Control 111 with Forwarding Congestion. The Forwarding Congestion is 112 produced by offering load to two ingress interfaces on the DUT 113 destined for the same single egress interface. The aggregate of 114 the ingress offered load MUST exceed the Forwarding Capacity of 115 the egress link to produce Forwarding Congestion. 117 Expected 118 Vector 119 | 120 | 121 \/ 122 --------- Offered Vector --------- 123 | |<--------------------------------| | 124 | | | | 125 | | | | 126 | DUT | | Tester| 127 | | | | 128 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 129 | | Output Vector | | 130 --------- --------- 132 Figure 1. Test Topology for Benchmarking 133 Without Forwarding Congestion 135 Expected 136 Vector 137 | 138 | 139 \/ 140 --------- Offered Vector --------- 141 | |<--------------------------------| | 142 | | Ingress Links 1,2 | | 143 | |<--------------------------------| | 144 | DUT | | Tester| 145 | | | | 146 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 147 | | Output Vector | | 148 --------- --------- 150 Figure 2. Test Topology for Benchmarking 151 With Forwarding Congestion 153 Network-layer Traffic Control Mechanisms 155 3.2 Test Considerations 157 3.2.1 Routing Configuration 158 Routing Protocols SHOULD NOT be used. All routing decisions 159 SHOULD be made based upon pre-configured static routes. 161 3.2.2 Interface Types 162 All test cases in this methodology document may be executed with 163 any interface type. All interfaces MUST be the same media and 164 Throughput [5,6] for each test case. 166 3.2.3 Offered Vector 168 The Offered Vector MUST be configured on the Tester as follows: 170 a. The Offered Load MUST be the Forwarding Capacity of the 171 device at a fixed packet size. 173 b. The Forwarding Capacity MUST be measured at the egress 174 interface of the DUT 176 c. Each test case MUST be executed using a single, selectable 177 packet size. Packet Size is measured in bytes and includes 178 the IP header and payload. If IPsec packets are used then 179 the packet size also includes it. Packet Size must be 180 equal to or less than the interface MTU so that there is no 181 fragmentation. 183 d. It is RECOMMENDED that the number of flows used be 184 1000, 10000, and/or 100000. A flow MUST be identified 185 by its DSCP, IP Source Address, and IP Destination Address. 187 e. It is RECOMMENDED that the number of DSCPs used be 188 1, 2, 3, 4, 6, 8, 16, and/or 64. When the number of DSCPs 189 is 1 then the Undifferentiated Response is benchmarked. 190 The actual values of the DSCPs used is selectable. 192 3.2.4 Test Duration 193 It is RECOMMENDED that the Test Duration for each test case 194 includes a minimum of 10 minutes of Offered Load and 195 Output Vector measurement 197 3.2.5 Expected Vector 198 The Expected Vector is configured on the DUT. The Traffic 199 Control mechanisms and specific configuration commands may 200 vary between DUTs. Test Cases may be repeated with 201 variation to the Expected Vector to produce a more 202 benchmark results. 204 Network-layer Traffic Control Mechanisms 206 3.3 Reporting Format 208 For each test case, it is recommended that the following 209 reporting format be completed: 211 PARAMETERS UNITS 212 ---------- ----- 214 Offered Vector 215 -------------- 216 Offered Load pps 217 Number of DSCPs {1..64} 218 Codepoint Set {0..63, 0..63, ... , x} 219 Number of Flows {1000, 10000, 100000} 220 Number of Flows per DSCP Number of Flows/Number of DSCPs 221 Packet Size bytes 223 Undifferentiated Response (Number of DSCPs = 1) 224 ------------------------- 225 Forwarding Capacity pps 226 Packet Loss packets 227 Forwarding Delay 228 Minimum msec 229 Maximum msec 230 Average msec 231 Jitter 232 Average msec 233 Peak-to-Peak msec 234 Out-of-Order Packets packets 235 Duplicate Packets packets 237 Expected Vector {for DSCP=n} (as configured on DUT) 238 ---------------------------- 239 Forwarding Capacity pps 240 Packet Loss packets 241 Forwarding Delay 242 Minimum msec 243 Maximum msec 244 Average msec 246 Output Vector {for DSCP=n} 247 -------------------------- 248 Forwarding Capacity pps 249 Packet Loss packets 250 Forwarding Delay 251 Minimum msec 252 Maximum msec 253 Average msec 254 Jitter 255 Average msec 256 Peak-to-Peak msec 257 Out-of-Order Packets packets 258 Duplicate Packets packets 259 Network-layer Traffic Control Mechanisms 261 4. Test Cases 263 4.1 Undifferentiated Response 265 Purpose: 266 To establish the baseline performance of the DUT. 268 Procedure: 269 1. Configure DUT with Expected Vector. 270 2. Configure the Tester for the Offered Vector. 271 Number of DSCPs MUST equal 1 and the 272 RECOMMENDED DSCP value is 0 (Best Effort). 273 Use 1000 Flows identified by IP SA/DA. All flows 274 have the same DSCP value. 275 3. Using the Test Topology in Figure 1, source the 276 Offered Load from the Tester to the DUT. 277 4. Measure and record the Output Vector. 278 5. Maintain offered load for 10 minutes minimum 279 to observe possible variations in measurements. 280 6. Repeat steps 2 through 5 with 10000 and 100000 281 Flows. 283 Expected Results: 284 Forwarding Vector equals the Offered Load. There 285 is no packet loss and no out-of-order packets. 287 4.2 Traffic Control Baseline Performance 288 Purpose: 289 To benchmark the Output Vectors for a Codepoint Set 290 without Forwarding Congestion. 292 Procedure: 293 1. Configure DUT with Expected Vector for each DSCP in 294 the Codepoint Set. 295 2. Configure the Tester for the Offered Vector. 296 Number of DSCPs MUST 2 or more. Any DSCP values can 297 be used. Use 1000 Flows identified by IP SA/DA 298 and DSCP value. 299 3. Using the Test Topology in Figure 1, source the 300 Offered Load from the Tester to the DUT. 301 4. Measure and record the Output Vector for each DSCP 302 in the Codepoint Set. 303 5. Maintain offered load for 10 minutes minimum 304 to observe possible variations in measurements. 305 6. Repeat steps 2 through 5 with 10000 and 100000 306 Flows. 307 7. Increment number of DSCPs used and repeat steps 308 1 through 6. 310 Expected Results: 311 Forwarding Vector equals the Offered Load. There is 312 no packet loss and no out-of-order packets. Output 313 vectors match the Expected Vectors for each DSCP in 314 the Codepoint Set. 316 Network-layer Traffic Control Mechanisms 318 4.3 Traffic Control Performance with Forwarding Congestion 319 Purpose: 320 To benchmark the Output Vectors for a Codepoint Set 321 with Forwarding Congestion. 323 Procedure: 324 1. Configure DUT with Expected Vector for each DSCP in 325 the Codepoint Set. 326 2. Configure the Tester for the Offered Vector. 327 Number of DSCPs MUST 2 or more. Any DSCP values can 328 be used. Use 1000 Flows identified by IP SA/DA 329 and DSCP value. The Offered Load MUST exceed the 330 Forwarding Capacity of a single egress link by 25% 331 using 2 ingress links. 332 3. Using the Test Topology in Figure 2, source the 333 Offered Load from the Tester to the DUT. The 334 aggregate of the ingress offered load MUST exceed 335 the Forwarding Capacity of the egress link to 336 produce Forwarding Congestion. 337 4. Measure and record the Output Vector for each DSCP 338 in the Codepoint Set. 339 5. Maintain offered load for 10 minutes minimum 340 to observe possible variations in measurements. 341 6. Repeat steps 2 through 5 with 10000 and 100000 342 Flows. 343 7. Increment offered load by 25% to 200% maximum. 344 8. Increment number of DSCPs used and repeat steps 345 1 through 6. 347 Expected Results: 348 Forwarding Vector equals the Offered Load. There is 349 no packet loss and no out-of-order packets. Output 350 vectors match the Expected Vectors for each DSCP in 351 the Codepoint Set. 353 Network-layer Traffic Control Mechanisms 355 5. IANA Considerations 357 This document requires no IANA considerations. 359 6. Security Considerations 361 Documents of this type do not directly affect the security of 362 the Internet or of corporate networks as long as benchmarking 363 is not performed on devices or systems connected to 364 production networks. 366 Packets with unintended and/or unauthorized DSCP or IP 367 precedence values may present security issues. Determining 368 the security consequences of such packets is out of scope for 369 this document. 371 7. Acknowledgments 372 Network-layer Traffic Control Mechanisms 374 8. References 375 8.1 Normative References 377 [Br91] Bradner, S., "Benchmarking Terminology for Network 378 Interconnection Devices", RFC 1242, July 1991. 380 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", RFC 2119, March 1997 383 [Br98] Braden, B., Clark, D., Crowcroft, J., Davie, B., 384 Deering, S., Estrin, D., Floyd, S., Jacobson, V., 385 Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, 386 K., Shenker, S., Wroclawski, J. and L. Zhang, 387 "Recommendations on Queue Management and Congestion 388 Avoidance in the Internet", RFC 2309, April 1998. 390 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN 391 Switching Devices", RFC 2285, July 1998. 393 [Ni98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition 394 of the Differentiated Services Field (DS Field) in the 395 IPv4 and IPv6 Headers", RFC 2474, December 1998. 397 [Pp06] Perser, J., Poretsky, S., Erramilli, S., and Khurana, S., 398 "Terminology for Benchmarking Network-layer Traffic 399 Control Mechanisms", draft-ieft-bwmg-dsmterm-12, work 400 in progress, 2006. 402 8.2 Informative References 404 [Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 405 Weiss, W., "An Architecture for Differentiated Services", 406 RFC 2475, December 1998. 408 [Br99] Bradner, S., McQuaid, J. "Benchmarking Methodology for 409 Network Interconnect Devices", RFC 2544, March 1999 411 [Fl93] Floyd, S., and Jacobson, V., "Random Early Detection 412 gateways for Congestion Avoidance", IEEE/ACM 413 Transactions on Networking, V.1 N.4, August 1993, p. 414 397-413. URL "ftp://ftp.ee.lbl.gov/papers/early.pdf". 416 [Ja99] Jacobson, V., Nichols, K., Poduri, K., "An Expedited 417 Forwarding PHB", RFC 2598, June 1999 419 [Ma91] Mankin, A., Ramakrishnan, K., "Gateway Congestion Control 420 Survey", RFC 1254, August 1991 422 [Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 423 "RTP: A Transport Protocol for Real-Time Applications", 424 RFC 1889, January 1996 425 Network-layer Traffic Control Mechanisms 427 9. Authors' Addresses 429 Scott Poretsky 430 Reef Point Systems 431 8 New England Executive Park 432 Burlington, MA 01803 433 USA 435 Phone: + 1 508 439 9008 436 EMail: sporetsky@reefpoint.com 438 Pierre-Yves Geay 439 Alcatel 440 Orvault, France 442 Email: Pierre-Yves.Geay@alcatel.fr 444 Full Copyright Statement 446 Copyright (C) The Internet Society (2006). 448 This document is subject to the rights, licenses and restrictions 449 contained in BCP 78, and except as set forth therein, the authors 450 retain all their rights. 452 This document and the information contained herein are provided on an 453 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 454 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 455 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 456 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 457 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 458 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 460 Intellectual Property 462 The IETF takes no position regarding the validity or scope of any 463 Intellectual Property Rights or other rights that might be claimed to 464 pertain to the implementation or use of the technology described in 465 this document or the extent to which any license under such rights 466 might or might not be available; nor does it represent that it has 467 made any independent effort to identify any such rights. Information 468 on the procedures with respect to rights in RFC documents can be 469 found in BCP 78 and BCP 79. 471 Copies of IPR disclosures made to the IETF Secretariat and any 472 assurances of licenses to be made available, or the result of an 473 attempt made to obtain a general license or permission for the use of 474 such proprietary rights by implementers or users of this 475 specification can be obtained from the IETF on-line IPR repository at 476 http://www.ietf.org/ipr. 478 The IETF invites any interested party to bring to its attention any 479 copyrights, patents or patent applications, or other proprietary 480 rights that may cover technology that may be required to implement 481 this standard. Please address the information to the IETF at ietf- 482 ipr@ietf.org. 484 Acknowledgement 485 Funding for the RFC Editor function is currently provided by the 486 Internet Society.