1. IPv6 Benchmarking Methodology
Ciprian Popoviciu, Ahmed Hamza, Gunter Van de Velde, Diego Dugatkin
IETF 69, July 22nd 2007
Chicago
draft-ietf-bmwg-ipv6-meth-02

2. draft-ietf-bmwg-ipv6-meth-02
Agenda
Overview
Last Call Review
Last Call Discussion
Next steps
draft-ietf-bmwg-ipv6-meth-02

3. draft-ietf-bmwg-ipv6-meth-02
“A document providing guidance in the area of IPv6 benchmarking would be welcome to organizations (including the US federal agencies mandated to deploy IPv6 on their backbone networks) attempting to understand why and how network device IPv6 performance must be tested. A document that attempts to define which areas need to considered and which describes how to test/benchmark these areas may be well received.” Bill Cerveny
Overview:
Complements RFC2544 by:
Adds benchmarking methodology recommendations that address specific aspects of IPv6 protocol architecture
Provide an updated list of benchmarks based on the experience gained with applying the RFC2544 recommendations to IPv4
Adds information related to SONET as a popular media type not mentioned by RFC2544
Went through several rounds of review within BMWG and v6ops WG
draft-ietf-bmwg-ipv6-meth-02

4. draft-ietf-bmwg-ipv6-meth-02
Overview (cont.)
Interest
Expressed by networking and test tool vendors
There is at least one implementation of the draft in a benchmarking suite
Used in benchmarking related to the OMB and DoD IPv6 mandates.
Timeline
Voted WG Working Item during the Montreal IETF 66th meeting
Currently in final WG Last Call until August 10
draft-ietf-bmwg-ipv6-meth-02

5. draft-ietf-bmwg-ipv6-meth-02
Last Call Review
Official Last Call reviews by:
Scott Bradner
Bill Cerveny
Rajiv Asati
All points made by the reviewers are addressed in version: draft-ietf-bmwg-ipv6-meth-02
The reviews and the resolution of points made are documented at:
draft-ietf-bmwg-ipv6-meth-02

6. draft-ietf-bmwg-ipv6-meth-02
Last Call Discussion
Additional comments and recommendations from:
David Newman (Topic: maximum throughput)
Dan Romascanu, Scott Bradner, David Newman (Topic: jumbo frames)
Timmons Player, Curtis Villamizar, Scott Bradner (Topic: back-to-back test)
Scott Bradner (Topic: throughput definition)
All these topics were addressed as documented in:
draft-ietf-bmwg-ipv6-meth-02

7. draft-ietf-bmwg-ipv6-meth-02
Last Call Discussion (Cont.)
One open item:
David Newman (Topic: SONET minimum frame size and accounting for the presence of signature fields in packets)
Proposed resolution:
Ethernet: 64, 128, 256, 512, 1024, 1280, 1518 bytes
SONET: 47, 64, 128, 256, 512, 1024, 1280, 1518, 2048, 4096 bytes
Include a note for the following topics:
- 47 was chosen as the limit case
- how to select a minimum frame size to include the signature field
draft-ietf-bmwg-ipv6-meth-02

8. draft-ietf-bmwg-ipv6-meth-02
IPv6 Benchmarking test suite: Vendor implementation
RFC2544/IPv6 Benchmark Suite, based on this IETF draft
Traffic Setup enhancements
IP/IPv6 dual stack
Test Setup Additions
IPv6 Extension Headers
IP/IPv6 traffic ratio
draft-ietf-bmwg-ipv6-meth-02

