A Holistic View of Network Emulation
We read Damien Garros' blog post -- Introduction to Network Emulation and Requirements for Virtual Network Devices with great interest as Mr. Garros takes an unusual view of networking. Our thoughts and comments follow.
Click on the link above to read the entire post.
Key Takeaways about Network Emulation in Mr. Garros’ Post
Define the most common use cases for Network Emulation:
Network Design, Validation, and Testing: Recreate a network to validate its behavior
Tools Development and Validation: Use virtual devices to develop/validate tools dependent on network devices
Training and Demos
Explain how Network Emulation differs from Network Virtualization or Network Simulation
Virtual network devices compared to physical network devices
Tips for evaluating a virtual network device for network emulation
Approaching Network Emulation from Two Perspectives
Mr. Garros’ viewpoint is that of an organization building out a network and that is certainly a valid one for some use-cases, but build-out is completely unnecessary when the goal is to test device resilience to networks under severe-stress conditions.
Those interested in network-edge equipment require a different perspective. For them, “the network” is most helpfully simplified into a single test “box” whose characteristics can be controlled for the purpose of testing the end-equipment’s behavior under a range of network conditions.
If all you want to do is make sure your smartphone app handles real-time audio or video streaming, it's a lot simpler and cheaper to test with network-simulator-in-a-box type solutions, such as the IWL KMAX network emulator.
An easy example, though certainly not meant to be the only class of such cases, would be a device or smartphone app utilizing isochronous traffic such as RTP, such that a group of friends can interact with each other as if they were all together, even when separated by thousands of miles.
What is the Importance of a Proper Test Area?
An important test-area for such devices would be to verify the device’s ability to scale-back its codec fidelity under severe-congestion conditions. The testers’ interest would be:
first, in assuring its coping algorithms reliably detected the congestion severity, and
second, that the scaling-back was appropriate. Not too much, not too little.
third, that messaging to the user was sufficiently clear so when communication-conditions degrade, the device continues to function as best it can, but eventually the users are adequately apprised.
fourth, an ability to capsulize these tests so the tests can be re-run for new software or firmware patches, updates, and releases. This regression-testing and test-automation should be easy to reconstitute.
These viewpoints are very different.
Those interested in building out a network need its elements to be present in the test-suite, and to be individually-controllable: e.g., sudden swings in link-utilization, electrical/optical- and loss-characteristics, etc. Whereas, producers of network-edge equipment want the opposite: network-in-a-box whose characteristics can be simplified down to just a few: delay, drop-rate, duplication, alteration, etc. That simplicity translates into an all-important virtue: the ability to run through a large number of test condition scenarios in minimal time. The less time it takes to move from one scenario to the next, the better.
Mr. Garros' opening sentence reveals his network build-out focus:
"Network Emulation consists of (re)creating a network in a virtual environment using virtual devices."
Unfortunately, the terminology in the networking industry is not sufficiently granular to differentiate the two environments (e.g. building out a network versus network-edge equipment). From the network-edge equipment point of view, one would prefer to use a real device with real data flows, as that would most closely mimic the real-world environment. Here the concern is network emulation to see how an app or device behaves and performs under a variety of network conditions that are otherwise quite difficult to generate.
Mr. Garros goes on to write:
"Some of the largest barriers are the quality of the virtual images, which are emulating production network devices, obtained from the network vendors and the lack of proper tools available to create large emulated environments."
However, Mr. Garros does not explain the specific quality issue.
Mr. Garros describes the three main uses for network emulation, but misses a very important one: verifying that an app or device can operate under adverse network conditions! In addition, his second use is vague; he writes:
"Tools development and Validation: Use virtual devices to validate and develop tools that are dependent on network devices."
Why would you want to have a tool that is dependent on a network device? Would it not be preferable to have a tool be independent of a network device? Perhaps Mr. Garros is referring to extremely costly, very large switches or routers, where having access to an emulated interface allows one to create software tools to interact with the interface without purchasing and installing the costly switch or router. But again, this is only a guess; the description is vague.
Differentiating Building Out a Network and Network Edge Equipment
Finally, Mr. Garros describes nine points to consider when evaluating a Virtual Network Device for Network Emulation. This could be its own separate blog post and is related to, but actually an entirely different topic than network emulation.
Mr. Garros would serve the reader by providing more examples for clarification. Our hope is that this blog post highlights the differences between building out a network and network-edge equipment .
For the latter, IWL suggests learning more about KMAX.