Although definitions and features are vendor-specific, traffic shapers have a few common capabilities: Traffic can be shaped based on class (such as protocol or subnet), flow or both. And you can set minimum and maximum bandwidths, as well as burst.
Burst is permitted only if there is extra bandwidth available. For example, you could assign FTP 10 Mbps normally, but burst to 15 Mbps when there is bandwidth available. You can give some advanced commands to high-end shapers, such as "Allow 8 Kbps for every VoIP session, but let VoIP use up only 1 Mbps. If VoIP is using 1 Mbps, do not allow any new VoIP sessions."
Lines or Windows
Traffic shapers work by queuing packets or manipulating TCP window sizes. Vendors that use queuing claim that TCP will throttle itself down automatically because of the queue, so using TRS (TCP rate shaping) is unnecessary, unnatural and not specified by the IETF.
Also, TRS cannot handle UDP (User Datagram Protocol) traffic. This is a minor consideration, however, because any traffic-shaping vendor that uses TRS will implement a second, queuing-based algorithm to handle UDP. Allot Communications and Lightspeed both make queuing traffic shapers.
TRS works by manipulating TCP-control data and window sizes. This tricks the TCP session into believing it is communicating to a host on a much slower link. Similar shaping would occur naturally if a modem user connected to a server on a T3. TRS vendors claim that queuing adds latency, causes more dropped packets and isn't as good at slowing down incoming traffic. Packeteer and Sitara both use TRS.
Queuing vendors have four major techniques at their disposal:
PQ (priority queuing) works just like ToS. Higher-priority queues transmit before lower queues, meaning lowest queues can become starved.
CBQ (class-based queuing) overcomes some of the starvation problems inherent in PQ. Classes can be configured with a minimum amount of bandwidth, and can borrow bandwidth from other classes if available.
WFQ (weighted fair queuing) will increase or decrease a queue size based on priority level. Bandwidth utilization is not taken into account.
HWFQ (hierarchical weighted fair queuing) evaluates the worst-case packet delay under various traffic scenarios based on real-time traffic, and uses this data in evaluating the queue.
The queuing versus rate-shaping argument has gone on for many years--but frankly, we feel that management interfaces, reporting quality and performance matter SUB: much more than the underlying technology.
Just Queue It
Implementing QoS doesn't have to be difficult or overly time-consuming, but it can be if you try too hard. Pick those applications that you absolutely need, and make sure that they always get enough network resources. Or, simply limit the worst offenders.
Bottom line: Don't automatically associate lack of performance with a need for more bandwidth. There's no reason to upgrade to Gigabit Ethernet when enabling QoS on a router for free could yield satisfactory results. At minimum, QoS can be used in the short term to keep the network up and running until the next purchasing cycle.
Michael J. DeMaria is an associate technology editor based at Network Computing's Syracuse University Real-World Labs®.
Write to him at mdemaria@nwc.com.
Post a comment or question on this story.