Enterprise routers from general vendors as Cisco Systems, Bay Networks/Northern Telecom, and 3Com include support for multiple queues and use some of these weighting algorithms to distribute traffic. However, even if you have a router that supports prioritization, you might still want to use a separate queuing-based bandwidth check, as packet-classifying processes can degrade router performance, the administrative workload of defining and implementing policies on a router might be too high, or the router might not support enough priority classes.

In addition, the router's classification method might be insufficiently rich for your needs. It would not be unfair to describe multiple-queue bandwidth management products as routers (or conceivably bridges) that have been optimized for granular and easy-to-configure queuing.

Wherever prioritization queues are implemented, they constitute a reactive, short-range solution. They do nothing to correct the source of the congestion they're reacting to--unless you consider packet dropping a corrective practice. Advocates of TCP rate control claim that queues make multi-service traffic flows chunkier and therefore less efficient, as chunks tend to overflow queues and create time-outs that could be avoided with rate control. Queuing advocates contend that rate-control activities are nonstandard interventions in end-to-end protocols that should be handled solely by the involved endpoints.

They predict that future developments in protocols and implementations will likely interfere with rate-control schemes. In addition, they claim that rate control is relatively slow to affect congestion and can sometimes result in oscillating series of over-corrections that may take several seconds to stabilize.

Of course, there's no law preventing vendors from using both rate control and queuing. Many of the products discussed in this article take this approach. One advantage of implementing both techniques is that flows traveling from a high-speed LAN to a low-speed Internet access link, as well as those coming from the Internet into the LAN, can be managed effectively.

Rate Control Products The first bandwidth management product that appeared on the market--and probably the one with the largest market share right now--is Packeteer's (Cupertino, CA) Packet Shaper. Packeteer's products are dedicated boxes running a proprietary real-time operating system. Each box contains a hard disk that only logs events; the box boots from flash ROM. The Packet Shaper 1000 has two 10Mbit/sec Ethernet ports and a WAN interface that supports throughput rates as high as 384Kbits/sec. The Packet Shaper 2000 can support rates as high as 10Mbits/sec, while the PacketShaper4000 can support rates as high as 45Mbits/sec.

Though Packeteer was the pioneer in TCP rate-control products, its Packet Shaper products implement a queue for UDP and SNA--protocols that don't have TCP'S convenient rate management hooks. But with TCP traffic, Packet Shapers classify flows, associate them with policies, measure the end-to-end latency of each flow, and predict the flow rate necessary for each flow to conform to specific policies.

They then release packets smoothly with modified window sizes, preventing the original senders from filling up the pipe, which would be the natural bent of senders in the absence of rate control. Packeteer claims its devices will never add more than 2 milliseconds of latency to a packet; almost any queue-based system would invariably have delays many times as large.