The Quest for QoS

The cliche "everything is relative" is certainly accurate when used to sum up the essence of QoS schemes. After all, our industry's quest for QoS is all about determining how to balance the demands of data, voice and video streams when there is insufficient bandwidth to give all of us the bandwidth we demand. With VoIP the norm and VoIP growing rapidly, QoS on the LAN has evolved from a theoretical nicety to a practical necessity.

At The Tolly Group, we've witnessed much of that evolution through our testing. A quick scan of our archives shows sophisticated QoS testing taking place as far back as 1999 - at a time when VoIP networks existed only in demo centers (if even there) and QoS was talked about only in terms of providing a "futureproof" infrastructure.

That test of Cabletron Fast Ethernet SmartSwitch 2200 devices was quite sophisticated for its time.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

The cliche "everything is relative" is certainly accurate when used to sum up the essence of QoS schemes. After all, our industry's quest for QoS is all about determining how to balance the demands of data, voice and video streams when there is insufficient bandwidth to give all of us the bandwidth we demand. With VoIP the norm and VoIP growing rapidly, QoS on the LAN has evolved from a theoretical nicety to a practical necessity.

At The Tolly Group, we've witnessed much of that evolution through our testing. A quick scan of our archives shows sophisticated QoS testing taking place as far back as 1999 - at a time when VoIP networks existed only in demo centers (if even there) and QoS was talked about only in terms of providing a "futureproof" infrastructure.

That test of Cabletron Fast Ethernet SmartSwitch 2200 devices was quite sophisticated for its time.

Using IEEE 802.1p as the QoS marking method, we illustrated that the Cabletron box could not only detect and prioritize traffic but also could apply sophisticated features to tune the application of QoS. We validated that the device could implement "strict prioritization" where high-priority traffic got all the bandwidth it wanted even if it consumed all bandwidth; we also tested "weighted fair queuing," where the switch capped the bandwidth given to high-priority traffic to make sure that lower-priority traffic did not "starve" and thereby crash the session.

Back then, of course, the priority queues would be allocated among data streams of various importance - rather than voice or video. Even then, when high speed usually meant Fast Ethernet, it was important for vendors to prove that when QoS was turned on, overall box performance didn't suffer.

Over the next few years, some basic QoS became the norm even for lower-end access switches. A test we performed on a Dell PowerConnect 5212 in mid-2003 is indicative of what one would find in many switches then and now. It supported 802.1p QoS recognition and allowed traffic to be allocated among four priority queues. It was also common to see switches that implemented eight priority queues and allowed a variety of methods for determining which traffic was to receive priority. This was usually done by assigning priority to a particular port or a virtual LAN. And, of course, by then many devices had implemented IP-based prioritization using Differentiated Services.

It is no surprise, though, as enterprise VoIP grew and IP-video was on the horizon that QoS options needed to increase. After all, while a VoIP conversation demands very little bandwidth, it is very sensitive to delay. A single stream of moderate quality video can pull close to 4M bit/sec - and could run for many minutes or hours depending upon the application.

A study we performed for U4EA in 2004 concerns itself entirely with granularity. That is, in situations where you have multiple priority streams, we observe how well individual streams can be tuned.

And just this month, we published a test using actual "triple-play" data streams to illustrate yet another more sophisticated twist to QoS - the impact of congestion on ingress.