draft-ietf-bmwg-ipv6-tran-tech-benchmarking-01.txt   draft-ietf-bmwg-ipv6-tran-tech-benchmarking-02.txt 
Benchmarking Working Group M. Georgescu Benchmarking Working Group M. Georgescu
Internet Draft NAIST Internet Draft NAIST
Intended status: Informational G. Lencse Intended status: Informational G. Lencse
Expires: September 2016 Szechenyi Istvan University Expires: January 2017 Szechenyi Istvan University
March 17, 2016 July 7, 2016
Benchmarking Methodology for IPv6 Transition Technologies Benchmarking Methodology for IPv6 Transition Technologies
draft-ietf-bmwg-ipv6-tran-tech-benchmarking-01.txt draft-ietf-bmwg-ipv6-tran-tech-benchmarking-02.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 45 skipping to change at page 1, line 45
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 September 17, 2016. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 2, line 46 skipping to change at page 2, line 46
5. Test Traffic...................................................8 5. Test Traffic...................................................8
5.1. Frame Formats and Sizes...................................8 5.1. Frame Formats and Sizes...................................8
5.1.1. Frame Sizes to Be Used over Ethernet.................9 5.1.1. Frame Sizes to Be Used over Ethernet.................9
5.2. Protocol Addresses........................................9 5.2. Protocol Addresses........................................9
5.3. Traffic Setup.............................................9 5.3. Traffic Setup.............................................9
6. Modifiers.....................................................10 6. Modifiers.....................................................10
7. Benchmarking Tests............................................10 7. Benchmarking Tests............................................10
7.1. Throughput - [RFC2544]...................................10 7.1. Throughput - [RFC2544]...................................10
7.2. Latency..................................................10 7.2. Latency..................................................10
7.3. Packet Delay Variation...................................11 7.3. Packet Delay Variation...................................11
7.3.1. PDV.................................................11 7.3.1. PDV.................................................12
7.3.2. IPDV................................................12 7.3.2. IPDV................................................12
7.4. Frame Loss Rate - [RFC2544]..............................13 7.4. Frame Loss Rate - [RFC2544]..............................13
7.5. Back-to-back Frames - [RFC2544]..........................13 7.5. Back-to-back Frames - [RFC2544]..........................13
7.6. System Recovery - [RFC2544]..............................13 7.6. System Recovery - [RFC2544]..............................13
7.7. Reset - [RFC2544]........................................13 7.7. Reset - [RFC2544]........................................13
8. Additional Benchmarking Tests for Stateful IPv6 Transition 8. Additional Benchmarking Tests for Stateful IPv6 Transition
Technologies.....................................................13 Technologies.....................................................13
8.1. Concurrent TCP Connection Capacity -[RFC3511]............13 8.1. Concurrent TCP Connection Capacity -[RFC3511]............14
8.2. Maximum TCP Connection Establishment Rate -[RFC3511].....13 8.2. Maximum TCP Connection Establishment Rate -[RFC3511].....14
9. DNS Resolution Performance....................................13 9. DNS Resolution Performance....................................14
9.1. Test and Traffic Setup...................................14 9.1. Test and Traffic Setup...................................14
9.2. Benchmarking DNS Resolution Performance..................15 9.2. Benchmarking DNS Resolution Performance..................15
9.2.1. Requirements for the Tester.........................16 9.2.1. Requirements for the Tester.........................16
10. Scalability..................................................17 10. Scalability..................................................17
10.1. Test Setup..............................................17 10.1. Test Setup..............................................17
10.1.1. Single Translation Transition Technologies.........17 10.1.1. Single Translation Transition Technologies.........17
10.1.2. Encapsulation/Double Translation Transition 10.1.2. Encapsulation/Double Translation Transition
Technologies...............................................18 Technologies...............................................18
10.2. Benchmarking Performance Degradation....................18 10.2. Benchmarking Performance Degradation....................18
10.2.1. Network performance degradation with simultaneous load 10.2.1. Network performance degradation with simultaneous load
...........................................................18 ...........................................................18
10.2.2. Network performance degradation with incremental load 10.2.2. Network performance degradation with incremental load
...........................................................19 ...........................................................19
11. Summarizing function and variation...........................20 11. NAT44 and NAT66..............................................20
12. Security Considerations......................................20 12. Summarizing function and variation...........................20
13. IANA Considerations..........................................20 13. Security Considerations......................................20
14. References...................................................21 14. IANA Considerations..........................................21
14.1. Normative References....................................21 15. References...................................................21
14.2. Informative References..................................21 15.1. Normative References....................................21
15. Acknowledgements.............................................23 15.2. Informative References..................................22
Appendix A. Theoretical Maximum Frame Rates......................24 16. Acknowledgements.............................................23
Appendix A. Theoretical Maximum Frame Rates......................25
1. Introduction 1. Introduction
The methodologies described in [RFC2544] and [RFC5180] help vendors The methodologies described in [RFC2544] and [RFC5180] help vendors
and network operators alike analyze the performance of IPv4 and and network operators alike analyze the performance of IPv4 and
IPv6-capable network devices. The methodology presented in [RFC2544] IPv6-capable network devices. The methodology presented in [RFC2544]
is mostly IP version independent, while [RFC5180] contains is mostly IP version independent, while [RFC5180] contains
complementary recommendations, which are specific to the latest IP complementary recommendations, which are specific to the latest IP
version, IPv6. However, [RFC5180] does not cover IPv6 transition version, IPv6. However, [RFC5180] does not cover IPv6 transition
technologies. technologies.
skipping to change at page 5, line 35 skipping to change at page 5, line 35
reference, the IPv6 transition technologies which employ stateful reference, the IPv6 transition technologies which employ stateful
mapping algorithms will be called stateful IPv6 transition mapping algorithms will be called stateful IPv6 transition
technologies. The efficiency with which the state table is managed technologies. The efficiency with which the state table is managed
can be an important performance indicator for these technologies. can be an important performance indicator for these technologies.
Hence, for the stateful IPv6 transition technologies additional Hence, for the stateful IPv6 transition technologies additional
benchmarking tests are RECOMMENDED. benchmarking tests are RECOMMENDED.
Table 1 contains the generic categories as well as associations with Table 1 contains the generic categories as well as associations with
some of the IPv6 transition technologies proposed in the IETF. some of the IPv6 transition technologies proposed in the IETF.
Table 1. IPv6 Transition Technologies Categories Table 1. IPv6 Transition Technologies Categories
o +---+--------------------+------------------------------------+ +---+--------------------+------------------------------------+
o | | Generic category | IPv6 Transition Technology | | | Generic category | IPv6 Transition Technology |
o +---+--------------------+------------------------------------+ +---+--------------------+------------------------------------+
o | 1 | Dual-stack | Dual IP Layer Operations [RFC4213] | | 1 | Dual-stack | Dual IP Layer Operations [RFC4213] |
o +---+--------------------+------------------------------------+ +---+--------------------+------------------------------------+
o | 2 | Single translation | NAT64 [RFC6146], IVI [RFC6219] | | 2 | Single translation | NAT64 [RFC6146], IVI [RFC6219] |
o +---+--------------------+------------------------------------+ +---+--------------------+------------------------------------+
o | 3 | Double translation | 464XLAT [RFC6877], MAP-T [RFC7599] | | 3 | Double translation | 464XLAT [RFC6877], MAP-T [RFC7599] |
o +---+--------------------+------------------------------------+ +---+--------------------+------------------------------------+
o | 4 | Encapsulation | DSLite[RFC6333], MAP-E [RFC7597] | | 4 | Encapsulation | DSLite[RFC6333], MAP-E [RFC7597] |
o | | | Lightweight 4over6 [RFC7596] | | | | Lightweight 4over6 [RFC7596] |
o | | | 6RD [RFC 5569] | | | | 6RD [RFC 5569] |
+---+--------------------+------------------------------------+ +---+--------------------+------------------------------------+
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
In this document, these words will appear with that interpretation In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying [RFC2119] significance. interpreted as carrying [RFC2119] significance.
skipping to change at page 9, line 51 skipping to change at page 10, line 5
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 6 of
this document UDP traffic SHOULD be employed. this document UDP traffic SHOULD be employed.
Considering that a transition technology could process both native
IPv6 traffic and translated/encapsulated traffic, the following
traffic setups are recommended:
i) IPvX only traffic (where the IPvX traffic is to be
translated/encapsulated by the DUT)
ii) 90% IPvX traffic and 10% IPvY native traffic
iii) 50% IPvX traffic and 50% IPvY native traffic
iv) 10% IPvX traffic and 90% IPvY native traffic
Considering that the stateful transition technologies need to manage Considering that the stateful transition technologies need to manage
the state table for each connection, a connection-oriented transport the state table for each connection, a connection-oriented transport
layer protocol needs to be used with the test traffic. Consequently, layer protocol needs to be used with the test traffic. Consequently,
TCP test traffic SHOULD be employed for the tests described in TCP test traffic SHOULD be employed for the tests described in
Section 7 of this document. Section 7 of this document.
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
skipping to change at page 10, line 38 skipping to change at page 10, line 51
definitions of latency from [RFC1242]. However, this memo provides a definitions of latency from [RFC1242]. However, this memo provides a
new measurement procedure. new measurement procedure.
Procedure: Similar to [RFC2544], the throughput for DUT at each of Procedure: Similar to [RFC2544], the throughput for DUT at each of
the listed frame sizes SHOULD be determined. Send a stream of frames the listed frame sizes SHOULD be determined. Send a stream of frames
at a particular frame size through the DUT at the determined 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
least 120 seconds in duration. least 120 seconds in duration.
Identifying tags SHOULD be included in at least 500 frames after 60 Identifying tags SHOULD be included in at least 500 frames after 60
seconds. For each tagged frame, the time at which was fully seconds. For each tagged frame, the time at which the frame was
transmitted (timestamp A) and the time at which the frame was fully transmitted (timestamp A) and the time at which the frame was
received (timestamp B) MUST be recorded. The latency is timestamp B received (timestamp B) MUST be recorded. The latency is timestamp B
minus timestamp A as per the relevant definition from RFC 1242, minus timestamp A as per the relevant definition from RFC 1242,
namely latency as defined for store and forward devices or latency namely latency as defined for store and forward devices or latency
as defined for bit forwarding devices. as defined for bit forwarding devices.
From the resulted (at least 500) latencies, 2 quantities SHOULD be From the resulted (at least 500) latencies, 2 quantities SHOULD be
calculated. One is the typical latency, which SHOULD be calculated calculated. One is the typical latency, which SHOULD be calculated
with the following formula: with the following formula:
TL=Median(Li) TL=Median(Li)
skipping to change at page 11, line 4 skipping to change at page 11, line 17
namely latency as defined for store and forward devices or latency namely latency as defined for store and forward devices or latency
as defined for bit forwarding devices. as defined for bit forwarding devices.
From the resulted (at least 500) latencies, 2 quantities SHOULD be From the resulted (at least 500) latencies, 2 quantities SHOULD be
calculated. One is the typical latency, which SHOULD be calculated calculated. One is the typical latency, which SHOULD be calculated
with the following formula: with the following formula:
TL=Median(Li) TL=Median(Li)
Where: TL - the reported typical latency of the stream Where: TL - the reported typical latency of the stream
Li -the latency for tagged frame i Li -the latency for tagged frame i
The other measure is the worst case latency, which SHOULD be The other measure is the worst case latency, which SHOULD be
calculated with the following formula: calculated with the following formula:
WCL=L99.9thPercentile WCL=L99.9thPercentile
Where: WCL - The reported worst case latency Where: WCL - The reported worst case latency
th L99.9thPercentile - The 99.9 Percentile of the stream measured
L99.9thPercentile - The 99.9th Percentile of the stream measured
latencies latencies
The test MUST be repeated at least 20 times with the reported The test MUST be repeated at least 20 times with the reported
value being the median of the recorded values. value being the median of the recorded values.
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 st th stream tested. To account for the variation, the 1 and 99 typical latency and worst case latency values for each type of data
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. columns. For a fine grain analysis, the histogram (as exemplified in
[RFC5481] Section 4.4) of one of the iterations MAY be displayed as
well.
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 grain analysis of delay RECOMMENDED to measure PDV. For a fine grain analysis of delay
variation, IPDV measurements MAY be performed as well. variation, IPDV measurements MAY be performed as well.
7.3.1. PDV 7.3.1. PDV
skipping to change at page 12, line 4 skipping to change at page 12, line 19
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
least 60 seconds in duration. Measure the One-way delay as described least 60 seconds in duration. Measure the One-way delay as described
by [RFC3393] for all frames in the stream. Calculate the PDV of the by [RFC3393] for all frames in the stream. Calculate the PDV of the
stream using the formula: stream using the formula:
PDV=D99.9thPercentile - Dmin PDV=D99.9thPercentile - Dmin
Where: D99.9thPercentile - the 99.9th Percentile (as it was Where: D99.9thPercentile - the 99.9th Percentile (as it was
described in [RFC5481]) of the One-way delay for the stream described in [RFC5481]) of the One-way delay for the stream
Dmin - the minimum One-way delay in the stream Dmin - the minimum One-way delay in the stream
As recommended in [RFC 2544], the test MUST be repeated at least 20 As recommended in [RFC 2544], the test MUST be repeated at least 20
times with the reported value being the median of the recorded st th values. Moreover, the 1 and 99 percentiles SHOULD be calculated to times with the reported value being the median of the recorded
account for the variation of the dataset. values. Moreover, the 1st and 99th percentiles SHOULD be calculated
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 th columns for the 1st and 99 percentile values MAY as well be size and the applied frame rate for the tested media types. Two
columns for the 1st and 99th percentile values MAY as well be
displayed. Following the recommendations of [RFC5481], the displayed. Following the recommendations of [RFC5481], the
RECOMMENDED units of measurement are milliseconds. RECOMMENDED units of 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
skipping to change at page 13, line 33 skipping to change at page 13, line 44
7.7. Reset - [RFC2544] 7.7. Reset - [RFC2544]
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 4, 5).
In addition to the IPv4/IPv6 transition function a network node can In addition to the IPv4/IPv6 transition function, a network node can
have a firewall function. This document is targeting only the have a firewall function. This document is targeting only the
network devices that do not have a firewall function, as this network devices that do not have a firewall function, as this
function can be benchmarked using the recommendations of [RFC3511]. function can be benchmarked using the recommendations of [RFC3511].
Consequently, only the tests described in [RFC3511] (Sections 5.2, Consequently, only the tests described in [RFC3511] (Sections 5.2,
5.3) are RECOMMENDED. Namely, the following additional tests SHOULD 5.3) are RECOMMENDED. Namely, the following additional tests SHOULD
be performed: be performed:
8.1. Concurrent TCP Connection Capacity -[RFC3511] 8.1. Concurrent TCP Connection Capacity -[RFC3511]
8.2. Maximum TCP Connection Establishment Rate -[RFC3511] 8.2. Maximum TCP Connection Establishment Rate -[RFC3511]
skipping to change at page 15, line 37 skipping to change at page 15, line 45
and the test is rerun. The duration of the test SHOULD be at least and the test is rerun. The duration of the test SHOULD be at least
60 seconds to reduce the potential gain of a DNS64 server, which is 60 seconds to reduce the potential gain of a DNS64 server, which is
able to exhibit higher performance by storing the requests and thus able to exhibit higher performance by storing the requests and thus
utilizing also the timeout time for answering them. For the same utilizing also the timeout time for answering them. For the same
reason, no higher timeout time than 1 second SHOULD be used. reason, no higher timeout time than 1 second SHOULD be used.
The number of processed DNS queries per second is the fastest rate The number of processed DNS queries per second is the fastest rate
at which the count of DNS replies sent by the DUT is equal to the 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. 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 th and 99 percentiles of the number of processed DNS queries per The test SHOULD be repeated at least 20 times and the median and 1st
second SHOULD be calculated. /99th percentiles of the number of processed DNS queries per second
SHOULD be calculated.
Details and parameters: Details and parameters:
1. Caching 1. Caching
First, all the DNS queries MUST contain different domain names (or First, all the DNS queries MUST contain different domain names (or
domain names MUST NOT be repeated before the cache of the DUT is domain names MUST NOT be repeated before the cache of the DUT is
exhausted). Then new tests MAY be executed with 10%, 20%, 30%, etc. exhausted). Then new tests MAY be executed with 10%, 20%, 30%, etc.
domain names which are repeated (early enough to be still in the domain names which are repeated (early enough to be still in the
cache). cache).
skipping to change at page 16, line 16 skipping to change at page 16, line 23
which have an AAAA record. which have an AAAA record.
Please note that the two conditions above are orthogonal, thus all Please note that the two conditions above are orthogonal, thus all
their combinations are possible and MAY be tested. The testing with their combinations are possible and MAY be tested. The testing with
0% repeated DNS names and with 0% existing AAAA record is REQUIRED 0% repeated DNS names and with 0% existing AAAA record is REQUIRED
and the other combinations are OPTIONAL. and the other combinations are OPTIONAL.
Reporting format: The primary result of the DNS64/DNS46 test is the Reporting format: The primary result of the DNS64/DNS46 test is the
average of the number of processed DNS queries per second measured average of the number of processed DNS queries per second measured
with the above mentioned "0% + 0% combination". The average SHOULD with the above mentioned "0% + 0% combination". The average SHOULD
be complemented with the margin of error to show the stability of st the result. If optional tests are done, the median and the 1 and th 99 percentiles MAY be presented in a two dimensional table where be complemented with the margin of error to show the stability of
the result. If optional tests are done, the median and the 1st and
99th percentiles MAY be presented in a two dimensional table where
the dimensions are the proportion of the repeated domain names and the dimensions are the proportion of the repeated domain names and
the proportion of the DNS names having AAAA records. The two table the proportion of the DNS names having AAAA records. The two table
headings SHOULD contain these percentage values. Alternatively, the headings SHOULD contain these percentage values. Alternatively, the
results MAY be presented as the corresponding two dimensional graph, results MAY be presented as the corresponding two dimensional graph,
too. In this case the graph SHOULD show the median values with the too. In this case the graph SHOULD show the median values with the
percentiles as error bars. From both the table and the graph, one percentiles as error bars. From both the table and the graph, one
dimensional excerpts MAY be made at any given fixed percentage value dimensional excerpts MAY be made at any given fixed percentage value
of the other dimension. In this case, the fixed value MUST be given of the other dimension. In this case, the fixed value MUST be given
together with a one dimensional table or graph. together with a one dimensional table or graph.
skipping to change at page 17, line 9 skipping to change at page 17, line 17
Remark: a sample open-source test program, dns64perf++ is available Remark: a sample open-source test program, dns64perf++ is available
from [Dns64perf]. It implements only the client part of the Tester from [Dns64perf]. It implements only the client part of the Tester
and it should be used together with an authoritative DNS server and it should be used together with an authoritative DNS server
implementation, e.g. BIND, NSD or YADIFA. implementation, e.g. BIND, NSD or YADIFA.
10. Scalability 10. 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. yet been proposed. In this context, scalability can be defined as
the ability of each transition technology to accommodate network
In this context, scalability can be defined as the ability of each growth. Poor scalability usually leads to poor performance.
transition technology to accommodate network growth. Considering this, scalability can be measured by quantifying the
network performance degradation while the network grows.
Poor scalability usually leads to poor performance. Considering
this, scalability can be measured by quantifying the network
performance degradation while the network grows.
The following subsections describe how the test setups can be The following subsections describe how the test setups can be
modified to create network growth and how the associated performance modified to create network growth and how the associated performance
degradation can be quantified. degradation can be quantified.
10.1. Test Setup 10.1. Test Setup
The test setups defined in Section 3 have to be modified to create The test setups defined in Section 3 have to be modified to create
network growth. network growth.
skipping to change at page 19, line 18 skipping to change at page 19, line 20
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 results and the n- relative performance change between the 1-flow results and the n-
flow results, using the following formula: 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
As a guideline for the maximum number of flows n, the value can be
deduced by measuring the Concurrent TCP Connection Capacity as
described by [RFC3511], following the test setups specified by
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.
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 6 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. to start all the flows, namely (n-1)xT. The measurement for the
first flow SHOULD be at least 60 seconds in duration.
The performance degradation of the X benchmarking dimension SHOULD The performance degradation of the X benchmarking dimension SHOULD
be calculated as relative performance change between the 1-flow be calculated as relative performance change between the 1-flow
results and the n-flow results, using the following formula results and the n-flow results, using the following formula
presented in Section 9.2.1. presented in Section 9.2.1. Intermediary degradation points for
1/4*n, 1/2*n and 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. measurement for T SHOULD be seconds. A column for the intermediary
degradation points MAY also be displayed.
11. Summarizing function and variation 11. NAT44 and NAT66
Although these technologies are not the primarily scope of this
document, the benchmarking methodology associated with single
translation technologies as defined in Section 4.1 can be employed
to benchmark NAT44 (as defined by [RFC2663] with the behavior
described by [RFC7857]) implementations and NAT66 (as defined by
[RFC6296]) implementations.
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-9, multiple test iterations are the tests presented in Sections 6-9, multiple test iterations are
recommended. Using a summarizing function (or measure of central RECOMMENDED. Using a summarizing function (or measure of central
tendency) can be a simple and effective way to compare the results tendency) can be a simple and effective way to compare the results
obtained across different iterations. However, over-summarization is obtained across different iterations. However, over-summarization is
an unwanted effect of reporting a single number. 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.
To that end, data presented in [ietf95pres] indicate the median as st th suitable summarizing function and the 1 and 99 percentiles as To that end, data presented in [ietf95pres] indicate the median as
variation measures for DNS Resolution Performance and PDV. suitable summarizing function and the 1st and 99th percentiles as
variation measures for DNS Resolution Performance and PDV. . The
median and percentile calculation functions SHOULD follow the
recommendations of [RFC2330] Section 11.3.
For a fine grain analysis of the frequency distribution of the data, For a fine grain analysis of the frequency distribution of the data,
histograms or cumulative distribution function plots can be histograms or cumulative distribution function plots can be
employed. employed.
12. Security Considerations 13. Security Considerations
Benchmarking activities as described in this memo are limited to Benchmarking activities as described in this memo are limited to
technology characterization using controlled stimuli in a laboratory technology characterization using controlled stimuli in a laboratory
environment, with dedicated address space and the constraints environment, with dedicated address space and the constraints
specified in the sections above. specified in the sections above.
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
traffic into a production network, or misroute traffic to the test traffic into a production network, or misroute traffic to the test
management network. management network.
Further, benchmarking is performed on a "black-box" basis, relying Further, benchmarking is performed on a "black-box" basis, relying
solely on measurements observable external to the DUT/SUT. Special solely on measurements observable external to the DUT/SUT. Special
capabilities SHOULD NOT exist in the DUT/SUT specifically for capabilities SHOULD NOT exist in the DUT/SUT specifically for
benchmarking purposes. Any implications for network security arising benchmarking purposes. Any implications for network security arising
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.
13. IANA Considerations 14. IANA Considerations
The IANA has allocated the prefix 2001:0002::/48 [RFC5180] for IPv6 The IANA has allocated the prefix 2001:0002::/48 [RFC5180] for IPv6
benchmarking. For IPv4 benchmarking, the 198.18.0.0/15 prefix was benchmarking. For IPv4 benchmarking, the 198.18.0.0/15 prefix was
reserved, as described in [RFC6890]. The two ranges are sufficient reserved, as described in [RFC6890]. The two ranges are sufficient
for benchmarking IPv6 transition technologies. for benchmarking IPv6 transition technologies.
14. References 15. References
14.1. Normative References 15.1. Normative References
[RFC1242] Bradner, S., "Benchmarking Terminology for Network [RFC1242] Bradner, S., "Benchmarking Terminology for Network
Interconnection Devices", [RFC1242], 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.
[RFC2330] Paxson, V., Almes, G. ,Mahdavi, J., and M. Mathis.
"Framework for IP performance metrics." RFC 2330, May
1998.
[RFC2544] Bradner, S., and J. McQuaid, "Benchmarking Methodology for [RFC2544] Bradner, S., and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", [RFC2544], March 1999. Network Interconnect Devices", RFC 2544, March 1999.
[RFC2647] Newman, D., "Benchmarking Terminology for Firewall [RFC2647] Newman, D., "Benchmarking Terminology for Firewall
Devices", [RFC2647], August 1999. Devices", [RFC2647], August 1999.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393, Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002. November 2002.
[RFC3511] Hickman, B., Newman, D., Tadjudin, S. and T. Martin, [RFC3511] Hickman, B., Newman, D., Tadjudin, S. and T. Martin,
"Benchmarking Methodology for Firewall Performance", "Benchmarking Methodology for Firewall Performance", RFC
[RFC3511], April 2003. 3511, April 2003.
[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.
[RFC5481] Morton, A., and B. Claise, "Packet Delay Variation [RFC5481] Morton, A., and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, March 2009. Applicability Statement", RFC 5481, March 2009.
[RFC6201] Asati, R., Pignataro, C., Calabria, F. and C. Olvera, [RFC6201] Asati, R., Pignataro, C., Calabria, F. and C. Olvera,
"Device Reset Characterization ", RFC 6201, March 2011. "Device Reset Characterization ", RFC 6201, March 2011.
14.2. Informative References 15.2. Informative References
[RFC2663] Srisuresh, P., and M. Holdrege. "IP Network Address
Translator (NAT) Terminology and Considerations", RFC2663,
August 1999.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569,
January 2010, <http://www.rfc-editor.org/info/rfc5569>. January 2010, <http://www.rfc-editor.org/info/rfc5569>.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011. IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
<http://www.rfc-editor.org/info/rfc6145>. <http://www.rfc-editor.org/info/rfc6145>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <http://www.rfc-editor.org/info/rfc6146>. April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
China Education and Research Network (CERNET) IVI China Education and Research Network (CERNET) IVI
Translation Design and Deployment for the IPv4/IPv6 Translation Design and Deployment for the IPv4/IPv6
Coexistence and Transition", RFC 6219, DOI Coexistence and Transition", RFC 6219, DOI
10.17487/RFC6219, May 2011, <http://www.rfc- 10.17487/RFC6219, May 2011, <http://www.rfc-
editor.org/info/rfc6219>. editor.org/info/rfc6219>.
[RFC6296] Wasserman, M., and F. Baker. "IPv6-to-IPv6 network prefix
translation." RFC6296, June 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4 Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011. Exhaustion", RFC 6333, August 2011.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC Combination of Stateful and Stateless Translation", RFC
6877, DOI 10.17487/RFC6877, April 2013, <http://www.rfc- 6877, DOI 10.17487/RFC6877, April 2013, <http://www.rfc-
editor.org/info/rfc6877>. editor.org/info/rfc6877>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153, RFC6890, "Special-Purpose IP Address Registries", BCP 153, RFC6890,
April 2013. April 2013.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
I. Farrer, "Lightweight 4over6: An Extension to the Dual- Farrer, "Lightweight 4over6: An Extension to the Dual-
Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
July 2015, <http://www.rfc-editor.org/info/rfc7596>. July 2015, <http://www.rfc-editor.org/info/rfc7596>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597, DOI Port with Encapsulation (MAP-E)", RFC 7597, DOI
10.17487/RFC7597, July 2015, <http://www.rfc- 10.17487/RFC7597, July 2015, <http://www.rfc-
editor.org/info/rfc7597>. editor.org/info/rfc7597>.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
and T. Murakami, "Mapping of Address and Port using and T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
2015, <http://www.rfc-editor.org/info/rfc7599>. 2015, <http://www.rfc-editor.org/info/rfc7599>.
[RFC7857] Penno, R., Perreault, S., Boucadair, M., Sivakumar, S.,
and K. Naito "Updates to Network Address Translation (NAT)
Behavioral Requirements" RFC 7857, April 2016.
[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 3-8, 2016, available: [to appear] Argentina, April 2016, available:
https://www.ietf.org/proceedings/95/slides/slides-95-bmwg-
2.pdf
15. 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. We would also like to thank Scott Bradner for the useful support. We would also like to thank Scott Bradner for the useful
suggestions. We also note that portions of text from Scott's suggestions. We also note that portions of text from Scott's
documents were used in this memo (e.g. Latency section). A big thank documents were used in this memo (e.g. Latency section). A big thank
you to Al Morton and Fred Baker for their detailed review of the you to Al Morton and Fred Baker for their detailed review of the
draft and very helpful suggestions. Other helpful comments and draft and very helpful suggestions. Other helpful comments and
suggestions were offered by Bhuvaneswaran Vengainathan, Andrew suggestions were offered by Bhuvaneswaran Vengainathan, Andrew
McGregor, Nalini Elkins, Kaname Nishizuka, Yasuhiro Ohara, Masataka McGregor, Nalini Elkins, Kaname Nishizuka, Yasuhiro Ohara, Masataka
Mawatari, Kostas Pentikousis and Bela Almasi. A special thank you to Mawatari, Kostas Pentikousis,Bela Almasi, Tim Chown, Paul Emmerich
the RFC Editor Team for their thorough editorial review and helpful and Stenio Fernandes. A special thank you to the RFC Editor Team for
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. 47 change blocks. 
78 lines changed or deleted 134 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/