draft-ietf-bmwg-hash-stuffing-01.txt   draft-ietf-bmwg-hash-stuffing-02.txt 
Network Working Group D. Newman Network Working Group D. Newman
Internet-Draft Network Test Internet-Draft Network Test
Expires: April 21, 2005 T. Player Expires: August 19, 2005 T. Player
Spirent Communications Spirent Communications
October 21, 2004 February 15, 2005
Hash and Stuffing: Overlooked Factors in Network Device Benchmarking Hash and Stuffing: Overlooked Factors in Network Device Benchmarking
draft-ietf-bmwg-hash-stuffing-01.txt draft-ietf-bmwg-hash-stuffing-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 37
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 21, 2005. This Internet-Draft will expire on August 19, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
Test engineers take pains to declare all factors that affect a given Test engineers take pains to declare all factors that affect a given
measurement, including offered load, packet length, test duration, measurement, including offered load, packet length, test duration,
and traffic orientation. However, current benchmarking practice and traffic orientation. However, current benchmarking practice
overlooks two factors that have a profound impact on test results. overlooks two factors that have a profound impact on test results.
First, existing methodologies do not require the reporting of First, existing methodologies do not require the reporting of
addresses or other test traffic contents, even though these fields addresses or other test traffic contents, even though these fields
can affect test results. Second, "stuff" bits and bytes inserted in can affect test results. Second, "stuff" bits and bytes inserted in
skipping to change at page 2, line 38 skipping to change at page 2, line 39
5.2.1 Calculating Bit-Stuffing Probability . . . . . . . . . 14 5.2.1 Calculating Bit-Stuffing Probability . . . . . . . . . 14
5.2.2 Bit Stuffing for Finite Strings . . . . . . . . . . . 15 5.2.2 Bit Stuffing for Finite Strings . . . . . . . . . . . 15
5.2.3 Applied Bit Stuffing . . . . . . . . . . . . . . . . . 15 5.2.3 Applied Bit Stuffing . . . . . . . . . . . . . . . . . 15
5.3 POS Byte Stuffing . . . . . . . . . . . . . . . . . . . . 16 5.3 POS Byte Stuffing . . . . . . . . . . . . . . . . . . . . 16
5.3.1 Nullifying ACCM . . . . . . . . . . . . . . . . . . . 16 5.3.1 Nullifying ACCM . . . . . . . . . . . . . . . . . . . 16
5.3.2 Other Stuffed Characters . . . . . . . . . . . . . . . 17 5.3.2 Other Stuffed Characters . . . . . . . . . . . . . . . 17
5.3.3 Applied Byte Stuffing . . . . . . . . . . . . . . . . 17 5.3.3 Applied Byte Stuffing . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 8.1 Normative References . . . . . . . . . . . . . . . . . . . 20
8.2 Informative References . . . . . . . . . . . . . . . . . . . 20 8.2 Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . 23
1. Introduction 1. Introduction
Experience in benchmarking networking devices suggests that the Experience in benchmarking networking devices suggests that the
contents of test traffic can have a profound impact on test results. contents of test traffic can have a profound impact on test results.
For example, some devices may forward randomly addressed traffic For example, some devices may forward randomly addressed traffic
without loss, but drop significant numbers of packets when offered without loss, but drop significant numbers of packets when offered
skipping to change at page 10, line 19 skipping to change at page 10, line 19
RECOMMENDED that uniformly random values between 0 and 1,048,575 be RECOMMENDED that uniformly random values between 0 and 1,048,575 be
used for all labels assigned by test equipment. used for all labels assigned by test equipment.
4.4 Network-layer Addressing 4.4 Network-layer Addressing
Routers make forwarding decisions based on destination network Routers make forwarding decisions based on destination network
address. Since there is no hashing of source and destination address. Since there is no hashing of source and destination
addresses, the requirement for pseudorandom patterns at the network addresses, the requirement for pseudorandom patterns at the network
layer is far less critical than in the Ethernet MAC address case. layer is far less critical than in the Ethernet MAC address case.
However, there are cases where randomly distributed IPv4 addresses However, there are cases where randomly distributed IPv4 and/or IPv6
are desirable. For example, the equal cost multipath (ECMP) feature addresses are desirable. For example, the equal cost multipath
performs load-sharing across multiple links. Routers implementing (ECMP) feature performs load-sharing across multiple links. Routers
ECMP may perform a hash of source and destination IP addresses in implementing ECMP may perform a hash of source and destination IP
assigning flows. addresses in assigning flows.
Since multiple ECMP routes by definition have the same metric, Since multiple ECMP routes by definition have the same metric,
routers use some other "tiebreaker" mechanism to assign traffic to routers use some other "tiebreaker" mechanism to assign traffic to
each link. As far as the authors are aware, there is no standard each link. As far as the authors are aware, there is no standard
algorithm for ECMP link assignment. Some implementations perform a algorithm for ECMP link assignment. Some implementations perform a
hash of all bits of the source and destination IP addresses for this hash of all bits of the source and destination IP addresses for this
purpose. purpose.
Just as in the case of MAC addresses, nonrandom IP addresses can have Just as in the case of MAC addresses, nonrandom IP addresses can have
an adverse effect on the outcome of ECMP link assignment decisions. an adverse effect on the outcome of ECMP link assignment decisions.
skipping to change at page 17, line 39 skipping to change at page 17, line 39
When testing a DUT/SUT that implements PPP in HDLC-like framing and When testing a DUT/SUT that implements PPP in HDLC-like framing and
L2TP (or any other technology that uses nonzero ACCM values), it is L2TP (or any other technology that uses nonzero ACCM values), it is
RECOMMENDED that testers reduce the maximum offered load by 13.3 RECOMMENDED that testers reduce the maximum offered load by 13.3
percent to avoid introducing congestion. percent to avoid introducing congestion.
When testing a DUT/SUT that implements PPP in HDLC-like framing and When testing a DUT/SUT that implements PPP in HDLC-like framing and
an ACCM value of 0x00, it is RECOMMENDED that testers reduce the an ACCM value of 0x00, it is RECOMMENDED that testers reduce the
maximum offered load by 0.8 percent to avoid introducing congestion. maximum offered load by 0.8 percent to avoid introducing congestion.
Note that the percentages given above are approximations. For Note that the percentages given above are approximations. For
greatest precision, the actual offered load should be calculated from greatest precision, the actual offered load should be calculated
the % overhead formula above and expressed in frames per second using the percentage overhead formula above and then expressed in
rather than percentage of line rate as the unit of measurement. frames per second (rounded down to the nearest integer).
Note also that the DUT/SUT may be able to forward offered loads Note also that the DUT/SUT may be able to forward offered loads
higher than the calculated theoretical maximum without packet loss. higher than the calculated theoretical maximum without packet loss.
Such results are the result of queuing on the part of the DUT/SUT. Such results are the result of queuing on the part of the DUT/SUT.
While a device's throughput may be above this level, delay-related While a device's throughput may be above this level, delay-related
measurements such as latency or jitter may be affected. Accordingly, measurements such as latency or jitter may be affected. Accordingly,
it is RECOMMENDED to reduce offered levels by the amount of it is RECOMMENDED to reduce offered levels by the amount of
byte-stuffing overhead when testing devices using byte-synchronous byte-stuffing overhead when testing devices using byte-synchronous
links. This recommendation applies for all measurements, including links. This recommendation applies for all measurements, including
throughput. throughput.
skipping to change at page 20, line 25 skipping to change at page 20, line 25
[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.
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, [RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615,
June 1999. June 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
2661, August 1999. RFC 2661, August 1999.
[RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology [RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology
for LAN Switching Devices", RFC 2889, August 2000. for LAN Switching Devices", RFC 2889, August 2000.
8.2 Informative References 8.2 Informative References
[Ca63] Campbell, D. and J. Stanley, "Experimental and [Ca63] Campbell, D. and J. Stanley, "Experimental and
Quasi-Experimental Designs for Research", 1963. Quasi-Experimental Designs for Research", 1963.
[Go97] Goralski, W., "SONET: A Guide to Synchronous Optical [Go97] Goralski, W., "SONET: A Guide to Synchronous Optical
Networks", 1997. Networks", 1997.
[Kn97] Knuth, D., "The Art of Computer Programming, Volume 2, Third [Kn97] Knuth, D., "The Art of Computer Programming, Volume 2, Third
Edition", 1997. Edition", 1997.
Authors' Addresses Authors' Addresses
David Newman David Newman
Network Test Network Test
EMail: dnewman@networktest.com Email: dnewman@networktest.com
Timmons C. Player Timmons C. Player
Spirent Communications Spirent Communications
EMail: timmons.player@spirentcom.com Email: timmons.player@spirentcom.com
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors gratefully acknowledge reviews and contributions by Glenn The authors gratefully acknowledge reviews and contributions by Glenn
Chagnot, Rafael Francis, Paul Hoffman, David Joyner, Joe Perches, and Chagnot, Rafael Francis, Paul Hoffman, David Joyner, Joe Perches, and
Scott Poretsky. Scott Poretsky.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
skipping to change at page 23, line 46 skipping to change at page 23, line 46
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/