In discussions of service levels, a lot of terms are thrown around, but often there isn't a common understanding of what these terms mean. For example, some people use Class of Service (CoS) interchangeably with Quality of Service (QoS), while others make clear distinctions between the two terms. CoS, which refers to the differentiation of traffic flows for unequal processing, is the most general way to divide up service performance. Service may be grouped into classes for charging back costs, blocking user access, and controlling the quality of traffic flows.

None of the CoS groupings will have specific guarantees; the only certainty is that the preferred classes will get better service than the less preferred ones. Some people refer to CoS only with respect to service-level guarantees. Others distinguish between hard QoS, which guarantees particular quality metrics, and soft QoS, which provides a better-than-best-effort, but not a guaranteed set of service distinctions. (Best-efforts service means there is no differentiation among, and therefore no prioritization of, different types of data flows. This type of service is what most of us have to put up with when using the Internet.)

Type of Service (ToS) is comparatively easy to understand. IP packets have a 1-byte ToS field that has been proposed for classifying packets for preferential queuing, and although this field has never been widely deployed in a standardized way, it could be used to indicate queuing priority and discard eligibility when the network is congested. Keep in mind that the Internet was designed to be a best-efforts network with intermediate nodes (that is, routers) that have no knowledge of end-to-end paths. In particular, such quality characteristics as delay (latency) and jitter (the variability of latency) are difficult to guarantee, especially when the end-to-end connection has to cross someone else's network.

Contrast this design principle with ATM's, which has built-in classes of service, and where every switch in a virtual circuit works in concert to deliver the service quality that was requested when the circuit was set up. RSVP and the Integrated Services movement (of which RSVP is a part) are big, cumbersome retrofits to the Internet. But it appears that future implementations of RSVP will remain primarily in localized campus or enterprise networks: Internet backbone ISPs have been reluctant to implement RSVP on a large scale, in part because every router along an RSVP-enabled connection must be RSVP-aware.

With the hope of a pervasive RSVP-supporting Internet waning, the new Differentiated Services committee spun off from the Integrated Services Committee at the IETR Diffserv is committed to supporting multiple classes of service across the Internet, most likely without hard QoS guarantees in the vast majority of deployments.

While we're considering terminology, I should point out that using the term bandwidth to refer to a communications channel's carrying capacity or maximum throughput rate obscures important distinctions. Bandwidth download is measured in hertz or megahertz, and it can be a characteristic only of analog channels. Carrying capacity, in bits per second or megabits per second, is related to bandwidth by Shannon's Law.

With a constant signal-to-noise ratio, capacity is proportional to bandwidth, but the two things are not the same. Nevertheless, it's impossible to win this battle when the IETF and most engineers don't distinguish between capacity and bandwidth. Network Magazine's style standards call for maintaining the distinction, but if this article's title referred to "Throughput Managing" or "Capacity Managing," no one would know what the article was about.