(or, Simulation vs. Emulation)

Sometimes you just have to use the right word. You know, like when people say, “I could care less,” when they really mean, “I couldn’t care less.” Cause if you could care less, that means you care some amount more than zero. But if you couldn’t care less, it means you care zero, cause you can’t care less than that.

Now, I’m not that guy who goes around at cocktail parties saying, “You know, it’s card sharp, not card shark.” Really, I’m not. OK, maybe I did that once. Or a few times. OK, I might be that guy. Not saying I am, just that it could be possible.

When it comes down to it, most people couldn’t care less if it’s sharp or shark, right? But when it comes to your enterprise application, it does matter that you get it right.

Of course, we know that testing under real-world conditions is important. Everybody knows that. We’ve seen what happens when you don‘t, and it’s not pretty. (See Network Impairments if you’re in doubt.)

You hear the terms “network emulation” and “network simulation” used a lot, sometimes interchangeably, but emulation and simulation are two different things. A network simulator uses software to imitate the behavior of a network. A network emulator uses hardware to imitate the behavior of a network. Hardware, software, who cares? You do.

The point of real-world testing is to precisely and repeatably reproduce network conditions in a controlled environment. So it stands to reason that you want a solution that can actually do that. Reproduce network conditions. Precisely. Repeatably.

A hardware-based emulation platform has the horsepower to do that. Pass all traffic through the impairment engine. All traffic. All speeds. All packet sizes. At line rate. Precisely and repeatably add delay in increments down to nanoseconds.

That’s what you need. You can’t afford to get in the middle of testing and discover your network simulator is creatively adding its own jitter or packet loss because it can’t keep up with the traffic. You need a solution that can dance all night.

So, now that you’re ready to bring real-world testing into your lab, make sure you get the right emulator – the one that can accurately reproduce the network in all its ugly reality. Because that’s the only way you’re going to know, instead of hope, that your solution really works out in the real world. Testing with network emulation means more stable solutions that perform as expected when the times (and the WAN) get tough. Wouldn’t it be loverly if everybody tested under real-world conditions with network emulation before release?

AKA Can the WAN whack your app? Soitenly!

Your application runs just fine on the LAN. You enable remote access and it slows to a crawl. Your local wise guy says, what do you expect, after all, the LAN is running on 100 Mbps or 1 Gbps Ethernet, but your WAN connection is a broadband service running 8 Mbps or so. So you increase the budget to add some bandwidth and see little or no improvement. The wise guy loses credibility, the users lose productivity and you lose sleep.

When it comes to application performance and transaction response time, it pays to remember that the LAN and WAN differ in more ways than one. There are actually Three Stooges lurking in the WAN: delay, loss and bandwidth. Individually they can cause problems. Collectively they can cause havoc.

When you have to resolve an issue, it’s important to know which Stooge is causing the problem.

Round trip time, also known as two-way delay, has a significant effect on throughput, especially when stateful protocols like TCP are involved. In one test, a file transfer from California to Asia with 400 ms of two-way delay could only achieve a 50 Kbps transfer rate, even though there was 2 Mbps of available bandwidth. When 1% packet loss was introduced, the transfer rate dropped to 20 Kbps. Increasing bandwidth can resolve some problems, but not this one. That’s focusing on the wrong Stooge.

Network emulation allows you to discover which Stooge is actually whacking your app so you can fix it the first time.

Fixing the problem is good. Avoiding it is even better. Network emulation allows you to test transaction response time and application performance under a variety of realistic network conditions, discover the primary contributors to poor performance, devise fixes to address them and then verify the fixes, all before deployment.

Beating the Stooges translates into reduced risk for your project, lower operating cost as you right-size your network, shorter development and QA schedules as you catch the issues early in the cycle, which means less time to deployment. A properly engineered and configured application means increased productivity for your organization, fewer tech support calls and improved user satisfaction, all of which establish a better competitive edge for your company.

Your mother always knows. The older you get, the more you realize how true it is.

You’re probably thinking your mother doesn’t know anything about networks. Telecommunications networks, that is. She probably had her own network that allowed her to know exactly what you had done before you even got home, so when you walked in the door she could say . . .

