LANs /

Update on QoS, Part 4

By Jeff Caruso
Network World High Speed LANs Newsletter, 03/21/01

In this series, we have been taking a look at the state of quality of service, or QoS. The series prompted many of you to write in, and I'd like to share some of the responses with you.

This reader points out that much work has been done on Differentiated Services (Diff-Serv), but this is really considered a WAN technology:

" QoS has changed very much in the past few years. Diff-Serv is the finer-grained definition of the [type-of-service] byte in the Layer 3 header. Some vendors are already shipping Diff-Serv in their hardware. Other vendors have the capability in software (this is slower than the hardware models). The ones that have the capability in software are working towards implementing it in hardware, but are playing catch-up. "

This reader says QoS is very much alive:

" I respectfully disagree with your recent [newsletter] discussing QoS. While the QoS Forum may not be active, customers are very concerned about deploying QoS. Almost every account I work with [wants to] ensure QoS tools are available in the products they are currently buying. And while you say voice is not being run across data networks, every account I work with is or is exploring how to put voice across their network. "

One reader says the promise of QoS sounds all too familiar:

" I'm curious about the state of QoS too. Regarding different service levels for different customers, I vaguely remember in the late '70s a switched service architecture called SDN, Software Defined Networks, at AT&T. One of the touted features was an ability to give different levels of service for various people in an organization. I don't think it flew then, and I don't think it should be a surprise that it wouldn't fly now. "

And here is another who is skeptical about QoS:

" I'm not surprised at the waning of the QoS Forum. Expectations for QoS seemed to me unreasonable. You mention one of the downsides of implementation, and that is politics. Even with something as seemingly user-neutral as weighted fair queuing, everyone might not appreciate the 'fair' part, especially those that do FTPs. The other is work. Unless you have some fairly 'automagic' scheme, I think there is great possibility of failure. Any scheme that requires any sort of human upkeep is going to cost money, and there is a likelihood of deterioration with time ... As you've guessed, I'm a bandwidth bigot. I would love to have some prioritization scheme in the toolbox just in case, but I wouldn't design based on it. "

As always, many thanks for writing in with your comments.