The World is Lacking Background Traffic

When I inherited the system test and quality assurance (QA) groups, along with my other responsibilities as Director of Engineering at my last Company, one of the things the QA engineers would do to make my head tilt was to configure all the tests with background traffic. Why would that make my head tilt? It was the background traffic they used; a popular traffic generator running layer 2 traffic with random data. I immediately said, "That's not background traffic - that traffic doesn't exist on any network". The engineer in charge of running the "background equipment" said that he didn't want the traffic to interfere with the test. Of course my next question was, "Then why run the traffic at all? If the background traffic is not to interfere with the traffic and it's not ANYWHERE near realistic - what's the point?"

I wanted realistic IP traffic the next time I visited and a week later I saw he had IPv4 traffic with random data being sent. Granted, this is a huge improvement over random Ethernet frames, but a long way to realistic traffic. I acknowledged this was a good improvement but wondered if he had any peer-to-peer traffic? The QA engineer asked why and I explained the recent feature we added for traffic shaping peer-to-peer traffic. He explained that this would get in the way. I suggested that he should be running P2P traffic all the time, "Think about it; if we have traffic shaping off - peer-to-peer traffic IS the background traffic and not the primary traffic." I told him to have 20 percent of the traffic peer-to-peer by next week.

Next week I come by and sure enough 80% of the traffic is IPv4 with random data, and 20% is a P2P datagram. Now, first knock, he didn't get the gist of what I was saying; he didn't take a look at all our features and pull in different traffic sources, he did the literal translation. Oh well.  However, and here is the second knock, there were 5 "streams" of traffic being sent. A stream being an instruction to the popular traffic generator to send out traffic. So what we had were first four packets of IPv4 with random data, then a single packet that is part of a P2P stream, then repeat. My not so surprising reaction, "Hey this isn't P2P, it's a packet."

Fast forward one week...the QA engineer is there with the rep for the test equipment. The sales engineer for the test equipment vendor has his head held high and says "I have a very complex TCL script here that will recreate the P2P flow exactly!" I pull out a copy of Ethereal (now Wireshark), take a look and the traffic is the same, except the IP address repeating over and over again. "This isn't background traffic, it's a single P2P flow played over and over again."  Pause.  Finally the SE for the test company says, "What do you expect, actual traffic?".

Yes!

 
We need to change the way people test, and it's a fundamental shift. After all, your product is going into a network with an average of 30+ different applications on the wire, don't you think your product should handle that traffic correctly? Background traffic needs to be real and this, along with other similar stories, led to the creation of BreakingPoint.  We understand the need for repeatable testing, so we want to dig into what background traffic should be, why you should do it this way and what NOT to do.

Background - it's a lot more important than most people realize.