Welcome!

Open Source Authors: Bruce Johnston, Colin Walker, Reuven Cohen, Timothy Fisher, RealWire News Distribution

Related Topics: Open Source

Open Source: Article

An Inexpensive Network Emulator for Testing Applications

Pre-deployment application behaviors

This article presents a simple and inexpensive methodology for predicting the performance of a client/server application over a wide area network. A network emulator, placed between the client and server, is used to vary key network properties, such as latency, bandwidth and packet loss. This method is not meant to replace extensive network modeling tools such as OPNET or Load Runner, however, it can provide developers with a simple way to explore the behavior of applications over a wide area network before deployment. For example, developers will be able to determine performance over a dial-up line or low-speed frame relay circuit.

The emulator uses the Linux operating system on a PC with built-in emulation and queuing utilities. The PC is configured to operate in "bridge" mode, which eliminates IP readdressing requirements. Performance of the emulator was validated using tests detailed in the sidebar "Network Emulation Details and Validation."

Bandwidth
Bandwidth provides a measure of the link capacity and is usually specified as bits per second (bps) or bytes per second (Bps). Increased bandwidth allows more data to flow over a link in the same amount of time.

When circuits are added in a series, the bottleneck is the link with the slowest bandwidth. For example, if the network path consists of a 128Kbps circuit, linked to an OC-3 (155MBps) backbone, and finally a DS-3 (45Mbps), the network bottleneck is the 128Kbps circuit - meaning it's not possible to push data through the total circuit faster than 128Kbps.

The bandwidth of the network emulator represents the slowest possible link in the circuit path. Since most circuit paths within the ESN will be symmetrical, identical bandwidth parameters will be applied to incoming and outgoing packets. Different bandwidths could be applied to simulate links such as asymmetrical digital subscriber lines (ADSLs).

Network Latency
Latency is the measure of the time for a packet to traverse the circuit path, and is usually expressed in terms of milliseconds. Each circuit, router, switch and other equipment within a circuit path increases the latency. Wide area network circuits account for the largest part of the network delay. The equipment usually adds less than a millisecond per device.

Table 1 shows typical latency values for each component. The values for applications (A and B) vary widely and are application dependent. This test scenario does not include these values, although it is recognized that network latency could have an impact on the overall performance. For example, if the latency exceeds an application retry timeout threshold, the application may request unnecessary retries, which could result in increased traffic and poorer performance overall.

From Table 1, it's clear that the wide area network links contribute the largest delay in the total latency. The network emulator applies the total latency (expect A and B) to the circuit path.

The "ping" utility measures round-trip delay, which is the total time for a request and answer to travel a circuit (i.e., out and back time). But path delays may not be symmetrical. Tools, such as the "one way ping" utility from the Internet end-to-end initiative, can be used to measure the link in one direction, but they require additional equipment and software.

ESN uses Cisco's proxy ping utility to measure round-trip delay. Infovista retrieves, stores, and trends this information, which creates the performance measuring baseline. The network emulator can apply delay to both incoming and outgoing packets to simulate asymmetrical delays. To simplify testing, identical delays will be used.

Bandwidth Delay Product
Application performance over a wide area network is limited by both latency (delay) and throughput (bandwidth). For example, the link may have low latency, but not enough capacity to support the application. Similarly, the link may have a lot of bandwidth (e.g., satellite circuits), but too much latency. (This second problem is also known as the "long, fat pipe" problem, which affects TCP performance.)

Each application may require different bandwidth delay products (BDP) (See Table 2). For example, an interactive, console-based application requires very little bandwidth and the limiting factor is the latency. As the interaction between the client and server increase, both factors may become important. Bandwidth Delay Product is measured in terms of (b/s x s) bits. In order to fully utilize a circuit, the TCP buffer should be at least the BDP.

Packet Loss
Not all packets reach their destinations. TCP can detect dropped packets and ask for a retry. However, this process slows performance. Packet loss ratio should be less than .1%. The network emulator can implement packet loss algorithms, but there are no plans to map application behavior over various packet loss ratios.

Testing Architecture
Figure 1 depicts the test architecture and is equivalent to Figure 2.

There are three zones that are referenced in the following discussions.

The following describes the components for each zone:

Zone 1: Remote Server End

  • WAN Circuit: Connects remote site to the network backbone
  • LAN (switches, hubs): Local area network
  • Equipment: Routers, firewalls, security devices
  • Application, server (computer, application): Varies greatly
Zone 2: Network
  • WAN: Network "cloud" that includes
    - Backbone transport
    - Associated WAN equipment (routers, switches, etc.)
    - Based on service level agreement
Zone 3:Client End
  • WAN Circuit: Connects remote site to the network backbone
  • LAN (switches, hubs): Local area network
  • Equipment: Routers, firewalls, security devices
  • Application, client (computer, application): Varies greatly

More Stories By Stu Mitchell

Stu Mitchell is the Enterprise Services Network Manager for the Department of the Interior, where he manages a network supporting 90,000 federal employees and 100,000 volunteers. Stu has worked in Interior for 18 years, including 11 years with the National Fish and Wildlife Forensics Laboratory. He holds a Bachelor of Science degree in Electrical Engineering degree from Virginia Tech and is a Certified Information Systems Security Professional.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.