Let's start with semantics. At the risk of sounding like the William Safire of networking terms, the phrases Quality of Service and service quality mean different things -- though you wouldn't know it by reading the trade press. QoS is a technical term, and service quality is an expectation. A carrier could offer QoS capabilities in a network yet do it poorly, thereby offering Quality of Service with bad service quality. So when a misguided reporter writes, "For incumbent carriers to enter the long-distance market, the FCC looks for improvements in Quality of Service," you should be thinking, "Carrier service quality would actually improve if they hired drunken chimpanzees as field techs."

Unlike bandwidth, not every network needs Quality of Service. If your network isn't congested, you needn't bother with QoS. And if you own the mechanism to create bandwidth, adding capacity is better than managing it. Cheap Ethernet capacity killed ATM in the campus. QoS enforcement is needed only when bandwidth is an underprovisioned and expensive resource, like in the wide area.

QoS is not just a box sitting on one point in the network, such as the LAN/WAN boundary. Effective QoS requires a consistent end-to-end view through the network that is independent of any platform, device or media. Unfortunately, this can become horrendously complex if it's overengineered.

Forget fine-grained traffic-classification mechanisms, such as RSVP; these strategies simply are not manageable in the real world. Instead, a few carefully considered classes of service can do the trick. Most networks can get by nicely with only a handful of traffic classes: one for real-time interactive (voice/video), one for high-priority business traffic (low latency/low loss), another for low-priority business traffic (higher latency/loss, such as for file transfers), and a class for nonessential flows that can be serviced as needed. Add a few more if it fits your situation, but stick to less than six or so.

Also forget QoS-aware applications. Even if developers actually knew how much network capacity their applications need, why would they request anything less than the best? Applications won't signal QoS -- and operating systems won't be involved in QoS policy either. Almost no Microsoft Windows 2000 deployments actually implement Admission Control Service, and though Windows XP does ship with QoS drivers by default (notably absent of RSVP support), most savvy users quickly disable them.

Traffic classification policy is solidly within the networking organization's control and, if used, should be done in the infrastructure as the earliest point flows enter the network. By mapping ingress traffic into classes, you ensure the actual enforcement of the traffic policy can happen at congestion points -- without requiring overburdened devices at the congestion point to be application-aware.

So it's important for network architects to decide what their traffic classes should be and how they'll be signaled at a technical level -- classifying applications using simple mechanisms, such as 802.1D user priority or DiffServ. That part is easy and obvious for many traffic flows; think real-time services. But determining the relative priority of one data application against another should not be done within the vacuum of IT -- let the business decide how apps should stack up.