Is there something you want to tell me?
. . . and the next thing you know, you’re spilling your guts. You never knew how she does it, but it always seemed to work. She could give lessons to Homeland Security.

Sometimes maybe she would interfere and insist you do something you thought was totally unnecessary, like change your shirt or take a sweater with you or get a sandwich or something and you would roll your eyes and she would say . . .

You’ll thank me later
. . . and you’d realize later she was right, but you’d never admit it.

So, now somebody comes along and says you need to test your application under real-world conditions with a network emulator and you’re thinking that you already threw all kinds of traffic at it and stress-tested it and got all the kinks worked out and you really don’t need to bother with a network emulator because it’s going to mess up your schedule and besides, what could go wrong? Right?

Just remember what your mother said.

It’s for your own good
That’s right. What could go wrong? Plenty! The effect of delay across the WAN is multiplied when session-oriented protocols like TCP are involved. If your application is too chatty, dropped packets and retransmissions can bring it to a grinding halt faster than you can make up your bed. If buffer sizes aren’t big enough to handle reorder problems, they turn into dropped packet problems.

The truth is that if your solution hasn’t been tested under real-world network conditions, you have no idea how it’s really going to act, and that’s not a good thing. In fact, it’s a really, really bad thing. It can mean a failed launch, delayed schedules, productivity loss, finger pointing, loss of confidence in your department. Bad stuff, Maynard.

On the other hand, if you test under real-world conditions using network emulation, your application will be ready for prime time and anything the network can throw at it. Which is good, because when it comes time for the rollout, you don’t want it to crash and burn and then hear your manager say . . .
It looks like a tornado came through here

Listen to your mother. Even if she doesn’t know anything about networks.

AKA: Know what floats (and sinks) your boat

-Your test lab is like Lake Placid, a nice, calm spot that the most rickety boat can sail without a problem.
-The WAN is like the north Atlantic, a capricious, wild, treacherous monster that can sink the most rugged vessel.
-Your solution is the boat.

Wouldn’t you like to know if it will survive the storm before you put out to sea?

You’re building or launching a solution of some kind. It could be an enterprise application or a website or VoIP or video conferencing. One thing is certain – it will be used across a network, either the Internet or a corporate wide-area network. What isn’t certain is if it will work as expected once it’s launched.

Too often a test plan covers the expected traffic, but not the expected network conditions. PCs with scripts are set up in a test lab, or perhaps a traffic generator/analyzer is used to simulate hundreds of users hitting the server. But the test network is pristine 10/100/1000 Ethernet on CAT5. Nothing like the network it will be deployed on.

The WAN does bad things to applications. It adds delay in varying amounts. It drops packets or sends them down different routes so they arrive out of order. It flips bits when nobody is looking. The perfect storm of delay and impairments is out there, just waiting to sink your project when it goes live.

Kinda depressing, isn’t it? But you can change the story to have a happy ending. You can put your solution through the perfect storm before it ever leaves the test lab, find out what can sink it, and fix the problem before it even happens.

That’s what we do. We create the perfect network storm right in your test lab, without anybody getting hurt. How do we do it? We make a hardware-based platform that can accurately and precisely emulate real-world network conditions. Any speed, any traffic, any packet size. And we’re the only ones who can do that.

Just think. What if you could:
- Understand and predict the behavior of your solution under every possible network scenario before it goes live.
- Know if it will meet service level objectives.
- Identify the factors that will affect performance.
- Make changes based on data instead of guesswork.
- Be confident that your solution will support the performance, robustness and scalability your organization needs in the initial roll-out.

And think what your boss will say when you show him a plan that will:
- Reduce development schedules
- Reduce support costs
- Avoiding live troubleshooting and downtime
- Increase revenue and competitive advantage

He might even send you a thank you gift, like movie passes or something.

Bring the perfect storm into your lab, take the drama out of your job, and save it for the movies, where it belongs.

[Network Testing, Network Emulation, Network Impairments]

