Once bandwidth management hardware is in place, you must divide traffic into classes, typically by IP address or TCP/IP application-level port number, although the classification schemes vary widely from product to product. Then you tell the bandwidth manager how much of the WAN traffic each class gets. Each product has different capabilities, ranging from assigning a simple raw number (for example, "The Web server gets no more than 512K bit/sec'') to more complex rules involving setting priorities and minimum and maximum amounts of traffic the device can pass.
Properly done, bandwidth management can be quite complex. Throttling back applications efficiently requires an in-depth knowledge of the entire protocol stack being used. For example, an application running over TCP may have internal retransmissions if packets are lost or delayed. TCP has a whole series of internal timers and buffer interactions that vary from implementation to implementation, and IP and Ethernet have their own sensitivities. Taken together, the simple-minded approach of "drop packets when limits are reached'' can have the effect of wasting WAN bandwidth, as well as skyrocketing LAN traffic and protocol stack CPU time.
Handling TCP traffic correctly means not only passing packets back and forth but looking deep into them. By delaying some packets, both sides of each TCP connection can be fooled into thinking that there is a long delay, which reduces retransmissions and overhead while letting the bandwidth manager efficiently throttle traffic.
RELATED LINKS
Back to the review of bandwidth managers
