draft-ietf-bmwg-imix-genome-02.txt   draft-ietf-bmwg-imix-genome-03.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Informational July 5, 2012 Intended status: Informational November 11, 2012
Expires: January 6, 2013 Expires: May 15, 2013
IMIX Genome: Specification of variable packet sizes for additional IMIX Genome: Specification of variable packet sizes for additional
testing testing
draft-ietf-bmwg-imix-genome-02 draft-ietf-bmwg-imix-genome-03
Abstract Abstract
Benchmarking Methodologies have always relied on test conditions with Benchmarking Methodologies have always relied on test conditions with
constant packet sizes, with the goal of understanding what network constant packet sizes, with the goal of understanding what network
device capability has been tested. Tests with constant packet size device capability has been tested. Tests with constant packet size
reveal device capabilities but differ significantly from the reveal device capabilities but differ significantly from the
conditions encountered in operational deployment, and so additional conditions encountered in operational deployment, and so additional
tests are sometimes conducted with a mixture of packet sizes, or tests are sometimes conducted with a mixture of packet sizes, or
"IMIX". The mixture of sizes a networking device will encounter is "IMIX". The mixture of sizes a networking device will encounter is
skipping to change at page 2, line 6 skipping to change at page 2, line 6
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 6, 2013. This Internet-Draft will expire on May 15, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Scope and Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope and Goals . . . . . . . . . . . . . . . . . . . . . . . 4
3. Specification of the IMIX Genome . . . . . . . . . . . . . . . 5 3. Specification of the IMIX Genome . . . . . . . . . . . . . . . 5
4. Specification of a Custom IMIX . . . . . . . . . . . . . . . . 6 4. Specification of a Custom IMIX . . . . . . . . . . . . . . . . 7
5. Reporting Long or Pseudo-Random Packet Sequences . . . . . . . 7 5. Reporting Long or Pseudo-Random Packet Sequences . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This memo defines a method to unambiguously specify the sequence of This memo defines a method to unambiguously specify the sequence of
packet sizes used in a load test. packet sizes used in a load test.
Benchmarking Methodologies [RFC2544] have always relied on test Benchmarking Methodologies [RFC2544] have always relied on test
conditions with constant packet sizes, with the goal of understanding conditions with constant packet sizes, with the goal of understanding
what network device capability has been tested. Tests with the what network device capability has been tested. Tests with the
smallest size stress the header processing capacity, and tests with smallest size stress the header processing capacity, and tests with
skipping to change at page 5, line 7 skipping to change at page 5, line 7
2. Scope and Goals 2. Scope and Goals
This memo defines a method to unambiguously specify the sequence of This memo defines a method to unambiguously specify the sequence of
packet sizes that have been used in a load test, assuming that a 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 relevant mix of sizes is known to the tester and the length of the
repeating sequence is not very long (<100 packets). repeating sequence is not very long (<100 packets).
The IMIX Genome will allow an exact sequence of packet sizes to be The IMIX Genome will allow an exact sequence of packet sizes to be
communicated as a single-line name, resolving the current ambiguity communicated as a single-line name, resolving the current ambiguity
with results that simply refer to "IMIX". with results that simply refer to "IMIX". This aspect is critical
because no ability has been demonstrated to extrapolate results from
one IMIX to another IMIX, even when the mix varies only slightly from
another IMIX, and certainly no ability to extrapolate results to
other circumstances.
While documentation of the exact sequence is ideal, the memo also 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 covers the case where the sequence of sizes is very long or may be
generated by a pseudo-random process. generated by a pseudo-random process.
It is a colossal non-goal to standardize one or more versions of the 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- IMIX. This topic has been discussed on many occasions on the bmwg-
list[IMIXonList]. The goal is to enable customization with minimal list[IMIXonList]. The goal is to enable customization with minimal
constraints while fostering repeatable testing once the fixed size constraints while fostering repeatable testing once the fixed size
testing is complete. testing is complete.
skipping to change at page 8, line 5 skipping to change at page 8, line 18
+------------------------------+----------------------+ +------------------------------+----------------------+
| 20 | abcd | | 20 | abcd |
| 5 | ggga | | 5 | ggga |
| 10 | dcba | | 10 | dcba |
+------------------------------+----------------------+ +------------------------------+----------------------+
When the sequence is designed to vary within some proportional When the sequence is designed to vary within some proportional
constraints, a table simply giving the proportions of each size MAY constraints, a table simply giving the proportions of each size MAY
be used instead. be used instead.
+-----------+---------------------+-----------------+ +-----------+---------------------+---------------------------+
| IP Length | Percentage of Total | Other Length(s) | | IP Length | Percentage of Total | Length(s) at other layers |
+-----------+---------------------+-----------------+ +-----------+---------------------+---------------------------+
| 64 | 23 | 82 | | 64 | 23 | 82 |
| 128 | 67 | 146 | | 128 | 67 | 146 |
| 1000 | 10 | 1018 | | 1000 | 10 | 1018 |
+-----------+---------------------+-----------------+ +-----------+---------------------+---------------------------+
Note that the table of proportions also allows non-standard packet Note that the table of proportions also allows non-standard packet
sizes, but trades the short genome specification and ability to sizes, but trades the short genome specification and ability to
specify the exact sequence for other flexibilities. specify the exact sequence for other flexibilities.
If a pseudo-random 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 pseudo-random generation algorithms and seeds
SHOULD be reported when used.
6. Security Considerations 6. Security Considerations
Benchmarking activities as described in this memo are limited to Benchmarking activities as described in this memo are limited to
technology characterization using controlled stimuli in a laboratory technology characterization using controlled stimuli in a laboratory
environment, with dedicated address space and the other constraints environment, with dedicated address space and the other constraints
[RFC2544]. [RFC2544].
The benchmarking network topology will be an independent test setup The benchmarking network topology will be an independent test setup
and MUST NOT be connected to devices that may forward the test and MUST NOT be connected to devices that may forward the test
traffic into a production network, or misroute traffic to the test traffic into a production network, or misroute traffic to the test
skipping to change at page 8, line 44 skipping to change at page 9, line 17
from the DUT/SUT SHOULD be identical in the lab and in production from the DUT/SUT SHOULD be identical in the lab and in production
networks. networks.
7. IANA Considerations 7. IANA Considerations
This memo makes no requests of IANA, and hopes that IANA will leave This memo makes no requests of IANA, and hopes that IANA will leave
it alone as well. it alone as well.
8. Acknowledgements 8. Acknowledgements
Thanks to Sarah Banks, Aamer Akhter, and Steve Maxwell for their Thanks to Sarah Banks, Aamer Akhter, Steve Maxwell, and Scott Bradner
reviews and comments. Ilya Varlashkin suggested the run-length for their reviews and comments. Ilya Varlashkin suggested the run-
coding approach in Section 5. length coding approach in Section 5.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999. Network Interconnect Devices", RFC 2544, March 1999.
9.2. Informative References 9.2. Informative References
 End of changes. 9 change blocks. 
27 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/