draft-ietf-bmwg-ipv6-tran-tech-benchmarking-02.txt   draft-ietf-bmwg-ipv6-tran-tech-benchmarking-03.txt 
Benchmarking Working Group M. Georgescu Benchmarking Working Group M. Georgescu
Internet Draft NAIST Internet Draft L. Pislaru
Intended status: Informational G. Lencse Intended status: Informational RCS&RDS
Expires: January 2017 Szechenyi Istvan University Expires: April 2017 G. Lencse
July 7, 2016 Szechenyi Istvan University
October 27, 2016
Benchmarking Methodology for IPv6 Transition Technologies Benchmarking Methodology for IPv6 Transition Technologies
draft-ietf-bmwg-ipv6-tran-tech-benchmarking-02.txt draft-ietf-bmwg-ipv6-tran-tech-benchmarking-03.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 44 skipping to change at page 2, line 4
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
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 April 27, 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 31 skipping to change at page 2, line 32
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. IPv6 Transition Technologies..............................4 1.1. IPv6 Transition Technologies..............................4
2. Conventions used in this document..............................5 2. Conventions used in this document..............................6
3. Terminology....................................................6 3. Terminology....................................................6
4. Test Setup.....................................................6 4. Test Setup.....................................................7
4.1. Single translation Transition Technologies................7 4.1. Single translation Transition Technologies................7
4.2. Encapsulation/Double translation Transition Technologies..7 4.2. Encapsulation/Double translation Transition Technologies..8
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............................................10
6. Modifiers.....................................................10 6. Modifiers.....................................................10
7. Benchmarking Tests............................................10 7. Benchmarking Tests............................................10
7.1. Throughput - [RFC2544]...................................10 7.1. Throughput...............................................11
7.2. Latency..................................................10 Use Section 26.1 of RFC2544 unmodified........................11
7.3. Packet Delay Variation...................................11 7.2. Latency..................................................11
7.3. Packet Delay Variation...................................12
7.3.1. PDV.................................................12 7.3.1. PDV.................................................12
7.3.2. IPDV................................................12 7.3.2. IPDV................................................13
7.4. Frame Loss Rate - [RFC2544]..............................13 7.4. Frame Loss Rate..........................................13
7.5. Back-to-back Frames - [RFC2544]..........................13 7.5. Back-to-back Frames......................................13
7.6. System Recovery - [RFC2544]..............................13 7.6. System Recovery..........................................14
7.7. Reset - [RFC2544]........................................13 7.7. Reset....................................................14
8. Additional Benchmarking Tests for Stateful IPv6 Transition 8. Additional Benchmarking Tests for Stateful IPv6 Transition
Technologies.....................................................13 Technologies.....................................................14
8.1. Concurrent TCP Connection Capacity -[RFC3511]............14 8.1. Concurrent TCP Connection Capacity.......................14
8.2. Maximum TCP Connection Establishment Rate -[RFC3511].....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...................................14 9.1. Test and Traffic Setup...................................14
9.2. Benchmarking DNS Resolution Performance..................15 9.2. Benchmarking DNS Resolution Performance..................16
9.2.1. Requirements for the Tester.........................16 9.2.1. Requirements for the Tester.........................17
10. Scalability..................................................17 10. Overload Scalability.........................................18
10.1. Test Setup..............................................17 10.1. Test Setup..............................................18
10.1.1. Single Translation Transition Technologies.........17 10.1.1. Single Translation Transition Technologies.........18
10.1.2. Encapsulation/Double Translation Transition 10.1.2. Encapsulation/Double Translation Transition
Technologies...............................................18 Technologies...............................................19
10.2. Benchmarking Performance Degradation....................18 10.2. Benchmarking Performance Degradation....................19
10.2.1. Network performance degradation with simultaneous load 10.2.1. Network performance degradation with simultaneous load
...........................................................18
10.2.2. Network performance degradation with incremental load
...........................................................19 ...........................................................19
11. NAT44 and NAT66..............................................20 10.2.2. Network performance degradation with incremental load
12. Summarizing function and variation...........................20 ...........................................................20
13. Security Considerations......................................20 11. NAT44 and NAT66..............................................21
14. IANA Considerations..........................................21 12. Summarizing function and variation...........................21
15. References...................................................21 13. Security Considerations......................................21
15.1. Normative References....................................21 14. IANA Considerations..........................................22
15.2. Informative References..................................22 15. References...................................................22
16. Acknowledgements.............................................23 15.1. Normative References....................................22
Appendix A. Theoretical Maximum Frame Rates......................25 15.2. Informative References..................................23
16. Acknowledgements.............................................25
Appendix A. Theoretical Maximum Frame Rates......................26
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 4, line 5 skipping to change at page 4, line 7
cannot directly communicate with IPv6-only nodes. To solve this cannot directly communicate with IPv6-only nodes. To solve this
issue, IPv6 transition technologies have been proposed and issue, IPv6 transition technologies have been proposed and
implemented. implemented.
This document presents benchmarking guidelines dedicated to IPv6 This document presents benchmarking guidelines dedicated to IPv6
transition technologies. The benchmarking tests can provide insights transition technologies. The benchmarking tests can provide insights
about the performance of these technologies, which can act as useful about the performance of these technologies, which can act as useful
feedback for developers, as well as for network operators going feedback for developers, as well as for network operators going
through the IPv6 transition process. through the IPv6 transition process.
The document also includes an approach to quantify load scalability. The document also includes an approach to quantify performance when
Load scalability can be defined as a system's ability to gracefully operating in overload. Overload scalability can be defined as a
accommodate higher loads. Because poor scalability usually leads to system's ability to gracefully accommodate greater numbers of flows
poor performance, the proposed approach is to quantify the load than the maximum number of flows which the DUT can operate normally.
scalability by measuring the performance degradation created by a The approach taken here is to quantify the overload scalability by
higher number of network flows. measuring the performance created by an excessive number of network
flows, and comparing performance to the non-overloaded case.
1.1. IPv6 Transition Technologies 1.1. IPv6 Transition Technologies
Two of the basic transition technologies, dual IP layer (also known Two of the basic transition technologies, dual IP layer (also known
as dual stack) and encapsulation are presented in [RFC4213]. as dual stack) and encapsulation are presented in [RFC4213].
IPv4/IPv6 Translation is presented in [RFC6144]. Most of the IPv4/IPv6 Translation is presented in [RFC6144]. Most of the
transition technologies employ at least one variation of these transition technologies employ at least one variation of these
mechanisms. Some of the more complex ones (e.g. DSLite [RFC6333]) mechanisms. Some of the more complex ones (e.g. DSLite [RFC6333])
are using all three. In this context, a generic classification of are using all three. In this context, a generic classification of
the transition technologies can prove useful. the transition technologies can prove useful.
skipping to change at page 4, line 32 skipping to change at page 4, line 35
Tentatively, we can consider a production network transitioning to Tentatively, we can consider a production network transitioning to
IPv6 as being constructed using the following IP domains: IPv6 as being constructed using the following IP domains:
o Domain A: IPvX specific domain o Domain A: IPvX specific domain
o Core domain: which may be IPvY specific or dual-stack(IPvX and o Core domain: which may be IPvY specific or dual-stack(IPvX and
IPvY) IPvY)
o Domain B: IPvX specific domain o Domain B: IPvX specific domain
Note: X,Y are part of the {4,6} set. Note: X,Y are part of the set {4,6}, and X NOT.EQUAL Y.
According to the technology used for the core domain traversal the According to the technology used for the core domain traversal the
transition technologies can be categorized as follows: transition technologies can be categorized as follows:
1. Single Translation: In this case, the production network is 1. Single Translation: In this case, the production network is
assumed to have only two domains, Domain A and the Core domain. assumed to have only two domains, Domain A and the Core domain.
The core domain is assumed to be IPvY specific. IPvX packets are The core domain is assumed to be IPvY specific. IPvX packets are
translated to IPvY at the edge between Domain A and the Core translated to IPvY at the edge between Domain A and the Core
domain. domain.
skipping to change at page 4, line 44 skipping to change at page 5, line 4
According to the technology used for the core domain traversal the According to the technology used for the core domain traversal the
transition technologies can be categorized as follows: transition technologies can be categorized as follows:
1. Single Translation: In this case, the production network is 1. Single Translation: In this case, the production network is
assumed to have only two domains, Domain A and the Core domain. assumed to have only two domains, Domain A and the Core domain.
The core domain is assumed to be IPvY specific. IPvX packets are The core domain is assumed to be IPvY specific. IPvX packets are
translated to IPvY at the edge between Domain A and the Core translated to IPvY at the edge between Domain A and the Core
domain. domain.
2. Dual-stack: the core domain devices implement both IP protocols 2. Dual-stack: the core domain devices implement both IP protocols
3. Encapsulation: The production network is assumed to have all 3. Encapsulation: The production network is assumed to have all
three domains, Domains A and B are IPvX specific, while the core three domains, Domains A and B are IPvX specific, while the core
domain is IPvY specific. An encapsulation mechanism is used to domain is IPvY specific. An encapsulation mechanism is used to
traverse the core domain. The IPvX packets are encapsulated to traverse the core domain. The IPvX packets are encapsulated to
IPvY packets at the edge between Domain A and the Core domain. IPvY packets at the edge between Domain A and the Core domain.
Subsequently, the IPvY packets are decapsulated at the edge Subsequently, the IPvY packets are de-encapsulated at the edge
between the Core domain and Domain B. between the Core domain and Domain B.
4. Double translation: The production network is assumed to have all 4. Double translation: The production network is assumed to have all
three domains, Domains A and B are IPvX specific, while the core three domains, Domains A and B are IPvX specific, while the core
domain is IPvY specific. A translation mechanism is employed for domain is IPvY specific. A translation mechanism is employed for
the traversal of the core network. The IPvX packets are the traversal of the core network. The IPvX packets are
translated to IPvY packets at the edge between Domain A and the translated to IPvY packets at the edge between Domain A and the
Core domain. Subsequently, the IPvY packets are translated back Core domain. Subsequently, the IPvY packets are translated back
to IPvX at the edge between the Core domain and Domain B. to IPvX at the edge between the Core domain and Domain B.
skipping to change at page 5, line 47 skipping to change at page 6, line 17
| | Generic category | IPv6 Transition Technology | | | Generic category | IPv6 Transition Technology |
+---+--------------------+------------------------------------+ +---+--------------------+------------------------------------+
| 1 | Dual-stack | Dual IP Layer Operations [RFC4213] | | 1 | Dual-stack | Dual IP Layer Operations [RFC4213] |
+---+--------------------+------------------------------------+ +---+--------------------+------------------------------------+
| 2 | Single translation | NAT64 [RFC6146], IVI [RFC6219] | | 2 | Single translation | NAT64 [RFC6146], IVI [RFC6219] |
+---+--------------------+------------------------------------+ +---+--------------------+------------------------------------+
| 3 | Double translation | 464XLAT [RFC6877], MAP-T [RFC7599] | | 3 | Double translation | 464XLAT [RFC6877], MAP-T [RFC7599] |
+---+--------------------+------------------------------------+ +---+--------------------+------------------------------------+
| 4 | Encapsulation | DSLite[RFC6333], MAP-E [RFC7597] | | 4 | Encapsulation | DSLite[RFC6333], MAP-E [RFC7597] |
| | | Lightweight 4over6 [RFC7596] | | | | Lightweight 4over6 [RFC7596] |
| | | 6RD [RFC 5569] | | | | 6RD [RFC5569] |
+---+--------------------+------------------------------------+ +---+--------------------+------------------------------------+
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.
Although these terms are usually associated with protocol Although these terms are usually associated with protocol
requirements, in this doc the terms are requirements for users and requirements, in this document the terms are requirements for users
systems that intend to implement the test conditions and claim and systems that intend to implement the test conditions and claim
conformance with this specification. conformance with this specification.
3. Terminology 3. Terminology
A number of terms used in this memo have been defined in other RFCs. A number of terms used in this memo have been defined in other RFCs.
Please refer to those RFCs for definitions, testing procedures and Please refer to those RFCs for definitions, testing procedures and
reporting formats. reporting formats.
Throughput (Benchmark) - [RFC2544] Throughput (Benchmark) - [RFC2544]
skipping to change at page 7, line 42 skipping to change at page 8, line 13
+--------------------+ +--------------------+
Figure 1. Test setup 1 Figure 1. Test setup 1
4.2. Encapsulation/Double translation Transition Technologies 4.2. Encapsulation/Double translation Transition Technologies
For evaluating the performance of Encapsulation and Double For evaluating the performance of Encapsulation and Double
translation transition technologies, a dual DUT setup (see Figure 2) translation transition technologies, a dual DUT setup (see Figure 2)
SHOULD be employed. The tester creates a network flow of IPvX SHOULD be employed. The tester creates a network flow of IPvX
packets. The first DUT is responsible for the encapsulation or packets. The first DUT is responsible for the encapsulation or
translation of IPvX packets into IPvY packets. The IPvY packets are translation of IPvX packets into IPvY packets. The IPvY packets are
decapsulated/translated back to IPvX packets by the second DUT and de-encapsulated/translated back to IPvX packets by the second DUT
forwarded to the tester. and forwarded to the tester.
+--------------------+ +--------------------+
| | | |
+---------------------|IPvX tester IPvX|<------------------+ +---------------------|IPvX tester IPvX|<------------------+
| | | | | | | |
| +--------------------+ | | +--------------------+ |
| | | |
| +--------------------+ +--------------------+ | | +--------------------+ +--------------------+ |
| | | | | | | | | | | |
+----->|IPvX DUT 1 IPvY |----->|IPvY DUT 2 IPvX |------+ +----->|IPvX DUT 1 IPvY |----->|IPvY DUT 2 IPvX |------+
| | | | | | | |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
Figure 2. Test setup 2 Figure 2. Test setup 2
One of the limitations of the dual DUT setup is the inability to One of the limitations of the dual DUT setup is the inability to
reflect asymmetries in behavior between the DUTs. Considering this, reflect asymmetries in behavior between the DUTs. Considering this,
additional performance tests SHOULD be performed using the single additional performance tests SHOULD be performed using the single
DUT setup. DUT setup.
Note: For encapsulation IPv6 transition technologies, in the single Note: For encapsulation IPv6 transition technologies, in the single
DUT setup, in order to test the decapsulation efficiency, the tester DUT setup, in order to test the de-encapsulation efficiency, the
SHOULD be able to send IPvX packets encasulated as IPvY. tester SHOULD be able to send IPvX packets encasulated as IPvY.
5. Test Traffic 5. Test Traffic
The test traffic represents the experimental workload and SHOULD The test traffic represents the experimental workload and SHOULD
meet the requirements specified in this section. The requirements meet the requirements specified in this section. The requirements
are dedicated to unicast IP traffic. Multicast IP traffic is outside are dedicated to unicast IP traffic. Multicast IP traffic is outside
of the scope of this document. of the scope of this document.
5.1. Frame Formats and Sizes 5.1. Frame Formats and Sizes
skipping to change at page 9, line 23 skipping to change at page 9, line 36
encapsulation/translation interfaces SHOULD be set for all encapsulation/translation interfaces SHOULD be set for all
interfaces of the DUT and tester. To be more specific, the minimum interfaces of the DUT and tester. To be more specific, the minimum
IPv6 MTU size (1280 bytes) plus the encapsulation/translation IPv6 MTU size (1280 bytes) plus the encapsulation/translation
overhead is the RECOMMENDED value for the physical interfaces as overhead is the RECOMMENDED value for the physical interfaces as
well as virtual ones. well as virtual ones.
5.1.1. Frame Sizes to Be Used over Ethernet 5.1.1. Frame Sizes to Be Used over Ethernet
Based on the recommendations of [RFC5180], the following frame sizes Based on the recommendations of [RFC5180], the following frame sizes
SHOULD be used for benchmarking IPvX/IPvY traffic on Ethernet links: SHOULD be used for benchmarking IPvX/IPvY traffic on Ethernet links:
64, 128, 256, 512, 1024, 1280, 1518, 1522, 2048, 4096, 8192 and 64, 128, 256, 512, 768 1024, 1280, 1518, 1522, 2048, 4096, 8192 and
9216. 9216.
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 A1.
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
[RFC6145] 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.
skipping to change at page 10, line 15 skipping to change at page 10, line 27
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
iv) 10% IPvX traffic and 90% IPvY native traffic iv) 10% IPvX traffic and 90% IPvY native traffic
Considering that the stateful transition technologies need to manage For the benchmarks dedicated to stateful IPv6 transition
the state table for each connection, a connection-oriented transport technologies, included in Section 8 of this memo (Concurrent TCP
layer protocol needs to be used with the test traffic. Consequently, Connection Capacity and Maximum TCP Connection Establishment Rate),
TCP test traffic SHOULD be employed for the tests described in the traffic SHOULD follow the recommendations of [RFC3511], Sections
Section 7 of this document. 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. [RFC5180] extent the conditions of a production environment. Section 6 of
describes complementary testing conditions specific to IPv6. Their [RFC5180] describes complementary testing conditions specific to
recommendations can be referred for IPv6 transition technologies IPv6. Their recommendations can be referred for IPv6 transition
testing as well. technologies testing as well.
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 - [RFC2544] 7.1. Throughput
Use Section 26.1 of RFC2544 unmodified.
7.2. Latency 7.2. Latency
Objective: To determine the latency. Typical latency is based on the Objective: To determine the latency. Typical latency is based on the
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
skipping to change at page 11, line 31 skipping to change at page 11, line 50
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
L99.9thPercentile - The 99.9th 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 for TL and WCL.
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
skipping to change at page 12, line 25 skipping to change at page 12, line 42
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 [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 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.
skipping to change at page 13, line 4 skipping to change at page 13, line 23
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 IPDV for by [RFC3393] for all frames in the stream. Calculate the IPDV for
each of the frames using the formula: each of the frames using the formula:
IPDV(i)=D(i) - D(i-1) IPDV(i)=D(i) - D(i-1)
Where: D(i) - the One-way delay of the i th frame in the stream Where: D(i) - the One-way delay of the i th frame in the stream
D(i-1) - the One-way delay of i-1 th frame in the stream
Given the nature of IPDV, reporting a single number might lead to Given the nature of IPDV, reporting a single number might lead to
over-summarization. In this context, the report for each measurement over-summarization. In this context, the report for each measurement
SHOULD include 3 values: Dmin, Dmed, and Dmax SHOULD include 3 values: Dmin, Dmed, and Dmax
Where: Dmin - the minimum One-way delay in the stream Where: Dmin - the minimum IPDV in the stream
Dmed - the median One-way delay of the stream Dmed - the median IPDV of the stream
Dmax - the maximum One-way delay in the stream Dmax - the maximum IPDVin 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. To summarize the 20 repetitions, for each of the 3 (Dmin, times. To summarize the 20 repetitions, for each of the 3 (Dmin,
Dmed and Dmax) the median value SHOULD be reported. Dmed and Dmax) the median value SHOULD be reported.
Reporting format: The median for the 3 proposed values SHOULD be Reporting format: The median for the 3 proposed values SHOULD be
reported. The IPDV results SHOULD be reported in a table with a row reported. The IPDV results SHOULD be reported in a table with a row
for each of the tested frame sizes. The columns SHOULD include the for each of the tested frame sizes. The columns SHOULD include the
frame size and associated frame rate for the tested media types and frame size and associated frame rate for the tested media types and
sub-columns for the three proposed reported values. Following the sub-columns for the three proposed reported values. Following the
recommendations of [RFC5481], the RECOMMENDED units of measurement recommendations of [RFC5481], the RECOMMENDED units of measurement
are milliseconds. are milliseconds.
7.4. Frame Loss Rate - [RFC2544] 7.4. Frame Loss Rate
7.5. Back-to-back Frames - [RFC2544] Use Section 26.3 of [RFC2544] unmodified.
7.6. System Recovery - [RFC2544] 7.5. Back-to-back Frames
7.7. Reset - [RFC2544] Use Section 26.4 of [RFC2544] unmodified.
7.6. System Recovery
Use Section 26.5 of[RFC2544]unmodified.
7.7. Reset
Use Section 26.6 of [RFC2544] 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 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
8.2. Maximum TCP Connection Establishment Rate -[RFC3511] Use Section 5.3 of [RFC3511] unmodified.
8.2. Maximum TCP Connection Establishment Rate
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.
9.1. Test and Traffic Setup 9.1. Test and Traffic Setup
The test setup follows the setup proposed for single translation The test setup follows the setup proposed for single translation
skipping to change at page 15, line 17 skipping to change at page 16, line 4
Please note that: Please note that:
- If the DNS64 server implements caching and there is a cache hit - If the DNS64 server implements caching and there is a cache hit
then step 1 is followed by step 6 (and steps 2 through 5 are then step 1 is followed by step 6 (and steps 2 through 5 are
omitted). omitted).
- If the domain name has an AAAA record then it is returned in - If the domain name has an AAAA record then it is returned in
step 3 by the authoritative DNS server, steps 4 and 5 are step 3 by the authoritative DNS server, steps 4 and 5 are
omitted, and the DNS64 server does not synthesizes an AAAA omitted, and the DNS64 server does not synthesizes an AAAA
record, but returns the received AAAA record to the client. record, but returns the received AAAA record to the client.
- As for the IP version used between the tester and the DUT, IPv6 - As for the IP version used between the tester and the DUT, IPv6
MUST be used between the client and the DNS64 server (as a MUST be used between the client and the DNS64 server (as a
DNS64 server provides service for an IPv6-only client), but DNS64 server provides service for an IPv6-only client), but
either IPv4 or IPv6 MAY be used between the DNS64 server and either IPv4 or IPv6 MAY be used between the DNS64 server and
the authoritative DNS server. the authoritative DNS server.
9.2. Benchmarking DNS Resolution Performance 9.2. Benchmarking DNS Resolution Performance
Objective: To determine DNS64 performance by means of the number of Objective: To determine DNS64 performance by means of the maximum
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) from the DUT. If the count query, having the default value 1 second) from the DUT. If the count
of sent queries is equal to the count of received replies, the rate of sent queries is equal to the count of received replies, the rate
of the queries is raised and the test is rerun. If fewer replies are of the queries is raised and the test is rerun. If fewer replies are
received than queries were sent, the rate of the queries is reduced received than queries were sent, the rate of the queries is reduced
and the test is rerun. The duration of the test SHOULD be at least and the test is rerun. The duration of each trial 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 maximum number of processed DNS queries per second is the
at which the count of DNS replies sent by the DUT is equal to the fastest rate at which the count of DNS replies sent by the DUT is
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:
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 domain names, 20%,
domain names which are repeated (early enough to be still in the 40%, 60%, 80% and 100% of which are cached. We note that ensuring a
cache). record being cached requires repeating it both "late enough" after
the first query to be already resolved and be present in the cache
and "early enough" to be still present in the cache.
2. Existence of AAAA record 2. Existence of AAAA record
First, all the DNS queries MUST contain domain names which do not First, all the DNS queries MUST contain domain names which do not
have an AAAA record and have exactly one A record. have an AAAA record and have exactly one A record.
Then new tests MAY be executed with 10%, 20%, 30%, etc. domain names Then new tests MAY be executed with domain names, 20%, 40%, 60%, 80%
which have an AAAA record. and 100% of 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% cached domain names and with 0% existing AAAA record is REQUIRED
and the other combinations are OPTIONAL. and the other combinations are OPTIONAL. (When all the domain names
are cached then the results do not depend on what percentage of the
domain names have AAAA records, thus these combinations are not
worth testing one by one.)
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 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 the result. If optional tests are done, the median and the 1st and
99th percentiles MAY be presented in a two dimensional table where 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
skipping to change at page 17, line 9 skipping to change at page 17, line 51
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]. It implements only the client part of the Tester from [Dns64perf] and it is documented in [Lencse]. It implements
and it should be used together with an authoritative DNS server only the client part of the Tester and it should be used together
implementation, e.g. BIND, NSD or YADIFA. with an authoritative DNS server implementation, e.g. BIND, NSD or
YADIFA.
10. 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, scalability can be defined as yet been proposed. In this context, we can define overload
the ability of each transition technology to accommodate network scalability as the ability of each transition technology to
growth. Poor scalability usually leads to poor performance. accommodate network growth. Poor scalability usually leads to poor
Considering this, scalability can be measured by quantifying the performance. Considering this, overload scalability can be measured
network performance degradation while the network grows. by quantifying the network performance degradation associated with
an increased number of network flows.
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 18, line 34 skipping to change at page 19, line 34
| | ... | | | | | | ... | | | |
| | +-----------------+ | DUT n+1 | | | | | +-----------------+ | DUT n+1 | | |
| +------->| NF2 DUT 2 NF2 |--->|NF2 NF2|--------+ | | +------->| NF2 DUT 2 NF2 |--->|NF2 NF2|--------+ |
| +-----------------+ | | | | +-----------------+ | | |
| +-----------------+ | | | | +-----------------+ | | |
+---------->| NF1 DUT 1 NF1 |--->|NF1 NF1|-----------+ +---------->| NF1 DUT 1 NF1 |--->|NF1 NF1|-----------+
+-----------------+ +---------------+ +-----------------+ +---------------+
Figure 4. Test setup 4 Figure 4. Test setup 4
This test setup can help to quantify the scalability of the server This test setup can help to quantify the scalability of the server
device. However, for testing the scalability of the client DUTs device. However, for testing the overload scalability of the client
additional recommendations are needed. DUTs additional recommendations are needed.
For encapsulation transition technologies a m:n setup can be For encapsulation transition technologies a m:n setup can be
created, where m is the number of flows applied to the same client created, where m is the number of flows applied to the same client
device and n the number of client devices connected to the same device and n the number of client devices connected to the same
server device. server device.
For the translation based transition technologies the client devices For the translation based transition technologies the client devices
can be separately tested with n network flows using the test setup can be separately tested with n network flows using the test setup
presented in Figure 3. presented in Figure 3.
10.2. Benchmarking Performance Degradation 10.2. Benchmarking Performance Degradation
skipping to change at page 19, line 4 skipping to change at page 19, line 47
created, where m is the number of flows applied to the same client created, where m is the number of flows applied to the same client
device and n the number of client devices connected to the same device and n the number of client devices connected to the same
server device. server device.
For the translation based transition technologies the client devices For the translation based transition technologies the client devices
can be separately tested with n network flows using the test setup can be separately tested with n network flows using the test setup
presented in Figure 3. presented in Figure 3.
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 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 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 (single flow) results
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
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.
skipping to change at page 20, line 26 skipping to change at page 21, line 26
Although these technologies are not the primarily scope of this Although these technologies are not the primarily 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-9, multiple test iterations are the tests presented in Sections 6 through 9, multiple test
RECOMMENDED. Using a summarizing function (or measure of central iterations are RECOMMENDED. Using a summarizing function (or measure
tendency) can be a simple and effective way to compare the results of central tendency) can be a simple and effective way to compare
obtained across different iterations. However, over-summarization is the results obtained across different iterations. However, over-
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.
To that end, data presented in [ietf95pres] indicate the median as To that end, data presented in [ietf95pres] indicate the median as
suitable summarizing function and the 1st and 99th percentiles as suitable summarizing function and the 1st and 99th percentiles as
variation measures for DNS Resolution Performance and PDV. . The variation measures for DNS Resolution Performance and PDV. The
median and percentile calculation functions SHOULD follow the median and percentile calculation functions SHOULD follow the
recommendations of [RFC2330] Section 11.3. 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.
13. 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
skipping to change at page 21, line 21 skipping to change at page 22, line 19
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.
14. IANA Considerations 14. IANA Considerations
The IANA has allocated the prefix 2001:0002::/48 [RFC5180] for IPv6 The IANA has allocated the prefix 2001:2::/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. Thus, no action is
requested.
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC1242] Bradner, S., "Benchmarking Terminology for Network [RFC1242] Bradner, S., "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, July 1991. Interconnection Devices", RFC 1242, July 1991.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2330] Paxson, V., Almes, G. ,Mahdavi, J., and M. Mathis. [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis.
"Framework for IP performance metrics." RFC 2330, May "Framework for IP performance metrics." RFC 2330, May
1998. 1998.
[RFC2544] Bradner, S., and J. McQuaid, "Benchmarking Methodology for [RFC2544] Bradner, S., and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999. Network Interconnect Devices", RFC 2544, March 1999.
[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
skipping to change at page 22, line 31 skipping to change at page 23, line 31
[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
Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
<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>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and Beijnum, I.,
"DNS64: DNS Extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers", RFC 6147, DOI
10.17487/RFC6147, April 2011, <http://www.rfc-
editor.org/info/rfc6147>.
[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 [RFC6296] Wasserman, M., and F. Baker. "IPv6-to-IPv6 network prefix
translation." RFC6296, June 2011. translation." RFC6296, June 2011.
skipping to change at page 23, line 29 skipping to change at page 24, line 29
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., [RFC7857] Penno, R., Perreault, S., Boucadair, M., Sivakumar, S.,
and K. Naito "Updates to Network Address Translation (NAT) and K. Naito "Updates to Network Address Translation (NAT)
Behavioral Requirements" RFC 7857, April 2016. Behavioral Requirements" RFC 7857, April 2016.
[RFC7915] LBao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915, DOI
10.17487/RFC7915, June 2016, <http://www.rfc-
editor.org/info/rfc7915>.
[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
[Lencse] Lencse, G., Bakai, D, "Design and Implementation of a Test
Program for Benchmarking DNS64 Servers", IEICE
Transactions on Communications, conditionally accepted,
revised version available:
http://www.hit.bme.hu/~lencse/publications/IEICE-2016-
dns64perfpp-revised.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. We would also like to thank Scott Bradner for the useful support. The thank you list should also include Emanuel Popa and the
suggestions. We also note that portions of text from Scott's RCS&RDS Backbone Team for their support and insights. We would also
documents were used in this memo (e.g. Latency section). A big thank like to thank Scott Bradner for the useful suggestions. We also note
you to Al Morton and Fred Baker for their detailed review of the that portions of text from Scott's documents were used in this memo
draft and very helpful suggestions. Other helpful comments and (e.g. Latency section). A big thank you to Al Morton and Fred Baker
suggestions were offered by Bhuvaneswaran Vengainathan, Andrew for their detailed review of the draft and very helpful suggestions.
McGregor, Nalini Elkins, Kaname Nishizuka, Yasuhiro Ohara, Masataka Other helpful comments and suggestions were offered by Bhuvaneswaran
Mawatari, Kostas Pentikousis,Bela Almasi, Tim Chown, Paul Emmerich Vengainathan, Andrew McGregor, Nalini Elkins, Kaname Nishizuka,
and Stenio Fernandes. A special thank you to the RFC Editor Team for Yasuhiro Ohara, Masataka Mawatari, Kostas Pentikousis, Bela Almasi,
their thorough editorial review and helpful suggestions. This Tim Chown, Paul Emmerich and Stenio Fernandes. A special thank you
document was prepared using 2-Word-v2.0.template.dot. to the RFC Editor Team for their thorough editorial review and
helpful suggestions. This 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.
skipping to change at page 26, line 7 skipping to change at page 27, line 7
| 1518 | 802 | 8,023 | 80,231 | 802,311 | | 1518 | 802 | 8,023 | 80,231 | 802,311 |
| 1522 | 800 | 8,003 | 80,026 | 800,256 | | 1522 | 800 | 8,003 | 80,026 | 800,256 |
| 2048 | 599 | 5,987 | 59,866 | 598,659 | | 2048 | 599 | 5,987 | 59,866 | 598,659 |
| 4096 | 302 | 3,022 | 30,222 | 302,224 | | 4096 | 302 | 3,022 | 30,222 | 302,224 |
| 8192 | 152 | 1,518 | 15,185 | 151,846 | | 8192 | 152 | 1,518 | 15,185 | 151,846 |
| 9216 | 135 | 1,350 | 13,505 | 135,048 | | 9216 | 135 | 1,350 | 13,505 | 135,048 |
+------------+---------+----------+-----------+------------+ +------------+---------+----------+-----------+------------+
Authors' Addresses Authors' Addresses
Marius Georgescu Marius Georgescu
Nara Institute of Science and Technology (NAIST) RCS&RDS
Takayama 8916-5 Strada Dr. Nicolae D. Staicovici 71-75
Nara Bucharest 030167
Japan Romania
Phone: +81 743 72 5216 Phone: +40 31 005 0979
Email: liviumarius-g@is.naist.jp Email: marius.georgescu@rcs-rds.ro
Liviu Pislaru
RCS&RDS
Strada Dr. Nicolae D. Staicovici 71-75
Bucharest 030167
Romania
Phone: +40 31 005 0979
Email: liviu.pislaru@rcs-rds.ro
Gabor Lencse Gabor Lencse
Szechenyi Istvan University Szechenyi Istvan University
Egyetem ter 1. Egyetem ter 1.
Gyor Gyor
Hungary Hungary
Phone: +36 20 775 8267 Phone: +36 20 775 8267
Email: lencse@sze.hu Email: lencse@sze.hu
 End of changes. 66 change blocks. 
139 lines changed or deleted 187 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/