9. draft-ietf-bmwg-ipv6-meth-02
IPv6 Benchmarking test suite: Vendor implementation
Signature = PatternSignature (4B) +
PacketGroupID +
SequenceNumber +
DataIntegrityChecksum +
TimeStamp
(default 20 B) = (variable size 2 to 12, default 4B) +
(optional field, fixed-size = 4 Bytes) +
(optional field, fixed-size = 2 Bytes) +
(optional field, fixed-size = 6 Bytes)
In general, the default “signature” Ixia uses is 20 bytes.  However, the term "signature" is overloaded as it includes several components.
Ingeneral, at the BMWG the term refers with to the sum of various elements that create identification overhead and the corresponding integrity checksums, etc.
Those 20 bytes of identification overhead (aka "signature") are the addition of the Ixia Pattern Signature (“pattern-signature”) itself (variable but usually 4 bytes), and the other 16 bytes coming from the sum of PacketGroupID (4 bytes), Sequence Number (4 bytes), Data Integrity Checksum (2 bytes), and Time Stamp (6 bytes).
However, the pattern-signature and associated fields described above can be manipulated and selected individually, e.g., using IxExplorer, to have smaller total overheads.
For example, the “signature” can be set to only include the pattern-signature, omitting the other fields mentioned above.  Also, Ixia allows the pattern-signature to be manipulated as a variable field that can be set as small as desired (in bytes), and can be user-defined to include any specific pattern (it is not forced to be the default Ixia pattern).  Using less than 2 bytes is not recommended because the likelyhood of having that same pattern randomly appear intermingled within the traffic increases as the size of the pattern decreases.  As general rule-of-thumb, 4-bytes is the recommended size and the default value.
The maximum length for the (user defined) Ixia Pattern-Signature itself is 12 bytes, thus the maximum total overhead is 28 bytes ( ), which includes the other fields of PacketGroupID (4 bytes), Sequence Number (4 bytes), Data Integrity Checksum (2 bytes), and Time Stamp (6 bytes).
1) What is the length of the Signature that IXIA uses in packets for testing purposes (to check delay, out of order, etc)?
Typically is 20 bytes, but is variable and can be flexibly adjusted by the user between 2 bytes and 28 bytes.  Less than 4 bytes is typically not recommended.
2) Is the length of the field variable or fixed?
Variable.
3) Since the concept was introduced, did IXIA change the lenght of the field?
Yes.  It was made variable to accommodate different signature sizes and provide flexibility to select all, some or none of the possible identification and integrity fields that collectively result in the overhead generally called “signature” (which includes the pattern-signature itself, too).
4) Are there any plans to increase the field?
No; not beyond the current pattern-signature itself (“Ixia Signature”) plus the additional 16 bytes for the other identification and integrity fields (PacketGroupID, Sequence Number, Data Integrity Checksum, Time Stamp) mentioned above.
One of the topics discussed at IETF65 was related to the IANA section for this draft and some discussion is included in the BMWG proceedings.
There was a bias for obtaining a dedicated IPv6 range in similar fashion as what is available for IPv4 benchmarking through rfc2544.
draft-ietf-bmwg-ipv6-meth-02

10. draft-ietf-bmwg-ipv6-meth-02
Next Steps
The draft is currently in a final Last Call for the period: 14 July 2007 through 10 August 2007
Next Steps:
Reach agreement on the last open item: minimum frame size for SONET and inclusion of signature field
Include any additional comments
Deliver the final version of the draft for publication
draft-ietf-bmwg-ipv6-meth-02

11. draft-ietf-bmwg-ipv6-meth-02
THANK YOU!
draft-ietf-bmwg-ipv6-meth-02

12. draft-ietf-bmwg-ipv6-meth-02
Document Goals:
Address a very acute and growing need for recommendations on evaluating network element performance for IPv6 deployments
A complement rather than a replacement of RFC2544 in accordance with BMWG strategy
Provide the additional, IPv6 specific guidelines to IP benchmarking while indicating the aspects of RFC2544 that are IP version independent
Maintain the structure and spirit of RFC2544.
draft-ietf-bmwg-ipv6-meth-02

13. draft-ietf-bmwg-ipv6-meth-02
WG Feedback:
List of Reviewers from BMWG and V6OPS WGs : Scott Bradner, Al Morton, Fred Baker, Pekka Savola, Brian Carpenter, Tim Chown, Benoit Lourdelet, Daniel Roesen, Jerry Perser, William Cerveny , Athanassios Liakopoulos, Rajiv Papneja, Sven Lanckmans, Silvija Dry, Aamer Akhter, Rajiv Asati, David Newman, Jim Mcquaid, Timmons Player, Miles McCredie, Curtis Villamizar.
IPv6 and Test tools experts reviewed and provided valuable feedback off the BMWG alias.
Thank you to all reviewers!
draft-ietf-bmwg-ipv6-meth-02