draft-ietf-bmwg-imix-genome-00.txt   draft-ietf-bmwg-imix-genome-01.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Informational October 20, 2011 Intended status: Informational January 8, 2012
Expires: April 22, 2012 Expires: July 11, 2012
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-00 draft-ietf-bmwg-imix-genome-01
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 April 22, 2012. This Internet-Draft will expire on July 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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 . . . . . . . . . . . . . . . . 6
5. Reporting Long or Pseudo-Random Packet Sequences . . . . . . . 7 5. Reporting Long or Pseudo-Random Packet Sequences . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
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
skipping to change at page 6, line 12 skipping to change at page 6, line 12
While this approach allows some flexibility, there are also While this approach allows some flexibility, there are also
constraints. constraints.
o Non-RFC2544 packet sizes would need to be approximated by those o Non-RFC2544 packet sizes would need to be approximated by those
available in the table. available in the table.
o The Genome for very long sequences can become undecipherable by o The Genome for very long sequences can become undecipherable by
humans. humans.
o z=MTU is seen as valuable (so far). o z=MTU is seen as valuable, so MTU MUST be specified if used.
o Whether more tabulated packet sizes would be useful is TBD, and o Whether more tabulated packet sizes would be useful is TBD, and
"jumbo" sizes were added in this version. "jumbo" sizes were added in this version.
Some questions testers must ask and answer when using the IMIX Genome Some questions testers must ask and answer when using the IMIX Genome
are: are:
1. Multiple Source-Destination Address Pairs: is the IMIX sequence 1. Multiple Source-Destination Address Pairs: is the IMIX sequence
applicable to each pair, across multiple pairs in sets, or across applicable to each pair, across multiple pairs in sets, or across
all pairs? all pairs?
2. Multiple Tester Ports:is the IMIX sequence applicable to each 2. Multiple Tester Ports: is the IMIX sequence applicable to each
port, across multiple ports in sets, or across all ports? port, across multiple ports in sets, or across all ports?
The chosen configuration would be expressed the following general The chosen configuration would be expressed the following general
form: form:
+-----------------------+-------------------------+-----------------+ +-----------------------+-------------------------+-----------------+
| Source | Destination | Corresponding | | Source | Destination | Corresponding |
| Address/Port/Blade | Address/Port/Blade | IMIX | | Address/Port/Blade | Address/Port/Blade | IMIX |
+-----------------------+-------------------------+-----------------+ +-----------------------+-------------------------+-----------------+
| x.x.x.x Blade2 | y.y.y.y Blade3 | IMIX - aaafg | | x.x.x.x Blade2 | y.y.y.y Blade3 | IMIX - aaafg |
skipping to change at page 7, line 26 skipping to change at page 7, line 26
+-------------+--------------------+ +-------------+--------------------+
For example: a five packet sequence with sizes aaa,aaa,aaa,ggg,ggg For example: a five packet sequence with sizes aaa,aaa,aaa,ggg,ggg
would be designated: would be designated:
CUSTOM IMIX - AAAGG CUSTOM IMIX - AAAGG
5. Reporting Long or Pseudo-Random Packet Sequences 5. Reporting Long or Pseudo-Random Packet Sequences
When the IMIX-Genome cannot be used (when the sheer length of the When the IMIX-Genome cannot be used (when the sheer length of the
sequence would make the genome unmanageable) or when the sequence is sequence would make the genome unmanageable), two options are
designed to vary within some proportional constraints, a table is possible. When a sequence can be decomposed into a series of short
necessary. repeating sequences, then a run-length encoding approach MAY be used
as shown below:
+------------------------------+----------------------+
| Count of Repeating Sequences | Packet Size Sequence |
+------------------------------+----------------------+
| 20 | abcd |
| 5 | ggga |
| 10 | dcba |
+------------------------------+----------------------+
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 | Other Length(s) | | IP Length | Percentage of Total | Other Length(s) |
+-----------+---------------------+-----------------+ +-----------+---------------------+-----------------+
| 64 | 23 | 82 | | 64 | 23 | 82 |
| 128 | 67 | 146 | | 128 | 67 | 146 |
| 1000 | 10 | 1018 | | 1000 | 10 | 1018 |
+-----------+---------------------+-----------------+ +-----------+---------------------+-----------------+
Note that this approach also allows non-standard packet sizes, but Note that the table of proportions also allows non-standard packet
trades the short genome specification and ability to specify the sizes, but trades the short genome specification and ability to
exact sequence for other flexibilities. specify the exact sequence for other flexibilities.
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
skipping to change at page 8, line 23 skipping to change at page 8, line 45
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, and Steve Maxwell for their
review and comments. review and comments. Ilya Varlashkin suggested the run-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. 12 change blocks. 
19 lines changed or deleted 32 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/