Call me what you want…just don’t call me late for dinner
You know how it is trying to do lunch. Half the battle is getting everyone to agree on a place. The other half is getting everyone to get to a stopping point at the same time so you can leave. Sumir says he’s almost done with the conference call, so Karen decides to respond to a few more emails. Sumir hangs up the phone and Karen says she has to type one more paragraph and Mark decides to go to the bathroom. Karen pops out of her cube, realizes everyone is waiting on Mark and has to be physically restrained from popping back in for one more email. It can take 15 minutes just to get everyone out the door.

If you do lunch with someone from another company it’s usually not as bad, since you just set a time and meet. Or so I thought. We picked a new deli close to her office where the Reubens were supposed to cause ecstatic visions. I was halfway through a transcendent encounter with my sandwich when Kim finally dropped into the other chair. I looked at her, munching in a serene but questioning way, at the cusp of enlightenment. She snagged a chip from my plate and said, “Rover.”

I took another bite and waited. She took another chip and continued. “ROVER is our new customer relationship management system. Stands for Remote Office something-or-other. It was supposed to streamline everything, order-tracking, support issues and all that while making it easier to work on the road or from home. Instead, it’s turned out to be a dog. It was painfully slow to start with, but last week they combined all the data centers into one facility in Denver and now it’s ridiculous. I got a call from our Portland sales team and tried to create a new incident record. It took two minutes just to log in, and an eternity to click through the screens. So, what’s good? Are the Reubens as wonderful as they say?”

Exuding an aura of pastrami-induced compassion, I gave her the other half of my sandwich and went to order another.

Her situation is not as unusual as it should be. Companies are developing and deploying distributed applications all the time without testing them against realistic WAN conditions. I’ve seen lots of reasons why this happens. The test plan overlooks the problems that can be caused by network impairments. Or they run a few test trials over their production network, usually after hours to prevent business disruptions, and have a false sense of confidence when they don’t see any problems.

Or they don’t realize that they can recreate actual network conditions in the test lab with an Anue Systems network emulator. It’s what we call network impairment testing or signal impairment testing. It lets you do to your application what the WAN is going to do to it, before you have hundreds of users like Kim complaining about your system. The cost of a network emulator is minor compared to what can happen when a system is deployed without network impairment testing. Productivity loss. Finger pointing between the network group and the applications group. Acrimonious meetings. Loss of confidence in your department. Morale issues among your staff.

It’s a shame, really, when, like karaoke, it’s completely preventable. It is possible to know in advance how your system works on a real network. To test during the relatively calm and rational time of development and testing instead of the high-visibility, company-wide exposure of a post-deployment crisis. To troubleshoot and identify performance and response-time issues early, when it is less expensive to find solutions and implement them.

That’s what we do. It’s nice working for a company that makes everyday life better for hundreds of thousands, if not millions of people. Spreading contentment and enlightenment. Kinda like buying a heavenly sandwich for everyone.

Metro Ethernet has simplified the deployment of enterprise Wide Area Networks (WANs) and reduced access and transport costs. Even so, traditional point-to-point circuits continue to play a significant role in enterprise networks in the 21st century. As a result, technologies have emerged to apply the simplicity and economy of Ethernet to the issue of private lines with dedicated bandwidth. Circuit Emulation Services (CES) and Pseudowire Emulation (PWE) have emerged as methods for carrying Time Division Multiplexing (TDM) circuits over a packet-switched network (PSN).

The benefits of transporting TDM over Ethernet are compelling. The CapEx and OpEx required to support TDM services can be lowered by reducing the cost and complexity of the equipment and by simplifying provisioning and troubleshooting. The solution benefits both top line and bottom line, driving sales with integrated services and reducing costs. It creates a sustainable business model for carriers, allowing them to offer a full range of communications and services, including end-to-end TDM services for enterprise, backhaul for wireless transport, or TDM access with interworking between Ethernet, Frame Relay and ATM. Cost savings can translate into price relief, easing budget pressure for customers.

