draft-ietf-bmwg-ipv6-tran-tech-benchmarking-06.txt   draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07.txt 
Benchmarking Working Group M. Georgescu Benchmarking Working Group M. Georgescu
Internet Draft L. Pislaru Internet Draft L. Pislaru
Intended status: Informational RCS&RDS Intended status: Informational RCS&RDS
Expires: October 2017 G. Lencse Expires: October 2017 G. Lencse
Szechenyi Istvan University Szechenyi Istvan University
April 18, 2017 April 29, 2017
Benchmarking Methodology for IPv6 Transition Technologies Benchmarking Methodology for IPv6 Transition Technologies
draft-ietf-bmwg-ipv6-tran-tech-benchmarking-06.txt draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07.txt
Abstract Abstract
There are benchmarking methodologies addressing the performance of There are benchmarking methodologies addressing the performance of
network interconnect devices that are IPv4- or IPv6-capable, but the network interconnect devices that are IPv4- or IPv6-capable, but the
IPv6 transition technologies are outside of their scope. This IPv6 transition technologies are outside of their scope. This
document provides complementary guidelines for evaluating the document provides complementary guidelines for evaluating the
performance of IPv6 transition technologies. More specifically, performance of IPv6 transition technologies. More specifically,
this document targets IPv6 transition technologies that employ this document targets IPv6 transition technologies that employ
encapsulation or translation mechanisms, as dual-stack nodes can be encapsulation or translation mechanisms, as dual-stack nodes can be
skipping to change at page 1, line 46 skipping to change at page 1, line 46
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference 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 October 18, 2016. This Internet-Draft will expire on October 29, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 3, line 10 skipping to change at page 3, line 10
7.4. Frame Loss Rate..........................................14 7.4. Frame Loss Rate..........................................14
7.5. Back-to-back Frames......................................14 7.5. Back-to-back Frames......................................14
7.6. System Recovery..........................................14 7.6. System Recovery..........................................14
7.7. Reset....................................................14 7.7. Reset....................................................14
8. Additional Benchmarking Tests for Stateful IPv6 Transition 8. Additional Benchmarking Tests for Stateful IPv6 Transition
Technologies.....................................................14 Technologies.....................................................14
8.1. Concurrent TCP Connection Capacity.......................14 8.1. Concurrent TCP Connection Capacity.......................14
8.2. Maximum TCP Connection Establishment Rate................14 8.2. Maximum TCP Connection Establishment Rate................14
9. DNS Resolution Performance....................................14 9. DNS Resolution Performance....................................14
9.1. Test and Traffic Setup...................................15 9.1. Test and Traffic Setup...................................14
9.2. Benchmarking DNS Resolution Performance..................16 9.2. Benchmarking DNS Resolution Performance..................16
9.2.1. Requirements for the Tester.........................17 9.2.1. Requirements for the Tester.........................17
10. Overload Scalability.........................................18 10. Overload Scalability.........................................18
10.1. Test Setup..............................................18 10.1. Test Setup..............................................18
10.1.1. Single Translation Transition Technologies.........18 10.1.1. Single Translation Transition Technologies.........18
10.1.2. Encapsulation/Double Translation Transition 10.1.2. Encapsulation/Double Translation Transition
Technologies...............................................19 Technologies...............................................19
10.2. Benchmarking Performance Degradation....................20 10.2. Benchmarking Performance Degradation....................19
10.2.1. Network performance degradation with simultaneous load 10.2.1. Network performance degradation with simultaneous load
...........................................................20 ...........................................................19
10.2.2. Network performance degradation with incremental load 10.2.2. Network performance degradation with incremental load
...........................................................20 ...........................................................20
11. NAT44 and NAT66..............................................21 11. NAT44 and NAT66..............................................21
12. Summarizing function and variation...........................21 12. Summarizing function and variation...........................21
13. Security Considerations......................................22 13. Security Considerations......................................22
14. IANA Considerations..........................................22 14. IANA Considerations..........................................22
15. References...................................................22 15. References...................................................22
15.1. Normative References....................................22 15.1. Normative References....................................22
15.2. Informative References..................................23 15.2. Informative References..................................23
16. Acknowledgements.............................................26 16. Acknowledgements.............................................26
skipping to change at page 7, line 14 skipping to change at page 7, line 14
Although both single tester and sender/receiver setups are Although both single tester and sender/receiver setups are
applicable to this methodology, the single tester setup will be used applicable to this methodology, the single tester setup will be used
to describe the DUT setup options. to describe the DUT setup options.
For the test setups presented in this memo, dynamic routing SHOULD For the test setups presented in this memo, dynamic routing SHOULD
be employed. However, the presence of routing and management frames be employed. However, the presence of routing and management frames
can represent unwanted background data that can affect the can represent unwanted background data that can affect the
benchmarking result. To that end, the procedures defined in benchmarking result. To that end, the procedures defined in
[RFC2544] (Sections 11.2 and 11.3) related to routing and management [RFC2544] (Sections 11.2 and 11.3) related to routing and management
frames SHOULD be used here as well. Moreover, the "Trial frames SHOULD be used here. Moreover, the "Trial description"
description" recommendations presented in [RFC2544] (Section 23) are recommendations presented in [RFC2544] (Section 23) are also valid
valid for this memo as well. for this memo.
In terms of route setup, the recommendations of [RFC2544] Section 13 In terms of route setup, the recommendations of [RFC2544] Section 13
are valid for this document as well assuming that an IPv6 version of are valid for this document assuming that an IPv6 version of the
the routing packets shown in appendix C.2.6.2 is used. routing packets shown in appendix C.2.6.2 is used.
4.1. Single translation Transition Technologies 4.1. Single translation Transition Technologies
For the evaluation of Single translation transition technologies, a For the evaluation of Single translation transition technologies, a
single DUT setup (see Figure 1) SHOULD be used. The DUT is single DUT setup (see Figure 1) SHOULD be used. The DUT is
responsible for translating the IPvX packets into IPvY packets. In responsible for translating the IPvX packets into IPvY packets. In
this context, the tester device SHOULD be configured to support both this context, the tester device SHOULD be configured to support both
IPvX and IPvY. IPvX and IPvY.
+--------------------+ +--------------------+
skipping to change at page 9, line 34 skipping to change at page 9, line 34
9216. 9216.
Note: for single translation transition technologies (e.g. NAT64) in Note: for single translation transition technologies (e.g. NAT64) in
the IPv6 -> IPv4 translation direction, 64 byte frames SHOULD be the IPv6 -> IPv4 translation direction, 64 byte frames SHOULD be
replaced by 84 byte frames. This would allow the frames to be replaced by 84 byte frames. This would allow the frames to be
transported over media such as the ones described by the IEEE 802.1Q transported over media such as the ones described by the IEEE 802.1Q
standard. Moreover, this would also allow the implementation of a standard. Moreover, this would also allow the implementation of a
frame identifier in the UDP data. frame identifier in the UDP data.
The theoretical maximum frame rates considering an example of frame The theoretical maximum frame rates considering an example of frame
overhead are presented in Appendix A1. overhead are presented in Appendix A.
5.2. Protocol Addresses 5.2. Protocol Addresses
The selected protocol addresses should follow the recommendations of The selected protocol addresses should follow the recommendations of
[RFC5180](Section 5) for IPv6 and [RFC2544](Section 12) for IPv4. [RFC5180](Section 5) for IPv6 and [RFC2544](Section 12) for IPv4.
Note: testing traffic with extension headers might not be possible Note: testing traffic with extension headers might not be possible
for the transition technologies, which employ translation. Proposed for the transition technologies, which employ translation. Proposed
IPvX/IPvY translation algorithms such as IP/ICMP translation IPvX/IPvY translation algorithms such as IP/ICMP translation
[RFC7915] do not support the use of extension headers. [RFC7915] do not support the use of extension headers.
5.3. Traffic Setup 5.3. Traffic Setup
Following the recommendations of [RFC5180], all tests described Following the recommendations of [RFC5180], all tests described
SHOULD be performed with bi-directional traffic. Uni-directional SHOULD be performed with bi-directional traffic. Uni-directional
traffic tests MAY also be performed for a fine grained performance traffic tests MAY also be performed for a fine grained performance
assessment. assessment.
Because of the simplicity of UDP, UDP measurements offer a more Because of the simplicity of UDP, UDP measurements offer a more
reliable basis for comparison than other transport layer protocols. reliable basis for comparison than other transport layer protocols.
Consequently, for the benchmarking tests described in Section 6 of Consequently, for the benchmarking tests described in Section 7 of
this document UDP traffic SHOULD be employed. this document UDP traffic SHOULD be employed.
Considering that a transition technology could process both native Considering that a transition technology could process both native
IPv6 traffic and translated/encapsulated traffic, the following IPv6 traffic and translated/encapsulated traffic, the following
traffic setups are recommended: traffic setups are recommended:
i) IPvX only traffic (where the IPvX traffic is to be i) IPvX only traffic (where the IPvX traffic is to be
translated/encapsulated by the DUT) translated/encapsulated by the DUT)
ii) 90% IPvX traffic and 10% IPvY native traffic ii) 90% IPvX traffic and 10% IPvY native traffic
iii) 50% IPvX traffic and 50% IPvY native traffic iii) 50% IPvX traffic and 50% IPvY native traffic
skipping to change at page 10, line 35 skipping to change at page 10, line 35
the traffic SHOULD follow the recommendations of [RFC3511], Sections the traffic SHOULD follow the recommendations of [RFC3511], Sections
5.2.2.2 and 5.3.2.2. 5.2.2.2 and 5.3.2.2.
6. Modifiers 6. Modifiers
The idea of testing under different operational conditions was first The idea of testing under different operational conditions was first
introduced in [RFC2544](Section 11) and represents an important introduced in [RFC2544](Section 11) and represents an important
aspect of benchmarking network elements, as it emulates, to some aspect of benchmarking network elements, as it emulates, to some
extent, the conditions of a production environment. Section 6 of extent, the conditions of a production environment. Section 6 of
[RFC5180] describes complementary testing conditions specific to [RFC5180] describes complementary testing conditions specific to
IPv6. Their recommendations can be followed for IPv6 transition IPv6. Their recommendations can also be followed for IPv6 transition
technologies testing as well. technologies testing.
7. Benchmarking Tests 7. Benchmarking Tests
The following sub-sections contain the list of all recommended The following sub-sections contain the list of all recommended
benchmarking tests. benchmarking tests.
7.1. Throughput 7.1. Throughput
Use Section 26.1 of RFC2544 unmodified. Use Section 26.1 of RFC2544 unmodified.
skipping to change at page 12, line 17 skipping to change at page 12, line 17
Reporting Format: The report MUST state which definition of latency Reporting Format: The report MUST state which definition of latency
(from RFC 1242) was used for this test. The summarized latency (from RFC 1242) was used for this test. The summarized latency
results SHOULD be reported in the format of a table with a row for results SHOULD be reported in the format of a table with a row for
each of the tested frame sizes. There SHOULD be columns for the each of the tested frame sizes. There SHOULD be columns for the
frame size, the rate at which the latency test was run for that frame size, the rate at which the latency test was run for that
frame size, for the media types tested, and for the resultant frame size, for the media types tested, and for the resultant
typical latency and worst case latency values for each type of data typical latency and worst case latency values for each type of data
stream tested. To account for the variation, the 1st and 99th stream tested. To account for the variation, the 1st and 99th
percentiles of the 20 iterations MAY be reported in two separated percentiles of the 20 iterations MAY be reported in two separated
columns. For a fine grained analysis, the histogram (as exemplified columns. For a fine grained analysis, the histogram (as exemplified
in [RFC5481] Section 4.4) of one of the iterations MAY be displayed in [RFC5481] Section 4.4) of one of the iterations MAY be
as well. displayed .
7.3. Packet Delay Variation 7.3. Packet Delay Variation
Considering two of the metrics presented in [RFC5481], Packet Delay Considering two of the metrics presented in [RFC5481], Packet Delay
Variation (PDV) and Inter Packet Delay Variation (IPDV), it is Variation (PDV) and Inter Packet Delay Variation (IPDV), it is
RECOMMENDED to measure PDV. For a fine grained analysis of delay RECOMMENDED to measure PDV. For a fine grained analysis of delay
variation, IPDV measurements MAY be performed as well. variation, IPDV measurements MAY be performed.
7.3.1. PDV 7.3.1. PDV
Objective: To determine the Packet Delay Variation as defined in Objective: To determine the Packet Delay Variation as defined in
[RFC5481]. [RFC5481].
Procedure: As described by [RFC2544], first determine the throughput Procedure: As described by [RFC2544], first determine the throughput
for the DUT at each of the listed frame sizes. Send a stream of for the DUT at each of the listed frame sizes. Send a stream of
frames at a particular frame size through the DUT at the determined frames at a particular frame size through the DUT at the determined
throughput rate to a specific destination. The stream SHOULD be at throughput rate to a specific destination. The stream SHOULD be at
skipping to change at page 13, line 8 skipping to change at page 13, line 8
Dmin - the minimum One-way delay in the stream Dmin - the minimum One-way delay in the stream
As recommended in [RFC2544], the test MUST be repeated at least 20 As recommended in [RFC2544], the test MUST be repeated at least 20
times with the reported value being the median of the recorded times with the reported value being the median of the recorded
values. Moreover, the 1st and 99th percentiles SHOULD be calculated values. Moreover, the 1st and 99th percentiles SHOULD be calculated
to account for the variation of the dataset. to account for the variation of the dataset.
Reporting Format: The PDV results SHOULD be reported in a table with Reporting Format: The PDV results SHOULD be reported in a table with
a row for each of the tested frame sizes and columns for the frame a row for each of the tested frame sizes and columns for the frame
size and the applied frame rate for the tested media types. Two size and the applied frame rate for the tested media types. Two
columns for the 1st and 99th percentile values MAY as well be columns for the 1st and 99th percentile values MAY be displayed.
displayed. Following the recommendations of [RFC5481], the Following the recommendations of [RFC5481], the RECOMMENDED units of
RECOMMENDED units of measurement are milliseconds. measurement are milliseconds.
7.3.2. IPDV 7.3.2. IPDV
Objective: To determine the Inter Packet Delay Variation as defined Objective: To determine the Inter Packet Delay Variation as defined
in [RFC5481]. in [RFC5481].
Procedure: As described by [RFC2544], first determine the throughput Procedure: As described by [RFC2544], first determine the throughput
for the DUT at each of the listed frame sizes. Send a stream of for the DUT at each of the listed frame sizes. Send a stream of
frames at a particular frame size through the DUT at the determined frames at a particular frame size through the DUT at the determined
throughput rate to a specific destination. The stream SHOULD be at throughput rate to a specific destination. The stream SHOULD be at
skipping to change at page 14, line 27 skipping to change at page 14, line 27
7.7. Reset 7.7. Reset
Use Section 4 of [RFC6201] unmodified. Use Section 4 of [RFC6201] unmodified.
8. Additional Benchmarking Tests for Stateful IPv6 Transition 8. Additional Benchmarking Tests for Stateful IPv6 Transition
Technologies Technologies
This section describes additional tests dedicated to the stateful This section describes additional tests dedicated to the stateful
IPv6 transition technologies. For the tests described in this IPv6 transition technologies. For the tests described in this
section, the DUT devices SHOULD follow the test setup and test section, the DUT devices SHOULD follow the test setup and test
parameters recommendations presented in [RFC3511] (Sections 4, 5). parameters recommendations presented in [RFC3511] (Sections 5.2 and
5.3)
In addition to the IPv4/IPv6 transition function, a network node can The following additional tests SHOULD be performed.
have a firewall function. This document is targeting only the
network devices that do not have a firewall function, as this
function can be benchmarked using the recommendations of [RFC3511].
Consequently, only the tests described in [RFC3511] (Sections 5.2,
5.3) are RECOMMENDED. Namely, the following additional tests SHOULD
be performed:
8.1. Concurrent TCP Connection Capacity 8.1. Concurrent TCP Connection Capacity
Use Section 5.3 of [RFC3511] unmodified. Use Section 5.2 of [RFC3511] unmodified.
8.2. Maximum TCP Connection Establishment Rate 8.2. Maximum TCP Connection Establishment Rate
Use Section 5.3 of RFC3511 unmodified. Use Section 5.3 of RFC3511 unmodified.
9. DNS Resolution Performance 9. DNS Resolution Performance
This section describes benchmarking tests dedicated to DNS64 (see This section describes benchmarking tests dedicated to DNS64 (see
[RFC6147]), used as DNS support for single translation technologies [RFC6147]), used as DNS support for single translation technologies
such as NAT64. such as NAT64.
skipping to change at page 16, line 28 skipping to change at page 16, line 24
number of successfully processed DNS requests per second. number of successfully processed DNS requests per second.
Procedure: Send a specific number of DNS queries at a specific rate Procedure: Send a specific number of DNS queries at a specific rate
to the DUT and then count the replies received in time (within a to the DUT and then count the replies received in time (within a
predefined timeout period from the sending time of the corresponding predefined timeout period from the sending time of the corresponding
query, having the default value 1 second) and valid (contains an query, having the default value 1 second) and valid (contains an
AAAA record) from the DUT. If the count of sent queries is equal to AAAA record) from the DUT. If the count of sent queries is equal to
the count of received replies, the rate of the queries is raised and the count of received replies, the rate of the queries is raised and
the test is rerun. If fewer replies are received than queries were the test is rerun. If fewer replies are received than queries were
sent, the rate of the queries is reduced and the test is rerun. The sent, the rate of the queries is reduced and the test is rerun. The
duration of each trial SHOULD be at least 60 seconds to reduce the duration of each trial SHOULD be at least 60 seconds. This will
potential gain of a DNS64 server, which is able to exhibit higher reduce the potential gain of a DNS64 server, which is able to
performance by storing the requests and thus utilizing also the exhibit higher performance by storing the requests and thus
timeout time for answering them. For the same reason, no higher utilizing also the timeout time for answering them. For the same
timeout time than 1 second SHOULD be used. reason, no higher timeout time than 1 second SHOULD be used. For
further considerations, see [Lencse1].
The maximum number of processed DNS queries per second is the The maximum number of processed DNS queries per second is the
fastest rate at which the count of DNS replies sent by the DUT is fastest rate at which the count of DNS replies sent by the DUT is
equal to the number of DNS queries sent to it by the test equipment. equal to the number of DNS queries sent to it by the test equipment.
The test SHOULD be repeated at least 20 times and the median and 1st The test SHOULD be repeated at least 20 times and the median and 1st
/99th percentiles of the number of processed DNS queries per second /99th percentiles of the number of processed DNS queries per second
SHOULD be calculated. SHOULD be calculated.
Details and parameters: Details and parameters:
skipping to change at page 18, line 8 skipping to change at page 18, line 6
Explanation: When performing DNS64 testing, each AAAA record query Explanation: When performing DNS64 testing, each AAAA record query
may result in at most two queries sent by the DUT, the first one of may result in at most two queries sent by the DUT, the first one of
them is for an AAAA record and the second one is for an A record them is for an AAAA record and the second one is for an A record
(the are both sent when there is no cache hit and also no AAAA (the are both sent when there is no cache hit and also no AAAA
record exists). The parameters above guarantee that the record exists). The parameters above guarantee that the
authoritative DNS server subsystem of the DUT is able to answer the authoritative DNS server subsystem of the DUT is able to answer the
queries at the required frequency using up not more than the half of queries at the required frequency using up not more than the half of
the timeout time. the timeout time.
Remark: a sample open-source test program, dns64perf++, is available Remark: a sample open-source test program, dns64perf++, is available
from [Dns64perf] and it is documented in [Lencse1]. It implements from [Dns64perf] and it is documented in [Lencse2]. It implements
only the client part of the Tester and it should be used together only the client part of the Tester and it should be used together
with an authoritative DNS server implementation, e.g. BIND, NSD or with an authoritative DNS server implementation, e.g. BIND, NSD or
YADIFA. Its experimental extension for testing caching is available YADIFA. Its experimental extension for testing caching is available
from [Lencse2] and it is documented in [Lencse3]. from [Lencse3] and it is documented in [Lencse4].
10. Overload Scalability 10. Overload Scalability
Scalability has been often discussed; however, in the context of Scalability has been often discussed; however, in the context of
network devices, a formal definition or a measurement method has not network devices, a formal definition or a measurement method has not
yet been proposed. In this context, we can define overload yet been proposed. In this context, we can define overload
scalability as the ability of each transition technology to scalability as the ability of each transition technology to
accommodate network growth. Poor scalability usually leads to poor accommodate network growth. Poor scalability usually leads to poor
performance. Considering this, overload scalability can be measured performance. Considering this, overload scalability can be measured
by quantifying the network performance degradation associated with by quantifying the network performance degradation associated with
skipping to change at page 20, line 20 skipping to change at page 19, line 51
devices can be separately tested with n network flows using the test devices can be separately tested with n network flows using the test
setup presented in Figure 4. setup presented in Figure 4.
10.2. Benchmarking Performance Degradation 10.2. Benchmarking Performance Degradation
10.2.1. Network performance degradation with simultaneous load 10.2.1. Network performance degradation with simultaneous load
Objective: To quantify the performance degradation introduced by n Objective: To quantify the performance degradation introduced by n
parallel and simultaneous network flows. parallel and simultaneous network flows.
Procedure: First, the benchmarking tests presented in Section 6 have Procedure: First, the benchmarking tests presented in Section 7 have
to be performed for one network flow. to be performed for one network flow.
The same tests have to be repeated for n network flows, where the The same tests have to be repeated for n network flows, where the
network flows are started simultaneously. The performance network flows are started simultaneously. The performance
degradation of the X benchmarking dimension SHOULD be calculated as degradation of the X benchmarking dimension SHOULD be calculated as
relative performance change between the 1-flow (single flow) results relative performance change between the 1-flow (single flow) results
and the n-flow results, using the following formula: and the n-flow results, using the following formula:
Xn - X1 Xn - X1
Xpd= ----------- * 100, where: X1 - result for 1-flow Xpd= ----------- * 100, where: X1 - result for 1-flow
X1 Xn - result for n-flows X1 Xn - result for n-flows
This formula SHOULD be applied only for lower is better benchmarks
(e.g. latency).
For higher is better benchmarks (e.g. throughput), the following
formula is RECOMMENDED.
X1 - Xn
Xpd= ----------- * 100, where: X1 - result for 1-flow
X1 Xn - result for n-flows
As a guideline for the maximum number of flows n, the value can be As a guideline for the maximum number of flows n, the value can be
deduced by measuring the Concurrent TCP Connection Capacity as deduced by measuring the Concurrent TCP Connection Capacity as
described by [RFC3511], following the test setups specified by described by [RFC3511], following the test setups specified by
Section 4. Section 4.
Reporting Format: The performance degradation SHOULD be expressed as Reporting Format: The performance degradation SHOULD be expressed as
a percentage. The number of tested parallel flows n MUST be clearly a percentage. The number of tested parallel flows n MUST be clearly
specified. For each of the performed benchmarking tests, there specified. For each of the performed benchmarking tests, there
SHOULD be a table containing a column for each frame size. The table SHOULD be a table containing a column for each frame size. The table
SHOULD also state the applied frame rate. SHOULD also state the applied frame rate. In the case of benchmarks
for which more than one value is reported (e.g. IPDV Section 7.3.2),
a column for each of the values SHOULD be included.
10.2.2. Network performance degradation with incremental load 10.2.2. Network performance degradation with incremental load
Objective: To quantify the performance degradation introduced by n Objective: To quantify the performance degradation introduced by n
parallel and incrementally started network flows. parallel and incrementally started network flows.
Procedure: First, the benchmarking tests presented in Section 6 have Procedure: First, the benchmarking tests presented in Section 7 have
to be performed for one network flow. to be performed for one network flow.
The same tests have to be repeated for n network flows, where the The same tests have to be repeated for n network flows, where the
network flows are started incrementally in succession, each after network flows are started incrementally in succession, each after
time t. In other words, if flow i is started at time x, flow i+1 time t. In other words, if flow i is started at time x, flow i+1
will be started at time x+t. Considering the time t, the time will be started at time x+t. Considering the time t, the time
duration of each iteration must be extended with the time necessary duration of each iteration must be extended with the time necessary
to start all the flows, namely (n-1)xt. The measurement for the to start all the flows, namely (n-1)xt. The measurement for the
first flow SHOULD be at least 60 seconds in duration. first flow SHOULD be at least 60 seconds in duration.
skipping to change at page 21, line 26 skipping to change at page 21, line 18
Section 10.2.1. Intermediary degradation points for 1/4*n, 1/2*n and Section 10.2.1. Intermediary degradation points for 1/4*n, 1/2*n and
3/4*n MAY also be performed. 3/4*n MAY also be performed.
Reporting Format: The performance degradation SHOULD be expressed as Reporting Format: The performance degradation SHOULD be expressed as
a percentage. The number of tested parallel flows n MUST be clearly a percentage. The number of tested parallel flows n MUST be clearly
specified. For each of the performed benchmarking tests, there specified. For each of the performed benchmarking tests, there
SHOULD be a table containing a column for each frame size. The table SHOULD be a table containing a column for each frame size. The table
SHOULD also state the applied frame rate and time duration T, used SHOULD also state the applied frame rate and time duration T, used
as increment step between the network flows. The units of as increment step between the network flows. The units of
measurement for T SHOULD be seconds. A column for the intermediary measurement for T SHOULD be seconds. A column for the intermediary
degradation points MAY also be displayed. degradation points MAY also be displayed. In the case of benchmarks
for which more than one value is reported (e.g. IPDV Section 7.3.2),
a column for each of the values SHOULD be included.
11. NAT44 and NAT66 11. NAT44 and NAT66
Although these technologies are not the primary scope of this Although these technologies are not the primary scope of this
document, the benchmarking methodology associated with single document, the benchmarking methodology associated with single
translation technologies as defined in Section 4.1 can be employed translation technologies as defined in Section 4.1 can be employed
to benchmark NAT44 (as defined by [RFC2663] with the behavior to benchmark NAT44 (as defined by [RFC2663] with the behavior
described by [RFC7857]) implementations and NAT66 (as defined by described by [RFC7857]) implementations and NAT66 (as defined by
[RFC6296]) implementations. [RFC6296]) implementations.
12. Summarizing function and variation 12. Summarizing function and variation
To ensure the stability of the benchmarking scores obtained using To ensure the stability of the benchmarking scores obtained using
the tests presented in Sections 6 through 9, multiple test the tests presented in Sections 7 through 9, multiple test
iterations are RECOMMENDED. Using a summarizing function (or measure iterations are RECOMMENDED. Using a summarizing function (or measure
of central tendency) can be a simple and effective way to compare of central tendency) can be a simple and effective way to compare
the results obtained across different iterations. However, over- the results obtained across different iterations. However, over-
summarization is an unwanted effect of reporting a single number. summarization is an unwanted effect of reporting a single number.
Measuring the variation (dispersion index) can be used to counter Measuring the variation (dispersion index) can be used to counter
the over-summarization effect. Empirical data obtained following the the over-summarization effect. Empirical data obtained following the
proposed methodology can also offer insights on which summarizing proposed methodology can also offer insights on which summarizing
function would fit better. function would fit better.
skipping to change at page 25, line 45 skipping to change at page 25, line 40
[Dns64perf] Bakai, D., "A C++11 DNS64 performance tester", [Dns64perf] Bakai, D., "A C++11 DNS64 performance tester",
available: https://github.com/bakaid/dns64perfpp available: https://github.com/bakaid/dns64perfpp
[ietf95pres] Georgescu, M., "Benchmarking Methodology for IPv6 [ietf95pres] Georgescu, M., "Benchmarking Methodology for IPv6
Transition Technologies", IETF 95, Buenos Aires, Transition Technologies", IETF 95, Buenos Aires,
Argentina, April 2016, available: Argentina, April 2016, available:
https://www.ietf.org/proceedings/95/slides/slides-95-bmwg- https://www.ietf.org/proceedings/95/slides/slides-95-bmwg-
2.pdf 2.pdf
[Lencse1] Lencse, G., Bakai, D, "Design and Implementation of a Test [Lencse1] Lencse, G., Georgescu, M. and Y. Kadobayashi,
"Benchmarking Methodology for DNS64 Servers", unpublished,
revised version is available:
http://www.hit.bme.hu/~lencse/publications/ECC-2017-B-M-
DNS64-revised.pdf
[Lencse2] Lencse, G., Bakai, D, "Design and Implementation of a Test
Program for Benchmarking DNS64 Servers", IEICE Program for Benchmarking DNS64 Servers", IEICE
Transactions on Communications, to be published (vol. Transactions on Communications, to be published (vol.
E100-B, no. 6. pp. -, June 2017.), advance publication is E100-B, no. 6. pp. -, June 2017.), advance publication is
available: http://doi.org/10.1587/transcom.2016EBN0007 available: http://doi.org/10.1587/transcom.2016EBN0007
revised version is freely available: revised version is freely available:
http://www.hit.bme.hu/~lencse/publications/IEICE-2016- http://www.hit.bme.hu/~lencse/publications/IEICE-2016-
dns64perfpp-revised.pdf dns64perfpp-revised.pdf
[Lencse2] http://www.hit.bme.hu/~lencse/dns64perfppc/ [Lencse3] http://www.hit.bme.hu/~lencse/dns64perfppc/
[Lencse3] G. Lencse, "Enabling Dns64perf++ for Benchmarking the [Lencse4] Lencse, G., "Enabling Dns64perf++ for Benchmarking the
Caching Performance of DNS64 Servers", unpublished, review Caching Performance of DNS64 Servers", unpublished, review
version is available: version is available:
http://www.hit.bme.hu/~lencse/publications/IEICE-2016- http://www.hit.bme.hu/~lencse/publications/IEICE-2016-
dns64perfppc-for-review.pdf dns64perfppc-for-review.pdf
16. Acknowledgements 16. Acknowledgements
The authors would like to thank Youki Kadobayashi and Hiroaki The authors would like to thank Youki Kadobayashi and Hiroaki
Hazeyama for their constant feedback and support. The thanks should Hazeyama for their constant feedback and support. The thanks should
be extended to the NECOMA project members for their continuous be extended to the NECOMA project members for their continuous
support. The thank you list should also include Emanuel Popa and the support. The thank you list should also include Emanuel Popa, Ionut
RCS&RDS Backbone Team for their support and insights. We would also Spirlea and the RCS&RDS IP/MPLS Backbone Team for their support and
like to thank Scott Bradner for the useful suggestions. We also note insights. We would also like to thank Scott Bradner for the useful
that portions of text from Scott's documents were used in this memo suggestions. We also note that portions of text from Scott's
(e.g. Latency section). A big thank you to Al Morton and Fred Baker documents were used in this memo (e.g. Latency section). A big thank
for their detailed review of the draft and very helpful suggestions. you to Al Morton and Fred Baker for their detailed review of the
Other helpful comments and suggestions were offered by Bhuvaneswaran draft and very helpful suggestions. Other helpful comments and
Vengainathan, Andrew McGregor, Nalini Elkins, Kaname Nishizuka, suggestions were offered by Bhuvaneswaran Vengainathan, Andrew
Yasuhiro Ohara, Masataka Mawatari, Kostas Pentikousis, Bela Almasi, McGregor, Nalini Elkins, Kaname Nishizuka, Yasuhiro Ohara, Masataka
Tim Chown, Paul Emmerich and Stenio Fernandes. A special thank you Mawatari, Kostas Pentikousis, Bela Almasi, Tim Chown, Paul Emmerich
to the RFC Editor Team for their thorough editorial review and and Stenio Fernandes. A special thank you to the RFC Editor Team for
helpful suggestions. This document was prepared using 2-Word- their thorough editorial review and helpful suggestions. This
v2.0.template.dot. document was prepared using 2-Word-v2.0.template.dot.
Appendix A. Theoretical Maximum Frame Rates Appendix A. Theoretical Maximum Frame Rates
This appendix describes the recommended calculation formulas for the This appendix describes the recommended calculation formulas for the
theoretical maximum frame rates to be employed over Ethernet as theoretical maximum frame rates to be employed over Ethernet as
example media. The formula takes into account the frame size example media. The formula takes into account the frame size
overhead created by the encapsulation or the translation process. overhead created by the encapsulation or the translation process.
For example, the 6in4 encapsulation described in [RFC4213] adds 20 For example, the 6in4 encapsulation described in [RFC4213] adds 20
bytes of overhead to each frame. bytes of overhead to each frame.
 End of changes. 31 change blocks. 
59 lines changed or deleted 74 lines changed or added

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