It’s no secret that the vast majority (over 90%) of traffic on the Internet is based on TCP, which is stateful and connection-oriented in nature, versus a minority of traffic based on UDP, which is both stateless and connectionless. However, it is curious that in network test labs throughput performance is almost always measured using RFC 2544-type testing to find the maximum non-drop rate for forwarding devices. So ingrained is the perception about this type of testing, that some engineers refer to RFC 2544 benchmarking as “RFC testing”, as if there were no other standards out there.
The RFC 2544 standard, and test equipment implementations, determine benchmarking uses completely stateless IP traffic. The assumption is that benchmarking throughput using simple IP traffic should be good enough, since routers are really just layer-3 devices anyway, right? The upper layers will take care of themselves, right?
Well, yes and no.
Benchmarking with RFC 2544 is useful in that it gives a good overall picture of the throughput of the device under test. To make an analogy, if you were told that Chicago’s O’Hare airport passes through up to 200,000 passengers per day, you would be impressed (as I am) by the fine people who work extremely hard at ORD to process so many passengers every single day. However, this fact doesn’t mean much to those passengers who had flights cancelled or delayed for whatever reason. Simply stating a high level of throughput ignores other important events that ultimately matter a great deal to the human beings who are ultimately the consumers of the services provided by airports, airlines, etc.
Similarly, network service providers ultimately need to care about the experience of their subscribers, even if the aggregate performance of individual devices or whole networks is at some astronomically high level.
Some of those subscribers may be paying extra for a high quality of service, ensuring 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, which might be treated differently from other packets (think of business class passengers who pay more, and therefore expect more from their experience).
Some of those subscribers are paying for more bandwidth so they can, for example share their personal experiences in real-time via Facebook Live streaming while at a large outdoor concert. This means video and audio traffic which is transported over TCP and not UDP. And yes, TCP means that connections need to be established before any data is sent, and moreover, the rate at which data is sent will ebb and flow depending on how congested the overall network is.
The reality is that RFC 2544 has been great for vendors who are selling routers and need to attach 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 big routers at the core of the Internet can deliver – they just care about getting the bandwidth – and the experiences they are paying for.
And so enters RFC 6349, which in contrast to RFC 2544, stresses networks with true TCP traffic that is stateful, connection-oriented – in short, much closer to the subscriber experiences that service providers care about, quality of experience and validating SLAs.
While this standard has existed since 2011, test tools for RFC 6349 have been limited to small handheld tools used by field personnel – until now. Spirent is pleased to announce the world’s first RFC 6349 implementation specifically designed for lab users. RFC 6349 is now available on Spirent MethodologyCenter, designed to increase lab productivity through a rapid and comprehensive configuration-to-results experience. Moreover, MethodologyCenter is used with proven and stable Spirent TestCenter ports, enabling RFC 6349 testing over a range of physical interfaces from 1G to 400G, or high-performing DPDK-enabled virtual ports.
To learn more, please check out our datasheet: RFC 6349 Methodology Pack datasheet