The benefits and applications for CES all depend on the delivery of a low-delay, low-jitter signal over Ethernet. Anue Network Emulators allow test engineers to introduce realistic network conditions in a controlled and repeatable fashion to predict performance in actual networks. The Technology Several organizations address standards for circuit emulation, including the Internet Engineering Task Force, the Metro Ethernet Forum, the MFA (MPLS, Frame Relay, ATM) Forum and the International Telecommunications Union. Solutions address encapsulation of Nx64, T1, E1, T3, E3, OC-3, STM-1, OC-12 and STM-4 lines for transmission across IP, MPLS and pure-Ethernet. The public switched telephone network (PSTN) was built based on time division multiplexing.

• The analog signals from the phone are byte sampled 8,000 times per second, producing a 64 kbps digital signal, called a DS0 circuit. (8 bits X 8,000 samples = 64,000 bits.)
• Twenty-four DS0 circuits are grouped together in time slots to form a DS1 (or T1) circuit of 1.544 mbps. (64 kbps X 24 lines = 1536 kbps + 8 kbps framing and signaling = 1544 kbps.)
• Twenty-eight DS1 circuits are grouped to form a DS3 circuit of 44.736 mbps. (1.544 mbps X 28 DS1-circuits = 43.232 mbps + 1.504 mbps framing and signaling – 44.736 mbps.)
• A DS3 circuit is encapsulated in SONET framing to form an STS-1 circuit of 51.84 mbps.
• Three STS-1 circuits are grouped to form an STS-3 circuit of 155.52 mbps.
• Twelve STS-1 circuits are grouped to form an STS-12 circuit of 622.08 mbps. These circuits are transmitted synchronously, i.e. as a continuous stream of bits controlled by a common clock. As a result the delay is low and exhibits minimal variation.

In a T1, every DS0 has 64 kbps of bandwidth available to it at all times, whether it is in use or not. The good news is that it can always carry the 8,000 samples per second required to support a phone conversation regardless of what is happening on the other channels. (Guaranteed bandwidth and performance.) The bad news is that the bandwidth is not available for other uses when no phone conversation is taking place. (Inefficient use of bandwidth.) The packet-switched network, on the other hand, uses a shared medium to transmit data on demand. Packets are transmitted asynchronously, i.e. they are transmitted as required and bit-timing is synchronized per message, not based on a system clock. Idle applications don’t reserve bandwidth that can be used by other applications. The result is a more efficient use of the network, but also the increased likelihood for contention during peak usage times. Buffering to manage contention can introduce highly variable delay and occasional packet loss.

Circuit Emulation Service (CES) is the process of transmitting TDM signals on a PSN transparently. At the source, TDM frames are converted to packets and transported in the core as packets. The packets are converted back to TDM frames at the destination, since the endpoints use traditional TDM equipment. CES involves:

1. Encapsulating data into packets.
2. Delivering synchronous timing information across the asynchronous PSN.
3. Ensuring that the packets are delivered with the low levels of loss and jitter required by TDM networks.

ES performance is affected directly or indirectly by four main characteristics of the packet network:

• packet loss
• packet mis-order
• packet network latency
• packet delay variation (PDV), also known as packet jitter

Since TDM is typically used to carry voice or video, disruption to the signal caused by conditions found in packet networks can have a significant effect on the user experience. Dropped voice/video frames are obvious listener/viewer as cutouts or distortion. High latency and mis-order can result in dropped packets if they don’t arrive before the buffer is transmitted.

Rapid failure protection is a characteristic of SONET networks not typically found in a PSN. If one path in a SONET network fails due to unacceptable bit error rates or loss of signal, the data is switched to an alternate path within 50 milliseconds. PSNs use routing protocols that typically converge on a new network topology in seconds rather than milliseconds, unless using a protocol designed to optimize failover response.

Testing Considerations
CES solutions employ various techniques to compensate for the effect of the PSN on TDM signals.

