高速以太网

RFC 6349 TCP Performance Testing Enters the Lab

作者:

browsing web phone AdobeStock 290012040-1240x600

RFC 6349 stresses networks with true TCP stateful Traffic; much closer to the subscriber experience required by service providers for QoE and SLAs.

RFC6349 blog image, datacenter with servers with 2 clouds between servers

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

喜欢我们的内容吗?

在这里订阅我们的博客

博客订阅

标签Ethernet+IP
Todd Law
Todd Law

Dr. Todd Law's professional experience includes over 18 years in the networking industries, with leading employers such as Hewlett-Packard, Agilent Technologies, Nortel Networks, and most recently Spirent Communications. Network test has been his focus for the past 14 years, and he has specialized in automation aspects of network test for the past five years. During that time, he has driven automation strategies that span from traditional script-based techniques, to next-generation automation tools which bring orders of magnitude in automation efficiency. Most recently, Dr. Law has also been instrumental in the formation of the Network Test Automation Forum, or NTAF, whose mission is to standardize the mechanism by which various test solutions communicate