By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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.
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.
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.