draft-ietf-bmwg-traffic-management-03.txt   draft-ietf-bmwg-traffic-management-04.txt 
Network Working Group B. Constantine Network Working Group B. Constantine
Internet Draft JDSU Internet Draft JDSU
Intended status: Informational R. Krishnan Intended status: Informational R. Krishnan
Expires: August 2015 Brocade Communications Expires: September 2015 Brocade Communications
February 23, 2015 March 29, 2015
Traffic Management Benchmarking Traffic Management Benchmarking
draft-ietf-bmwg-traffic-management-03.txt draft-ietf-bmwg-traffic-management-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 23, 2015. This Internet-Draft will expire on September 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 14, line 54 skipping to change at page 14, line 54
(LAG). This would result in the same scheduling and shaping (LAG). This would result in the same scheduling and shaping
configuration applied to all the member physical ports. The focus of configuration applied to all the member physical ports. The focus of
this draft is only on tests at a physical port level. this draft is only on tests at a physical port level.
The following sections provide the objective, procedure, metrics, and The following sections provide the objective, procedure, metrics, and
reporting format for each test. For all test steps, the following reporting format for each test. For all test steps, the following
global parameters must be specified: global parameters must be specified:
Test Runs (Tr). Defines the number of times the test needs to be run Test Runs (Tr). Defines the number of times the test needs to be run
to ensure accurate and repeatable results. The recommended value is to ensure accurate and repeatable results. The recommended value is
3. a minimum of 10.
Test Duration (Td). Defines the duration of a test iteration, Test Duration (Td). Defines the duration of a test iteration,
expressed in seconds. The recommended minimum value is 60 seconds. expressed in seconds. The recommended minimum value is 60 seconds.
The variability in the test results MUST be measured between Test The variability in the test results MUST be measured between Test
Runs and if the variation is characterized as a significant portion Runs and if the variation is characterized as a significant portion
of the measured values, the next step may be to revise the methods to of the measured values, the next step may be to revise the methods to
achieve better consistency. achieve better consistency.
6.1. Policing Tests 6.1. Policing Tests
A policer is defined as the entity performing the policy function. A policer is defined as the entity performing the policy function.
The intent of the policing tests is to verify the policer performance The intent of the policing tests is to verify the policer performance
(i.e. CIR-CBS and EIR-EBS parameters). The tests will verify that the (i.e. CIR-CBS and EIR-EBS parameters). The tests will verify that the
network device can handle the CIR with CBS and the EIR with EBS and network device can handle the CIR with CBS and the EIR with EBS and
will use back-back packet testing concepts from [RFC2544] (but will use back-back packet testing concepts from [RFC2544] (but
adapted to burst size algorithms and terminology). Also MEF-14,19, adapted to burst size algorithms and terminology). Also [MEF-14],
37 provide some basis for specific components of this test. The [MEF-19], and [MEF-37] provide some basis for specific components of
burst hunt algorithm defined in section 5.1.1 can also be used to this test. The burst hunt algorithm defined in section 5.1.1 can
automate the measurement of the CBS value. also be used to automate the measurement of the CBS value.
The tests are divided into two (2) sections; individual policer The tests are divided into two (2) sections; individual policer
tests and then full capacity policing tests. It is important to tests and then full capacity policing tests. It is important to
benchmark the basic functionality of the individual policer then benchmark the basic functionality of the individual policer then
proceed into the fully rated capacity of the device. This capacity proceed into the fully rated capacity of the device. This capacity
may include the number of policing policies per device and the may include the number of policing policies per device and the
number of policers simultaneously active across all ports. number of policers simultaneously active across all ports.
6.1.1 Policer Individual Tests 6.1.1 Policer Individual Tests
skipping to change at page 32, line 38 skipping to change at page 32, line 38
- Policers on ingress and queuing on egress - Policers on ingress and queuing on egress
- Policers on ingress and shapers on egress (not intended for a - Policers on ingress and shapers on egress (not intended for a
flow to be policed then shaped, these would be two different flow to be policed then shaped, these would be two different
flows tested at the same time) flows tested at the same time)
- etc. - etc.
The test procedures and reporting formatting from the previous The test procedures and reporting formatting from the previous
sections may be modified to accommodate the capacity test profile. sections may be modified to accommodate the capacity test profile.
Appendix A: Open Source Tools for Traffic Management Testing Appendix A: Open Source Tools for Traffic Management Testing
This framework specifies that stateless and stateful behaviors SHOULD This framework specifies that stateless and stateful behaviors SHOULD
both be tested. Four (4) open source tools that can be used are both be tested. Some open source tools that can be used to
iperf, netperf (with netperf-wrapper), uperf, and TMIX to accomplish accomplish many of the tests proposed in this framework are:
many of the tests proposed in this framework. iperf, netperf (with netperf-wrapper),uperf, TMIX,
TCP-incast-generator, and D-ITG (Distributed Internet Traffic
Generator).
Iperf can generate UDP or TCP based traffic; a client and server must Iperf can generate UDP or TCP based traffic; a client and server must
both run the iperf software in the same traffic mode. The server is both run the iperf software in the same traffic mode. The server is
set up to listen and then the test traffic is controlled from the set up to listen and then the test traffic is controlled from the
client. Both uni-directional and bi-directional concurrent testing client. Both uni-directional and bi-directional concurrent testing
are supported. are supported.
The UDP mode can be used for the stateless traffic testing. The The UDP mode can be used for the stateless traffic testing. The
target bandwidth, packet size, UDP port, and test duration can be target bandwidth, packet size, UDP port, and test duration can be
controlled. A report of bytes transmitted, packets lost, and delay controlled. A report of bytes transmitted, packets lost, and delay
variation are provided by the iperf receiver. variation are provided by the iperf receiver.
The TCP mode can be used for stateful traffic testing to test bulk Iperf (TCP mode), TCP-incast-generator, and D-ITG can be used for
transfer traffic. The TCP Window size (which is actually the SSB), stateful traffic testing to test bulk transfer traffic. The TCP
the number of connections, the packet size, TCP port and the test Window size (which is actually the SSB), the number of connections,
duration can be controlled. A report of bytes transmitted and the packet size, TCP port and the test duration can be controlled.
throughput achieved are provided by the iperf sender. A report of bytes transmitted and throughput achieved are provided
by the iperf sender, while TCP-incast-generator and D-ITG provide
even more statistics.
Netperf is a software application that provides network bandwidth Netperf is a software application that provides network bandwidth
testing between two hosts on a network. It supports Unix domain testing between two hosts on a network. It supports Unix domain
sockets, TCP, SCTP, DLPI and UDP via BSD Sockets. Netperf provides sockets, TCP, SCTP, DLPI and UDP via BSD Sockets. Netperf provides
a number of predefined tests e.g. to measure bulk (unidirectional) a number of predefined tests e.g. to measure bulk (unidirectional)
data transfer or request response performance data transfer or request response performance
http://en.wikipedia.org/wiki/Netperf). Netperf-wrapper is a Python http://en.wikipedia.org/wiki/Netperf). Netperf-wrapper is a Python
script that runs multiple simultaneous netperf instances and script that runs multiple simultaneous netperf instances and
aggregate the results. aggregate the results.
skipping to change at page 33, line 28 skipping to change at page 33, line 36
application model descriptor can be based off of empirical data, but application model descriptor can be based off of empirical data, but
currently the import of packet captures is not directly supported. currently the import of packet captures is not directly supported.
Tmix is another application traffic emulation tool and uses packet Tmix is another application traffic emulation tool and uses packet
captures directly to create the traffic profile. The packet trace is captures directly to create the traffic profile. The packet trace is
'reverse compiled' into a source-level characterization, called a 'reverse compiled' into a source-level characterization, called a
connection vector, of each TCP connection present in the trace. While connection vector, of each TCP connection present in the trace. While
most widely used in ns2 simulation environment, TMix also runs on most widely used in ns2 simulation environment, TMix also runs on
Linux hosts. Linux hosts.
Iperf, Netperf-wrapper, uperf, and Tmix's traffic generation These open source tool's traffic generation capabilities facilitate
parameters facilitate the emulation of the TCP test patterns which the emulation of the TCP test patterns which are discussed in
are discussed in Appendix B. Appendix B.
Appendix B: Stateful TCP Test Patterns Appendix B: Stateful TCP Test Patterns
This framework recommends at a minimum the following TCP test This framework recommends at a minimum the following TCP test
patterns since they are representative of real world application patterns since they are representative of real world application
traffic (section 5.2.1 describes some methods to derive other traffic (section 5.2.1 describes some methods to derive other
application-based TCP test patterns). application-based TCP test patterns).
- Bulk Transfer: generate concurrent TCP connections whose aggregate - Bulk Transfer: generate concurrent TCP connections whose aggregate
number of in-flight data bytes would fill the BDP. Guidelines number of in-flight data bytes would fill the BDP. Guidelines
skipping to change at page 35, line 50 skipping to change at page 36, line 5
Max. = 100KB Max. = 1MB Max. = 50KB Max. = 750B Max. = 100KB Max. = 1MB Max. = 50KB Max. = 750B
Number of server Ave. = 50 Ave. = 200 Ave. = 100 Ave. = 15 Number of server Ave. = 50 Ave. = 200 Ave. = 100 Ave. = 15
messages (Ns) Min. = 10 Min. = 25 Min. = 15 Min. = 5 messages (Ns) Min. = 10 Min. = 25 Min. = 15 Min. = 5
Max. = 200 Max. = 1000 Max. = 500 Max. = 40 Max. = 200 Max. = 1000 Max. = 500 Max. = 40
Server processing Ave. = 0.5s Ave. = 1s Ave. = 2s Ave. = 4s Server processing Ave. = 0.5s Ave. = 1s Ave. = 2s Ave. = 4s
time (Tsp)** Min. = 0.1s Min. = 0.5s Min. = 1s Min. = 0.5s time (Tsp)** Min. = 0.1s Min. = 0.5s Min. = 1s Min. = 0.5s
Max. = 5s Max. = 20s Max. = 10s Max. = 15s Max. = 5s Max. = 20s Max. = 10s Max. = 15s
Complex Business Application, eCommerce, and Email Send / Receive
(continued):
Simple Complex
Parameter Biz. App. Biz. App eCommerce* Email
--------------------------------------------------------------------
File size Ave. = 50KB Ave. = 100KB Ave. = N/A Ave. = 100KB File size Ave. = 50KB Ave. = 100KB Ave. = N/A Ave. = 100KB
upload (Su) Min. = 2KB Min. = 10KB Min. = N/A Min. = 20KB upload (Su) Min. = 2KB Min. = 10KB Min. = N/A Min. = 20KB
Max. = 200KB Max. = 2MB Max. = N/A Max. = 10MB Max. = 200KB Max. = 2MB Max. = N/A Max. = 10MB
File size Ave. = 50KB Ave. = 100KB Ave. = N/A Ave. = 100KB File size Ave. = 50KB Ave. = 100KB Ave. = N/A Ave. = 100KB
download (Sd) Min. = 2KB Min. = 10KB Min. = N/A Min. = 20KB download (Sd) Min. = 2KB Min. = 10KB Min. = N/A Min. = 20KB
Max. = 200KB Max. = 2MB Max. = N/A Max. = 10MB Max. = 200KB Max. = 2MB Max. = N/A Max. = 10MB
* eCommerce used a combination of packet capture techniques and * eCommerce used a combination of packet capture techniques and
reference traffic flows from "SPECweb2009" (need proper reference) reference traffic flows from "SPECweb2009" (need proper reference)
** The client and server processing time is distributed across the ** The client and server processing time is distributed across the
transmission / receipt of all of messages. Client processing time transmission / receipt of all of messages. Client processing time
consists mainly of the delay between user interactions (not machine consists mainly of the delay between user interactions (not machine
processing). processing).
And again, the parameters in this table are the guidelines for the And again, the parameters in this table are the guidelines for the
TCP test pattern traffic generation. The test tool can use fixed TCP test pattern traffic generation. The test tool can use fixed
parameters for simpler tests and mathematical distributions for more parameters for simpler tests and mathematical distributions for more
complex tests. However, the test pattern must be repeatable to complex tests. However, the test pattern must be repeatable to
skipping to change at page 37, line 4 skipping to change at page 37, line 26
Max. = 25 Max. = 25
Client processing Ave. = 1ms Client processing Ave. = 1ms
time (Tcp) Min. = 0.5ms time (Tcp) Min. = 0.5ms
Max. = 2 Max. = 2
Server response Ave. = 2KB Server response Ave. = 2KB
size (Srs) Min. = 500B size (Srs) Min. = 500B
Max. = 100KB Max. = 100KB
Number of server Ave. = 10 Number of server Ave. = 10
messages (Ns) Min. = 10 messages (Ns) Min. = 10
Max. = 200 Max. = 200
Server processing Ave. = 1ms
Server processing Ave. = 1ms
time (Tsp) Min. = 0.5ms time (Tsp) Min. = 0.5ms
Max. = 2ms Max. = 2ms
Block Ave. = N/A Block Ave. = N/A
Size (Sb)* Min. = 16KB Size (Sb)* Min. = 16KB
Max. = 128KB Max. = 128KB
*Depending upon the tested file size, the block size will be *Depending upon the tested file size, the block size will be
transferred n number of times to complete the example. An example transferred n number of times to complete the example. An example
would be a 10 MB file test and 64KB block size. In this case 160 would be a 10 MB file test and 64KB block size. In this case 160
blocks would be transferred after the control channel is opened blocks would be transferred after the control channel is opened
skipping to change at page 38, line 23 skipping to change at page 38, line 42
[RFC5481] A. Morton et al., "Packet Delay Variation Applicability [RFC5481] A. Morton et al., "Packet Delay Variation Applicability
Statement," RFC5481 March 2009 Statement," RFC5481 March 2009
[RFC6703] A. Morton et al., "Reporting IP Network Performance [RFC6703] A. Morton et al., "Reporting IP Network Performance
Metrics: Different Points of View." RFC 6703 August 2012 Metrics: Different Points of View." RFC 6703 August 2012
[RFC2680] G. Almes et al., "A One-way Packet Loss Metric for IPPM," [RFC2680] G. Almes et al., "A One-way Packet Loss Metric for IPPM,"
RFC2680 September 1999 RFC2680 September 1999
[RFC2697] J. Heinanen et al., "A Single Rate Three Color Marker,"
RFC2697, September 1999
[RFC2698] J. Heinanen et al., "A Two Rate Three Color Marker, "
RFC2698, September 1999
[RFC4689] S. Poretsky et al., "Terminology for Benchmarking [RFC4689] S. Poretsky et al., "Terminology for Benchmarking
Network-layer Traffic Control Mechanisms," RFC4689, Network-layer Traffic Control Mechanisms," RFC4689,
October 2006 October 2006
[RFC4737] A. Morton et al., "Packet Reordering Metrics," RFC4737, [RFC4737] A. Morton et al., "Packet Reordering Metrics," RFC4737,
February 2006 February 2006
[RFC4115] O. Aboul-Magd et al., "A Differentiated Service Two-Rate, [RFC4115] O. Aboul-Magd et al., "A Differentiated Service Two-Rate,
Three-Color Marker with Efficient Handling of in-Profile Traffic." Three-Color Marker with Efficient Handling of in-Profile Traffic."
RFC4115 July 2005 RFC4115 July 2005
[RFC6349] Barry Constantine et al., "Framework for TCP Throughput [RFC6349] Barry Constantine et al., "Framework for TCP Throughput
Testing," RFC6349, August 2011 Testing," RFC6349, August 2011
10.2. Informative References
[RFC2697] J. Heinanen et al., "A Single Rate Three Color Marker,"
RFC2697, September 1999
[RFC2698] J. Heinanen et al., "A Two Rate Three Color Marker, "
RFC2698, September 1999
[AQM-RECO] Fred Baker et al., "IETF Recommendations Regarding [AQM-RECO] Fred Baker et al., "IETF Recommendations Regarding
Active Queue Management," August 2014, Active Queue Management," August 2014,
https://datatracker.ietf.org/doc/draft-ietf-aqm- https://datatracker.ietf.org/doc/draft-ietf-aqm-
recommendation/ recommendation/
[MEF-10.2] "MEF 10.2: Ethernet Services Attributes Phase 2," October [MEF-10.2] "MEF 10.2: Ethernet Services Attributes Phase 2," October
2009, http://metroethernetforum.org/PDF_Documents/ 2009, http://metroethernetforum.org/PDF_Documents/
technical-specifications/MEF10.2.pdf technical-specifications/MEF10.2.pdf
[MEF-12.1] "MEF 12.1: Carrier Ethernet Network Architecture [MEF-12.1] "MEF 12.1: Carrier Ethernet Network Architecture
Framework -- Framework --
Part 2: Ethernet Services Layer - Base Elements," April Part 2: Ethernet Services Layer - Base Elements," April
2010, https://www.metroethernetforum.org/Assets/Technical 2010, https://www.metroethernetforum.org/Assets/Technical
_Specifications/PDF/MEF12.1.pdf _Specifications/PDF/MEF12.1.pdf
[MEF-26] "MEF 26: External Network Network Interface (ENNI) - [MEF-26] "MEF 26: External Network Network Interface (ENNI) -
Phase 1,"January 2010, http://www.metroethernetforum.org Phase 1,"January 2010, http://www.metroethernetforum.org
/PDF_Documents/technical-specifications/MEF26.pdf /PDF_Documents/technical-specifications/MEF26.pdf
10.2. Informative References [MEF-14] "Abstract Test Suite for Traffic Management Phase 1,
https://www.metroethernetforum.org/Assets
/Technical_Specifications/PDF/MEF_14.pdf
[MEF-19] "Abstract Test Suite for UNII Type 1",
https://www.metroethernetforum.org/Assets
/Technical_Specifications/PDF/MEF_19.pdf
[MEF-37] "Abstract Test Suite for ENNI",
https://www.metroethernetforum.org/Assets
/Technical_Specifications/PDF/MEF_37.pdf
Authors' Addresses Authors' Addresses
Barry Constantine Barry Constantine
JDSU, Test and Measurement Division JDSU, Test and Measurement Division
Germantown, MD 20876-7100, USA Germantown, MD 20876-7100, USA
Phone: +1 240 404 2227 Phone: +1 240 404 2227
Email: barry.constantine@jdsu.com Email: barry.constantine@jdsu.com
Ram Krishnan Ram Krishnan
 End of changes. 15 change blocks. 
30 lines changed or deleted 52 lines changed or added

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