idnits 2.17.1 draft-morton-bmwg-imix-genome-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 6, 2010) is 4944 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft AT&T Labs 4 Intended status: Informational October 6, 2010 5 Expires: April 9, 2011 7 IMIX Genome: Specification of variable packet sizes for additional 8 testing 9 draft-morton-bmwg-imix-genome-00 11 Abstract 13 Benchmarking Methodologies have always relied on test conditions with 14 constant packet sizes, with the goal of understanding what network 15 device capability has been tested. Constant packets sizes differ 16 significantly from the conditions encountered in operational 17 deployment, and so additional tests are sometimes conducted with a 18 mixture of packet sizes, or "IMIX". The mixture of sizes a 19 networking device will encounter is highly variable and depends on 20 many factors. An IMIX suited for one networking device and 21 deployment will not be appropriate for another. However, the mix of 22 sizes may be known and the tester may be asked to augment the fixed 23 size tests. To address this need, and the additional goal of 24 repeatable test conditions, this draft proposes a way to specify the 25 exact repeating sequence of packet sizes from the usual set of fixed 26 sizes. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 9, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. First Draft . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Scope and Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Specification of the IMIX Genome . . . . . . . . . . . . . . . 5 71 4. Reporting Long or Pseudo-Random Packet Sequences . . . . . . . 6 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 This memo defines a method to unambiguously specify the sequence of 83 packet sizes used in a load test. 85 Benchmarking Methodologies [RFC2544] have always relied on test 86 conditions with constant packet sizes, with the goal of understanding 87 what network device capability has been tested. Tests with the 88 smallest size stress the header processing capacity, and tests with 89 the largest size stress the overall bit processing capacity. Tests 90 with sizes in-between may determine the transition between these two 91 capacities. 93 Constant packets sizes differ significantly from the conditions 94 encountered in operational deployment, and so additional tests are 95 sometimes conducted with a mixture of packet sizes. The set of sizes 96 used is often called an Internet Mix, or "IMIX" [Spirent], [IXIA], 97 [Agilent]. 99 The mixture of sizes a networking device will encounter is highly 100 variable and depends on many factors. An IMIX suited for one 101 networking device and deployment will not be appropriate for another. 102 However, the mix of sizes may be known and the tester may be asked to 103 augment the fixed size tests. 105 To address this need, and the additional goal of repeatable test 106 conditions, this draft proposes a way to specify the exact repeating 107 sequence of packet sizes from the usual set of fixed sizes: the IMIX 108 Genome. 110 1.1. First Draft 112 In this first draft, some section are very short or to-be-provided 113 (TBP), and there are several questions identified for further 114 discussion. 116 2. Scope and Goals 118 This memo defines a method to unambiguously specify the sequence of 119 packet sizes that have been used in a load test, assuming that a 120 relevant mix of sizes is known to the tester and the length of the 121 repeating sequence is not very long (<30 packets). 123 The IMIX Genome will allow an exact sequence of packet sizes to be 124 communicated as a single-line name, resolving the current ambiguity 125 with results that simply refer to "IMIX". 127 While documentation of the exact sequence is ideal, the memo also 128 covers the case where the sequence of sizes is very long or may be 129 generated by a pseudo-random process. 131 It is a colossal non-goal to standardize one or more versions of the 132 IMIX. This topic has been discussed on many occasions on the bmwg- 133 list[IMIXonList]. The goal is to enable customization with minimal 134 constraints while fostering repeatable testing once the fixed size 135 testing is complete. 137 3. Specification of the IMIX Genome 139 The IMIX Genome is specified in the following format: 141 IMIX - 123456...x 143 where each number is replaced by the letter corresponding to the 144 packet size of the packet at that position in the sequence. The 145 following table gives the letter encoding for the [RFC2544] standard 146 sizes (64, 128, 256, 512, 1024, 1280, and 1518 bytes). 148 +-------------+--------------------+ 149 | Size, bytes | Genome Code Letter | 150 +-------------+--------------------+ 151 | 64 | a | 152 | 128 | b | 153 | 256 | c | 154 | 512 | d | 155 | 1024 | e | 156 | 1280 | f | 157 | 1518 | g | 158 | MTU ?? | h | 159 +-------------+--------------------+ 161 For example: a five packet sequence with sizes 64,64,64,1280,1518 162 would be designated: 164 IMIX - aaafg 166 While this approach allows some flexibility, there are also 167 constraints. 169 o Non-RFC2544 packet sizes would need to be approximated by those 170 available in the table. 172 o The Genome for very long sequences can become undecipherable by 173 humans. 175 o Whether h=MTU is useful/desirable is TBD. 177 o Whether more tabulated packet sizes would be useful is TBD. 179 Some open issues with this format are: 181 1. Multiple Source-Destination Address Pairs: is the IMIX sequence 182 applicable to each pair, across multiple pairs in sets, or across 183 all pairs? 185 2. Multiple Tester Ports:is the IMIX sequence applicable to each 186 port, across multiple ports in sets, or across all ports? 188 4. Reporting Long or Pseudo-Random Packet Sequences 190 When the IMIX-Genome cannot be used (when the sheer length of the 191 sequence would make the genome unmanageable) or when the sequence is 192 designed to vary within some proportional constraints, a table is 193 necessary. 195 +-----------+---------------------+-----------------+ 196 | IP Length | Percentage of Total | Other Length(s) | 197 +-----------+---------------------+-----------------+ 198 | 64 | 23 | 82 | 199 | 128 | 67 | 146 | 200 | 1000 | 10 | 1018 | 201 +-----------+---------------------+-----------------+ 203 Note that this approach also allows non-standard packet sizes, but 204 trades the short genome specification and ability to specify the 205 exact sequence for other flexibilities. 207 >>> Specification for psuedo-random size generation here? <<< 209 5. Security Considerations 211 Benchmarking activities as described in this memo are limited to 212 technology characterization using controlled stimuli in a laboratory 213 environment, with dedicated address space and the other constraints 214 [RFC2544]. 216 The benchmarking network topology will be an independent test setup 217 and MUST NOT be connected to devices that may forward the test 218 traffic into a production network, or misroute traffic to the test 219 management network. 221 Further, benchmarking is performed on a "black-box" basis, relying 222 solely on measurements observable external to the DUT/SUT. 224 Special capabilities SHOULD NOT exist in the DUT/SUT specifically for 225 benchmarking purposes. Any implications for network security arising 226 from the DUT/SUT SHOULD be identical in the lab and in production 227 networks. 229 6. IANA Considerations 231 This memo makes no requests of IANA, and hopes that IANA will leave 232 it alone as well. 234 7. Acknowledgements 236 8. References 238 8.1. Normative References 240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 241 Requirement Levels", BCP 14, RFC 2119, March 1997. 243 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 244 Network Interconnect Devices", RFC 2544, March 1999. 246 8.2. Informative References 248 [Agilent] http://www.ixiacom.com/pdfs/test_plans/ 249 agilent_journal_of_internet_test_methodologies.pdf, "The 250 Journal of Internet Test Methodologies", 2007. 252 [IMIXonList] 253 http://www.ietf.org/mail-archive/web/bmwg/current/ 254 msg00691.html, "Discussion on IMIX", 2003. 256 [IXIA] http://www.ixiacom.com/library/test_plans/ 257 display?skey=testing_pppox, "Library: Test Plans", 2010. 259 [Spirent] http://gospirent.com/whitepaper/ 260 IMIX%20Test%20Methodolgy%20Journal.pdf, "Test Methodology 261 Journal: IMIX (Internet Mix) Journal", 2006. 263 Author's Address 265 Al Morton 266 AT&T Labs 267 200 Laurel Avenue South 268 Middletown,, NJ 07748 269 USA 271 Phone: +1 732 420 1571 272 Fax: +1 732 368 1192 273 Email: acmorton@att.com 274 URI: http://home.comcast.net/~acmacm/