Bandwidth Management on WANs

For managing bandwidth, the basic requirement is knowledge of the exact amount of bandwidth each application consumes. It sounds easy, but actually it isn't. You'll have to get into knowing the average packet size used by applications that use your WAN link. How often is that application used? Is it often enough to merit reserving certain bandwidth just for it or does it use the link only during certain time of the day? 

There can be other reasons for managing bandwidth as well. Take server consolidation for instance. This concept is meant to tackle the problem of server proliferation in organizations by reducing the total number of servers and using fewer and more powerful ones. Here, in some cases, it might be more cost effective to move most servers into a data center, and connect to it through WAN links. So, what was being processed locally at individual offices and plants would be done remotely over WAN links. This would really require proper bandwidth management. 

Another factor that can squeeze your WAN link out of its capabilities are the security threats-worms, viruses and denial of service attacks have picked up like anything over the past year. They're enough to congest a LAN, so imagine what would happen to your WAN.






Possible Solutions



Network administrators use various tools through which they can control traffic over clogged links on the network. This can be done at the router level or using specific solutions. 

The solution can be divided into three major parts, namely, detecting and analyzing application traffic, controlling the same and finally, compressing it so that more bandwidth is available.






Detecting and Analyzing Application Traffic



So, the first step in bandwidth management is to find out what is running on the network. Various tools are available that give you a proper breakup of your bandwidth usage by application. They can give you reports based on a range of variables such as HTTP classification based on URL or MIME type, IP addresses, MAC addresses, address ranges, subnets, QoS markings such as Diffserv, MPLS, IP CoS/ToS and IP precedence. Once you have this data, it's time to start controlling.






Bandwidth Control and Compression



Control can be exercised using a host of options such as policies, queuing and packet marking. Policies vary depending upon what kind of control you want. These could be based on dynamic user based link partition, application based, discard and no admittance, or simply ignore policy. 

You may, for instance, want to allocate certain amount of bandwidth for certain users, or block certain IPs from communicating. They can take care of time sensitive traffic such as VoIP by providing such traffic dedicated bandwidth. 



Queuing involves holding up traffic at the WAN link based upon various policies and controls, and passing only priority traffic. Though a good mechanism, but it suffers from serious bottlenecks such as packet dropping if the queues become too long. Finally, there are packet marking techniques to maintain the quality of service such as IntServ, DiffServ and
MPLS.

The next logical step after control is compression. System administrators can compress mission critical traffic before leaving it free on the WAN network in order to gain bandwidth and faster transfer. Though it sounds simple at the surface level, it is quite a task to identify the application, choose the correct compression method for the same and apply it in real-time.

There are various tools available that let an organization manage network traffic at the router level. For example, Cisco routers have a lot of bandwidth management features, which can be used depending upon the kind of applications you want to manage. If it's a VoIP deployment then there's a tool called AutoQoS. Another company into bandwidth management is Packeteer, which has dedicated modules that cater specifically to identification, control and compression. Finally, though bandwidth management may seem to be more cost effective at the router level, it can still overload the router resources. So, you may want to also consider using standalone solutions if you have very high amount of application traffic.