draft-ietf-bmwg-2544-as-01.txt   draft-ietf-bmwg-2544-as-02.txt 
Network Working Group S. Bradner Network Working Group S. Bradner
Internet-Draft Harvard University Internet-Draft Harvard University
Intended status: Informational K. Dubray Intended status: Informational K. Dubray
Expires: April 22, 2012 Juniper Networks Expires: September 13, 2012 Juniper Networks
J. McQuaid J. McQuaid
Turnip Video Turnip Video
A. Morton A. Morton
AT&T Labs AT&T Labs
October 20, 2011 March 12, 2012
RFC 2544 Applicability Statement: Use on Production Networks Considered RFC 2544 Applicability Statement: Use on Production Networks Considered
Harmful Harmful
draft-ietf-bmwg-2544-as-01 draft-ietf-bmwg-2544-as-02
Abstract Abstract
Benchmarking Methodology Working Group (BMWG) has been developing key Benchmarking Methodology Working Group (BMWG) has been developing key
performance metrics and laboratory test methods since 1990, and performance metrics and laboratory test methods since 1990, and
continues this work at present. Recent application of the methods continues this work at present. Recent application of the methods
beyond their intended scope is cause for concern. This memo beyond their intended scope is cause for concern. This memo
clarifies the scope of RFC 2544 and other benchmarking work for the clarifies the scope of RFC 2544 and other benchmarking work for the
IETF community. IETF community.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 September 13, 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
skipping to change at page 3, line 11 skipping to change at page 3, line 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
This memo clarifies the scope of RFC 2544 [RFC2544], and other This memo clarifies the scope of RFC 2544 [RFC2544], and other
benchmarking work for the IETF community. benchmarking work for the IETF community.
Benchmarking Methodologies (beginning with [RFC2544]) have always Benchmarking Methodologies (beginning with [RFC2544]) have always
relied on test conditions that can only be reliably produced in the relied on test conditions that can only be produced and replicated
laboratory. Thus it was surprising to find that this foundation reliably in the laboratory. Thus it was surprising to find that this
methodology was being cited in several unintended applications, such foundation methodology was being cited in several unintended
as: applications, such as:
1. Validation of telecommunication service configuration, such as 1. Validation of telecommunication service configuration, such as
the Committed Information Rate (CIR). the Committed Information Rate (CIR).
2. Validation of performance metrics in a telecommunication Service 2. Validation of performance metrics in a telecommunication Service
Level Agreement (SLA), such as frame loss and latency. Level Agreement (SLA), such as frame loss and latency.
3. As an integral part of telecommunication service activation 3. As an integral part of telecommunication service activation
testing, where traffic that shares network resources with the testing, where traffic that shares network resources with the
test might be adversely affected. test might be adversely affected.
Above, we distinguish "telecommunication service" (where a network Above, we distinguish "telecommunication service" (where a network
service provider contracts with a customer to transfer information service provider contracts with a customer to transfer information
between specified interfaces at different geographic locations in the between specified interfaces at different geographic locations) from
real world) from the generic term "service". Also, we use the the generic term "service". Also, we use the adjective "production"
adjective "production" to refer to networks carrying live user to refer to networks carrying live user traffic. [RFC2544] used the
traffic. [RFC2544] used the term "real-world" to refer production term "real-world" to refer to production networks and to
networks and to differentiate them from test networks. differentiate them from test networks.
Although RFC 2544 is held up as the standard reference for such Although RFC 2544 is held up as the standard reference for such
testing, we believe that the actual methods used vary from RFC 2544 testing, we believe that the actual methods used vary from RFC 2544
in significant ways. Since the only citation is to RFC 2544, the in significant ways. Since the only citation is to RFC 2544, the
modifications are opaque to the standards community and to users in modifications are opaque to the standards community and to users in
general (an undesirable situation). general (an undesirable situation).
To directly address this situation, the past and present Chairs of To directly address this situation, the past and present Chairs of
the IETF Benchmarking Methodology Working Group (BMWG) have prepared the IETF Benchmarking Methodology Working Group (BMWG) have prepared
this Applicability Statement for RFC 2544. this Applicability Statement for RFC 2544.
skipping to change at page 5, line 13 skipping to change at page 5, line 13
that causes packet/frame loss. Any other sources of traffic on the that causes packet/frame loss. Any other sources of traffic on the
network will cause packet loss to occur at a tester data rate lower network will cause packet loss to occur at a tester data rate lower
than the rate that would be achieved without the extra traffic. than the rate that would be achieved without the extra traffic.
4.2. Containment of Implementation Failure Impact 4.2. Containment of Implementation Failure Impact
RFC 2544 methods, specifically to determine Throughput as defined in RFC 2544 methods, specifically to determine Throughput as defined in
[RFC1242] and other benchmarks, may overload the resources of the [RFC1242] and other benchmarks, may overload the resources of the
device under test, and may cause failure modes in the device under device under test, and may cause failure modes in the device under
test. Since failures can become the root cause of more wide-spread test. Since failures can become the root cause of more wide-spread
failure, it is clearly desirable to contain all DUT traffic within failure, it is clearly desirable to contain all test traffic within
the ITE. the ITE.
In addition, such testing can have a negative affect on any traffic In addition, such testing can have a negative affect on any traffic
which shares resources with the test stream(s) since, in most cases, which shares resources with the test stream(s) since, in most cases,
the traffic load will be close to the capacity of the network links. the traffic load will be close to the capacity of the network links.
Appendix C.2.2 of [RFC2544] (as adjusted by errata) gives the private Appendix C.2.2 of [RFC2544] (as adjusted by errata) gives the private
IPv4 address range for testing: IPv4 address range for testing:
"...The network addresses 198.18.0.0 through 198.19.255.255 have been "...The network addresses 198.18.0.0 through 198.19.255.255 have been
skipping to change at page 6, line 4 skipping to change at page 6, line 4
The tests in [RFC2544] were designed to measure the performance of The tests in [RFC2544] were designed to measure the performance of
network devices, not of networks, and certainly not production network devices, not of networks, and certainly not production
networks carrying user traffic on shared resources. There will be networks carrying user traffic on shared resources. There will be
unanticipated difficulties when applying these methods outside the unanticipated difficulties when applying these methods outside the
lab environment. lab environment.
Operating test equipment on production networks according to the Operating test equipment on production networks according to the
methods described in [RFC2544], where overload is a possible outcome, methods described in [RFC2544], where overload is a possible outcome,
would no doubt be harmful to user traffic performance. These tests would no doubt be harmful to user traffic performance. These tests
MUST NOT be used on active networks. And as discussed above, the MUST NOT be used on production networks and as discussed above, the
tests will never produce a reliable or accurate benchmarking result. tests will never produce a reliable or accurate benchmarking result
on a production network.
[RFC2544] methods have never been validated on a network path, even [RFC2544] methods have never been validated on a network path, even
when that path is not part of a production network and carrying no when that path is not part of a production network and carrying no
other traffic. It is unknown whether the tests can be used to other traffic. It is unknown whether the tests can be used to
measure valid and reliable performance of a multi-device, multi- measure valid and reliable performance of a multi-device, multi-
network path. It is possible that some of the tests may prove to be network path. It is possible that some of the tests may prove valid
valid in some path scenarios, but that work has not been done or has in some path scenarios, but that work has not been done or has not
not been shared with the IETF community. Thus, such testing is been shared with the IETF community. Thus, such testing is contra-
contra-indicated by the BMWG. indicated by the BMWG.
6. What to do without RFC 2544? 6. What to do without RFC 2544?
The IETF has addressed the problem of production network performance The IETF has addressed the problem of production network performance
measurement by chartering a different working group: IP Performance measurement by chartering a different working group: IP Performance
Metrics (IPPM). This working group has developed a set of standard Metrics (IPPM). This working group has developed a set of standard
metrics to assess the quality, performance, and reliability of metrics to assess the quality, performance, and reliability of
Internet packet transfer services. These metrics can be measured by Internet packet transfer services. These metrics can be measured by
network operators, end users, or independent testing groups. We note network operators, end users, or independent testing groups. We note
that some IPPM metrics differ from RFC 2544 metrics with similar that some IPPM metrics differ from RFC 2544 metrics with similar
names, and there is likely to be confusion if the details are names, and there is likely to be confusion if the details are
ignored. ignored.
IPPM has not standardized methods for raw capacity measurement of IPPM has not yet standardized methods for raw capacity measurement of
Internet paths. Such testing needs to adequately consider the strong Internet paths. Such testing needs to adequately consider the strong
possibility for degradation to any other traffic that may be present possibility for degradation to any other traffic that may be present
due to congestion. There are no specific methods proposed for due to congestion. There are no specific methods proposed for
activation of a packet transfer service in IPPM. activation of a packet transfer service in IPPM.
Other standards may help to fill gaps in telecommunication service Other standards may help to fill gaps in telecommunication service
testing. For example, the IETF has many standards intended to assist testing. For example, the IETF has many standards intended to assist
with network operation, administration and maintenance (OAM), the with network operation, administration and maintenance (OAM), and
ITU-T Study Group 12 has a recommendation on service activation test ITU-T Study Group 12 has a recommendation on service activation test
methodology. methodology.
The world will not spin off axis while waiting for appropriate and The world will not spin off axis while waiting for appropriate and
standardized methods to emerge from the consensus process. standardized methods to emerge from the consensus process.
7. Security Considerations 7. Security Considerations
This Applicability Statement is also intended to help preserve the This Applicability Statement is also intended to help preserve the
security of the Internet by clarifying that the scope of [RFC2544] security of the Internet by clarifying that the scope of [RFC2544]
and other BMWG memos are all limited to testing in laboratory ITE, and other BMWG memos are all limited to testing in a laboratory ITE,
thus avoiding accidental Denial of Service attacks or congestion due thus avoiding accidental Denial of Service attacks or congestion due
to high traffic volume test streams. to high traffic volume test streams.
All Benchmarking activities are limited to technology All Benchmarking activities are limited to technology
characterization using controlled stimuli in a laboratory 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 7, line 31 skipping to change at page 7, line 32
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.
8. IANA Considerations 8. 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.
9. Acknowledgements 9. Acknowledgements
Thanks to Matt Zekauskas, Bill Cerveny, Barry Constantine, and Curtis Thanks to Matt Zekauskas, Bill Cerveny, Barry Constantine, Curtis
Villamizar for reading and suggesting improvements for this memo. Villamizar, and David Newman for reading and suggesting improvements
to this memo.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC1242] Bradner, S., "Benchmarking terminology for network [RFC1242] Bradner, S., "Benchmarking terminology for network
interconnection devices", RFC 1242, July 1991. interconnection devices", RFC 1242, July 1991.
[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.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D.
Dugatkin, "IPv6 Benchmarking Methodology for Network Dugatkin, "IPv6 Benchmarking Methodology for Network
Interconnect Devices", RFC 5180, May 2008. Interconnect Devices", RFC 5180, May 2008.
10.2. Informative References 10.2. Informative References
Authors' Addresses Authors' Addresses
Scott Bradner Scott Bradner
Harvard University Harvard University
 End of changes. 15 change blocks. 
29 lines changed or deleted 28 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/