Easy WAN Emulation for Application Testing

Anyone who has ever had to deliver application traffic over a WAN has no doubt run into the issue of trying to determine how their application would perform for a remote user.

In this article I will outline some of the issues with WAN delivery, and then move on to some easy WAN emulation tools to help simulate the conditions that remote users might experience.

This will enable you to set performance benchmarks for your application even though you are located on the LAN with ideal network conditions.

What is a WAN?

A Wide Area Network (WAN) is any network that is connected via slower network links than one would find at the primary Local Area Network (LAN) environment. A WAN can be made up of private links such as telco provided MPLS, VPNs or even just the plain old Internet.

WANs typically have lower bandwidth and throughput than LAN links, but more importantly, they usually have a lot more hops from source to destination. With each hop, you potentially introduce additional latency and packet routing issues.

Most modern WANs are actually pretty good. Internet interconnects are constantly being updated and upgraded giving better performance and bandwidth.

But there are areas where this is not the case. Any geo-dispersed WAN, especially in the less developed regions, can and do suffer from "traditional" WAN problems.

In the map graphic above can see that the connecting links do not go direct from Point A to Point B. The different colours also indicate the different cable systems and operators that are involved.

WAN Problems

There are three main issues that can affect your traffic traversing a WAN. Bandwidth, latency, and packet loss.

Bandwidth

Bandwidth is the load-carrying "capacity" of the WAN. Although bandwidth can affect latency, it is not the same thing.

When bandwidth gets exhausted, packet latency increases as queuing of data is required.

Latency

Latency is the amount of time a packet takes to go from Point A to Point B. This is effectively the "speed" of the WAN.

Latency is primarily affected by the number of hops that are traversed on the way from Point A to B. Typically, the greater the distance between two points, the more hops are traversed and the latency increases.

The further a packet has to go can also affect the routes a packet takes to go between the two points. Packet 1 can go via Route 1, while Packet 2 can go via Route 2. If one route is more latent than the other, the packets might arrive at different time. Ideally you want a stable amount of latency. A constant higher latency is better than a lower, highly-erratic latency.

Packet Loss

Packets get lost for a number of reasons. They can simply be dropped by one of the hops, or they can take so long to get to the destination that they exceed their time to live.

Depending on the transport protocol, a packet is either permanently lost, or the packet has be requested for a second time.

UDP is a best effort protocol. A packet is sent but no consideration is given to whether the packet is actually received at the other end. TCP is different in that it tries to guarantee packet delivery via a three-way handshake. A packet has to be confirmed to be received on the client side. Because of this, TCP-based connections are typically very resilient even over lossy networks.

The real problem occurs when packet loss increases, performance of an application exponentially decreases.

Based on this information you should be able to see that high bandwidth availability does not necessarily guarantee good performance. in fact, a lossy, erratic network will negatively impact you, despite a surplus of available bandwidth.

WAN Emulation Testing Tools

There are various tools to help you simulate WAN conditions. Some of them are very complex. Some are pretty expensive. Some are both! Below are the two free tools I use most often for my own day-to-day testing.

Chrome

The simplest tool to use is the Chrome browser. As part of the Chrome Developer Tools, you have the option to introduce throttling.

The Chrome Developer Tools allow you to apply throttling in two ways:

1. Cap out the maximum bandwidth a session will use
2. Specify some latency.

Specifying latency is quite handy for most scenarios and you can configure your own settings. The only problem is that it will throttle with ideal conditions. Latency is 100% constant and no packet loss or any of the other issues described above are introduced.

The Chrome Developer Tools do a really good job of keeping track of page loads time etc. The bandwidth cap is quite accurate, and is an easy way to dial in your testing settings.

In the image below, you can see two custom throttling profiles as well as numerous presets. The one thing you will notice is that I have specified zero ms latency.

The only caveat with Chrome is that it is only useful for testing web applications. Having said that, browser-based web applications would normally make up the majority of applications you would want to test.

Clumsy

The Clumsy application allows you to introduce the kinds of issues that Chrome does not allow you to simulate.

The big advantage, for more advanced testing, is that Clumsy allows you to impose restrictions on all traffic at the transport layer, and not only for web traffic at the application layer.

Clumsy also allows you to go beyond constant latency by configuring the following options:

• Lag = Latency
• Throttle = Latency variance on a % of packets
• Duplicate, Drop and Out of Order also work on a % of packets

You can also specify to which traffic you want to apply the "clumsy-ness". For example, here I specified my default gateway as both the source and destination address to which the filtering is applied. First, you can see the normal Wi-Fi network performance:

Next, I enabled all network degradation options. You can see from the ping replies that the performance is now very erratic. At this level of disruption almost no traffic will flow successfully.

Now you're ready to dial in the desired amount of WAN emulation to benchmark your application. For reference I used the following settings to simulate a WAN link from Australia to South Africa. This is based on actual performance from the network.

When testing an application with this methodology we can still use the feature-rich Chrome Developer Tools, but now we have a "realistic" WAN emulation rather than simple bandwidth throttling.

Conclusions

For any system administrator, web developer, reverse proxy or VPN administrator, finding easy WAN emulation tools is extremely useful to establish how an application is affected by varying network conditions.

By setting performance benchmarks and functional thresholds, you can determine at which point the application actually breaks. This information can be used to size and scale Internet and MPLS links scientifically rather than just making an (educated) guess.