RFC 6349 emphasizes networks with true TCP state traffic; much closer to the subscriber experience required by service providers for QoE and SLA.
It is no secret that the vast majority (more than 90%) of Internet traffic is based on TCP, which is stateful and connection-oriented by nature, versus a minority of traffic based on UDP, which is stateless and connectionless. However, it is curious that in network testing laboratories, performance is almost always measured using RFC 2544-type tests to find the maximum non-drop rate for forwarding devices. So ingrained is the perception of this type of testing that some engineers refer to RFC 2544 benchmarking as “RFC testing,” as if no other standards existed.
The RFC 2544 standard, and implementations of test equipment, determine that benchmarking uses completely stateless IP traffic. It is assumed that performance benchmarking using simple IP traffic should be sufficient, since routers are actually layer 3 devices, right? The upper layers take care of themselves, right?
Well, yes and no.
Benchmarking with RFC 2544 is useful because it provides a good overall picture of the performance of the device under test. To make an analogy, if you were told that up to 200,000 passengers pass through Chicago’s O’Hare airport each day, you would be impressed (as I am) by the good people who work hard at ORD to process so many passengers each day. However, this fact means little to passengers whose flights have been canceled or delayed for any reason. The mere statement of a high performance level ignores other important facts that, ultimately, matter much to the humans who are ultimately the consumers of the services provided by airports, airlines, etc.
Similarly, network service providers ultimately have to care about their subscribers’ experience, even if the aggregate performance of individual devices or entire networks is at some astronomically high level.
Some of those subscribers may be paying more for a high-quality service that guarantees a certain level of bandwidth, lower latency, etc. This will be reflected in the Diffserv code points, VLAN IDs, and/or VLAN priority bits used to identify packets, or qualities of service, that could be treated differently than other packets (think of business-class passengers who pay more and therefore expect more from their experience).
Some of those subscribers pay for more bandwidth so they can, for example, share their personal experiences in real time via Facebook Live streaming while attending a large outdoor concert. This means that video and audio traffic is transported over TCP and not UDP. And yes, TCP means that connections must be established before data is sent, and moreover, the rate at which data is sent flows and ebbs depending on how congested the network is overall.
The reality is that RFC 2544 has been great for router vendors who need to assign a high-performance number to a routing product for sales and marketing purposes. Another reality, however, is the world of service providers, where subscribers don’t really care how much bandwidth the large routers at the Internet core can provide, they only care about getting the bandwidth and experiences they pay for.
And so enters RFC 6349, which in contrast to RFC 2544, emphasizes networks with true TCP traffic that is stateful, connection-oriented - in short, much closer to the subscriber experiences that service providers care about for quality of experience and SLA validation.
Although this standard has existed since 2011, test tools for RFC 6349 have been limited to small handheld tools used by field staff - until now. Spirent is pleased to announce the world’s first RFC 6349 implementation designed specifically for laboratory users. RFC 6349 is now available in SpirentMethodologyCenter, designed to increase laboratory productivity through a fast and complete setup-to-results experience. Additionally, MethodologyCenter is used with tested and stable ports from SpirentTestCenter, enabling RFC 6349 testing across a range of physical interfaces from 1G to 400G, or high-performance virtual ports enabled for DPDK.
Spirent TestCenter Datasheet: https://www.tecnous.com/wp-content/uploads/2019/09/Spirent-C50-100G.pdf