From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6985.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc6985.txt (limited to 'doc/rfc/rfc6985.txt') diff --git a/doc/rfc/rfc6985.txt b/doc/rfc/rfc6985.txt new file mode 100644 index 0000000..c4c30c6 --- /dev/null +++ b/doc/rfc/rfc6985.txt @@ -0,0 +1,563 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Morton +Request for Comments: 6985 AT&T Labs +Category: Informational July 2013 +ISSN: 2070-1721 + + + IMIX Genome: Specification of Variable Packet Sizes + for Additional Testing + +Abstract + + Benchmarking methodologies have always relied on test conditions with + constant packet sizes, with the goal of understanding what network + device capability has been tested. Tests with a constant packet size + reveal device capabilities but differ significantly from the + conditions encountered in operational deployment, so additional tests + are sometimes conducted with a mixture of packet sizes, or "IMIX" + ("Internet Mix"). The mixture of sizes a networking device will + encounter is highly variable and depends on many factors. An IMIX + suited for one networking device and deployment will not be + appropriate for another. However, the mix of sizes may be known, and + the tester may be asked to augment the fixed-size tests. To address + this need and the perpetual goal of specifying repeatable test + conditions, this document defines a way to specify the exact + repeating sequence of packet sizes from the usual set of fixed sizes + and from other forms of mixed-size specification. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6985. + + + + + + + + + +Morton Informational [Page 1] + +RFC 6985 IMIX Genome July 2013 + + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://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. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Requirements Language ...........................................3 + 3. Scope and Goals .................................................3 + 4. Specification of the IMIX Genome ................................4 + 5. Specification of a Custom IMIX ..................................6 + 6. Reporting Long or Pseudorandom Packet Sequences .................7 + 6.1. Run-Length Encoding ........................................7 + 6.2. Table of Proportions .......................................7 + 6.3. Deterministic Algorithm ....................................7 + 6.4. Pseudorandom Length Algorithm ..............................8 + 6.5. Pseudorandom Sequence Algorithm ............................8 + 7. Security Considerations .........................................8 + 8. Acknowledgements ................................................8 + 9. References ......................................................9 + 9.1. Normative References .......................................9 + 9.2. Informative References .....................................9 + +1. Introduction + + This memo defines a method to unambiguously specify the sequence of + packet sizes used in a load test. + + Benchmarking methodologies [RFC2544] have always relied on test + conditions with constant packet sizes, with the goal of understanding + what network device capability has been tested. Tests with the + smallest size stress the header processing capacity, and tests with + the largest size stress the overall bit-processing capacity. Tests + with sizes in between may determine the transition between these two + capacities. + + + + + +Morton Informational [Page 2] + +RFC 6985 IMIX Genome July 2013 + + + Streams of constant packet size differ significantly from the + conditions encountered in operational deployment, so additional tests + are sometimes conducted with a mixture of packet sizes. The set of + sizes used is often called an Internet Mix, or "IMIX" [Spirent] + [IXIA] [Agilent]. + + The mixture of sizes a networking device will encounter is highly + variable and depends on many factors. An IMIX suited for one + networking device and deployment will not be appropriate for another. + However, the mix of sizes may be known, and the tester may be asked + to augment the fixed-size tests. The references above cite the + original studies and their methodologies. Similar methods can be + used to determine new size mixes present on a link or network. We + note that the architecture for IP Flow Information Export [RFC5470] + provides one method to gather packet-size information on private + networks. + + To address this need and the perpetual goal of specifying repeatable + test conditions, this memo proposes a way to specify the exact + repeating sequence of packet sizes from the usual set of fixed sizes: + the IMIX Genome. Other, less exact forms of size specification are + also recommended for extremely complicated or customized size mixes. + We apply the term "genome" to infer that the entire test packet-size + sequence can be replicated if this information is known -- a parallel + to the information needed for biological replication. + + This memo takes the position that it cannot be proven for all + circumstances that the sequence of packet sizes does not affect the + test result; thus, a standardized specification of sequence is + valuable. + +2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +3. Scope and Goals + + This memo defines a method to unambiguously specify the sequence of + packet sizes that have been used in a load test, assuming that a + relevant mix of sizes is known to the tester and the length of the + repeating sequence is not very long (<100 packets). + + The IMIX Genome will allow an exact sequence of packet sizes to be + communicated as a single-line name, resolving the current ambiguity + with results that simply refer to "IMIX". This aspect is critical + because no ability has been demonstrated to extrapolate results from + + + +Morton Informational [Page 3] + +RFC 6985 IMIX Genome July 2013 + + + one IMIX to another IMIX -- and certainly no ability to extrapolate + results to other circumstances -- even when the mix varies only + slightly from another IMIX. + + While documentation of the exact sequence is ideal, the memo also + covers the case where the sequence of sizes is very long or may be + generated by a pseudorandom process. + + It is a colossal non-goal to standardize one or more versions of the + IMIX. This topic has been discussed on many occasions on the BMWG + mailing list [IMIXonList]. The goal is to enable customization with + minimal constraints while fostering repeatable testing once the + fixed-size testing is complete. Thus, the requirements presented in + this specification, expressed in [RFC2119] terms, are intended for + those performing/reporting laboratory tests to improve clarity and + repeatability. + +4. Specification of the IMIX Genome + + The IMIX Genome is specified in the following format: + + IMIX - 123456...x + + where each number is replaced by the letter corresponding to the size + of the packet at that position in the sequence. The following table + gives the letter encoding for the [RFC2544] standard sizes (64, 128, + 256, 512, 1024, 1280, and 1518 bytes) and "jumbo" sizes (2112, 9000, + and 16000 bytes). Note that the 4-octet Ethernet frame check + sequence may fail to detect bit errors in the larger jumbo frames + [Jumbo1] [Jumbo2]. + + +--------------+--------------------+ + | Size (Bytes) | Genome Code Letter | + +--------------+--------------------+ + | 64 | a | + | 128 | b | + | 256 | c | + | 512 | d | + | 1024 | e | + | 1280 | f | + | 1518 | g | + | 2112 | h | + | 9000 | i | + | 16000 | j | + | MTU | z | + +--------------+--------------------+ + + + + + +Morton Informational [Page 4] + +RFC 6985 IMIX Genome July 2013 + + + For example, a five-packet sequence with sizes 64,64,64,1280,1518 + would be designated: + + IMIX - aaafg + + If z (MTU) is used, the tester MUST specify the length of the MTU in + the report. + + While this approach allows some flexibility, there are also + constraints. + + o Packet sizes not defined by RFC 2544 would need to be approximated + by those available in the table. + + o The genome for very long sequences can become undecipherable by + humans. + + Some questions testers must ask and answer when using the IMIX Genome + are: + + 1. Multiple source-destination address pairs: Is the IMIX sequence + applicable to each pair, across multiple pairs in sets, or across + all pairs? + + 2. Multiple tester ports: Is the IMIX sequence applicable to each + port, across multiple ports in sets, or across all ports? + + The chosen configuration would be expressed in the following general + form: + + +-------------------+------------------------+---------------------+ + | Source Address + | Destination Address + | Corresponding IMIX | + | Port AND/OR Blade | Port AND/OR Blade | | + +-------------------+------------------------+---------------------+ + | x.x.x.x Blade2 | y.y.y.y Blade3 | IMIX - aaafg | + +-------------------+------------------------+---------------------+ + + where testers can specify the IMIX used between any two entities in + the test architecture (and "Blade" is a component in a multi- + component device chassis). + + + + + + + + + + + +Morton Informational [Page 5] + +RFC 6985 IMIX Genome July 2013 + + +5. Specification of a Custom IMIX + + This section describes how to specify an IMIX with locally selected + packet sizes. + + The custom IMIX is specified in the following format: + + CUSTOM IMIX - 123456...x + + where each number is replaced by the letter corresponding to the size + of the packet at that position in the sequence. The tester MUST + complete the following table, giving the letter encoding for each + size used, where each set of three lower-case letters would be + replaced by the integer size in octets. + + +--------------+--------------------+ + | Size (Bytes) | Custom Code Letter | + +--------------+--------------------+ + | aaa | A | + | bbb | B | + | ccc | C | + | ddd | D | + | eee | E | + | fff | F | + | ggg | G | + | etc. | up to Z | + +--------------+--------------------+ + + For example, a five-packet sequence with sizes + aaa=64,aaa=64,aaa=64,ggg=1020,ggg=1020 would be designated: + + CUSTOM IMIX - AAAGG + + + + + + + + + + + + + + + + + + + +Morton Informational [Page 6] + +RFC 6985 IMIX Genome July 2013 + + +6. Reporting Long or Pseudorandom Packet Sequences + + When the IMIX Genome cannot be used (when the sheer length of the + sequence would make the genome unmanageable), five options are + possible, as noted in the following subsections. + +6.1. Run-Length Encoding + + When a sequence can be decomposed into a series of short repeating + sequences, then a run-length encoding approach MAY be specified as + shown in the table below (using the single lower-case letter Genome + Codes from Section 4): + + +------------------------------+----------------------+ + | Count of Repeating Sequences | Packet-Size Sequence | + +------------------------------+----------------------+ + | 20 | abcd | + | 5 | ggga | + | 10 | dcba | + +------------------------------+----------------------+ + + The run-length encoding approach is also applicable to the custom + IMIX as described in Section 5 (where the single upper-case letter + Genome Codes would be used instead). + +6.2. Table of Proportions + + When the sequence is designed to vary within some proportional + constraints, a table simply giving the proportions of each size MAY + be used instead. + + +-----------+---------------------+---------------------------+ + | IP Length | Percentage of Total | Length(s) at Other Layers | + +-----------+---------------------+---------------------------+ + | 64 | 23 | 82 | + | 128 | 67 | 146 | + | 1000 | 10 | 1018 | + +-----------+---------------------+---------------------------+ + + Note that the table of proportions also allows non-standard packet + sizes but trades the short genome specification and ability to + specify the exact sequence for other flexibilities. + +6.3. Deterministic Algorithm + + If a deterministic packet-size generation method is used (such as a + monotonic increase by 1 octet from start value to MTU), then the + generation algorithm SHOULD be reported. + + + +Morton Informational [Page 7] + +RFC 6985 IMIX Genome July 2013 + + +6.4. Pseudorandom Length Algorithm + + If a pseudorandom length generation capability is used, then the + generation algorithm SHOULD be reported with the results along with + the seed value used. We also recognize the opportunity to randomize + inter-packet spacing from a test sender as well as the size, and both + spacing and length pseudorandom generation algorithms and seeds + SHOULD be reported when used. + +6.5. Pseudorandom Sequence Algorithm + + Finally, we note another possibility: a pseudorandom sequence + generates an index to the table of packet lengths, and the generation + algorithm SHOULD be reported with the results, along with the seed + value if used. + +7. Security Considerations + + Benchmarking activities as described in this memo are limited to + technology characterization using controlled stimuli in a laboratory + environment, with dedicated address space and other constraints + [RFC2544]. + + The benchmarking network topology will be an independent test setup + and MUST NOT be connected to devices that may forward the test + traffic into a production network or misroute traffic to the test + management network. + + Further, benchmarking is performed on a "black-box" basis, relying + solely on measurements observable external to the Device Under Test + (DUT) or System Under Test (SUT). + + Special capabilities SHOULD NOT exist in the DUT/SUT specifically for + benchmarking purposes. Any implications for network security arising + from the DUT/SUT SHOULD be identical in the lab and in production + networks. + +8. Acknowledgements + + Thanks to Sarah Banks, Aamer Akhter, Steve Maxwell, and Scott Bradner + for their reviews and comments. Ilya Varlashkin suggested the + run-length encoding approach in Section 6.1. + + + + + + + + + +Morton Informational [Page 8] + +RFC 6985 IMIX Genome July 2013 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for + Network Interconnect Devices", RFC 2544, March 1999. + +9.2. Informative References + + [Agilent] Agilent, "The Journal of Internet Test Methodologies", + September 2007, . + + [IMIXonList] + IETF Benchmarking Methodology Working Group, "Discussion + on IMIX", October 2003, . + + [IXIA] IXIA, "Testing PPPoX and L2TP Broadband Access Devices", + 2004, . + + [Jumbo1] Dykstra, P., "Gigabit Ethernet Jumbo Frames, and why you + should care", WareOnEarth Communications, Inc., December + 1999, . + + [Jumbo2] Mathis, M., "The Ethernet CRC limits packets to about + 12 kBytes. (NOT)", Pittsburgh Supercomputing Center, + April 2003, + . + + [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, + "Architecture for IP Flow Information Export", RFC 5470, + March 2009. + + [Spirent] Spirent, "Test Methodology Journal: IMIX (Internet Mix) + Journal", January 2006, . + + + + + + + + + + +Morton Informational [Page 9] + +RFC 6985 IMIX Genome July 2013 + + +Author's Address + + Al Morton + AT&T Labs + 200 Laurel Avenue South + Middletown, NJ 07748 + USA + + Phone: +1 732 420 1571 + Fax: +1 732 368 1192 + EMail: acmorton@att.com + URI: http://home.comcast.net/~acmacm/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Morton Informational [Page 10] + -- cgit v1.2.3