Reserving Bandwidth and Identifying Traffic Hogs
A better and more elegant solution is to reserve some bandwidth for the apps that really need it and to decrease the overall traffic on the network. To do that, of course, it’s necessary to analyze what you’re carrying on your network, and then decide what traffic you really want and what you want to restrict. “Most people are aware they have a problem, but they don’t know what it is until they take the time to find out at the application layer,” says Roger Hockaday, a marketing director at Packeteer.
The surprising thing is that solutions for traffic identification and shaping aren’t really that expensive. Packeteer’s PacketSeeker only costs a thousand dollars or so, yet it can automatically discover traffic from hundreds of applications and provide a clear picture of what’s really causing problems on a network. And the revelations are often disturbing. When you do find what’s on your network, it’s not uncommon to discover that most of the problems are being caused by a handful of P2P users.
The good news is that once you know what you’re facing, it’s not that hard to make changes and get the network in better shape. To do this you’ll need a policy-based network management tool like Packeteer’s PacketShaper, Israel-based Allot Communications’s NetReality, or any of the other products from vendors competing in this space.
How Policy-based Management Tools Can Help
How can policy-based management tools actually help? By enabling network admins to set up policies dictating which applications are mission critical and how much bandwidth they need to run properly, which applications (like Web browsers) are important and should have a certain amount of bandwidth available to them, and which traffic is unwelcome (possibly streamed media, probably P2P traffic) and therefore to be discouraged.
For example, with Packeteer’s PacketShaper it’s possible to set policies such as:
- Per-App Minimum: Protect all the traffic in one class. You specify the size of the reserved virtual link, choose if it can exceed that size, and optionally cap its growth. For instance, reserve a minimum of 20% of the WAN link for MS Exchange. Allow Exchange to exceed the minimum if bandwidth is available, but cap it at 60% of the link.
- Per-App Maximum: Cap all the traffic in one class. Even when the traffic bursts, other applications are not impacted. For example, limit the FTP total to 128 Kbps in a T1 link.
- Per-Session Minimum: Protect latency-sensitive sessions. Deliver a minimum rate for each individual session of a traffic class, allow that session prioritized access to excess bandwidth, and set a limit on the total bandwidth it can use.
- Per-Session Maximum: Keep greedy traffic sessions in line. For example, cap each FTP download at 10 Kbps.
- Dynamic Per-User Minimum and Maximum: Dynamically control per-user bandwidth without having to resort to tedious per-user configuration. Unused bandwidth is loaned to others.
Mission-critical apps typically don’t need huge amounts of bandwidth — SAP, for example, only needs 16 Kbps per user — so it’s fairly simple math if you have 10 SAP users to set a policy that makes a reserved virtual link for SAP traffic of 160 Kbps at all times.
While you might like to get rid of “leisure” traffic like P2P traffic completely, you’re probably better off tolerating and containing it rather than trying to eliminate it altogether, according to Hockaday. “If you try to prohibit P2P, the apps look for ways through the firewall. If you contain them, they won’t port hop. In educational establishments, some of them find that a huge amount of bandwidth, like 90 percent, is outbound P2P. We suggest they don’t prohibit it, but only allow inbound traffic.”
Page 3: Added Security via Network Traffic Management