• Buffers are used to compensate for packet mis-order and PDV. However, since a buffer actually increases the delay in a system, care must be taken to achieve the optimum balance between quality and performance.
• Packet Loss Concealment (PLC) is used to mask the effect of intentionally or unintentionally dropped packets. Simple solutions insert silence or replay the last received frame. Others use algorithms to interpolate values based on the data in the previous and following frames, if available.
• Fast re-route protocols are used to reduce the delay encountered in PSNs when a path fails and route-forwarding tables are updated.
• Some CES standards specify the tracking and reporting of performance metrics and status/alarm indicators to assist in delivering and maintaining an acceptable the level of network performance.

In a Perfect Word: The Performance Baseline. The first step in testing CES is to evaluate it in a test lab under optimum conditions. The infrastructure of the test lab should provide an environment with no packet loss, no packet reorder and minimal delay. As all aspects of the solution are tested, such as packet loss concealment, buffering, or protection failover, the maximum performance limits of the system are determined. These limits establish the baseline which will be used for comparison against the results of tests in a more realistic environment.

Real-World Testing: The Reality Check. CES is not delivered on an ideal network. Packetized TDM signals run in combination with other traffic through multiple devices and across infrastructure that spans significant distances. The result is an environment that presents some level of delay, impairment, and bandwidth limitation, the severity of which depends on how well the network is engineered.

To deliver CES with confidence, test and debugging iterations must be performed under the conditions in which it will actually be deployed, and also under worse conditions to account for equipment failure and disaster conditions. Rather than test on a live network, which is expensive and impractical, real-world testing is achieved by using network emulation in the test lab.

Each of the tests performed during baselining are performed again with a network emulator creating impairments such as packet loss, delay, bit errors, sequence errors or duplication in a controlled fashion. The emulator can also model the effects of high traffic load by constraining available bandwidth. The actual delay, impairment and bandwidth values used are determined by various methods.

Before and After. Features that are susceptible to specific impairments should be baselined and then tested in the presence of the impairments known to affect them. As issues are revealed, troubleshooting uncovers root causes and facilitates the debugging of applications or tuning of network parameters. This iterative process is required to assure robust solutions and minimize support costs.

Buffer size. Buffers are targeted specifically to addressing issues of mis-ordered packets and PDV. Quality or performance scores from the baseline tests should be compared to results as re-order and jitter are applied in a controlled fashion. As breaking points are established, adjustments to buffering can be tested to known values to discover optimum buffer design and configuration.

Packet Loss Concealment Algorithms. PLC is targeted at packet loss. Implementations are tested against multiple loss profiles, from periodic and random loss rates to burst loss events associated with traffic congestion, route failure and route flapping. Performance thresholds are established for each loss profile.

Timing Distribution. Circuit Emulation requires timing signals to be distributed within packets instead of at the physical layer as is done with SONET/SDH. As packets are delayed, dropped or otherwise impaired, timing signals are affected and synchronization can be lost. Synchronization frequency and phase then needs to be recovered.

Failure protection. Since CES is often used for real-time applications such as voice and video, performance of failure protection is important. In addition to validating acceptable fail-over times for loss of signal, error and loss should be ramped up to verify that fail-over is initiated at proper impairment thresholds.

Statistics, status and alarms. A successful CES implementation depends on management of PSN impairments that adversely affect TDM applications. The solution must accurately track and report metrics such as sent/received packets, errored data blocks, errored seconds, packet loss, mis-ordered packets, misconnection, malformed frames, PDV, buffer overruns and underruns, and others. This functionality is tested by introducing the relevant impairments in a controlled fashion and verifying the counters, status and alarm indicators reflect the impairment.

Conclusion
A successful CES solution requires testing under real-world conditions to guarantee that it can provide TDM-like performance by compensating for conditions that occur in IP networks. Using Anue Network Emulators enables engineers to predict application performance, thereby reducing risk, accelerating time to market, and allows deployment with fewer problems and more confidence.

The migration of voice traffic from the traditional public switched telephone network (PSTN) to IP networks has been gaining momentum in recent years. Protocols supporting Voice over IP (VoIP) have matured and market acceptance continues to grow.

Large enterprises led the move to a converged network supporting both data and voice, closely followed by mid-sized business. Although a significant capital outlay was required up-front, the business case was compelling. Cost is reduced for network management and support and eliminated for long-distance and overseas calls. In addition, productivity can be increased through features such as unified messaging, advanced call routing and application integration.

