Making QoS work

By Tom Henderson, |  Development

QoS is new; buying bandwidth to solve application communications problems is old.
Fatter pipes are brute force; QoS is intelligent flow-control assertion.

The problem with making QoS work in Windows-2000-based networks has historically
been a problem with QoS in general: It's seen as complex and application-driven.
Applications that need QoS-multimedia apps have historically been a low priority in
business situations, and simply unusable in consumers' slow-speed, dial-up

Faster technology doesn't equal faster QoS adoption

Now, the advent of faster modems, broadband deployments, and other market drivers has
dramatically increased demand for multimedia applications. To paraphrase Mark Knopfler
of Dire Straits: I want my MTV -- and what's its URL?

QoS, though, is often vexed by the perceived complexity of deploying support for it.
Organizations ignore it unless serious business-application throughput is being
hampered by some other service. "If it ain't broke, don't fix it!" is the hue and

Another demotivator is fear. Many network designers think both types of
QoS -- qualitative and quantitative -- are tough to implement, and that the benefits of
QoS are obscure and difficult to sell to management. This is actually an avoidance
problem: QoS can be easily justified with the right information, and surprisingly, most
of the foundational components are already in your OS to support it. The key is that
applications must ask for QoS, and the delivery chain must support these requests.

Review of quantitative QoS

Quantitative QoS applications -- think multimedia and isochronicity protocols -- are
host-to-host, and therefore stream-oriented. Relationships are generally built between
a desktop user and a multimedia source; in Internet Telephony/VoIP, two relationships
are established, one in each direction.

Whatever the relationship -- unicast or multicast (see " href=,2848,1_1227,00.html>Understanding
QoS for timing-sensitive applications") -- all the routers along a delivery chain
must be able to support the desired type of QoS. Any router that doesn't is a potential
entrance point for the latency and resulting jitter that breaks the time-domain needs
of applications, which may cause the multimedia reproduction to suffer. Voice apps will
have gaps spiked into them. Videos will freeze and catch up, like a dying VCR. Keep
within the time-domain boundary, and the results will be acceptable.

Join us:






Answers - Powered by ITworld

Ask a Question