The Value Behind Realistic Network Traffic Emulation
Ever wondered why your networking equipment isn’t reaching its advertised performance? Why it has lower performance when introduced in a production environment, but in the lab passed – with flying colors – a battery of tests much tougher than its normal predicted usage?
As you’ve probably guessed it by now, the difference comes from the network payload present in those tests and that’s because the actual contents matter when you have a device doing deep packet inspection and performing some kind of matching operations.
Realistic network traffic
To understand this phenomenon, let’s have a look at the actual difference between realistic and nonrealistic network traffic. Figure 1 shows us the case of the widely used HTTP protocol, both in terms of contents as well as performance of the device under test (DUT).
Figure 1: Realistic vs. Fake HTTP data in terms of contents and DUT performance metrics
Why is performance impacted?
When a device performs deep packet inspection (DPI), it needs to use some kind of matching algorithm. A very common example is the Boyer-Moore string search algorithm.1 This algorithm was developed by Bob Boyer and J. Strother Moore in 1977, and is a generally recognized benchmark for fast searching.
The Boyer-Moore algorithm works by using the search string to build two tables defining the behavior after a mismatch. Those tables allow the search to use the information gained when checking for a match in one location to rule out as many potential match positions as possible. Each check that results in a mismatch is followed by a table lookup to see whether that check included a substring of the match expression, and how far the expression must shift over to align with that substring. Whichever table provides the largest shift is used.
To get the maximum benefit from these tables, the Boyer-Moore algorithm starts making its comparison from the end of the string it’s matching. That way, if the character that’s examined doesn’t appear in any substring of the match string, the whole string cannot fit where it is and can be moved over by its entire length.
That being said, very uniform data is the best case scenario for the Boyer-Moore Algorithm, while a random string of characters that happens to overlap the set of characters in the match pattern is approaching a worst case scenario. A real world example would fall somewhere in between those. Whether a device uses Boyer-Moore specifically or some other algorithm, the fact is that the specific content it must examine has a dramatic effect on the workload of the device.
Besides the algorithmic performance, the actual contents can also influence other factors – such as data caching – that can lead to lower than expected throughput.
So, it’s critically important when evaluating a device to use data that closely resembles the content it is likely to see in the real world. That’s the only way to get a view of the actual performance of the device.
Markov text generator
When people communicate online, they usually use some form of written language that gets encoded and sent and received via a protocol. So, in order to emulate network traffic as close as possible to real-life, we must actually generate syntactically correct language constructs and not just random words.
This is where a Markov text generator2 comes in and makes use of a Markov process in order to generate superficially real-looking text given a sample document or text corpus. The same text generation process is also used by spammers to intersperse real-looking paragraphs into unsolicited email and post comments in an attempt to evade spam filters.
How does a Markov generated text compare to just random words? See for yourself in Figure 2.
|sopping Marginally interval Beverage tricky truth folk mountainous corporate quarterfinal banana mortuary Eventually chronically; teargas Wearily Sgt. time zone diminish! Paraffin Saw beginner southwestern serial killer machinery! diehard nervous empowerment eviction we Proven. Trajectory ordain driven small talk manage pamphlet; Inventory unbeaten navigator Sternly chatterbox insubstantial symbolize misbehave Oriental sociable stained glass phony. opener tardiness spy decide! ally uninsured visual fought matted sluice fluke quadruped Inuit across trace surprising chipper cramped? childlike bison blusher enlighten consecrate putt vegetable all Godchild circumstantial, justly, pointed brunette, fortieth humbly primary school hilariously careless overwrought? ascribe reprisal involvement epithet transpire scrabble sponsorship aloud. aquatic||And one had to admit that I didn't relish the idea of bringing pals back in the small hours now, but I must say that to me there seems to be something positively fiendish in a man who acted from the best motives, but your ladyship, knowing him better, he had a kind of paternal muscular spasm about the mouth, which is capable of being developed. Life became like what the poet Johnnie says -- one grand, sweet song. She made me feel as if I were a memorizing freak at the halls. I hadn't been expecting her for days. Payable in advance?|
Figure 2: Randomly-generated text (left) vs. Text generated by the Markov process (right)
Now, you might argue that the text on the left will have the same effect with regards to how your network equipment will function: it’s gibberish. But you have to take into consideration that a language has certain rules, and those rules will influence what you’ll see on a real network. These rules can’t be captured by just generating random words, and they may lead to a worst-case running time for the DPI engine. On the positive side, these very same rules may also be used to optimize the DPI engine for real-world scenarios.
We’ve seen that realistic network content is important, and how we can obtain it with the use of a Markov process. But we only touched the subject on a single language, namely English.
Having content in another language introduces new rules, and may have different effects on how a network equipment behaves. The new language may have different characters in addition to the English ones, or a different character set altogether (e.g., Chinese). Along with different character sets, multibyte UTF8 characters may also be present in other languages. Such languages may also have different rules and a different syntax. All of these factors imply hard to predict effects on how the device under test behaves when that type of content is being analyzed.
Currently, our Markov text generator is able to generate sentences and blocks of text in the following languages:
The Markov text generator is used in all of our protocols where it makes sense, so once a new language is added it’s available to all of them. Our text corpuses behind the Markov generator also embody common language sentences and constructs that you would typically see online, thus making the generated contents much more real.
A glimpse of things to come
Also, the actual smarts that go into a network product can and should only be done in conditions that resemble as close as possible the real-life scenarios in order to demonstrate those optimizations – because otherwise unpleasant surprises will occur.
Another recent trend is the increased use of machine learning in network products in order to handle the complexity and diversity of network traffic, as well as react to unknown threats. In this regard, being able to train and test the machine learning models against realistic network traffic is a must.
To this end, the Ixia ATI team is committed to delivering the most realistic emulation possible for all of our supported protocols and testing scenarios, as well as keeping our most widely used protocols up to date through the Evergreen program. We want our customers to know their their products will function as expected in the real world.