Beyond Layer 4 versus Layer 7, when it comes to choosing a QoS method, you can get basic, or you can get complex. Let's start simple.

Plain-Cheese Techniques

When faced with a shortage of network resources, the easiest solution is to overprovision.

Need more bandwidth? Install a second T1. Routers dropping packets? Buy a RAM upgrade. Although it may sound like the lazy man's answer to QoS, overprovisioning is a valid and sometimes necessary route. For example, you can't transfer camcorder DV (digital video) streams over 802.11b in real time. Consumer-quality DV runs at 25 to 36 Mbps, while 802.11b runs at 11 Mbps (in practice, it's only 4 to 6 Mbps). If you have a 128-Kbps ISDN circuit and want to run 100 simultaneous VoIP sessions at 8 Kbps, not even the most fully loaded QoS solution will deliver.

Furthermore, enabling any QoS method on routers, firewalls and other network infrastructure devices consumes processing power and RAM, which may force you to buy more powerful equipment anyway.

Just be careful you don't end up spending more money provisioning than you would using a specialized QoS technique. For example, consider a branch office with a 1.5-Mbps DSL connection that costs $150 per month. Web traffic is hideously slow, so you might decide to upgrade to dual connections rather than listen to users grouse about the lack of bandwidth. First, do a traffic analysis: Streaming Internet radio or something equally frivolous might be the culprit. By using QoS to reduce or eliminate streaming audio, we found that our example branch office could save $1,800 annually.

Another way to conserve bandwidth is to use compression. Graphics can have their resolution or color depth reduced, video can be compressed with efficient codecs such as MPEG or DivX, and audio can be encoded at a lower bit rate or converted from stereo to mono. These lossy compression schemes can be taken only so far before there is a noticeable drop in quality.

As an alternative, you can use a lossless method such as zip, gzip or Aladdin Stuffit. Lossless compression doesn't reduce quality, but it doesn't cut file sizes as dramatically, either. Furthermore, lossless compression doesn't work efficiently on already compressed data, such as JPEGs, MP3s or video files.

Another best practice is to enable HTTP compression on Web servers. Compression was specified in HTTP 1.0 but was left as optional for client support. HTTP 1.1 clients, on the other hand, are required to support compression. HTML compresses efficiently: We once squeezed 8 GB of text onto a standard CD. The only downside is that HTTP compression imposes CPU overhead.

Expand Networks, Packeteer and Peribit Networks all sell site-to-site compression appliances that sit behind the Internet routers at your branch offices and automatically compress all traffic flowing through them. Of course, you must have a compression appliance at each end of a link, and traffic not sent between the appliances is not compressed. But these devices are inexpensive and will maximize your WAN links (see "Smarter Compression Technology.").

If none of these simpler methods fills the bill, it's time to get fancy.