WAN optimization and bottlenecks: Is the WAN really the weakest link?

"How much traffic" is no longer a good enough measure of WAN bandwidth. In this tip, Carrie Higbie looks at how today's ever-increasing expectations for data transfer rates require increased attention to WAN optimization, and suggests how applications-level traffic monitoring can lead to better WAN optimization strategies.

Carrie Higbie
Many years ago when I started in this industry, 9.6 baud lines were "new" and considered high speed(ish). When we looked at network speeds, we were stuck with the speed of the WAN as the slowest link. Many said that there was no need for 10 Mbps network speeds because the WAN circuits were much smaller. Back then, of course, we were using shared media networks, polling and hubs. How's that for a blast from the past? The Internet didn't exist yet (commercially, anyway), and billboards were the latest and greatest thing. What we do with computers has changed drastically in a relatively short period of time.

Bandwidth and throughput have certainly changed. I am not talking only about T1 lines. As an example, the winners of the bandwidth challenge at the 2005 supercomputing show transferred physics data at a rate of more than 150 gigabits per second -- equivalent to downloading more than 130 DVD movies in one minute. Today's ever-increasing expectations for data transfer rates require increased attention to WAN optimization.

WAN circuits and zero-frame calculations
In an era when WAN throughput exceeds much of the LAN throughput (or at least has the potential to do so), it is important to address what speeds are needed, and for what applications. How should a company manage its WAN circuits to get the most bang for the buck? First, we must understand that WAN traffic can differ from LAN traffic in many ways. From the type of packets to the payload and the routing information, WAN packets and protocols are developed to fly the information around the WAN.

SPECIAL REPORT

WAN optimization -- Benefits and options
Technologies are emerging to allow users to manipulate WAN traffic for better efficiency and throughput. Our special report examines the options:
>> WAN optimization strategies: Making the right decision
>> WAN optimization: Making the business case
>> The ABCs of WAN optimization >> Application acceleration: An introduction to data reduction
>> Application acceleration: Compression and centralization >> WAN optimization and bottlenecks: Is the WAN really the weakest link?
Earlier WAN communication circuit sizing was based on probability of zero frames. This number also helped determine buffer size in the hardware. The idea was to determine the size of your data transfers and number of users -- and after figuring in buffers and the like, you could determine the probability that the WAN link would have zero frames. The numbers were checked against various circuit sizes until you reached a circuit size that you could live with, both financially and in terms of support for your data transfers.

Bear in mind that data does not mind retransmissions here and there, but adding VoIP and real-time video applications changes the WAN outlook. A few retransmitted voice frames can be a disaster. The same thing holds true for any frames that end up in the bit bucket. So the challenge of taking care of WAN traffic goes above and beyond the probability of zero-frame calculations.

Monitoring bandwidth
Thankfully, to help with these calculations and throughput tests, today there are many tools such as traffic shapers, bandwidth managers and simulators (to help with modeling). When you look at WAN links, you also need to know what types of services will be using them -- for instance, video streaming and voice will need a dedicated minimum amount of bandwidth at all times. You can increase your bandwidth, which may be expensive, or use it more effectively (the better option). My favorite bandwidth manager and traffic shaping software is by Packeteer.

Speeding up traffic
One misconception is: "I don't need a faster network; my WAN circuit is a T-1. Since it's a bottleneck, all I need is 10 Mbps." That's like saying that a drive from Los Angeles to New York has a portion where the speed limit is only 10 mph, so we might as well drive the entire way at 10 mph. There are certainly lots of communications that do not happen on your WAN link.

There are also things that happen on the WAN side to speed communications above and beyond those in a LAN. These include such things as Classless Inter-Domain Routing (CIDR), also called classless routing, in which the ISP answers for all IP addresses in its range. This speeds up packet processing and is part of the reason that http headers are being recycled for VoIP communications using SIP technology.

We also now have the ability to move traffic based on MPLS information and other application information, allowing us to prioritize this information. Queuing and buffering use consistently higher-speed memory. Many of the functions are now wire speed (in other words, they happen in firmware rather than software), which makes them operate much more quickly.

It is true that LAN communications may be faster than WAN circuits, but in today's networks, that is not always the case. It is also important to note that with the enhancements in routing, packets move much more efficiently on circuits than in the past. Routers even communicate route information much more efficiently than before. It is also true that in most instances, not all users will use the Internet at the same time.

Applications-level traffic monitoring
The reality is that for many years, the WAN was the single biggest bottleneck. Higher-speed circuits were largely unaffordable. This has changed dramatically over the last five years, but we still want to maintain the best and healthiest network possible in both local and wide-area portions. In order to do this effectively, we need to know much more than "how much traffic." We need to know what type of traffic at an applications level.

This is critical because we will still have buffers that discard packets when they are full, especially during crunch times when there is a lot of traffic. Average utilization is a poor statistic as noted above. But with RMON and some other tools used for modeling, coupled with actual traffic reports, we can come much closer to properly sizing our circuits. In the following example, for instance, we are looking at one interface for company "X."

We can see various statistics in the graph; most important, we can see the maximum traffic by hour. If you look at the "average" line and then look at the maximum lines, you will see very different results. If you plan for averages and then add real-time applications such as voice or video, this can worsen problems with links. It is also important to note what scale the utilization is using when you pull your percentages. In this example, we can clearly see when most people get to work and start getting emails, go to lunch, and so on.

Now contrast the graph above with the following one:

This graph shows a circuit that is highly overtaxed and overused. The graph is for the same multi-site company, but a different circuit. Now we see that it would matter if voice were added to this circuit as opposed to one of the other available circuits. It is also apparent that managing traffic on circuits can make a big difference.

WAN optimization options
What are your options? Obviously you have to know what your traffic is and what the patterns are before you can make any decisions. Any time a circuit is overused, like the one above in the second figure, you are bound to have dropped connections and less-than-desirable voice communications.

Options include increasing your speeds, adding supplemental connections and tailoring where traffic goes based on application, IP address or type of service. You will also want to make sure the LAN is healthy so that you don't have frequent retransmissions depleting network resources. In the examples above, we directed all voice traffic to the first interface because it had the lowest use. The second was data only, and no new services were added; in fact, we supplemented the latter with a second circuit.

When looking at utilization, the study should encompass 30 days. This ensures that end-of-month processing and other once-in-a-while applications are taken into consideration. Utilization should never be judged based on a day's or week's worth of traffic. Understanding your WAN traffic patterns and options will increase multi-site reliability and ensure that you are paying for the right balance of bandwidth and performance.

About the author:
Carrie Higbie, global network applications market manager for The Siemon Company, has been involved in the computing and networking industries for nearly 20 years. Carrie has taught classes for Novell, Microsoft and Cisco certifications, as well as CAD/CAE, networking and programming on a collegiate level. She serves as the "Preparing your network for VoIP" expert on SearchVoIP.com.

This was first published in July 2006

Dig deeper on Managed services

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchNetworking

SearchUnifiedCommunications

SearchTelecom

SearchSDN

Close