RFC 8219
Benchmarking Methodology for IPv6 Transition Technologies
RFC 8219: Benchmarking Methodology for IPv6 Transition Technologies 🦋
okay bestie, RFC 8219 is giving benchmarking methodology realness ✨ It's titled "Benchmarking Methodology for IPv6 Transition Technologies," and it came out in August 2017.
It was written by M. Georgescu and L. Pislaru (both from RCS&RDS) and G. Lencse (from Szechenyi Istvan University). It's Informational, which means it isn't on the Internet Standards Track. It's here to share knowledge, not to lay down the law 🧚 Its ISSN is 2070-1721. The title block doesn't list any RFC that it obsoletes or updates, so there's no extra drama there 💅
Abstract
okay so the abstract is the quick tour 💖 People already have benchmarking methods for network interconnect devices that can handle IPv4 or IPv6, but IPv6 transition technologies are not covered by them. This document fills that gap with extra guidelines for measuring how well IPv6 transition technologies perform 🌸
It focuses on the transition technologies that use encapsulation or translation mechanisms. Dual-stack nodes can already be tested with the recommendations in RFCs 2544 and 5180, so they're not the main event here. The methodology also includes a metric for benchmarking load scalability ✨
Status of This Memo
Real talk: this document is not an Internet Standards Track specification. It's published purely for informational purposes 🎀
It is a product of the Internet Engineering Task Force (IETF), and it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is eligible for any level of Internet Standard, so check out Section 2 of RFC 7841 if you want the details 🙈
For the latest status, errata, and feedback info, head to http://www.rfc-editor.org/info/rfc8219 🔗
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved 🌈
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read them carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💜
Table of Contents
1. Introduction ....................................................4
1.1. IPv6 Transition Technologies ...............................4
2. Conventions Used in This Document ...............................6
3. Terminology .....................................................7
4. Test Setup ......................................................7
4.1. Single-Translation Transition Technologies .................8
4.2. Encapsulation and Double-Translation Transition
Technologies ...............................................8
5. Test Traffic ....................................................9
5.1. Frame Formats and Sizes ....................................9
5.1.1. Frame Sizes to Be Used over Ethernet ...............10
5.2. Protocol Addresses ........................................10
5.3. Traffic Setup .............................................10
6. Modifiers ......................................................11
7. Benchmarking Tests .............................................11
7.1. Throughput ................................................11
7.2. Latency ...................................................11
7.3. Packet Delay Variation ....................................13
7.3.1. PDV ................................................13
7.3.2. IPDV ...............................................14
7.4. Frame Loss Rate ...........................................15
7.5. Back-to-Back Frames .......................................15
7.6. System Recovery ...........................................15
7.7. Reset .....................................................15
8. Additional Benchmarking Tests for Stateful IPv6 Transition
Technologies ...................................................15
8.1. Concurrent TCP Connection Capacity ........................15
8.2. Maximum TCP Connection Establishment Rate .................15
9. DNS Resolution Performance .....................................15
9.1. Test and Traffic Setup ....................................16
9.2. Benchmarking DNS Resolution Performance ...................17
9.2.1. Requirements for the Tester ........................18
10. Overload Scalability ..........................................19
10.1. Test Setup ...............................................19
10.1.1. Single-Translation Transition Technologies ........19
10.1.2. Encapsulation and Double-Translation
Transition Technologies ...........................20
10.2. Benchmarking Performance Degradation .....................21
10.2.1. Network Performance Degradation with
Simultaneous Load .................................21
10.2.2. Network Performance Degradation with
Incremental Load ..................................22
11. NAT44 and NAT66 ...............................................22
12. Summarizing Function and Variation ............................23
13. Security Considerations .......................................23
14. IANA Considerations ...........................................24
15. References ....................................................24
15.1. Normative References .....................................24
15.2. Informative References ...................................25
Appendix A. Theoretical Maximum Frame Rates........................29
Acknowledgements...................................................30
Authors' Addresses ................................................301. Introduction ✨
The methodologies in [RFC2544] and [RFC5180] help vendors and network operators analyze how IPv4 and IPv6-capable network devices perform 💅 The one in [RFC2544] is mostly independent of IP version, while [RFC5180] adds extra recommendations that are specific to the latest IP version, IPv6. The catch is that [RFC5180] doesn't cover IPv6 transition technologies 🫶
IPv6 isn't backwards compatible, so IPv4-only nodes can't talk directly to IPv6-only nodes. That's the whole reason IPv6 transition technologies have been proposed and implemented 😭
This document brings benchmarking guidelines made for IPv6 transition technologies. The tests can reveal how these technologies perform, which is super useful feedback for developers and network operators who are going through the IPv6 transition process 🍓
The document also covers a way to measure performance under overload. Overload scalability is a system's ability to gracefully handle more flows than the Device Under Test (DUT) can normally operate with. The approach here is to quantify it by measuring the performance produced by an excessive number of network flows, then comparing that to the non-overloaded case 🔥
1.1. IPv6 Transition Technologies 🦋
Okay so, two of the basic transition technologies are dual IP layer (aka dual stack) and encapsulation, and both are explained in [RFC4213] ✨. IPv4/IPv6 translation gets its own spotlight in [RFC6144] 💅. Most transition technologies are basically a remix of at least one of these, so a generic classification is lowkey super useful 🧚.
Picture a production network moving to IPv6 as being built from these IP domains:
- Domain A: IPvX-specific domain
- Core domain: IPvY-specific or dual-stack (IPvX and IPvY) domain
- Domain B: IPvX-specific domain
Note: X,Y are part of the set {4,6}, and X is NOT EQUAL to Y.
Next, the transition techs get sorted by how they handle traversal of the core domain 👑:
- Dual stack: Devices in the core domain implement both IP protocols.
- Single translation: Here the production network only has two domains: Domain A and the core domain. The core domain is IPvY specific. IPvX packets get translated to IPvY at the edge between Domain A and the core domain 🔥.
- Double translation: The production network has all three domains. Domains A and B are IPvX specific, and the core domain is IPvY specific. A translation mechanism handles the trip across the core network. IPvX packets get translated to IPvY packets at the edge between Domain A and the core domain, and then the IPvY packets get translated back to IPvX at the edge between the core domain and Domain B 🌈.
- Encapsulation: Same three-domain setup. Domains A and B are IPvX specific, and the core domain is IPvY specific. An encapsulation mechanism is used to cross the core domain. IPvX packets are encapsulated into IPvY packets at the edge between Domain A and the core domain, and then the IPvY packets are de-encapsulated at the edge between the core domain and Domain B 🎀.
Dual-stack transition techs can be fully evaluated with the benchmarking methodologies from [RFC2544] and [RFC5180], so this document focuses on the other three categories: single-translation, double-translation, and encapsulation transition technologies 🍓.
Another big way to sort IPv6 transition techs is whether they use stateful or stateless mapping algorithms 🧠. The stateful ones (like Stateful NAT64 [RFC6146]) create dynamic correlations between IP addresses or {IP address, transport protocol, transport port number} tuples, and those get stored in a state table. For ease of reference, this document calls transition techs that use stateful mapping algorithms "stateful IPv6 transition technologies" 💖. How efficiently the state table is managed can be a really important performance indicator for these techs, so additional benchmarking tests are RECOMMENDED for stateful IPv6 transition technologies 😭.
Table 1 has the generic categories and some of the IPv6 transition technologies proposed in the IETF. The list is not exhaustive, so don't panic if your fave isn't on it 🙈.
+---+--------------------+------------------------------------+
| | Generic category | IPv6 Transition Technology |
+---+--------------------+------------------------------------+
| 1 | Dual stack | Dual IP Layer Operations [RFC4213] |
+---+--------------------+------------------------------------+
| 2 | Single translation | NAT64 [RFC6146], IVI [RFC6219] |
+---+--------------------+------------------------------------+
| 3 | Double translation | 464XLAT [RFC6877], MAP-T [RFC7599] |
+---+--------------------+------------------------------------+
| 4 | Encapsulation | DS-Lite [RFC6333], MAP-E [RFC7597],|
| | | Lightweight 4over6 [RFC7596], |
| | | 6rd [RFC5569], 6PE [RFC4798], |
| | | 6VPE [RFC4659] |
+---+--------------------+------------------------------------+
Table 1: IPv6 Transition Technologies Categories2. Conventions Used in This Document 📜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💅.
Even though these terms are usually about protocol requirements, here they're requirements for users and systems that want to implement the test conditions and claim conformance with this specification 🫶.
3. Terminology 🌸
A bunch of terms used in this memo are already defined in other RFCs. Check those RFCs for the definitions, testing procedures, and reporting formats 🧚.
- Throughput (Benchmark) [RFC2544]
- Frame Loss Rate (Benchmark) [RFC2544]
- Back-to-Back Frames (Benchmark) [RFC2544]
- System Recovery (Benchmark) [RFC2544]
- Reset (Benchmark) [RFC6201]
- Concurrent TCP Connection Capacity (Benchmark) [RFC3511]
- Maximum TCP Connection Establishment Rate (Benchmark) [RFC3511]
4. Test Setup 🛠️
The test environment setup options recommended for benchmarking IPv6 transition technologies are very similar to the ones in Section 6 of [RFC2544] ✨. For the Tester setup, the options in [RFC2544] and [RFC5180] can be applied here too. The DUT setup options, though, need to be explained in the context of the targeted categories of IPv6 transition technologies: single translation, double translation, and encapsulation 💖.
Single Tester and sender/receiver setups both work for this methodology, but this memo uses the single Tester setup to describe the DUT setup options 🎀.
For the test setups in this memo, dynamic routing SHOULD be employed 🦋. The catch is that routing and management frames can show up as unwanted background data and mess with the benchmarking result 😬. So the procedures in Sections 11.2 and 11.3 of [RFC2544] about routing and management frames SHOULD be used here. The "trial description" recommendations in Section 23 of [RFC2544] are also valid for this memo 📜.
For route setup, the recommendations in Section 13 of [RFC2544] are valid for this document, assuming IPv6-capable routing protocols are used 🌈.
4.1. Single-Translation Transition Technologies 🔥
To evaluate single-translation transition technologies, a single DUT setup (see Figure 1) SHOULD be used. The DUT is responsible for translating IPvX packets into IPvY packets. The Tester device SHOULD be configured to support both IPvX and IPvY 💅.
+--------------------+
| |
+------------|IPvX Tester IPvY|<-------------+
| | | |
| +--------------------+ |
| |
| +--------------------+ |
| | | |
+----------->|IPvX DUT IPvY|--------------+
| |
+--------------------+
Figure 1: Test Setup 1 (Single DUT)4.2. Encapsulation and Double-Translation Transition Technologies 🦋
To evaluate the performance of encapsulation and double-translation transition technologies, a dual DUT setup (see Figure 2) SHOULD be employed 💜. The Tester creates a network flow of IPvX packets. The first DUT is responsible for encapsulating or translating IPvX packets into IPvY packets. The second DUT then de-encapsulates or translates the IPvY packets back to IPvX packets and forwards them to the Tester 🧚.
+--------------------+
| |
+---------------------|IPvX Tester IPvX|<------------------+
| | | |
| +--------------------+ |
| |
| +--------------------+ +--------------------+ |
| | | | | |
+----->|IPvX DUT 1 IPvY |----->|IPvY DUT 2 IPvX |------+
| | | |
+--------------------+ +--------------------+
Figure 2: Test Setup 2 (Dual DUT)One limitation of the dual DUT setup is that it can't reflect asymmetries in behavior between the DUTs 🙈. Because of that, additional performance tests SHOULD be performed using the single DUT setup 🔥.
Note: For encapsulation IPv6 transition technologies in the single DUT setup, the Tester SHOULD be able to send IPvX packets encapsulated as IPvY in order to test the de-encapsulation efficiency 🎀.
5. Test Traffic 💖
The test traffic is the experimental workload, and it SHOULD meet the requirements in this section 🌸. These requirements are for unicast IP traffic only. Multicast IP traffic is outside the scope of this document 🚫.
5.1. Frame Formats and Sizes 📏
[RFC5180] describes the frame size requirements for two commonly used media types: Ethernet and SONET (Synchronous Optical Network) ✨. [RFC2544] also covers other media types, like token ring and Fiber Distributed Data Interface (FDDI). The recommendations in those two documents can be used for the dual-stack transition technologies. For the rest of the transition technologies, the frame overhead introduced by translation or encapsulation MUST be considered 😤.
The encapsulation/translation process makes different size frames on different segments of the test setup 🧩. For example, single-translation transition technologies create different frame sizes on the receiving segment, because IPvX packets get translated to IPvY. That's not a problem as long as the bandwidth of the employed media isn't exceeded. To keep from exceeding the media's limits, the frame size overhead needs to be taken into account when calculating the maximum theoretical frame rates. The calculation method for Ethernet, plus a calculation example, are detailed in Appendix A 💅. The details of the media employed for the benchmarking tests MUST be noted in all test reports 📝.
Speaking of frame overhead, MTU recommendations are needed to avoid frame loss from an MTU mismatch between the virtual encapsulation/translation interfaces and the physical network interface controllers (NICs) 😭. To avoid that situation, the larger MTU between the physical NICs and the virtual encapsulation/translation interfaces SHOULD be set for all interfaces of the DUT and Tester 🫶.
To be more specific, the minimum IPv6 MTU size (1280 bytes) plus the encapsulation/translation overhead is the RECOMMENDED value for the physical interfaces as well as the virtual ones 🌈.
5.1.1. Frame Sizes to Be Used over Ethernet ✨
Okay so, bestie, this is where we pick our frame sizes for poking at IPvX/IPvY traffic on Ethernet 🎀. Based on the recommendations of [RFC5180], the following frame sizes SHOULD be used for benchmarking IPvX/IPvY traffic on Ethernet links: 64, 128, 256, 512, 768, 1024, 1280, 1518, 1522, 2048, 4096, 8192, and 9216. Literally a whole menu of sizes 💅🌸
For Ethernet frames bigger than 1500 bytes, you can go check out the [IEEE802.1AC] standard. It's giving "read the manual" energy 📖🦋
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 lets the frames get carried over media like the ones described in the [IEEE802.1Q] standard 🧚. Moreover, this also allows the implementation of a frame identifier in the UDP data 🫶. So cute, right? 😭
The theoretical maximum frame rates, using an example of frame overhead, are shown in Appendix A 💜.
5.2. Protocol Addresses
Okay, next up is picking protocol addresses 🍓. The selected protocol addresses SHOULD follow the recommendations of Section 5 of [RFC5180] for IPv6 and Section 12 of [RFC2544] for IPv4. Main character energy for addressing, iykyk 👑.
Note: Testing traffic with extension headers might not be possible for the transition technologies that employ translation. Like, lowkey a plot twist 🙈. Proposed IPvX/IPvY translation algorithms such as IP/ICMP translation [RFC7915] do not support the use of extension headers 💀.
5.3. Traffic Setup
So for traffic setup, following the recommendations of [RFC5180], all tests described SHOULD be performed with bidirectional traffic 🔥. Unidirectional traffic tests MAY also be performed for a fine-grained performance assessment, which is giving "zoom in" vibes 🔍✨.
Because UDP is so simple, UDP measurements offer a more reliable basis for comparison than other transport-layer protocols 💖. Consequently, for the benchmarking tests described in Section 7 of this document, UDP traffic SHOULD be employed. Bestie, UDP is the GOAT here 🦋.
Considering that a transition technology could process both native IPv6 traffic and translated/encapsulated traffic, the following traffic setups are recommended 🌈:
i) IPvX only traffic (where the IPvX traffic is to be
translated/encapsulated by the DUT)
ii) 90% IPvX traffic and 10% IPvY native traffic
iii) 50% IPvX traffic and 50% IPvY native traffic
iv) 10% IPvX traffic and 90% IPvY native trafficFor the benchmarks dedicated to stateful IPv6 transition technologies, included in Section 8 of this memo (Concurrent TCP Connection Capacity and Maximum TCP Connection Establishment Rate), the traffic SHOULD follow the recommendations of Sections 5.2.2.2 and 5.3.2.2 of [RFC3511] 🎀.
- Modifiers ⭐
The idea of testing under different operational conditions was first introduced in Section 11 of [RFC2544], and it's honestly iconic because it kind of copies what a real production environment feels like 🌸. Section 6 of [RFC5180] describes complementary test conditions specific to IPv6 💜. The recommendations in [RFC2544] and [RFC5180] can also be followed for testing of IPv6 transition technologies 🫶.
- Benchmarking Tests 🔥
Okay, here are all the recommended benchmarking tests. The following sub-sections describe every single one 💅.
7.1. Throughput
Use Section 26.1 of [RFC2544] unmodified. No edits, no drama 🎀.
7.2. Latency ⏱️
Objective: To determine the latency. Typical latency is based on the definitions of latency from [RFC1242]. However, this memo provides a new measurement procedure 🦋.
Procedure: Similar to [RFC2544], the throughput for DUT at each of the listed frame sizes SHOULD be determined. Send a stream of frames at a particular frame size through the DUT at the determined throughput rate to a specific destination. The stream SHOULD be at least 120 seconds in duration 😭.
Identifying tags SHOULD be included in at least 500 frames after 60 seconds. For each tagged frame, 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 minus timestamp A as per the relevant definition from RFC 1242, namely, latency as defined for store and forward devices or latency as defined for bit forwarding devices ✨.
We recommend encoding the identifying tag in the payload of the frame. To be more exact, the identifier SHOULD be inserted after the UDP header 🧚.
From the resulting (at least 500) latencies, two quantities SHOULD be calculated. One is the typical latency, which SHOULD be calculated with the following formula:
TL = Median(Li)Where:
- TL = the reported typical latency of the stream
- Li = the latency for tagged frame i
The other measure is the worst-case latency, which SHOULD be calculated with the following formula:
WCL = L99.9thPercentileWhere:
- WCL = the reported worst-case latency
- L99.9thPercentile = the 99.9th percentile of the stream-measured latencies
The test MUST be repeated at least 20 times with the reported value being the median of the recorded values for TL and WCL. Twenty rounds, no skipping 🔁💖.
Reporting Format: The report MUST state which definition of latency (from RFC 1242) was used for this test. The summarized latency results SHOULD be reported in the format of a table with a row for each of the tested frame sizes. There SHOULD be columns for the frame size, the rate at which the latency test was run for that frame size, the media types tested, and the resultant typical latency, and the worst-case latency values for each type of data stream tested. To account for the variation, the 1st and 99th percentiles of the 20 iterations MAY be reported in two separated columns. For a fine-grained analysis, the histogram (as exemplified in Section 4.4 of [RFC5481]) of one of the iterations MAY be displayed 📊🌈.
7.3. Packet Delay Variation 🦋
[RFC5481] presents two metrics: Packet Delay Variation (PDV) and Inter Packet Delay Variation (IPDV). Measuring PDV is RECOMMENDED; for a fine-grained analysis of delay variation, IPDV measurements MAY be performed 💜.
7.3.1. PDV
Objective: To determine the Packet Delay Variation as defined in [RFC5481] 🎀.
Procedure: As described by [RFC2544], first determine the throughput for the DUT at each of the listed frame sizes. Send a stream of frames at a particular frame size through the DUT at the determined throughput rate to a specific destination. The stream SHOULD be at least 60 seconds in duration. Measure the one-way delay as described by [RFC3393] for all frames in the stream. Calculate the PDV of the stream using the formula:
PDV = D99.9thPercentile - DminWhere:
- D99.9thPercentile = the 99.9th percentile (as described in [RFC5481]) of the one-way delay for the stream
- Dmin = the minimum one-way delay in the stream
As recommended in [RFC2544], the test MUST be repeated at least 20 times with the reported value being the median of the recorded values. Moreover, the 1st and 99th percentiles SHOULD be calculated to account for the variation of the dataset 🙈.
Reporting Format: The PDV results SHOULD be reported in a table with a row for each of the tested frame sizes and columns for the frame size and the applied frame rate for the tested media types. Two columns for the 1st and 99th percentile values MAY be displayed. Following the recommendations of [RFC5481], the RECOMMENDED units of measurement are milliseconds ⏱️✨.
7.3.2. IPDV
Objective: To determine the Inter Packet Delay Variation as defined in [RFC5481] 🌸.
Procedure: As described by [RFC2544], first determine the throughput for the DUT at each of the listed frame sizes. Send a stream of frames at a particular frame size through the DUT at the determined throughput rate to a specific destination. The stream SHOULD be at least 60 seconds in duration. Measure the one-way delay as described by [RFC3393] for all frames in the stream. Calculate the IPDV for each of the frames using the formula:
IPDV(i) = D(i) - D(i-1)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 over-summarization. In this context, the report for each measurement SHOULD include three values: Dmin, Dmed, and Dmax. Not one number, three! 🙅♀️💅
Where:
- Dmin = the minimum IPDV in the stream
- Dmed = the median IPDV of the stream
- Dmax = the maximum IPDV in the stream
The test MUST be repeated at least 20 times. To summarize the 20 repetitions, for each of the three (Dmin, Dmed, and Dmax), the median value SHOULD be reported 🔁.
Reporting format: The median for the three proposed values SHOULD be 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 frame size and associated frame rate for the tested media types and sub-columns for the three proposed reported values. Following the recommendations of [RFC5481], the RECOMMENDED units of measurement are milliseconds 🎀💜.
7.4. Frame Loss Rate
Use Section 26.3 of [RFC2544] unmodified. Same as before, no changes, periodt 💅.
7.5. Back-to-Back Frames
Use Section 26.4 of [RFC2544] unmodified 🦋.
7.6. System Recovery
Use Section 26.5 of [RFC2544] unmodified ✨.
7.7. Reset
Use Section 4 of [RFC6201] unmodified 🌈.
- Additional Benchmarking Tests for Stateful IPv6 Transition Technologies 🧚
This section describes additional tests dedicated to stateful IPv6 transition technologies. For the tests described in this section, the DUT devices SHOULD follow the test setup and test parameters recommendations presented in Sections 5.2 and 5.3 of [RFC3511] 💖.
The following additional tests SHOULD be performed.
8.1. Concurrent TCP Connection Capacity
Use Section 5.2 of [RFC3511] unmodified 🫶.
8.2. Maximum TCP Connection Establishment Rate
Use Section 5.3 of [RFC3511] unmodified 👑.
- DNS Resolution Performance 🌸
This section describes benchmarking tests dedicated to DNS64 (see [RFC6147]), used as DNS support for single-translation technologies such as NAT64. DNS64 is the glow-up for NAT64, no cap 💜✨.
9.1. Test and Traffic Setup 🎀
okay so the test setup in Figure 3 follows the same setup we saw in Figure 1 for the single-translation IPv6 transition technologies 💖
1:AAAA query +--------------------+
+------------| |<-------------+
| |IPv6 Tester IPv4| |
| +-------->| |----------+ |
| | +--------------------+ 3:empty | |
| | 6:synt'd AAAA, | |
| | AAAA +--------------------+ 5:valid A| |
| +---------| |<---------+ |
| |IPv6 DUT IPv4| |
+----------->| (DNS64) |--------------+
+--------------------+ 2:AAAA query, 4:A query
Figure 3: Test Setup 3 (DNS64)The test traffic SHOULD be made up of these messages, in this order 🦋
- Query for the AAAA record of a domain name (from the client to the DNS64 server)
- Query for the AAAA record of that same domain name (from the DNS64 server to the authoritative DNS server)
- Empty AAAA record answer (from the authoritative DNS server to the DNS64 server)
- Query for the A record of that same domain name (from the DNS64 server to the authoritative DNS server)
- Valid A record answer (from the authoritative DNS server to the DNS64 server)
- Synthesized AAAA record answer (from the DNS64 server to the client)
The Tester is playing two roles at once: it's the DNS client AND the authoritative DNS server 🫶 It MAY be one single physical device, or, if you'd rather, two physical devices MAY be used instead ✨
Now, a few things to keep in mind 👑
- If the DNS64 server does caching and gets a cache hit, then step 1 goes straight to step 6, and steps 2 through 5 get skipped 💅
- If the domain name already has a AAAA record, the authoritative DNS server sends it back in step 3, steps 4 and 5 get skipped, and the DNS64 server does NOT synthesize anything. It just passes the received AAAA record along to the client 🌸
- About the IP versions between the Tester and the DUT: IPv6 MUST be used between the client and the DNS64 server (because a DNS64 server is serving an IPv6-only client, bestie 😭). But either IPv4 or IPv6 MAY be used between the DNS64 server and the authoritative DNS server 🌈
9.2. Benchmarking DNS Resolution Performance 💜
Objective: figuring out DNS64 performance by finding the maximum number of DNS requests that get processed successfully per second. Main character energy 👑
Procedure: you send a specific number of DNS queries at a specific rate to the DUT, then count up the replies that come back from the DUT. A reply only counts if it arrives in time (within a predefined timeout period, counted from when the matching query was sent, with the default value being 1 second) AND it's valid, meaning it contains a AAAA record 🔥 If the number of queries sent equals the number of replies received, you raise the rate and rerun the test. If fewer replies came back than queries were sent, you lower the rate and rerun 🦋
Each trial SHOULD run for at least 60 seconds. Why? A short trial would give a DNS64 server a sneaky advantage, since it could store the requests and use up the timeout time to answer them later 🙈 For that same reason, no timeout longer than 1 second SHOULD be used. If you want to dig deeper into this, check out [Lencse1] 🧚
The maximum number of processed DNS queries per second is the fastest rate at which the number of DNS replies sent by the DUT equals the number of DNS queries the test equipment sent to it. That's the iconic number ✨
The test SHOULD be repeated at least 20 times. Then you calculate the median plus the 1st and 99th percentiles of the number of processed DNS queries per second, because we want the full picture 💖
Details and parameters 🍓
- Caching
First, ALL the DNS queries MUST contain different domain names. (Or, the domain names MUST NOT be repeated until the DUT's cache is used up.) Then, new tests MAY be run once the domain names are 20%, 40%, 60%, 80%, and 100% cached. To make sure a record is actually cached, you have to repeat a domain name both "late enough" after the first query, so it's already resolved and sitting in the cache, AND "early enough" that it's still in the cache 🌈
- Existence of a AAAA record
First, ALL the DNS queries MUST contain domain names that do NOT have a AAAA record and have exactly one A record. Then, new tests MAY be run when 20%, 40%, 60%, 80%, and 100% of the domain names have a AAAA record 🫶
These two conditions are orthogonal, which is a fancy way of saying they don't affect each other. So every combination of them is possible and MAY be tested 🦋 The testing with 0% cached domain names AND 0% existing AAAA records is REQUIRED. All the other combinations are OPTIONAL 💅 (Once every domain name is cached, the results don't depend on what percentage of them have AAAA records, so testing those combos one by one isn't worth the effort 🙈)
Reporting format 📊: the main result of the DNS64 test is the median number of processed DNS queries per second, measured with the "0% + 0% combination" from above. The median SHOULD come with the 1st and 99th percentiles too, to show how stable the result is ✨ If you run the optional tests, you MAY present the median and the 1st and 99th percentiles in a two-dimensional table, where the dimensions are the proportion of repeated domain names and the proportion of domain names that have AAAA records. The two table headings SHOULD include these percentage values 🌸 Or, if you prefer, the results MAY be shown as a matching two-dimensional graph. In that case, the graph SHOULD show the median values with the percentiles as error bars 💜 From either the table or the graph, you MAY pull out one-dimensional excerpts at any fixed percentage of the other dimension. But if you do, the fixed value MUST be given together with that one-dimensional table or graph 🎀
9.2.1. Requirements for the Tester 🧚
Before a Tester can be used to test a DUT at rate r queries per second with a t-second timeout, it MUST run a self-test. This makes sure the Tester's own poor performance isn't messing up the results 😭 For the self-test, the Tester is looped back (the DUT is left out), and its authoritative DNS server subsystem is set up to answer ALL the AAAA record queries. To PASS the self-test, the Tester SHOULD be able to answer AAAA record queries at a rate of 2*(r+delta) within a 0.25*t timeout, where the value of delta is at least 0.1 💖
Explanation: when you do DNS64 testing, each AAAA record query can result in at most two queries sent by the DUT. The first is for a AAAA record, and the second is for an A record. (Both get sent when there's no cache hit and no AAAA record exists.) The parameters above guarantee that the DUT's authoritative DNS server subsystem can answer those queries at the required frequency while using up no more than half of the timeout time 🫶
Note: a sample open-source test program, dns64perf++, is available from [Dns64perf] and is documented in [Lencse2]. It implements only the client part of the Tester and should be used together with an authoritative DNS server implementation, e.g., BIND, NSD, or YADIFA. Its experimental extension for testing caching is available from [Lencse3] and is documented in [Lencse4] 🌈
10. Overload Scalability 🦋
Scalability gets talked about a LOT, but when it comes to network devices, nobody has come up with a formal definition or a measurement method yet 🙈 So in this context, we can define overload scalability as the ability of each transition technology to handle network growth. Poor scalability usually leads to poor performance, and that's the tea ☕ So overload scalability can be measured by quantifying how much network performance degrades as the number of network flows goes up 💅
The next subsections explain how the test setups can be changed to create network growth, and how the resulting performance degradation can be quantified ✨
10.1. Test Setup 🎀
The test setups defined in Section 4 have to be modified to create network growth 💜
10.1.1. Single-Translation Transition Technologies 🔥
For single-translation transition technologies, network growth can be created by increasing the number of network flows (NFs) that the Tester machine generates. Check out Figure 4 👑
+-------------------------+
+------------|NF1 NF1|<-------------+
| +---------|NF2 Tester NF2|<----------+ |
| | ...| | | |
| | +-----|NFn NFn|<------+ | |
| | | +-------------------------+ | | |
| | | | | |
| | | +-------------------------+ | | |
| | +---->|NFn NFn|-------+ | |
| | ...| DUT | | |
| +-------->|NF2 (translator) NF2|-----------+ |
+----------->|NF1 NF1|--------------+
+-------------------------+
Figure 4: Test Setup 4 (Single DUT with Increased
Network Flows)10.1.2. Encapsulation and Double-Translation Transition Technologies 🎀
okay so for encapsulation and double-translation transition technologies, a multi-flow setup is recommended 💅 Think multipoint-to-point: for most transition technologies, one of the edge nodes is built to support more than one connecting device 🦋 So the recommended test setup is an n:1 design, where n is the number of client DUTs connected to the same server DUT. Check out Figure 5 (it's giving main character energy 👑):
+-------------------------+
+--------------------|NF1 NF1|<--------------+
| +-----------------|NF2 Tester NF2|<-----------+ |
| | ...| | | |
| | +-------------|NFn NFn|<-------+ | |
| | | +-------------------------+ | | |
| | | | | |
| | | +-----------------+ +---------------+ | | |
| | +--->| NFn DUT n NFn |--->|NFn NFn| ---+ | |
| | +-----------------+ | | | |
| | ... | | | |
| | +-----------------+ | DUT n+1 | | |
| +------->| NF2 DUT 2 NF2 |--->|NF2 NF2|--------+ |
| +-----------------+ | | |
| +-----------------+ | | |
+---------->| NF1 DUT 1 NF1 |--->|NF1 NF1|-----------+
+-----------------+ +---------------+
Figure 5: Test Setup 5 (DUAL DUT with Increased
Network Flows)This test setup can help you quantify the scalability of the server device ✨ However, testing the overload scalability of the client DUTs needs additional recommendations 😭
For encapsulation transition technologies, you can create an m:n setup, where m is the number of flows applied to the same client device and n is the number of client devices connected to the same server device 🧚
For translation-based transition technologies, the client devices can be tested separately with n network flows, using the test setup presented in Figure 4 🌸
10.2. Benchmarking Performance Degradation 💜
10.2.1. Network Performance Degradation with Simultaneous Load 🔥
Objective: To quantify the performance degradation introduced by n parallel and simultaneous network flows. Literally the whole point, bestie 💖
Procedure: First, the benchmarking tests presented in Section 7 have to be performed for one network flow. Then you repeat the same tests for n network flows, where the network flows are started simultaneously. The performance degradation of the X benchmarking dimension SHOULD be calculated as relative performance change between the 1-flow (single flow) results and the n-flow results, using this formula:
Xn - X1
Xpd = ----------- * 100, where: X1 = result for 1-flow
X1 Xn = result for n-flowsThis formula SHOULD be applied only for "lower is better" benchmarks (e.g., latency). For "higher is better" benchmarks (e.g., throughput), the following formula is RECOMMENDED:
X1 - Xn
Xpd = ----------- * 100, where: X1 = result for 1-flow
X1 Xn = result for n-flowsAs a guideline for the maximum number of flows n, you can deduce the value by measuring the Concurrent TCP Connection Capacity as described by [RFC3511], following the test setups specified by Section 4 🫶
Reporting Format: The performance degradation SHOULD be expressed as a percentage. The number of tested parallel flows n MUST be clearly specified 🍓 For each of the performed benchmarking tests, there SHOULD be a table with a column for each frame size. The table SHOULD also state the applied frame rate. In the case of benchmarks for which more than one value is reported (e.g., IPDV, discussed in Section 7.3.2), a column for each of the values SHOULD be included 💅
10.2.2. Network Performance Degradation with Incremental Load 🌈
Objective: To quantify the performance degradation introduced by n parallel and incrementally started network flows. Stagger it, slay it 🦋
Procedure: First, the benchmarking tests presented in Section 7 have to be performed for one network flow. Then you repeat the same tests for n network flows, where the network flows are started incrementally in succession, each after time t. In other words, if flow i is started at time x, flow i+1 will be started at time x+t. Considering the time t, the time duration of each iteration must be extended with the time necessary to start all the flows, namely, (n-1)xt. The measurement for the first flow SHOULD be at least 60 seconds in duration ⏰
The performance degradation of the x benchmarking dimension SHOULD be calculated as relative performance change between the 1-flow results and the n-flow results, using the formula presented in Section 10.2.1. Intermediary degradation points for 1/4*n, 1/2*n, and 3/4*n MAY also be performed ✨
Reporting Format: The performance degradation SHOULD be expressed as a percentage. The number of tested parallel flows n MUST be clearly specified 🎀 For each of the performed benchmarking tests, there SHOULD be a table with a column for each frame size. The table SHOULD also state the applied frame rate and time duration T, which is used as an incremental step between the network flows. The units of measurement for T SHOULD be seconds. A column for the intermediary degradation points MAY also be displayed. In the case of benchmarks for which more than one value is reported (e.g., IPDV, discussed in Section 7.3.2), a column for each of the values SHOULD be included 🥹
11. NAT44 and NAT66 🌸
Although these technologies aren't the primary scope of this document, the benchmarking methodology for single-translation technologies (as defined in Section 4.1) can be used to benchmark implementations that use NAT44 (as defined by [RFC2663] with the behavior described by [RFC7857]) and implementations that use NAT66 (as defined by [RFC6296]) 🦋
12. Summarizing Function and Variation 📊
To keep the benchmarking scores from Sections 7 through 9 stable, multiple test iterations are RECOMMENDED. A summarizing function (or measure of central tendency) can be a simple, effective way to compare results across different iterations. However, over-summarization is an unwanted effect of reporting a single number 🙈
Measuring the variation (dispersion index) can counter the over-summarization effect. Empirical data obtained following the proposed methodology can also offer insights on which summarizing function would fit better.
To that end, data presented in [ietf95pres] indicate the median as a suitable summarizing function, and the 1st and 99th percentiles as variation measures for DNS Resolution Performance and PDV. The median and percentile calculation functions SHOULD follow the recommendations of Section 11.3 of [RFC2330] 💜
For a fine-grained look at the frequency distribution of the data, histograms or cumulative distribution function plots can be employed 📈
13. Security Considerations 🚨
Okay, this one is serious, so listen up 🫶 Benchmarking activities described in this memo are limited to technology characterization using controlled stimuli in a laboratory environment, with dedicated address space and the constraints specified in the sections above.
The benchmarking network topology will be an independent test setup and MUST NOT be connected to devices that may forward the test traffic into a production network or misroute traffic to the test management network. Do not plug this into prod, periodt 💀
Further, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the DUT or System Under Test (SUT). Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes. Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks. No cheating allowed, no cap 🙅♀️
14. IANA Considerations 🧚
The IANA has allocated the prefix 2001:2::/48 [RFC5180] for IPv6 benchmarking. For IPv4 benchmarking, the 198.18.0.0/15 prefix was reserved, as described in [RFC6890]. The two ranges are sufficient for benchmarking IPv6 transition technologies. Thus, no action is requested ✨
15. References 📚
15.1. Normative References
[RFC1242] Bradner, S., "Benchmarking Terminology for Network
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
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,
"Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998,
<http://www.rfc-editor.org/info/rfc2330>.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544,
DOI 10.17487/RFC2544, March 1999,
<http://www.rfc-editor.org/info/rfc2544>.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002,
<http://www.rfc-editor.org/info/rfc3393>.
[RFC3511] Hickman, B., Newman, D., Tadjudin, S., and T. Martin,
"Benchmarking Methodology for Firewall Performance",
RFC 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.
Dugatkin, "IPv6 Benchmarking Methodology for Network
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
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,
"Device Reset Characterization", RFC 6201,
DOI 10.17487/RFC6201, March 2011,
<http://www.rfc-editor.org/info/rfc6201>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>.15.2. Informative References 📚✨
okay bestie, here's the extra-credit reading list 🤓💜 Each entry keeps its original details so you can look up the exact document:
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999,
<http://www.rfc-editor.org/info/rfc2663>.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213,
DOI 10.17487/RFC4213, October 2005,
<http://www.rfc-editor.org/info/rfc4213>.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
<http://www.rfc-editor.org/info/rfc4659>.
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
"Connecting IPv6 Islands over IPv4 MPLS Using IPv6
Provider Edge Routers (6PE)", RFC 4798,
DOI 10.17487/RFC4798, February 2007,
<http://www.rfc-editor.org/info/rfc4798>.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569,
January 2010, <http://www.rfc-editor.org/info/rfc5569>.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
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
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011,
<http://www.rfc-editor.org/info/rfc6147>.
[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
China Education and Research Network (CERNET) IVI
Translation Design and Deployment for the IPv4/IPv6
Coexistence and Transition", RFC 6219,
DOI 10.17487/RFC6219, May 2011,
<http://www.rfc-editor.org/info/rfc6219>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
<http://www.rfc-editor.org/info/rfc6296>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
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:
Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013,
<http://www.rfc-editor.org/info/rfc6877>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, 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.
Farrer, "Lightweight 4over6: An Extension to the Dual-
Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
July 2015, <http://www.rfc-editor.org/info/rfc7596>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597,
DOI 10.17487/RFC7597, July 2015,
<http://www.rfc-editor.org/info/rfc7597>.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
and T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
2015, <http://www.rfc-editor.org/info/rfc7599>.
[RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar,
S., and K. Naito, "Updates to Network Address Translation
(NAT) Behavioral Requirements", BCP 127, RFC 7857,
DOI 10.17487/RFC7857, April 2016,
<http://www.rfc-editor.org/info/rfc7857>.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915,
DOI 10.17487/RFC7915, June 2016,
<http://www.rfc-editor.org/info/rfc7915>.
[Dns64perf]
Bakai, D., "A C++11 DNS64 performance tester",
<https://github.com/bakaid/dns64perfpp>.
[ietf95pres]
Georgescu, M., "Benchmarking Methodology for IPv6
Transition Technologies", IETF 95 Proceedings, Buenos
Aires, Argentina, April 2016,
<https://www.ietf.org/proceedings/95/slides/
slides-95-bmwg-2.pdf>.
[Lencse1] Lencse, G., Georgescu, M., and Y. Kadobayashi,
"Benchmarking Methodology for DNS64 Servers", Computer
Communications, vol. 109, no. 1, pp. 162-175,
DOI 10.1016/j.comcom.2017.06.004, September 2017,
<http://www.sciencedirect.com/science/article/pii/
S0140366416305904?via%3Dihub>
[Lencse2] Lencse, G. and D. Bakai, "Design and Implementation of a
Test Program for Benchmarking DNS64 Servers", IEICE
Transactions on Communications, Vol. E100-B, No. 6,
pp. 948-954, DOI 10.1587/transcom.2016EBN0007, June 2017,
<https://www.jstage.jst.go.jp/article/transcom/E100.B/
6/E100.B_2016EBN0007/_article>.
[Lencse3] dns64perfppc,
<http://www.hit.bme.hu/~lencse/dns64perfppc/>.
[Lencse4] Lencse, G., "Enabling Dns64perf++ for Benchmarking the
Caching Performance of DNS64 Servers", unpublished, review
version, <http://www.hit.bme.hu/~lencse/publications/
IEICE-2016-dns64perfppc-for-review.pdf>.
[IEEE802.1AC]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Media Access Control (MAC) Service
Definition", IEEE 802.1AC.
[IEEE802.1Q]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Bridges and Bridged Networks", IEEE Std
802.1Q.Appendix A. Theoretical Maximum Frame Rates 🧮💖
this appendix is all about the recommended formulas for working out theoretical maximum frame rates over Ethernet, used here as the example medium 🎀 the math has to account for the extra frame size overhead that comes from encapsulation or translation. for example, the 6in4 encapsulation from [RFC4213] adds 20 bytes of overhead to each frame 🦋
so, with X as the frame size and O as the overhead from encapsulation or translation, the maximum theoretical frame rate for Ethernet is:
Line Rate (bps)
------------------------------------
(8 bits/byte) * (X+O+20) bytes/framethe calculation follows the formula recommended by [RFC5180] in Appendix A.1 ✨ as an example, the frame rate recommended for testing a 6in4 implementation over 10 Mb/s Ethernet with 64-byte frames works out like this:
10,000,000 (bps)
-------------------------------------- = 12,019 fps
(8 bits/byte) * (64+20+20) bytes/frameand here's the full list of recommended frame rates for 6in4 encapsulation 📊🌸
+------------+---------+----------+-----------+------------+
| Frame size | 10 Mb/s | 100 Mb/s | 1000 Mb/s | 10000 Mb/s |
| (bytes) | (fps) | (fps) | (fps) | (fps) |
+------------+---------+----------+-----------+------------+
| 64 | 12,019 | 120,192 | 1,201,923 | 12,019,231 |
| 128 | 7,440 | 74,405 | 744,048 | 7,440,476 |
| 256 | 4,223 | 42,230 | 422,297 | 4,222,973 |
| 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 |
| 1280 | 947 | 9,470 | 94,697 | 946,970 |
| 1518 | 802 | 8,023 | 80,231 | 802,311 |
| 1522 | 800 | 8,003 | 80,026 | 800,256 |
| 2048 | 599 | 5,987 | 59,866 | 598,659 |
| 4096 | 302 | 3,022 | 30,222 | 302,224 |
| 8192 | 152 | 1,518 | 15,185 | 151,846 |
| 9216 | 135 | 1,350 | 13,505 | 135,048 |
+------------+---------+----------+-----------+------------+Acknowledgements 🫶🌈
big thank-yous go out to Youki Kadobayashi and Hiroaki Hazeyama for their constant feedback and support 💜 shoutout to the NECOMA project members for their continuous support too ✨ thanks also to Emanuel Popa, Ionut Spirlea, and the RCS&RDS IP/MPLS Backbone Team for their support and insights 🙌
the authors thank Scott Bradner for his useful suggestions, and they note that portions of text from Scott's documents were used in this memo (e.g., the "Latency" section) 📝 a massive thank you to Al Morton and Fred Baker for their detailed review and very helpful suggestions 😭 other helpful comments and suggestions came from Bhuvaneswaran Vengainathan, Andrew McGregor, Nalini Elkins, Kaname Nishizuka, Yasuhiro Ohara, Masataka Mawatari, Kostas Pentikousis, Bela Almasi, Tim Chown, Paul Emmerich, and Stenio Fernandes 👑 and finally, a special thank you to the RFC Editor Team for their thorough editorial review and helpful suggestions 💅
Authors' Addresses 💌
Marius Georgescu
RCS&RDS
Strada Dr. Nicolae D. Staicovici 71-75
Bucharest 030167
Romania
Phone: +40 31 005 0979
Email: marius.georgescu@rcs-rds.ro
Liviu Pislaru
RCS&RDS
Strada Dr. Nicolae D. Staicovici 71-75
Bucharest 030167
Romania
Phone: +40 31 005 0979
Email: liviu.pislaru@rcs-rds.ro
Gabor Lencse
Szechenyi Istvan University
Egyetem ter 1.
Gyor
Hungary
Phone: +36 20 775 8267
Email: lencse@sze.hu📦 where this page comes from
- ietf: rfc8219 2017-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms