draft-ietf-bmwg-ipv6-tran-tech-benchmarking-03.txt   draft-ietf-bmwg-ipv6-tran-tech-benchmarking-04.txt 
Benchmarking Working Group M. Georgescu Benchmarking Working Group M. Georgescu
Internet Draft L. Pislaru Internet Draft L. Pislaru
Intended status: Informational RCS&RDS Intended status: Informational RCS&RDS
Expires: April 2017 G. Lencse Expires: September 2017 G. Lencse
Szechenyi Istvan University Szechenyi Istvan University
October 27, 2016 March 1, 2017
Benchmarking Methodology for IPv6 Transition Technologies Benchmarking Methodology for IPv6 Transition Technologies
draft-ietf-bmwg-ipv6-tran-tech-benchmarking-03.txt draft-ietf-bmwg-ipv6-tran-tech-benchmarking-04.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 2, line 4 skipping to change at page 1, line 45
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 September 1, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. respect to this document.
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
skipping to change at page 2, line 34 skipping to change at page 2, line 33
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..............................6 2. Conventions used in this document..............................6
3. Terminology....................................................6 3. Terminology....................................................6
4. Test Setup.....................................................7 4. Test Setup.....................................................6
4.1. Single translation Transition Technologies................7 4.1. Single translation Transition Technologies................7
4.2. Encapsulation/Double translation Transition Technologies..8 4.2. Encapsulation/Double translation Transition Technologies..7
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............................................10 5.3. Traffic Setup.............................................9
6. Modifiers.....................................................10 6. Modifiers.....................................................10
7. Benchmarking Tests............................................10 7. Benchmarking Tests............................................10
7.1. Throughput...............................................11 7.1. Throughput...............................................11
Use Section 26.1 of RFC2544 unmodified........................11 Use Section 26.1 of RFC2544 unmodified........................11
7.2. Latency..................................................11 7.2. Latency..................................................11
7.3. Packet Delay Variation...................................12 7.3. Packet Delay Variation...................................12
7.3.1. PDV.................................................12 7.3.1. PDV.................................................12
7.3.2. IPDV................................................13 7.3.2. IPDV................................................13
7.4. Frame Loss Rate..........................................13 7.4. Frame Loss Rate..........................................14
7.5. Back-to-back Frames......................................13 7.5. Back-to-back Frames......................................14
7.6. System Recovery..........................................14 7.6. System Recovery..........................................14
7.7. Reset....................................................14 7.7. Reset....................................................14
8. Additional Benchmarking Tests for Stateful IPv6 Transition 8. Additional Benchmarking Tests for Stateful IPv6 Transition
Technologies.....................................................14 Technologies.....................................................14
8.1. Concurrent TCP Connection Capacity.......................14 8.1. Concurrent TCP Connection Capacity.......................14
8.2. Maximum TCP Connection Establishment Rate................14 8.2. Maximum TCP Connection Establishment Rate................14
9. DNS Resolution Performance....................................14 9. DNS Resolution Performance....................................14
9.1. Test and Traffic Setup...................................14 9.1. Test and Traffic Setup...................................15
9.2. Benchmarking DNS Resolution Performance..................16 9.2. Benchmarking DNS Resolution Performance..................16
9.2.1. Requirements for the Tester.........................17 9.2.1. Requirements for the Tester.........................17
10. Overload Scalability.........................................18 10. Overload Scalability.........................................18
10.1. Test Setup..............................................18 10.1. Test Setup..............................................18
10.1.1. Single Translation Transition Technologies.........18 10.1.1. Single Translation Transition Technologies.........18
10.1.2. Encapsulation/Double Translation Transition 10.1.2. Encapsulation/Double Translation Transition
Technologies...............................................19 Technologies...............................................19
10.2. Benchmarking Performance Degradation....................19 10.2. Benchmarking Performance Degradation....................20
10.2.1. Network performance degradation with simultaneous load 10.2.1. Network performance degradation with simultaneous load
...........................................................19 ...........................................................20
10.2.2. Network performance degradation with incremental load 10.2.2. Network performance degradation with incremental load
...........................................................20 ...........................................................20
11. NAT44 and NAT66..............................................21 11. NAT44 and NAT66..............................................21
12. Summarizing function and variation...........................21 12. Summarizing function and variation...........................21
13. Security Considerations......................................21 13. Security Considerations......................................22
14. IANA Considerations..........................................22 14. IANA Considerations..........................................22
15. References...................................................22 15. References...................................................22
15.1. Normative References....................................22 15.1. Normative References....................................22
15.2. Informative References..................................23 15.2. Informative References..................................23
16. Acknowledgements.............................................25 16. Acknowledgements.............................................26
Appendix A. Theoretical Maximum Frame Rates......................26 Appendix A. Theoretical Maximum Frame Rates......................27
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 40 skipping to change at page 4, line 38
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 set {4,6}, and X NOT.EQUAL Y. 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. Dual-stack: the core domain devices implement both IP protocols.
2. 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 3. Double translation: 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
domain is IPvY specific. An encapsulation mechanism is used to
traverse the core domain. The IPvX packets are encapsulated to
IPvY packets at the edge between Domain A and the Core domain.
Subsequently, the IPvY packets are de-encapsulated at the edge
between the Core domain and Domain B.
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.
4. Encapsulation: The production network is assumed to have all
three domains, Domains A and B are IPvX specific, while the core
domain is IPvY specific. An encapsulation mechanism is used to
traverse the core domain. The IPvX packets are encapsulated to
IPvY packets at the edge between Domain A and the Core domain.
Subsequently, the IPvY packets are de-encapsulated at the edge
between the Core domain and Domain B.
The performance of Dual-stack transition technologies can be fully The performance of Dual-stack transition technologies can be fully
evaluated using the benchmarking methodologies presented by evaluated using the benchmarking methodologies presented by
[RFC2544] and [RFC5180]. Consequently, this document focuses on the [RFC2544] and [RFC5180]. Consequently, this document focuses on the
other 3 categories: Single translation, Encapsulation and Double other 3 categories: Single translation, Encapsulation and Double
translation transition technologies. translation transition technologies.
Another important aspect by which the IPv6 transition technologies Another important aspect by which the IPv6 transition technologies
can be categorized is their use of stateful or stateless mapping can be categorized is their use of stateful or stateless mapping
algorithms. The technologies that use stateful mapping algorithms algorithms. The technologies that use stateful mapping algorithms
(e.g. Stateful NAT64 [RFC6146]) create dynamic correlations between (e.g. Stateful NAT64 [RFC6146]) create dynamic correlations between
skipping to change at page 7, line 38 skipping to change at page 7, line 27
In terms of route setup, the recommendations of [RFC2544] Section 13 In terms of route setup, the recommendations of [RFC2544] Section 13
are valid for this document as well assuming that an IPv6 version of are valid for this document as well assuming that an IPv6 version of
the routing packets shown in appendix C.2.6.2 is used. the routing packets shown in appendix C.2.6.2 is used.
4.1. Single translation Transition Technologies 4.1. Single translation Transition Technologies
For the evaluation of Single translation transition technologies, a For the evaluation of Single translation transition technologies, a
single DUT setup (see Figure 1) SHOULD be used. The DUT is single DUT setup (see Figure 1) SHOULD be used. The DUT is
responsible for translating the IPvX packets into IPvY packets. In responsible for translating the IPvX packets into IPvY packets. In
this context, the tester device should be configured to support both this context, the tester device SHOULD be configured to support both
IPvX and IPvY. IPvX and IPvY.
+--------------------+ +--------------------+
| | | |
+------------|IPvX tester IPvY|<-------------+ +------------|IPvX tester IPvY|<-------------+
| | | | | | | |
| +--------------------+ | | +--------------------+ |
| | | |
| +--------------------+ | | +--------------------+ |
| | | | | | | |
skipping to change at page 9, line 36 skipping to change at page 9, line 23
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, 768 1024, 1280, 1518, 1522, 2048, 4096, 8192 and 64, 128, 256, 512, 768, 1024, 1280, 1518, 1522, 2048, 4096, 8192 and
9216. 9216.
Note: for single translation transition technologies (e.g. NAT64) in
the IPv6 -> IPv4 translation direction, 64 byte frames SHOULD be
replaced by 84 byte frames. This would allow the frames to be
transported over media such as the ones described by the IEEE 802.1Q
standard. Moreover, this would also allow the implementation of a
frame identifier in the UDP data.
The theoretical maximum frame rates considering an example of frame The theoretical maximum frame rates considering an example of frame
overhead are presented in Appendix A1. overhead are presented in Appendix 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
skipping to change at page 11, line 29 skipping to change at page 11, line 29
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 the frame was seconds. For each tagged frame, the time at which the frame was
fully 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.
We recommend to encode the identifying tag in the payload of the
frame. To be more exact, the identifier SHOULD be inserted after the
UDP header.
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
skipping to change at page 13, line 24 skipping to change at page 13, line 29
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 IPDV in the stream Where: Dmin - the minimum IPDV in the stream
Dmed - the median IPDV of the stream Dmed - the median IPDV of the stream
Dmax - the maximum IPDVin the stream Dmax - the maximum IPDVin the stream
As recommended in [RFC 2544], the test MUST be repeated at least 20 The test MUST be repeated at least 20 times. To summarize the 20
times. To summarize the 20 repetitions, for each of the 3 (Dmin, repetitions, for each of the 3 (Dmin, Dmed and Dmax) the median
Dmed and Dmax) the median value SHOULD be reported. 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 7.4. Frame Loss Rate
Use Section 26.3 of [RFC2544] unmodified. Use Section 26.3 of [RFC2544] unmodified.
7.5. Back-to-back Frames 7.5. Back-to-back Frames
Use Section 26.4 of [RFC2544] unmodified. Use Section 26.4 of [RFC2544] unmodified.
7.6. System Recovery 7.6. System Recovery
Use Section 26.5 of[RFC2544]unmodified. Use Section 26.5 of [RFC2544] unmodified.
7.7. Reset 7.7. Reset
Use Section 26.6 of [RFC2544] unmodified. 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
skipping to change at page 14, line 45 skipping to change at page 15, line 7
Use Section 5.3 of RFC3511 unmodified. Use Section 5.3 of RFC3511 unmodified.
9. DNS Resolution Performance 9. DNS Resolution Performance
This section describes benchmarking tests dedicated to DNS64 (see This section describes benchmarking tests dedicated to DNS64 (see
[RFC6147]), used as DNS support for single translation technologies [RFC6147]), used as DNS support for single translation technologies
such as NAT64. such as NAT64.
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 in Figure 3 follows the setup proposed for single
IPv6 transition technologies in Figure 1. translation IPv6 transition technologies in Figure 1.
1:AAAA query +--------------------+ 1:AAAA query +--------------------+
+------------| |<-------------+ +------------| |<-------------+
| |IPv6 Tester IPv4| | | |IPv6 Tester IPv4| |
| +-------->| |----------+ | | +-------->| |----------+ |
| | +--------------------+ 3:empty | | | | +--------------------+ 3:empty | |
| | 6:synt'd AAAA, | | | | 6:synt'd AAAA, | |
| | AAAA +--------------------+ 5:valid A| | | | AAAA +--------------------+ 5:valid A| |
| +---------| |<---------+ | | +---------| |<---------+ |
| |IPv6 DUT IPv4| | | |IPv6 DUT IPv4| |
+----------->| (DNS64) |--------------+ +----------->| (DNS64) |--------------+
+--------------------+ 2:AAAA query, 4:A query +--------------------+ 2:AAAA query, 4:A query
Figure 3. DNS64 test setup
The test traffic SHOULD follow the following steps. The test traffic SHOULD follow the following steps.
1. Query for the AAAA record of a domain name (from client to DNS64 1. Query for the AAAA record of a domain name (from client to DNS64
server) server)
2. Query for the AAAA record of the same domain name (from DNS64 2. Query for the AAAA record of the same domain name (from DNS64
server to authoritative DNS server) server to authoritative DNS server)
3. Empty AAAA record answer (from authoritative DNS server to DNS64 3. Empty AAAA record answer (from authoritative DNS server to DNS64
skipping to change at page 16, line 19 skipping to change at page 16, line 23
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 maximum Objective: To determine DNS64 performance by means of the maximum
number of successfully processed DNS requests per second. number of successfully processed DNS requests per second.
Procedure: Send a specific number of DNS queries at a specific rate Procedure: Send a specific number of DNS queries at a specific rate
to the DUT and then count the replies received in time (within a to the DUT and then count the replies received in time (within a
predefined timeout period from the sending time of the corresponding predefined timeout period from the sending time of the corresponding
query, having the default value 1 second) from the DUT. If the count query, having the default value 1 second) and valid (contains an
of sent queries is equal to the count of received replies, the rate AAAA record) from the DUT. If the count of sent queries is equal to
of the queries is raised and the test is rerun. If fewer replies are the count of received replies, the rate of the queries is raised and
received than queries were sent, the rate of the queries is reduced the test is rerun. If fewer replies are received than queries were
and the test is rerun. The duration of each trial SHOULD be at least sent, the rate of the queries is reduced and the test is rerun. The
60 seconds to reduce the potential gain of a DNS64 server, which is duration of each trial SHOULD be at least 60 seconds to reduce the
able to exhibit higher performance by storing the requests and thus potential gain of a DNS64 server, which is able to exhibit higher
utilizing also the timeout time for answering them. For the same performance by storing the requests and thus utilizing also the
reason, no higher timeout time than 1 second SHOULD be used. timeout time for answering them. For the same reason, no higher
timeout time than 1 second SHOULD be used.
The maximum number of processed DNS queries per second is the The maximum number of processed DNS queries per second is the
fastest rate at which the count of DNS replies sent by the DUT is fastest rate at which the count of DNS replies sent by the DUT is
equal to the number of DNS queries sent to it by the test equipment. equal to the number of DNS queries sent to it by the test equipment.
The test SHOULD be repeated at least 20 times and the median and 1st The test SHOULD be repeated at least 20 times and the median and 1st
/99th percentiles of the number of processed DNS queries per second /99th percentiles of the number of processed DNS queries per second
SHOULD be calculated. SHOULD be calculated.
Details and parameters: Details and parameters:
skipping to change at page 17, line 13 skipping to change at page 17, line 19
and 100% of 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% cached domain 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. (When all the domain names and the other combinations are OPTIONAL. (When all the domain names
are cached then the results do not depend on what percentage of the are cached then the results do not depend on what percentage of the
domain names have AAAA records, thus these combinations are not domain names have AAAA records, thus these combinations are not
worth testing one by one.) 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 test is the median
average of the number of processed DNS queries per second measured of the number of processed DNS queries per second measured with the
with the above mentioned "0% + 0% combination". The average SHOULD above mentioned "0% + 0% combination". The median SHOULD be
be complemented with the margin of error to show the stability of complemented with the 1st and 99th percentiles to show the stability
the result. If optional tests are done, the median and the 1st and of the result. If optional tests are done, the median and the 1st
99th percentiles MAY be presented in a two dimensional table where and 99th percentiles MAY be presented in a two dimensional table
the dimensions are the proportion of the repeated domain names and where the dimensions are the proportion of the repeated domain names
the proportion of the DNS names having AAAA records. The two table and the proportion of the DNS names having AAAA records. The two
headings SHOULD contain these percentage values. Alternatively, the table headings SHOULD contain these percentage values.
results MAY be presented as the corresponding two dimensional graph, Alternatively, the results MAY be presented as the corresponding two
too. In this case the graph SHOULD show the median values with the dimensional graph, too. In this case the graph SHOULD show the
percentiles as error bars. From both the table and the graph, one median values with the percentiles as error bars. From both the
dimensional excerpts MAY be made at any given fixed percentage value table and the graph, one dimensional excerpts MAY be made at any
of the other dimension. In this case, the fixed value MUST be given given fixed percentage value of the other dimension. In this case,
together with a one dimensional table or graph. the fixed value MUST be given together with a one dimensional table
or graph.
9.2.1. Requirements for the Tester 9.2.1. Requirements for the Tester
Before a Tester can be used for testing a DUT at rate r queries per Before a Tester can be used for testing a DUT at rate r queries per
second with t seconds timeout, it MUST perform a self-test in order second with t seconds timeout, it MUST perform a self-test in order
to exclude the possibility that the poor performance of the Tester to exclude the possibility that the poor performance of the Tester
itself influences the results. For performing a self-test, the itself influences the results. For performing a self-test, the
tester is looped back (leaving out DUT) and its authoritative DNS tester is looped back (leaving out DUT) and its authoritative DNS
server subsystem is configured to be able to answer all the AAAA server subsystem is configured to be able to answer all the AAAA
record queries. For passing the self-test, the Tester SHOULD be able record queries. For passing the self-test, the Tester SHOULD be able
skipping to change at page 17, line 51 skipping to change at page 18, line 8
Explanation: When performing DNS64 testing, each AAAA record query Explanation: When performing DNS64 testing, each AAAA record query
may result in at most two queries sent by the DUT, the first one of may result in at most two queries sent by the DUT, the first one of
them is for an AAAA record and the second one is for an A record them is for an AAAA record and the second one is for an A record
(the are both sent when there is no cache hit and also no AAAA (the are both sent when there is no cache hit and also no AAAA
record exists). The parameters above guarantee that the record exists). The parameters above guarantee that the
authoritative DNS server subsystem of the DUT is able to answer the authoritative DNS server subsystem of the DUT is able to answer the
queries at the required frequency using up not more than the half of queries at the required frequency using up not more than the half of
the timeout time. the timeout time.
Remark: a sample open-source test program, dns64perf++ is available Remark: a sample open-source test program, dns64perf++ is available
from [Dns64perf] and it is documented in [Lencse]. It implements from [Dns64perf] and it is documented in [Lencse1]. It implements
only the client part of the Tester and it should be used together only the client part of the Tester and it should be used together
with an authoritative DNS server implementation, e.g. BIND, NSD or with an authoritative DNS server implementation, e.g. BIND, NSD or
YADIFA. YADIFA. Its experimental extension for testing caching is available
from [Lencse2] and it is documented in [Lencse3].
10. Overload Scalability 10. Overload Scalability
Scalability has been often discussed; however, in the context of Scalability has been often discussed; however, in the context of
network devices, a formal definition or a measurement method has not network devices, a formal definition or a measurement method has not
yet been proposed. In this context, we can define overload yet been proposed. In this context, we can define overload
scalability as the ability of each transition technology to scalability as the ability of each transition technology to
accommodate network growth. Poor scalability usually leads to poor accommodate network growth. Poor scalability usually leads to poor
performance. Considering this, overload scalability can be measured performance. Considering this, overload scalability can be measured
by quantifying the network performance degradation associated with by quantifying the network performance degradation associated with
skipping to change at page 18, line 31 skipping to change at page 18, line 38
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.
10.1.1. Single Translation Transition Technologies 10.1.1. Single Translation Transition Technologies
In the case of single translation transition technologies the In the case of single translation transition technologies the
network growth can be generated by increasing the number of network network growth can be generated by increasing the number of network
flows generated by the tester machine (see Figure 3). flows generated by the tester machine (see Figure 4).
+-------------------------+ +-------------------------+
+------------|NF1 NF1|<-------------+ +------------|NF1 NF1|<-------------+
| +---------|NF2 tester NF2|<----------+ | | +---------|NF2 tester NF2|<----------+ |
| | ...| | | | | | ...| | | |
| | +-----|NFn NFn|<------+ | | | | +-----|NFn NFn|<------+ | |
| | | +-------------------------+ | | | | | | +-------------------------+ | | |
| | | | | | | | | | | |
| | | +-------------------------+ | | | | | | +-------------------------+ | | |
| | +---->|NFn NFn|-------+ | | | | +---->|NFn NFn|-------+ | |
| | ...| DUT | | | | | ...| DUT | | |
| +-------->|NF2 (translator) NF2|-----------+ | | +-------->|NF2 (translator) NF2|-----------+ |
+----------->|NF1 NF1|--------------+ +----------->|NF1 NF1|--------------+
+-------------------------+ +-------------------------+
Figure 3. Test setup 3 Figure 4. Test setup 3
10.1.2. Encapsulation/Double Translation Transition Technologies 10.1.2. Encapsulation/Double Translation Transition Technologies
Similarly, for the encapsulation/double translation technologies a Similarly, for the encapsulation/double translation technologies a
multi-flow setup is recommended. Considering a multipoint-to-point multi-flow setup is recommended. Considering a multipoint-to-point
scenario, for most transition technologies, one of the edge nodes is scenario, for most transition technologies, one of the edge nodes is
designed to support more than one connecting devices. Hence, the designed to support more than one connecting devices. Hence, the
recommended test setup is a n:1 design, where n is the number of recommended test setup is a n:1 design, where n is the number of
client DUTs connected to the same server DUT (See Figure 4). client DUTs connected to the same server DUT (See Figure 5).
+-------------------------+ +-------------------------+
+--------------------|NF1 NF1|<--------------+ +--------------------|NF1 NF1|<--------------+
| +-----------------|NF2 tester NF2|<-----------+ | | +-----------------|NF2 tester NF2|<-----------+ |
| | ...| | | | | | ...| | | |
| | +-------------|NFn NFn|<-------+ | | | | +-------------|NFn NFn|<-------+ | |
| | | +-------------------------+ | | | | | | +-------------------------+ | | |
| | | | | | | | | | | |
| | | +-----------------+ +---------------+ | | | | | | +-----------------+ +---------------+ | | |
| | +--->| NFn DUT n NFn |--->|NFn NFn| ---+ | | | | +--->| NFn DUT n NFn |--->|NFn NFn| ---+ | |
| | +-----------------+ | | | | | | +-----------------+ | | | |
| | ... | | | | | | ... | | | |
| | +-----------------+ | 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 5. 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 overload scalability of the client device. However, for testing the overload scalability of the client
DUTs 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 4.
10.2. Benchmarking Performance Degradation 10.2. Benchmarking Performance Degradation
10.2.1. Network performance degradation with simultaneous load 10.2.1. Network performance degradation with simultaneous load
Objective: To quantify the performance degradation introduced by n Objective: To quantify the performance degradation introduced by n
parallel and simultaneous network flows. parallel and simultaneous network flows.
Procedure: First, the benchmarking tests presented in Section 6 have Procedure: First, the benchmarking tests presented in Section 6 have
to be performed for one network flow. to be performed for one network flow.
skipping to change at page 22, line 30 skipping to change at page 22, line 47
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. Thus, no action is for benchmarking IPv6 transition technologies. Thus, no action is
requested. 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, DOI 10.17487/RFC1242,
July 1991, <http://www.rfc-editor.org/info/rfc1242>.
[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, DOI
10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>.
[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, DOI
1998. 10.17487/RFC2330, May 1998, <http://www.rfc-
editor.org/info/rfc2330>.
[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, DOI
10.17487/RFC2544, March 1999, <http://www.rfc-
editor.org/info/rfc2544>.
[RFC2647] Newman, D., "Benchmarking Terminology for Firewall [RFC2647] Newman, D., "Benchmarking Terminology for Firewall
Devices", [RFC2647], August 1999. Devices", RFC 2647, DOI 10.17487/RFC1242, August 1999,
<http://www.rfc-editor.org/info/rfc2647>.
[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, DOI
November 2002. 10.17487/RFC3393, November 2002, <http://www.rfc-
editor.org/info/rfc3393>.
[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", RFC "Benchmarking Methodology for Firewall Performance", RFC
3511, April 2003. 3511, DOI 10.17487/RFC3511, April 2003, <http://www.rfc-
editor.org/info/rfc3511>.
[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, DOI 10.17487/RFC5180, May
2008, <http://www.rfc-editor.org/info/rfc5180>.
[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, DOI 10.17487/RFC5481,
March 2009, <http://www.rfc-editor.org/info/rfc5481>.
[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, DOI
10.17487/RFC6201, March 2011, <http://www.rfc-
editor.org/info/rfc6201>.
15.2. Informative References 15.2. Informative References
[RFC2663] Srisuresh, P., and M. Holdrege. "IP Network Address [RFC2663] Srisuresh, P., and M. Holdrege. "IP Network Address
Translator (NAT) Terminology and Considerations", RFC2663, Translator (NAT) Terminology and Considerations", RFC2663,
August 1999. DOI 10.17487/RFC2663, August 1999, <http://www.rfc-
editor.org/info/rfc2663>.
[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, DOI
10.17487/RFC4213, October 2005, <http://www.rfc-
editor.org/info/rfc4213>.
[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, DOI 10.17487/RFC6144,
April 2011, <http://www.rfc-editor.org/info/rfc6144>.
[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., [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
"DNS64: DNS Extensions for Network Address Translation Beijnum, "DNS64: DNS Extensions for Network Address
from IPv6 Clients to IPv4 Servers", RFC 6147, DOI Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
10.17487/RFC6147, April 2011, <http://www.rfc- DOI 10.17487/RFC6147, April 2011, <http://www.rfc-
editor.org/info/rfc6147>. 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, DOI 10.17487/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, DOI 10.17487/RFC6333, August 2011,
<http://www.rfc-editor.org/info/rfc6333>.
[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. DOI 10.17487/RFC6890, April 2013, <http://www.rfc-
editor.org/info/rfc6890>.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and 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., [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, DOI 10.17487/RFC7857,
April 2016, <http://www.rfc-editor.org/info/rfc7857>.
[RFC7915] LBao, C., Li, X., Baker, F., Anderson, T., and F. Gont, [RFC7915] LBao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915, DOI "IP/ICMP Translation Algorithm", RFC 7915, DOI
10.17487/RFC7915, June 2016, <http://www.rfc- 10.17487/RFC7915, June 2016, <http://www.rfc-
editor.org/info/rfc7915>. 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 [Lencse1] Lencse, G., Bakai, D, "Design and Implementation of a Test
Program for Benchmarking DNS64 Servers", IEICE Program for Benchmarking DNS64 Servers", IEICE
Transactions on Communications, conditionally accepted, Transactions on Communications, to be published (vol.
revised version available: E100-B, no. 6. pp. -, June 2017.), advance publication is
available: http://doi.org/10.1587/transcom.2016EBN0007
revised version is freely available:
http://www.hit.bme.hu/~lencse/publications/IEICE-2016- http://www.hit.bme.hu/~lencse/publications/IEICE-2016-
dns64perfpp-revised.pdf dns64perfpp-revised.pdf
[Lencse2] http://www.hit.bme.hu/~lencse/dns64perfppc/
[Lencse3] G. Lencse, "Enabling Dns64perf++ for Benchmarking the
Caching Performance of DNS64 Servers", unpublished, review
version is available:
http://www.hit.bme.hu/~lencse/publications/IEICE-2016-
dns64perfppc-for-review.pdf
16. Acknowledgements 16. Acknowledgements
The authors would like to thank Youki Kadobayashi and Hiroaki The authors would like to thank Youki Kadobayashi and Hiroaki
Hazeyama for their constant feedback and support. The thanks should Hazeyama for their constant feedback and support. The thanks should
be extended to the NECOMA project members for their continuous be extended to the NECOMA project members for their continuous
support. The thank you list should also include Emanuel Popa and the support. The thank you list should also include Emanuel Popa and the
RCS&RDS Backbone Team for their support and insights. We would also RCS&RDS Backbone Team for their support and insights. We would also
like to thank Scott Bradner for the useful suggestions. We also note like to thank Scott Bradner for the useful suggestions. We also note
that portions of text from Scott's documents were used in this memo that portions of text from Scott's documents were used in this memo
(e.g. Latency section). A big thank you to Al Morton and Fred Baker (e.g. Latency section). A big thank you to Al Morton and Fred Baker
skipping to change at page 26, line 42 skipping to change at page 27, line 42
can be found in the following table: can be found in the following table:
+------------+---------+----------+-----------+------------+ +------------+---------+----------+-----------+------------+
| Frame size | 10 Mb/s | 100 Mb/s | 1000 Mb/s | 10000 Mb/s | | Frame size | 10 Mb/s | 100 Mb/s | 1000 Mb/s | 10000 Mb/s |
| (bytes) | (fps) | (fps) | (fps) | (fps) | | (bytes) | (fps) | (fps) | (fps) | (fps) |
+------------+---------+----------+-----------+------------+ +------------+---------+----------+-----------+------------+
| 64 | 12,019 | 120,192 | 1,201,923 | 12,019,231 | | 64 | 12,019 | 120,192 | 1,201,923 | 12,019,231 |
| 128 | 7,440 | 74,405 | 744,048 | 7,440,476 | | 128 | 7,440 | 74,405 | 744,048 | 7,440,476 |
| 256 | 4,223 | 42,230 | 422,297 | 4,222,973 | | 256 | 4,223 | 42,230 | 422,297 | 4,222,973 |
| 512 | 2,264 | 22,645 | 226,449 | 2,264,493 | | 512 | 2,264 | 22,645 | 226,449 | 2,264,493 |
| 678 | 1,740 | 17,409 | 174,094 | 1,740,947 |
| 1024 | 1,175 | 11,748 | 117,481 | 1,174,812 | | 1024 | 1,175 | 11,748 | 117,481 | 1,174,812 |
| 1280 | 947 | 9,470 | 94,697 | 946,970 | | 1280 | 947 | 9,470 | 94,697 | 946,970 |
| 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 |
+------------+---------+----------+-----------+------------+ +------------+---------+----------+-----------+------------+
 End of changes. 59 change blocks. 
93 lines changed or deleted 145 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/