Acceptance of VoIP has reached the small business and consumer market, with systems available at electronics retailers and integrated services offered by telcos and cable companies. The term VoIP can even be heard in radio and television commercials.

A successful VoIP solution must provide quality of experience for the user by compensating for negative conditions that occur in IP networks. Anue Network Emulators allow test engineers to introduce those conditions in a controlled and repeatable fashion to predict quality of experience in actual networks.

In addition to the Internet Protocol (IP), there are a number of other protocols that make VoIP possible. They can be divided into call setup/signaling and transport of the call itself.

Transport Control Protocol (TCP) is the reliable-transport partner in the TCP/IP protocol suite. As a result, it is used to encapsulate call signaling protocols to verify that the call is established. However, TCP has too much overhead to efficiently transport the actual call. User Datagram Protocol (UDP), a connectionless transport protocol, is used to carry the voice packets.

During call setup, a TCP connection between the two endpoints is established. This can involve the use of proxy, registration and redirect servers to locate the IP address of the called party. Once the TCP session is in place, the ring (called party) and ring back (calling party) tones are triggered and the parameters governing the call are negotiated. These can include master/slave settings for controlling the session, choice of codec (coder-decoder) and compression scheme, the type of call (voice/video conference) and security settings, such as encryption. Call setup/signaling protocols include H.225/Q.913, H.245, H.323, SIP, SDP, MGCP and MEGACO.

Once the call is established, the conversation is encoded or digitized (converted from analog signals to bits), compressed, and split into groups of bytes to be encapsulated into payloads for transport across the network. It may also be encrypted. Real-time Transport Protocol (RTP) is used to maintain packet sequence, since UDP doesn’t have the sequencing support provided by TCP. Real-time Transport Control Protocol (RTCP) is the companion protocol that provides out-of-band control information for an RTP flow. RTCP can provide feedback on quality of service (QoS) for the flow to a VoIP application, which can adjust differentiated services (DiffServ) parameters for the flow.

VoIP requires the seamless operation of many protocols and functions. The conversation must be sampled, coded and decoded, compressed and decompressed, packetized and depacketized, encrypted and decrypted. The transport must have the capability of delivering the required bandwidth at the appropriate service level. Signaling is required to establish the connection and negotiate settings. Most importantly, the system must be able to deliver high voice quality over the deployed infrastructure. And all of this must be delivered in the presence of data traffic.

In a Perfect Word: The Performance Baseline:The first step in testing VoIP is to evaluate it in a test lab under optimum conditions. The infrastructure of the test lab should provide an environment with no packet loss, no packet reorder and minimal delay. As all aspects of the solution are tested, such as signaling capacity, voice capacity and voice quality (PESQ/PSQM MOS scores), the maximum performance limits of the system are determined. These limits establish the baseline, which will be used for comparison against the results of tests in a more realistic environment.

Real-World Testing: The Reality Check: VoIP is not delivered on an ideal network. It travels in combination with other traffic through multiple devices and across infrastructure that spans significant distances. The result is an environment that presents some level of delay, impairment, and bandwidth limitation, the severity of which depends on how well the network is engineered.

To deliver VoIP with confidence, test and debugging iterations must be performed under the conditions in which the solution will actually be deployed, and also under worse conditions to account for equipment failure and disaster conditions. Rather than test on a live network, which is expensive and impractical, real-world testing is achieved by using network emulation in the test lab.

Each of the tests performed during baselining are performed again with a network emulator creating impairments such as packet loss, delay, bit errors, sequence errors or duplication in a controlled fashion. The emulator can also model the effects of high traffic load by constraining available bandwidth. The actual delay, impairment and bandwidth values used are determined by various methods.

Before and After: Features that are susceptible to specific impairments should be baselined and then tested in the presence of the impairments known to affect them. As issues are revealed, troubleshooting uncovers root causes and facilitates the debugging of applications or tuning of network parameters. This iterative process is required to assure robust solutions and minimize support costs.

