Setting up WAN environment: Open Source

Introduction

In the context of designing application performance from ground up every aspect of end user usage needs to be considered before the application is rolled out to production. One topic of interest is the inter connectivity of the computing systems and end user connectivity to the computing systems in the production. The paradigm shifts in interconnectivity of computing systems in the internet age has led applications to be accessible over internet. In lieu of corporate connectivity WAN (Wide Area Network) are predominantly being put to use by enterprises where consolidation; integration and globalization is the name of the game. A dedicated line between two corporate locations is not a dream anymore; it is a reality.

Predominantly it has been observed that applications and the underlying infrastructure being deployed have not been built with WAN in mind so the end up failing miserably (w. r .t. performance) when deployed. Enterprises want to validate if the application performance meet their desired QOS and SLA in the new context. This article briefly introduces the context of WAN over TCP, outlines the different test types which need to be carried out and cheat sheet on how it can be achieved using traffic control utility using a Linux box.

WAN over TCP TCP was not built with WAN in mind. WAN brings with it its own bag of challenges, low network bandwidth and high latencies. The following items form the basic limitations of TCP over WAN TCP Window Size Window size is the maximum amount of data which could be transmitted over a network connection before there is a need to receive acknowledge from the receiver. Typical TCP window sizes are limited to 65Kbyte; in the perspective of WAN available window sizes are high (Window size is calculated as a product of Bandwidth*RTT e.g. Windowsize for a satellite connection = 45Mbs * 540ms = 3038Kbytes). This has resulted in large unutilized bandwidth; RFC1323 which some operating systems have implemented help to over come this limitation. Slow Start TCP sessions are slow starters; they require a higher warm up (ramp up) time. This results in very poor performance for short duration sessions. Inefficient Error Recovery and Packet Loss TCP was built with resilient error recovery; this causes the entire stream to be transmitted if there is any lost portion. Packet losses can occur due to intermediate network connectivity or routers can drop the packets due to congestion. Each such retransmission would lead to non-optimum usage of the available bandwidth coupled with penalties due to high latencies and slow start.

WAN Test types To simulate WAN environment inside a test lab (LAN) the following capabilities are required • Throttle Bandwidth : Recreate a WAN link by restricting throughput on the LAN link • Network Latency: Varying time taken for a bit to traverse the network • Network Errors : Packet loss and packet corruption • Jitter: a random time variation in the arrival of packets A list of test types which needs to conducted to ensure accurate simulation of WAN inside lab(LAN) environment Latency Testing Time it takes in milliseconds for an IP packet to cross the WAN on the application under test with respect to application response time. The latency in real time is determined by geographical distance, available bandwidth and quality of network. Packet Loss This will help to determine the application response time and survivability of losing IP packets; we would also get insight into the application behavior due to network timeouts. Line Error Testing This will introduce line-level bit errors which in real time could be caused to hardware failures or interference as data packets travel through the WAN cloud. Link disconnection Testing The effects of intermittent physical breakdown between client and server; this will rule out any side effects such as data loss. Packet reordering, duplication and fragmentation The objective of the tests is to understand the application performance due to the effects of packet arrival order, packet duplication and fragmentation.

Simulating WAN in a Lab The clients should be connected to a delay router which in turn connects to the server. The netem (network emulator on a Linux box) can be controlled by traffic control utility (tc is part of iproute2 packages). Tc has command line options which can be set by providing appropriate values. The table documents the options available which help to simulate the WAN according to desired characteristics. Option Description Bw Bandwidth to be throttled bits/sec Delay Delay (milliseconds) Jit Random jitter in milliseconds Loss Random packet loss (in %) Corrupt Packets corrupted (in %) Dist Networks can emulated with uniform, normal, pareto, paretonormal distribution Sample command line arguments: tc qdisc add dev eth0 root netem delay 200ms tc qdisc change dev eth0 root netem loss .1%