idnits 2.17.00 (12 Aug 2021) /tmp/idnits11239/draft-ietf-bmwg-ipv6-tran-tech-benchmarking-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 12, 2017) is 1797 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802.1AC' is mentioned on line 405, but not defined == Unused Reference: 'IEEE802.1AC-2016' is defined on line 1194, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Benchmarking Working Group M. Georgescu 2 Internet Draft L. Pislaru 3 Intended status: Informational RCS&RDS 4 Expires: December 2017 G. Lencse 5 Szechenyi Istvan University 6 June 12, 2017 8 Benchmarking Methodology for IPv6 Transition Technologies 9 draft-ietf-bmwg-ipv6-tran-tech-benchmarking-08.txt 11 Abstract 13 There are benchmarking methodologies addressing the performance of 14 network interconnect devices that are IPv4- or IPv6-capable, but the 15 IPv6 transition technologies are outside of their scope. This 16 document provides complementary guidelines for evaluating the 17 performance of IPv6 transition technologies. More specifically, 18 this document targets IPv6 transition technologies that employ 19 encapsulation or translation mechanisms, as dual-stack nodes can be 20 very well tested using the recommendations of RFC2544 and RFC5180. 21 The methodology also includes a metric for benchmarking load 22 scalability. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on December 12, 2016. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with 64 respect to this document. Code Components extracted from this 65 document must include Simplified BSD License text as described in 66 Section 4.e of the Trust Legal Provisions and are provided without 67 warranty as described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction...................................................3 72 1.1. IPv6 Transition Technologies..............................4 73 2. Conventions used in this document..............................6 74 3. Terminology....................................................6 75 4. Test Setup.....................................................6 76 4.1. Single translation Transition Technologies................7 77 4.2. Encapsulation/Double translation Transition Technologies..7 78 5. Test Traffic...................................................8 79 5.1. Frame Formats and Sizes...................................8 80 5.1.1. Frame Sizes to Be Used over Ethernet.................9 81 5.2. Protocol Addresses........................................9 82 5.3. Traffic Setup.............................................9 83 6. Modifiers.....................................................10 84 7. Benchmarking Tests............................................10 85 7.1. Throughput...............................................11 86 Use Section 26.1 of RFC2544 unmodified........................11 87 7.2. Latency..................................................11 88 7.3. Packet Delay Variation...................................12 89 7.3.1. PDV.................................................12 90 7.3.2. IPDV................................................13 91 7.4. Frame Loss Rate..........................................14 92 7.5. Back-to-back Frames......................................14 93 7.6. System Recovery..........................................14 94 7.7. Reset....................................................14 96 8. Additional Benchmarking Tests for Stateful IPv6 Transition 97 Technologies.....................................................14 98 8.1. Concurrent TCP Connection Capacity.......................14 99 8.2. Maximum TCP Connection Establishment Rate................14 100 9. DNS Resolution Performance....................................14 101 9.1. Test and Traffic Setup...................................14 102 9.2. Benchmarking DNS Resolution Performance..................16 103 9.2.1. Requirements for the Tester.........................17 104 10. Overload Scalability.........................................18 105 10.1. Test Setup..............................................18 106 10.1.1. Single Translation Transition Technologies.........18 107 10.1.2. Encapsulation/Double Translation Transition 108 Technologies...............................................19 109 10.2. Benchmarking Performance Degradation....................19 110 10.2.1. Network performance degradation with simultaneous load 111 ...........................................................19 112 10.2.2. Network performance degradation with incremental load 113 ...........................................................20 114 11. NAT44 and NAT66..............................................21 115 12. Summarizing function and variation...........................21 116 13. Security Considerations......................................22 117 14. IANA Considerations..........................................22 118 15. References...................................................22 119 15.1. Normative References....................................22 120 15.2. Informative References..................................23 121 16. Acknowledgements.............................................26 122 Appendix A. Theoretical Maximum Frame Rates......................27 124 1. Introduction 126 The methodologies described in [RFC2544] and [RFC5180] help vendors 127 and network operators alike analyze the performance of IPv4 and 128 IPv6-capable network devices. The methodology presented in [RFC2544] 129 is mostly IP version independent, while [RFC5180] contains 130 complementary recommendations, which are specific to the latest IP 131 version, IPv6. However, [RFC5180] does not cover IPv6 transition 132 technologies. 134 IPv6 is not backwards compatible, which means that IPv4-only nodes 135 cannot directly communicate with IPv6-only nodes. To solve this 136 issue, IPv6 transition technologies have been proposed and 137 implemented. 139 This document presents benchmarking guidelines dedicated to IPv6 140 transition technologies. The benchmarking tests can provide insights 141 about the performance of these technologies, which can act as useful 142 feedback for developers, as well as for network operators going 143 through the IPv6 transition process. 145 The document also includes an approach to quantify performance when 146 operating in overload. Overload scalability can be defined as a 147 system's ability to gracefully accommodate greater numbers of flows 148 than the maximum number of flows which the Device under test (DUT) 149 can operate normally. The approach taken here is to quantify the 150 overload scalability by measuring the performance created by an 151 excessive number of network flows, and comparing performance to the 152 non-overloaded case. 154 1.1. IPv6 Transition Technologies 156 Two of the basic transition technologies, dual IP layer (also known 157 as dual stack) and encapsulation are presented in [RFC4213]. 158 IPv4/IPv6 Translation is presented in [RFC6144]. Most of the 159 transition technologies employ at least one variation of these 160 mechanisms. In this context, a generic classification of the 161 transition technologies can prove useful. 163 We can consider a production network transitioning to IPv6 as being 164 constructed using the following IP domains: 166 o Domain A: IPvX specific domain 168 o Core domain: which may be IPvY specific or dual-stack(IPvX and 169 IPvY) 171 o Domain B: IPvX specific domain 173 Note: X,Y are part of the set {4,6}, and X NOT.EQUAL Y. 175 According to the technology used for the core domain traversal the 176 transition technologies can be categorized as follows: 178 1. Dual-stack: the core domain devices implement both IP protocols. 180 2. Single Translation: In this case, the production network is 181 assumed to have only two domains, Domain A and the Core domain. 182 The core domain is assumed to be IPvY specific. IPvX packets are 183 translated to IPvY at the edge between Domain A and the Core 184 domain. 186 3. Double translation: The production network is assumed to have all 187 three domains; Domains A and B are IPvX specific, while the core 188 domain is IPvY specific. A translation mechanism is employed for 189 the traversal of the core network. The IPvX packets are 190 translated to IPvY packets at the edge between Domain A and the 191 Core domain. Subsequently, the IPvY packets are translated back 192 to IPvX at the edge between the Core domain and Domain B. 194 4. Encapsulation: The production network is assumed to have all 195 three domains; Domains A and B are IPvX specific, while the core 196 domain is IPvY specific. An encapsulation mechanism is used to 197 traverse the core domain. The IPvX packets are encapsulated to 198 IPvY packets at the edge between Domain A and the Core domain. 199 Subsequently, the IPvY packets are de-encapsulated at the edge 200 between the Core domain and Domain B. 202 The performance of Dual-stack transition technologies can be fully 203 evaluated using the benchmarking methodologies presented by 204 [RFC2544] and [RFC5180]. Consequently, this document focuses on the 205 other 3 categories: Single translation, Encapsulation and Double 206 translation transition technologies. 208 Another important aspect by which the IPv6 transition technologies 209 can be categorized is their use of stateful or stateless mapping 210 algorithms. The technologies that use stateful mapping algorithms 211 (e.g. Stateful NAT64 [RFC6146]) create dynamic correlations between 212 IP addresses or {IP address, transport protocol, transport port 213 number} tuples, which are stored in a state table. For ease of 214 reference, the IPv6 transition technologies which employ stateful 215 mapping algorithms will be called stateful IPv6 transition 216 technologies. The efficiency with which the state table is managed 217 can be an important performance indicator for these technologies. 218 Hence, for the stateful IPv6 transition technologies additional 219 benchmarking tests are RECOMMENDED. 221 Table 1 contains the generic categories as well as associations with 222 some of the IPv6 transition technologies proposed in the IETF. 223 Please note that the list is not exhaustive. 225 Table 1. IPv6 Transition Technologies Categories 226 +---+--------------------+------------------------------------+ 227 | | Generic category | IPv6 Transition Technology | 228 +---+--------------------+------------------------------------+ 229 | 1 | Dual-stack | Dual IP Layer Operations [RFC4213] | 230 +---+--------------------+------------------------------------+ 231 | 2 | Single translation | NAT64 [RFC6146], IVI [RFC6219] | 232 +---+--------------------+------------------------------------+ 233 | 3 | Double translation | 464XLAT [RFC6877], MAP-T [RFC7599] | 234 +---+--------------------+------------------------------------+ 235 | 4 | Encapsulation | DSLite[RFC6333], MAP-E [RFC7597] | 236 | | | Lightweight 4over6 [RFC7596] | 237 | | | 6RD [RFC5569], 6PE [RFC4798], 6VPE | 238 | | | 6VPE [RFC4659] | 239 +---+--------------------+------------------------------------+ 241 2. Conventions used in this document 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in [RFC2119]. 247 In this document, these words will appear with that interpretation 248 only when in ALL CAPS. Lower case uses of these words are not to be 249 interpreted as carrying [RFC2119] significance. 251 Although these terms are usually associated with protocol 252 requirements, in this document the terms are requirements for users 253 and systems that intend to implement the test conditions and claim 254 conformance with this specification. 256 3. Terminology 258 A number of terms used in this memo have been defined in other RFCs. 259 Please refer to those RFCs for definitions, testing procedures and 260 reporting formats. 262 Throughput (Benchmark) - [RFC2544] 264 Frame Loss Rate (Benchmark) - [RFC2544] 266 Back-to-back Frames (Benchmark) - [RFC2544] 268 System Recovery (Benchmark) - [RFC2544] 270 Reset (Benchmark) - [RFC6201] 272 Concurrent TCP Connection Capacity (Benchmark) - [RFC3511] 274 Maximum TCP Connection Establishment Rate (Benchmark) - [RFC3511] 276 4. Test Setup 278 The test environment setup options recommended for IPv6 transition 279 technologies benchmarking are very similar to the ones presented in 280 Section 6 of [RFC2544]. In the case of the tester setup, the options 281 presented in [RFC2544] and [RFC5180] can be applied here as well. 282 However, the Device under test (DUT) setup options should be 283 explained in the context of the targeted categories of IPv6 284 transition technologies: Single translation, Double translation and 285 Encapsulation transition technologies. 287 Although both single tester and sender/receiver setups are 288 applicable to this methodology, the single tester setup will be used 289 to describe the DUT setup options. 291 For the test setups presented in this memo, dynamic routing SHOULD 292 be employed. However, the presence of routing and management frames 293 can represent unwanted background data that can affect the 294 benchmarking result. To that end, the procedures defined in 295 [RFC2544] (Sections 11.2 and 11.3) related to routing and management 296 frames SHOULD be used here. Moreover, the "Trial description" 297 recommendations presented in [RFC2544] (Section 23) are also valid 298 for this memo. 300 In terms of route setup, the recommendations of [RFC2544] Section 13 301 are valid for this document assuming that IPv6 capable routing 302 protocols are used.. 304 4.1. Single translation Transition Technologies 306 For the evaluation of Single translation transition technologies, a 307 single DUT setup (see Figure 1) SHOULD be used. The DUT is 308 responsible for translating the IPvX packets into IPvY packets. In 309 this context, the tester device SHOULD be configured to support both 310 IPvX and IPvY. 312 +--------------------+ 313 | | 314 +------------|IPvX tester IPvY|<-------------+ 315 | | | | 316 | +--------------------+ | 317 | | 318 | +--------------------+ | 319 | | | | 320 +----------->|IPvX DUT IPvY|--------------+ 321 | | 322 +--------------------+ 323 Figure 1. Test setup 1 325 4.2. Encapsulation/Double translation Transition Technologies 327 For evaluating the performance of Encapsulation and Double 328 translation transition technologies, a dual DUT setup (see Figure 2) 329 SHOULD be employed. The tester creates a network flow of IPvX 330 packets. The first DUT is responsible for the encapsulation or 331 translation of IPvX packets into IPvY packets. The IPvY packets are 332 de-encapsulated/translated back to IPvX packets by the second DUT 333 and forwarded to the tester. 335 +--------------------+ 336 | | 337 +---------------------|IPvX tester IPvX|<------------------+ 338 | | | | 339 | +--------------------+ | 340 | | 341 | +--------------------+ +--------------------+ | 342 | | | | | | 343 +----->|IPvX DUT 1 IPvY |----->|IPvY DUT 2 IPvX |------+ 344 | | | | 345 +--------------------+ +--------------------+ 346 Figure 2. Test setup 2 348 One of the limitations of the dual DUT setup is the inability to 349 reflect asymmetries in behavior between the DUTs. Considering this, 350 additional performance tests SHOULD be performed using the single 351 DUT setup. 353 Note: For encapsulation IPv6 transition technologies, in the single 354 DUT setup, in order to test the de-encapsulation efficiency, the 355 tester SHOULD be able to send IPvX packets encasulated as IPvY. 357 5. Test Traffic 359 The test traffic represents the experimental workload and SHOULD 360 meet the requirements specified in this section. The requirements 361 are dedicated to unicast IP traffic. Multicast IP traffic is outside 362 of the scope of this document. 364 5.1. Frame Formats and Sizes 366 [RFC5180] describes the frame size requirements for two commonly 367 used media types: Ethernet and SONET (Synchronous Optical Network). 368 [RFC2544] covers also other media types, such as token ring and 369 FDDI. The recommendations of the two documents can be used for the 370 dual-stack transition technologies. For the rest of the transition 371 technologies, the frame overhead introduced by translation or 372 encapsulation MUST be considered. 374 The encapsulation/translation process generates different size 375 frames on different segments of the test setup. For instance, the 376 single translation transition technologies will create different 377 frame sizes on the receiving segment of the test setup, as IPvX 378 packets are translated to IPvY. This is not a problem if the 379 bandwidth of the employed media is not exceeded. To prevent 380 exceeding the limitations imposed by the media, the frame size 381 overhead needs to be taken into account when calculating the maximum 382 theoretical frame rates. The calculation method for the Ethernet, as 383 well as a calculation example, are detailed in Appendix A. The 384 details of the media employed for the benchmarking tests MUST be 385 noted in all test reports. 387 In the context of frame size overhead, MTU recommendations are 388 needed in order to avoid frame loss due to MTU mismatch between the 389 virtual encapsulation/translation interfaces and the physical 390 network interface controllers (NICs). To avoid this situation, the 391 larger MTU between the physical NICs and virtual 392 encapsulation/translation interfaces SHOULD be set for all 393 interfaces of the DUT and tester. To be more specific, the minimum 394 IPv6 MTU size (1280 bytes) plus the encapsulation/translation 395 overhead is the RECOMMENDED value for the physical interfaces as 396 well as virtual ones. 398 5.1.1. Frame Sizes to Be Used over Ethernet 400 Based on the recommendations of [RFC5180], the following frame sizes 401 SHOULD be used for benchmarking IPvX/IPvY traffic on Ethernet links: 402 64, 128, 256, 512, 768, 1024, 1280, 1518, 1522, 2048, 4096, 8192 and 403 9216. 405 For Ethernet frames exceeding 1500 bytes in size, the [IEEE802.1AC] 406 standard can be consulted. 408 Note: for single translation transition technologies (e.g. NAT64) in 409 the IPv6 -> IPv4 translation direction, 64 byte frames SHOULD be 410 replaced by 84 byte frames. This would allow the frames to be 411 transported over media such as the ones described by the IEEE 802.1Q 412 standard. Moreover, this would also allow the implementation of a 413 frame identifier in the UDP data. 415 The theoretical maximum frame rates considering an example of frame 416 overhead are presented in Appendix A. 418 5.2. Protocol Addresses 420 The selected protocol addresses should follow the recommendations of 421 [RFC5180](Section 5) for IPv6 and [RFC2544](Section 12) for IPv4. 423 Note: testing traffic with extension headers might not be possible 424 for the transition technologies, which employ translation. Proposed 425 IPvX/IPvY translation algorithms such as IP/ICMP translation 426 [RFC7915] do not support the use of extension headers. 428 5.3. Traffic Setup 430 Following the recommendations of [RFC5180], all tests described 431 SHOULD be performed with bi-directional traffic. Uni-directional 432 traffic tests MAY also be performed for a fine grained performance 433 assessment. 435 Because of the simplicity of UDP, UDP measurements offer a more 436 reliable basis for comparison than other transport layer protocols. 437 Consequently, for the benchmarking tests described in Section 7 of 438 this document UDP traffic SHOULD be employed. 440 Considering that a transition technology could process both native 441 IPv6 traffic and translated/encapsulated traffic, the following 442 traffic setups are recommended: 444 i) IPvX only traffic (where the IPvX traffic is to be 445 translated/encapsulated by the DUT) 446 ii) 90% IPvX traffic and 10% IPvY native traffic 447 iii) 50% IPvX traffic and 50% IPvY native traffic 448 iv) 10% IPvX traffic and 90% IPvY native traffic 450 For the benchmarks dedicated to stateful IPv6 transition 451 technologies, included in Section 8 of this memo (Concurrent TCP 452 Connection Capacity and Maximum TCP Connection Establishment Rate), 453 the traffic SHOULD follow the recommendations of [RFC3511], Sections 454 5.2.2.2 and 5.3.2.2. 456 6. Modifiers 458 The idea of testing under different operational conditions was first 459 introduced in [RFC2544](Section 11) and represents an important 460 aspect of benchmarking network elements, as it emulates, to some 461 extent, the conditions of a production environment. Section 6 of 462 [RFC5180] describes complementary testing conditions specific to 463 IPv6. Their recommendations can also be followed for IPv6 transition 464 technologies testing. 466 7. Benchmarking Tests 468 The following sub-sections contain the list of all recommended 469 benchmarking tests. 471 7.1. Throughput 473 Use Section 26.1 of RFC2544 unmodified. 475 7.2. Latency 477 Objective: To determine the latency. Typical latency is based on the 478 definitions of latency from [RFC1242]. However, this memo provides a 479 new measurement procedure. 481 Procedure: Similar to [RFC2544], the throughput for DUT at each of 482 the listed frame sizes SHOULD be determined. Send a stream of frames 483 at a particular frame size through the DUT at the determined 484 throughput rate to a specific destination. The stream SHOULD be at 485 least 120 seconds in duration. 487 Identifying tags SHOULD be included in at least 500 frames after 60 488 seconds. For each tagged frame, the time at which the frame was 489 fully transmitted (timestamp A) and the time at which the frame was 490 received (timestamp B) MUST be recorded. The latency is timestamp B 491 minus timestamp A as per the relevant definition from RFC 1242, 492 namely latency as defined for store and forward devices or latency 493 as defined for bit forwarding devices. 495 We recommend to encode the identifying tag in the payload of the 496 frame. To be more exact, the identifier SHOULD be inserted after the 497 UDP header. 499 From the resulted (at least 500) latencies, 2 quantities SHOULD be 500 calculated. One is the typical latency, which SHOULD be calculated 501 with the following formula: 503 TL=Median(Li) 505 Where: TL - the reported typical latency of the stream 507 Li -the latency for tagged frame i 509 The other measure is the worst case latency, which SHOULD be 510 calculated with the following formula: 512 WCL=L99.9thPercentile 514 Where: WCL - The reported worst case latency 516 L99.9thPercentile - The 99.9th Percentile of the stream measured 517 latencies 518 The test MUST be repeated at least 20 times with the reported 519 value being the median of the recorded values for TL and WCL. 521 Reporting Format: The report MUST state which definition of latency 522 (from RFC 1242) was used for this test. The summarized latency 523 results SHOULD be reported in the format of a table with a row for 524 each of the tested frame sizes. There SHOULD be columns for the 525 frame size, the rate at which the latency test was run for that 526 frame size, for the media types tested, and for the resultant 527 typical latency and worst case latency values for each type of data 528 stream tested. To account for the variation, the 1st and 99th 529 percentiles of the 20 iterations MAY be reported in two separated 530 columns. For a fine grained analysis, the histogram (as exemplified 531 in [RFC5481] Section 4.4) of one of the iterations MAY be 532 displayed . 534 7.3. Packet Delay Variation 536 Considering two of the metrics presented in [RFC5481], Packet Delay 537 Variation (PDV) and Inter Packet Delay Variation (IPDV), it is 538 RECOMMENDED to measure PDV. For a fine grained analysis of delay 539 variation, IPDV measurements MAY be performed. 541 7.3.1. PDV 543 Objective: To determine the Packet Delay Variation as defined in 544 [RFC5481]. 546 Procedure: As described by [RFC2544], first determine the throughput 547 for the DUT at each of the listed frame sizes. Send a stream of 548 frames at a particular frame size through the DUT at the determined 549 throughput rate to a specific destination. The stream SHOULD be at 550 least 60 seconds in duration. Measure the One-way delay as described 551 by [RFC3393] for all frames in the stream. Calculate the PDV of the 552 stream using the formula: 554 PDV=D99.9thPercentile - Dmin 556 Where: D99.9thPercentile - the 99.9th Percentile (as it was 557 described in [RFC5481]) of the One-way delay for the stream 559 Dmin - the minimum One-way delay in the stream 561 As recommended in [RFC2544], the test MUST be repeated at least 20 562 times with the reported value being the median of the recorded 563 values. Moreover, the 1st and 99th percentiles SHOULD be calculated 564 to account for the variation of the dataset. 566 Reporting Format: The PDV results SHOULD be reported in a table with 567 a row for each of the tested frame sizes and columns for the frame 568 size and the applied frame rate for the tested media types. Two 569 columns for the 1st and 99th percentile values MAY be displayed. 570 Following the recommendations of [RFC5481], the RECOMMENDED units of 571 measurement are milliseconds. 573 7.3.2. IPDV 575 Objective: To determine the Inter Packet Delay Variation as defined 576 in [RFC5481]. 578 Procedure: As described by [RFC2544], first determine the throughput 579 for the DUT at each of the listed frame sizes. Send a stream of 580 frames at a particular frame size through the DUT at the determined 581 throughput rate to a specific destination. The stream SHOULD be at 582 least 60 seconds in duration. Measure the One-way delay as described 583 by [RFC3393] for all frames in the stream. Calculate the IPDV for 584 each of the frames using the formula: 586 IPDV(i)=D(i) - D(i-1) 588 Where: D(i) - the One-way delay of the i th frame in the stream 590 D(i-1) - the One-way delay of i-1 th frame in the stream 592 Given the nature of IPDV, reporting a single number might lead to 593 over-summarization. In this context, the report for each measurement 594 SHOULD include 3 values: Dmin, Dmed, and Dmax 596 Where: Dmin - the minimum IPDV in the stream 598 Dmed - the median IPDV of the stream 600 Dmax - the maximum IPDV in the stream 602 The test MUST be repeated at least 20 times. To summarize the 20 603 repetitions, for each of the 3 (Dmin, Dmed and Dmax) the median 604 value SHOULD be reported. 606 Reporting format: The median for the 3 proposed values SHOULD be 607 reported. The IPDV results SHOULD be reported in a table with a row 608 for each of the tested frame sizes. The columns SHOULD include the 609 frame size and associated frame rate for the tested media types and 610 sub-columns for the three proposed reported values. Following the 611 recommendations of [RFC5481], the RECOMMENDED units of measurement 612 are milliseconds. 614 7.4. Frame Loss Rate 616 Use Section 26.3 of [RFC2544] unmodified. 618 7.5. Back-to-back Frames 620 Use Section 26.4 of [RFC2544] unmodified. 622 7.6. System Recovery 624 Use Section 26.5 of [RFC2544] unmodified. 626 7.7. Reset 628 Use Section 4 of [RFC6201] unmodified. 630 8. Additional Benchmarking Tests for Stateful IPv6 Transition 631 Technologies 633 This section describes additional tests dedicated to the stateful 634 IPv6 transition technologies. For the tests described in this 635 section, the DUT devices SHOULD follow the test setup and test 636 parameters recommendations presented in [RFC3511] (Sections 5.2 and 637 5.3) 639 The following additional tests SHOULD be performed. 641 8.1. Concurrent TCP Connection Capacity 643 Use Section 5.2 of [RFC3511] unmodified. 645 8.2. Maximum TCP Connection Establishment Rate 647 Use Section 5.3 of RFC3511 unmodified. 649 9. DNS Resolution Performance 651 This section describes benchmarking tests dedicated to DNS64 (see 652 [RFC6147]), used as DNS support for single translation technologies 653 such as NAT64. 655 9.1. Test and Traffic Setup 657 The test setup in Figure 3 follows the setup proposed for single 658 translation IPv6 transition technologies in Figure 1. 660 1:AAAA query +--------------------+ 661 +------------| |<-------------+ 662 | |IPv6 Tester IPv4| | 663 | +-------->| |----------+ | 664 | | +--------------------+ 3:empty | | 665 | | 6:synt'd AAAA, | | 666 | | AAAA +--------------------+ 5:valid A| | 667 | +---------| |<---------+ | 668 | |IPv6 DUT IPv4| | 669 +----------->| (DNS64) |--------------+ 670 +--------------------+ 2:AAAA query, 4:A query 671 Figure 3. DNS64 test setup 673 The test traffic SHOULD follow the following steps. 675 1. Query for the AAAA record of a domain name (from client to DNS64 676 server) 678 2. Query for the AAAA record of the same domain name (from DNS64 679 server to authoritative DNS server) 681 3. Empty AAAA record answer (from authoritative DNS server to DNS64 682 server) 684 4. Query for the A record of the same domain name (from DNS64 server 685 to authoritative DNS server) 687 5. Valid A record answer (from authoritative DNS server to DNS64 688 server) 690 6. Synthesized AAAA record answer (from DNS64 server to client) 692 The Tester plays the role of DNS client as well as authoritative DNS 693 server. It MAY be realized as a single physical device, or 694 alternatively, two physical devices MAY be used. 696 Please note that: 698 - If the DNS64 server implements caching and there is a cache 699 hit, then step 1 is followed by step 6 (and steps 2 through 5 700 are omitted). 701 - If the domain name has an AAAA record, then it is returned in 702 step 3 by the authoritative DNS server; steps 4 and 5 are 703 omitted, and the DNS64 server does not synthesizes an AAAA 704 record, but returns the received AAAA record to the client. 706 - As for the IP version used between the tester and the DUT, IPv6 707 MUST be used between the client and the DNS64 server (as a 708 DNS64 server provides service for an IPv6-only client), but 709 either IPv4 or IPv6 MAY be used between the DNS64 server and 710 the authoritative DNS server. 712 9.2. Benchmarking DNS Resolution Performance 714 Objective: To determine DNS64 performance by means of the maximum 715 number of successfully processed DNS requests per second. 717 Procedure: Send a specific number of DNS queries at a specific rate 718 to the DUT and then count the replies received in time (within a 719 predefined timeout period from the sending time of the corresponding 720 query, having the default value 1 second) and valid (contains an 721 AAAA record) from the DUT. If the count of sent queries is equal to 722 the count of received replies, the rate of the queries is raised and 723 the test is rerun. If fewer replies are received than queries were 724 sent, the rate of the queries is reduced and the test is rerun. The 725 duration of each trial SHOULD be at least 60 seconds. This will 726 reduce the potential gain of a DNS64 server, which is able to 727 exhibit higher performance by storing the requests and thus 728 utilizing also the timeout time for answering them. For the same 729 reason, no higher timeout time than 1 second SHOULD be used. For 730 further considerations, see [Lencse1]. 732 The maximum number of processed DNS queries per second is the 733 fastest rate at which the count of DNS replies sent by the DUT is 734 equal to the number of DNS queries sent to it by the test equipment. 736 The test SHOULD be repeated at least 20 times and the median and 1st 737 /99th percentiles of the number of processed DNS queries per second 738 SHOULD be calculated. 740 Details and parameters: 742 1. Caching 743 First, all the DNS queries MUST contain different domain names (or 744 domain names MUST NOT be repeated before the cache of the DUT is 745 exhausted). Then new tests MAY be executed with domain names, 20%, 746 40%, 60%, 80% and 100% of which are cached. We note that ensuring a 747 record being cached requires repeating it both "late enough" after 748 the first query to be already resolved and be present in the cache 749 and "early enough" to be still present in the cache. 751 2. Existence of AAAA record 752 First, all the DNS queries MUST contain domain names which do not 753 have an AAAA record and have exactly one A record. 755 Then new tests MAY be executed with domain names, 20%, 40%, 60%, 80% 756 and 100% of which have an AAAA record. 758 Please note that the two conditions above are orthogonal, thus all 759 their combinations are possible and MAY be tested. The testing with 760 0% cached domain names and with 0% existing AAAA record is REQUIRED 761 and the other combinations are OPTIONAL. (When all the domain names 762 are cached, then the results do not depend on what percentage of the 763 domain names have AAAA records, thus these combinations are not 764 worth testing one by one.) 766 Reporting format: The primary result of the DNS64 test is the median 767 of the number of processed DNS queries per second measured with the 768 above mentioned "0% + 0% combination". The median SHOULD be 769 complemented with the 1st and 99th percentiles to show the stability 770 of the result. If optional tests are done, the median and the 1st 771 and 99th percentiles MAY be presented in a two dimensional table 772 where the dimensions are the proportion of the repeated domain names 773 and the proportion of the DNS names having AAAA records. The two 774 table headings SHOULD contain these percentage values. 775 Alternatively, the results MAY be presented as the corresponding two 776 dimensional graph, too. In this case the graph SHOULD show the 777 median values with the percentiles as error bars. From both the 778 table and the graph, one dimensional excerpts MAY be made at any 779 given fixed percentage value of the other dimension. In this case, 780 the fixed value MUST be given together with a one dimensional table 781 or graph. 783 9.2.1. Requirements for the Tester 785 Before a Tester can be used for testing a DUT at rate r queries per 786 second with t seconds timeout, it MUST perform a self-test in order 787 to exclude the possibility that the poor performance of the Tester 788 itself influences the results. For performing a self-test, the 789 tester is looped back (leaving out DUT) and its authoritative DNS 790 server subsystem is configured to be able to answer all the AAAA 791 record queries. For passing the self-test, the Tester SHOULD be able 792 to answer AAAA record queries at 2*(r+delta) rate within 0.25*t 793 timeout, where the value of delta is at least 0.1. 795 Explanation: When performing DNS64 testing, each AAAA record query 796 may result in at most two queries sent by the DUT, the first one of 797 them is for an AAAA record and the second one is for an A record 798 (the are both sent when there is no cache hit and also no AAAA 799 record exists). The parameters above guarantee that the 800 authoritative DNS server subsystem of the DUT is able to answer the 801 queries at the required frequency using up not more than the half of 802 the timeout time. 804 Remark: a sample open-source test program, dns64perf++, is available 805 from [Dns64perf] and it is documented in [Lencse2]. It implements 806 only the client part of the Tester and it should be used together 807 with an authoritative DNS server implementation, e.g. BIND, NSD or 808 YADIFA. Its experimental extension for testing caching is available 809 from [Lencse3] and it is documented in [Lencse4]. 811 10. Overload Scalability 813 Scalability has been often discussed; however, in the context of 814 network devices, a formal definition or a measurement method has not 815 yet been proposed. In this context, we can define overload 816 scalability as the ability of each transition technology to 817 accommodate network growth. Poor scalability usually leads to poor 818 performance. Considering this, overload scalability can be measured 819 by quantifying the network performance degradation associated with 820 an increased number of network flows. 822 The following subsections describe how the test setups can be 823 modified to create network growth and how the associated performance 824 degradation can be quantified. 826 10.1. Test Setup 828 The test setups defined in Section 3 have to be modified to create 829 network growth. 831 10.1.1. Single Translation Transition Technologies 833 In the case of single translation transition technologies the 834 network growth can be generated by increasing the number of network 835 flows generated by the tester machine (see Figure 4). 837 +-------------------------+ 838 +------------|NF1 NF1|<-------------+ 839 | +---------|NF2 tester NF2|<----------+ | 840 | | ...| | | | 841 | | +-----|NFn NFn|<------+ | | 842 | | | +-------------------------+ | | | 843 | | | | | | 844 | | | +-------------------------+ | | | 845 | | +---->|NFn NFn|-------+ | | 846 | | ...| DUT | | | 847 | +-------->|NF2 (translator) NF2|-----------+ | 848 +----------->|NF1 NF1|--------------+ 849 +-------------------------+ 850 Figure 4. Test setup 3 852 10.1.2. Encapsulation/Double Translation Transition Technologies 854 Similarly, for the encapsulation/double translation technologies a 855 multi-flow setup is recommended. Considering a multipoint-to-point 856 scenario, for most transition technologies, one of the edge nodes is 857 designed to support more than one connecting devices. Hence, the 858 recommended test setup is a n:1 design, where n is the number of 859 client DUTs connected to the same server DUT (See Figure 5). 861 +-------------------------+ 862 +--------------------|NF1 NF1|<--------------+ 863 | +-----------------|NF2 tester NF2|<-----------+ | 864 | | ...| | | | 865 | | +-------------|NFn NFn|<-------+ | | 866 | | | +-------------------------+ | | | 867 | | | | | | 868 | | | +-----------------+ +---------------+ | | | 869 | | +--->| NFn DUT n NFn |--->|NFn NFn| ---+ | | 870 | | +-----------------+ | | | | 871 | | ... | | | | 872 | | +-----------------+ | DUT n+1 | | | 873 | +------->| NF2 DUT 2 NF2 |--->|NF2 NF2|--------+ | 874 | +-----------------+ | | | 875 | +-----------------+ | | | 876 +---------->| NF1 DUT 1 NF1 |--->|NF1 NF1|-----------+ 877 +-----------------+ +---------------+ 878 Figure 5. Test setup 4 880 This test setup can help to quantify the scalability of the server 881 device. However, for testing the overload scalability of the client 882 DUTs additional recommendations are needed. 883 For encapsulation transition technologies, a m:n setup can be 884 created, where m is the number of flows applied to the same client 885 device and n the number of client devices connected to the same 886 server device. 887 For the translation based transition technologies, the client 888 devices can be separately tested with n network flows using the test 889 setup presented in Figure 4. 891 10.2. Benchmarking Performance Degradation 893 10.2.1. Network performance degradation with simultaneous load 895 Objective: To quantify the performance degradation introduced by n 896 parallel and simultaneous network flows. 898 Procedure: First, the benchmarking tests presented in Section 7 have 899 to be performed for one network flow. 901 The same tests have to be repeated for n network flows, where the 902 network flows are started simultaneously. The performance 903 degradation of the X benchmarking dimension SHOULD be calculated as 904 relative performance change between the 1-flow (single flow) results 905 and the n-flow results, using the following formula: 907 Xn - X1 908 Xpd= ----------- * 100, where: X1 - result for 1-flow 909 X1 Xn - result for n-flows 911 This formula SHOULD be applied only for lower is better benchmarks 912 (e.g. latency). 913 For higher is better benchmarks (e.g. throughput), the following 914 formula is RECOMMENDED. 916 X1 - Xn 917 Xpd= ----------- * 100, where: X1 - result for 1-flow 918 X1 Xn - result for n-flows 920 As a guideline for the maximum number of flows n, the value can be 921 deduced by measuring the Concurrent TCP Connection Capacity as 922 described by [RFC3511], following the test setups specified by 923 Section 4. 925 Reporting Format: The performance degradation SHOULD be expressed as 926 a percentage. The number of tested parallel flows n MUST be clearly 927 specified. For each of the performed benchmarking tests, there 928 SHOULD be a table containing a column for each frame size. The table 929 SHOULD also state the applied frame rate. In the case of benchmarks 930 for which more than one value is reported (e.g. IPDV Section 7.3.2), 931 a column for each of the values SHOULD be included. 933 10.2.2. Network performance degradation with incremental load 935 Objective: To quantify the performance degradation introduced by n 936 parallel and incrementally started network flows. 938 Procedure: First, the benchmarking tests presented in Section 7 have 939 to be performed for one network flow. 941 The same tests have to be repeated for n network flows, where the 942 network flows are started incrementally in succession, each after 943 time t. In other words, if flow i is started at time x, flow i+1 944 will be started at time x+t. Considering the time t, the time 945 duration of each iteration must be extended with the time necessary 946 to start all the flows, namely (n-1)xt. The measurement for the 947 first flow SHOULD be at least 60 seconds in duration. 949 The performance degradation of the x benchmarking dimension SHOULD 950 be calculated as relative performance change between the 1-flow 951 results and the n-flow results, using the formula presented in 952 Section 10.2.1. Intermediary degradation points for 1/4*n, 1/2*n and 953 3/4*n MAY also be performed. 955 Reporting Format: The performance degradation SHOULD be expressed as 956 a percentage. The number of tested parallel flows n MUST be clearly 957 specified. For each of the performed benchmarking tests, there 958 SHOULD be a table containing a column for each frame size. The table 959 SHOULD also state the applied frame rate and time duration T, used 960 as increment step between the network flows. The units of 961 measurement for T SHOULD be seconds. A column for the intermediary 962 degradation points MAY also be displayed. In the case of benchmarks 963 for which more than one value is reported (e.g. IPDV Section 7.3.2), 964 a column for each of the values SHOULD be included. 966 11. NAT44 and NAT66 968 Although these technologies are not the primary scope of this 969 document, the benchmarking methodology associated with single 970 translation technologies as defined in Section 4.1 can be employed 971 to benchmark NAT44 (as defined by [RFC2663] with the behavior 972 described by [RFC7857]) implementations and NAT66 (as defined by 973 [RFC6296]) implementations. 975 12. Summarizing function and variation 977 To ensure the stability of the benchmarking scores obtained using 978 the tests presented in Sections 7 through 9, multiple test 979 iterations are RECOMMENDED. Using a summarizing function (or measure 980 of central tendency) can be a simple and effective way to compare 981 the results obtained across different iterations. However, over- 982 summarization is an unwanted effect of reporting a single number. 984 Measuring the variation (dispersion index) can be used to counter 985 the over-summarization effect. Empirical data obtained following the 986 proposed methodology can also offer insights on which summarizing 987 function would fit better. 989 To that end, data presented in [ietf95pres] indicate the median as 990 suitable summarizing function and the 1st and 99th percentiles as 991 variation measures for DNS Resolution Performance and PDV. The 992 median and percentile calculation functions SHOULD follow the 993 recommendations of [RFC2330] Section 11.3. 995 For a fine grained analysis of the frequency distribution of the 996 data, histograms or cumulative distribution function plots can be 997 employed. 999 13. Security Considerations 1001 Benchmarking activities as described in this memo are limited to 1002 technology characterization using controlled stimuli in a laboratory 1003 environment, with dedicated address space and the constraints 1004 specified in the sections above. 1006 The benchmarking network topology will be an independent test setup 1007 and MUST NOT be connected to devices that may forward the test 1008 traffic into a production network, or misroute traffic to the test 1009 management network. 1011 Further, benchmarking is performed on a "black-box" basis, relying 1012 solely on measurements observable external to the DUT/SUT. Special 1013 capabilities SHOULD NOT exist in the DUT/SUT specifically for 1014 benchmarking purposes. Any implications for network security arising 1015 from the DUT/SUT SHOULD be identical in the lab and in production 1016 networks. 1018 14. IANA Considerations 1020 The IANA has allocated the prefix 2001:2::/48 [RFC5180] for IPv6 1021 benchmarking. For IPv4 benchmarking, the 198.18.0.0/15 prefix was 1022 reserved, as described in [RFC6890]. The two ranges are sufficient 1023 for benchmarking IPv6 transition technologies. Thus, no action is 1024 requested. 1026 15. References 1028 15.1. Normative References 1030 [RFC1242] Bradner, S., "Benchmarking Terminology for Network 1031 Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, 1032 July 1991, . 1034 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1035 Requirement Levels", BCP 14, RFC 2119, DOI 1036 10.17487/RFC2119, March 1997, . 1039 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1040 "Framework for IP performance metrics", RFC 2330, DOI 1041 10.17487/RFC2330, May 1998, . 1044 [RFC2544] Bradner, S., and J. McQuaid, "Benchmarking Methodology for 1045 Network Interconnect Devices", RFC 2544, DOI 1046 10.17487/RFC2544, March 1999, . 1049 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1050 Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 1051 10.17487/RFC3393, November 2002, . 1054 [RFC3511] Hickman, B., Newman, D., Tadjudin, S. and T. Martin, 1055 "Benchmarking Methodology for Firewall Performance", RFC 1056 3511, DOI 10.17487/RFC3511, April 2003, . 1059 [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. 1060 Dugatkin, "IPv6 Benchmarking Methodology for Network 1061 Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May 1062 2008, . 1064 [RFC5481] Morton, A., and B. Claise, "Packet Delay Variation 1065 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 1066 March 2009, . 1068 [RFC6201] Asati, R., Pignataro, C., Calabria, F. and C. Olvera, 1069 "Device Reset Characterization ", RFC 6201, DOI 1070 10.17487/RFC6201, March 2011, . 1073 15.2. Informative References 1075 [RFC2663] Srisuresh, P., and M. Holdrege. "IP Network Address 1076 Translator (NAT) Terminology and Considerations", RFC2663, 1077 DOI 10.17487/RFC2663, August 1999, . 1080 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1081 for IPv6 Hosts and Routers", RFC 4213, DOI 1082 10.17487/RFC4213, October 2005, . 1085 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1086 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1087 IPv6 VPN", RFC 4659, September 2006, . 1090 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 1091 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 1092 Provider Edge Routers (6PE)", RFC 4798, February 2007, 1093 1095 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1096 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 1097 January 2010, . 1099 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1100 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 1101 April 2011, . 1103 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1104 NAT64: Network Address and Protocol Translation from IPv6 1105 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1106 April 2011, . 1108 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1109 Beijnum, "DNS64: DNS Extensions for Network Address 1110 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1111 DOI 10.17487/RFC6147, April 2011, . 1114 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 1115 China Education and Research Network (CERNET) IVI 1116 Translation Design and Deployment for the IPv4/IPv6 1117 Coexistence and Transition", RFC 6219, DOI 1118 10.17487/RFC6219, May 2011, . 1121 [RFC6296] Wasserman, M., and F. Baker. "IPv6-to-IPv6 network prefix 1122 translation." RFC6296, DOI 10.17487/RFC6296, June 2011. 1124 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1125 Stack Lite Broadband Deployments Following IPv4 1126 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 1127 . 1129 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1130 Combination of Stateful and Stateless Translation", RFC 1131 6877, DOI 10.17487/RFC6877, April 2013, . 1134 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 1135 "Special-Purpose IP Address Registries", BCP 153, RFC6890, 1136 DOI 10.17487/RFC6890, April 2013, . 1139 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1140 Farrer, "Lightweight 4over6: An Extension to the Dual- 1141 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 1142 July 2015, . 1144 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 1145 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 1146 Port with Encapsulation (MAP-E)", RFC 7597, DOI 1147 10.17487/RFC7597, July 2015, . 1150 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 1151 and T. Murakami, "Mapping of Address and Port using 1152 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 1153 2015, . 1155 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Sivakumar, S., 1156 and K. Naito "Updates to Network Address Translation (NAT) 1157 Behavioral Requirements" RFC 7857, DOI 10.17487/RFC7857, 1158 April 2016, . 1160 [RFC7915] LBao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 1161 "IP/ICMP Translation Algorithm", RFC 7915, DOI 1162 10.17487/RFC7915, June 2016, . 1165 [Dns64perf] Bakai, D., "A C++11 DNS64 performance tester", 1166 available: https://github.com/bakaid/dns64perfpp 1168 [ietf95pres] Georgescu, M., "Benchmarking Methodology for IPv6 1169 Transition Technologies", IETF 95, Buenos Aires, 1170 Argentina, April 2016, available: 1171 https://www.ietf.org/proceedings/95/slides/slides-95-bmwg- 1172 2.pdf 1174 [Lencse1] Lencse, G., Georgescu, M. and Y. Kadobayashi, 1175 "Benchmarking Methodology for DNS64 Servers", unpublished, 1176 revised version is available: 1177 http://www.hit.bme.hu/~lencse/publications/ECC-2017-B-M- 1178 DNS64-revised.pdf 1180 [Lencse2] Lencse, G., Bakai, D, "Design and Implementation of a Test 1181 Program for Benchmarking DNS64 Servers", IEICE 1182 Transactions on Communications, vol. E100-B, no. 6. pp. 1183 948-954, (June 2017), freely available from: 1184 http://doi.org/10.1587/transcom.2016EBN0007 1186 [Lencse3] http://www.hit.bme.hu/~lencse/dns64perfppc/ 1188 [Lencse4] Lencse, G., "Enabling Dns64perf++ for Benchmarking the 1189 Caching Performance of DNS64 Servers", unpublished, review 1190 version is available: 1191 http://www.hit.bme.hu/~lencse/publications/IEICE-2016- 1192 dns64perfppc-for-review.pdf 1194 [IEEE802.1AC-2016] IEEE Standard, "802.1AC-2016 - IEEE Standard for 1195 Local and metropolitan area networks -- Media Access 1196 Control (MAC) Service Definition", 2016, available: 1197 https://standards.ieee.org/findstds/standard/802.1AC- 1198 2016.html 1200 16. Acknowledgements 1202 The authors would like to thank Youki Kadobayashi and Hiroaki 1203 Hazeyama for their constant feedback and support. The thanks should 1204 be extended to the NECOMA project members for their continuous 1205 support. The thank you list should also include Emanuel Popa, Ionut 1206 Spirlea and the RCS&RDS IP/MPLS Backbone Team for their support and 1207 insights. We would also like to thank Scott Bradner for the useful 1208 suggestions. We also note that portions of text from Scott's 1209 documents were used in this memo (e.g. Latency section). A big thank 1210 you to Al Morton and Fred Baker for their detailed review of the 1211 draft and very helpful suggestions. Other helpful comments and 1212 suggestions were offered by Bhuvaneswaran Vengainathan, Andrew 1213 McGregor, Nalini Elkins, Kaname Nishizuka, Yasuhiro Ohara, Masataka 1214 Mawatari, Kostas Pentikousis, Bela Almasi, Tim Chown, Paul Emmerich 1215 and Stenio Fernandes. A special thank you to the RFC Editor Team for 1216 their thorough editorial review and helpful suggestions. This 1217 document was prepared using 2-Word-v2.0.template.dot. 1219 Appendix A. Theoretical Maximum Frame Rates 1221 This appendix describes the recommended calculation formulas for the 1222 theoretical maximum frame rates to be employed over Ethernet as 1223 example media. The formula takes into account the frame size 1224 overhead created by the encapsulation or the translation process. 1225 For example, the 6in4 encapsulation described in [RFC4213] adds 20 1226 bytes of overhead to each frame. 1228 Considering X to be the frame size and O to be the frame size 1229 overhead created by the encapsulation on translation process, the 1230 maximum theoretical frame rate for Ethernet can be calculated using 1231 the following formula: 1233 Line Rate (bps) 1234 ------------------------------ 1235 (8bits/byte)*(X+O+20)bytes/frame 1237 The calculation is based on the formula recommended by RFC5180 in 1238 Appendix A1. As an example, the frame rate recommended for testing a 1239 6in4 implementation over 10Mb/s Ethernet with 64 bytes frames is: 1241 10,000,000(bps) 1242 ------------------------------ = 12,019 fps 1243 (8bits/byte)*(64+20+20)bytes/frame 1245 The complete list of recommended frame rates for 6in4 encapsulation 1246 can be found in the following table: 1248 +------------+---------+----------+-----------+------------+ 1249 | Frame size | 10 Mb/s | 100 Mb/s | 1000 Mb/s | 10000 Mb/s | 1250 | (bytes) | (fps) | (fps) | (fps) | (fps) | 1251 +------------+---------+----------+-----------+------------+ 1252 | 64 | 12,019 | 120,192 | 1,201,923 | 12,019,231 | 1253 | 128 | 7,440 | 74,405 | 744,048 | 7,440,476 | 1254 | 256 | 4,223 | 42,230 | 422,297 | 4,222,973 | 1255 | 512 | 2,264 | 22,645 | 226,449 | 2,264,493 | 1256 | 678 | 1,740 | 17,409 | 174,094 | 1,740,947 | 1257 | 1024 | 1,175 | 11,748 | 117,481 | 1,174,812 | 1258 | 1280 | 947 | 9,470 | 94,697 | 946,970 | 1259 | 1518 | 802 | 8,023 | 80,231 | 802,311 | 1260 | 1522 | 800 | 8,003 | 80,026 | 800,256 | 1261 | 2048 | 599 | 5,987 | 59,866 | 598,659 | 1262 | 4096 | 302 | 3,022 | 30,222 | 302,224 | 1263 | 8192 | 152 | 1,518 | 15,185 | 151,846 | 1264 | 9216 | 135 | 1,350 | 13,505 | 135,048 | 1265 +------------+---------+----------+-----------+------------+ 1267 Authors' Addresses 1268 Marius Georgescu 1269 RCS&RDS 1270 Strada Dr. Nicolae D. Staicovici 71-75 1271 Bucharest 030167 1272 Romania 1274 Phone: +40 31 005 0979 1275 Email: marius.georgescu@rcs-rds.ro 1277 Liviu Pislaru 1278 RCS&RDS 1279 Strada Dr. Nicolae D. Staicovici 71-75 1280 Bucharest 030167 1281 Romania 1283 Phone: +40 31 005 0979 1284 Email: liviu.pislaru@rcs-rds.ro 1286 Gabor Lencse 1287 Szechenyi Istvan University 1288 Egyetem ter 1. 1289 Gyor 1290 Hungary 1292 Phone: +36 20 775 8267 1293 Email: lencse@sze.hu