Quality of Service: VoIP is sensitive to packet loss. While packet loss concealment (PLC) algorithms can help mask the effect of missing packets, there is a threshold beyond which PLC is ineffective. QoS is employed to guarantee delivery of VoIP with minimum latency. Different schemes may be used depending on the implementation. VoIP queues must be able to deliver packets with minimum loss, even in the presence of other, lower priority traffic. Bandwidth oversubscription should be tested to verify that lower priority traffic is dropped to accommodate VoIP. Impairment profiles can be configured based on where the QoS is implemented, such as in the experimental bits in the MPLS header (core network traffic engineering), the DSCP/ToS bits in the IP header (aggregation-level QoS) or the 802.1p-bits in the VLAN tag (DSLAM or PON QoS).

Voice quality: Voice quality can be affected by network jitter, sequence errors, jitter discards (frames discarded due to arriving too late) and packet loss. Implementations are tested against multiple loss profiles, from periodic and random loss rates to burst loss events associated with traffic congestion, route failure and route flapping. Acceptable quality thresholds are established for each loss profile.

Buffer size: Buffers are targeted specifically to address issues of mis-ordered packets and jitter. Quality or performance scores from the baseline tests should be compared to results as re-order and jitter are applied in a controlled fashion. As breaking points are established, adjustments to buffering can be tested to known values to discover optimum buffer design and configuration.

PLC Algorithms: PLC is targeted at packet loss. Implementations are tested against multiple loss profiles, from periodic and random loss rates to burst loss events associated with traffic congestion, route failure and route flapping. Performance thresholds are established for each loss profile.

Performance Thresholds: When baselining performance, packet loss and sequence errors caused by the system under test may increase as thresholds are reached. When testing with impairments, the amount of impairment injected should be compared to the impairment measured by the analyzer to compare performance thresholds to the baseline thresholds.

In addition, performance thresholds under realistic conditions are used to determine the service level parameters required when deploying VoIP over an existing enterprise network. If additional bandwidth or a service level increase is required, it must be known before deployment to avoid loss of productivity and possibly revenue.

In conclusion, a successful VoIP solution requires testing under real-world conditions to guarantee that it can provide capacity and quality by compensating for conditions that occur in IP networks. Using Anue Network Emulators enables engineers to predict application performance, thereby reducing risk, accelerating time to market, and allowing deployment with fewer problems and more confidence.

Business Continuity • Disaster Recovery • Remote Backup • Storage Extension • Proof Of Concept

Many major corporations are in the process of migrating their data centers from their back office to large regional data centers.
IT departments are legitimately concerned that such moves will adversely affect their critical business applications.
In fact, a significant percentage of applications will experience quality-of-service (QoS) and qual-ity-of-experience (QoE) problems.
What causes these problems?

• An increase in application response times due to added network latency and im-pairments. These are the most significant factors that will affect the new network’s performance. Application latency can be much greater than network latency. Add-ing even a modest amount of delay onto a network (

• When data centers are relocated, new services are often added. These include access from the home or the road by us-ers with low-bandwidth and high-latency network connections.

• Many modern applications logically link objects across the network. If any one object is moved, response times can in-crease in a significant manner.

• New and additional network equipment in-creases the potential for latency and ex-cessive packet jitter.

In order to ensure a new network configuration will perform to acceptable levels of operation, you must:

• Create a virtual environment that will emulate the conditions of the new net-work.

• Establish pre-move baseline performance levels.

• Use an Anue Network Emulator to inject projected latency and impairments to the virtual network environment.

This will allow you to identify applications that will be impacted by the data center migration. Some applications will require tuning to achieve acceptable response levels. Some will fail altogether.
Once fixes are made and acceptable performance levels achieved, the virtual test network will provide a level of confidence and prove that the migration will succeed with minimal risk to busi-ness operations.

Remote Backups for Business Continuity & Disaster Recovery
Remote backup centers have the same issues. Be sure to thoroughly test for performance from these data centers. Otherwise, when the main data center goes down, or access to it fails, and data access switches to your backup center, your business will not be able to continue in a satisfactory manner.
Succeeding in Server Migration
With careful planning and testing, IT organizations can successfully migrate and upgrade their data center operations.

Case Study
A leading information technology services provider began a major project to move its client’s mainframe systems to a central service center 1000 miles away. But before they could perform the migration it was critical to test the impact of such a distance on mainframe applications. Using network emulators from Anue Systems, the team introduced delay into the live production environment between the users and the mainframe, exactly emulating the setup they wanted to implement with the proposed network. Transmission latency times of up to 80msec were emulated. Other impairments included throttling down the bandwidth to 40Mbps, reordering and corrupting Ethernet frames, and introducing packet jitter. All of these tests were designed to match impairments that could occur on the deployed network.

The initial test showed that their client’s critical business applications – as well as their ODBC (Open Data-base Connectivity) and JDBC (Java Database Connectivity) applications – did not work with the delay that the emulated distance introduced. With 20msec of latency their applications were straining. Tasks that normally took 60 minutes to run took 100 minutes. At 80msec, some applications stopped working entirely. Fortunately, the team was able to detect the failure in real time and dynamically eliminate the delay to avoid end user problems on the live network. The team then focused on tuning and tweaking these applications to operate with the several milliseconds of delay associated with the 1000-mile distance. Once optimized, they re-tested the applications using the emulator and validated that the performance was acceptable to end-users.

Satellite communications have long been subject to noticeable signal delays. The lags in satellite TV broadcasts and phone calls are examples that many of us have experienced first hand. Traveling at the speed of light, it takes over 200 ms to reach geosynchronous orbit (GEO) and back. Even using satellites at low earth orbit (LEO) of 200 to 400 km, transmission times between two terrestrial locations can be significant.

Next generation satellite communications technologies are now being developed using much higher bandwidth than ever before. Defense applications, in particular, will use gigabit, and even ten gigabit, data rates. In some cases, “free space optics” is being researched as a way to transmit high bandwidth signals between satellites in space. As a result of higher data rates, emulating and testing satellite communications using fiber optic cables in a traditional lab environment is increasingly common. Anue Emulators, with their precise, controllable and enormous delay capabilities fit this requirement perfectly.

Applications such as collaborative computing, distributed CAD/CAM, scientific visualization, remote sensing data relay, messaging and navigational services, electronic publishing, and others, create demand for new satellite telecommunications networks. The effects of dynamic variation of data path length and related jitter must be
considered and tested for with each new application to assure it will work before released to consumers.

Anue Network Emulators are an essential tool for satellite communications testing, providing variable path delays, jitter simulation, and dynamic error introduction, acting just like a real satellite network link. High-bandwidth satellite networks provide a growing variety of network services. Before these services can be deployed they must be thoroughly tested on the ground. Since satellites are frequently in orbits that are great distances apart, it is essential to emulate those distances while testing on the ground.
Round-trip transmission times to and from geosynchronous orbit – where satellites park some 22,300 miles above the equator – are approximately 250 msec, a considerable delay for a communications network. The satellite’s position may not be constant and, in fact, because they communicate with both ground stations and other satellites, there will be transmission paths of many different distances to consider. Unlike a fixed length of fiber optic cable, the Network Emulator is like a variable-distance cable without dB loss, so it can be used for all-distances testing rather than specific distance testing.
The communication satellite may be a moving object with a continuously varying distance to the point that it communicates with. A Doppler effect simulation feature requested by Anué customers emulates the variations in distance with a continuous smooth slew of delay distance. One of the Doppler effects is receiver signal jitter. A receiver expects a pulse of data at very regular intervals. The receiver’s eye pattern determines which signals it finds acceptable. Should the edge of a signal change at a time inside the eye pattern the receiver may go out of synchronization and communication might be temporarily lost. As the transmitter receiver pair move relative to each other the regular intervals may not be regular enough.

The Network Emulator forces the jitter to see how the receiver and in fact the application reacts. The impact on applications of long delays, jitter, Doppler effects, and other impairments, can be critical and must be tested before any satellite-based communication system is launched. After launch may be too late, that is why an Network Emulator is critical to the satellite communications testing strategy.