To put it politely, Forrester Research Inc. analyst Robert Whiteley was fed up with the delusions surrounding network...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Quality of Service (QoS).
"I was tired of [misconceptions] about QoS," he said. "There are a lot of myths out there."
The misunderstandings, Whiteley said, have come from a renewed interest in QoS. That spike, he said, was brought on by a shift "to IP-based applications and converged multimedia networks that can easily be foiled by IP's best-effort nature." They also prompted Forrester to do a little research and issue a report outlining the three myths of network QoS.
Though QoS is necessary in some situations, implementing it isn't easy, Whiteley attests. It's nowhere near as simple as many think. Users need to be wary of vendor hype and avoid three major stumbling blocks -- that QoS is standard, easy to set up and part of a static configuration.
"It's important to note that QoS is not a technology, but rather an attribute of your network defined across many technologies like routers, switches and appliances," he said. "The ability to deploy QoS has been around for a decade, but rarely has it been implemented throughout the entire network because it suffers from three misconceptions."
The main goal of QoS is to ensure that not all network traffic is treated equally. This is done by marking traffic by classes of service and by shaping traffic to quell a free-for-all IP data network where certain classes hog bandwidth and traffic becomes congested.
According to Whiteley, QoS is not standard and not universally available. While QoS across a homogenous network is easier to figure out, turn on and maintain, few corporate networks comprise equipment from a single vendor. Plus, he said, QoS in the LAN and in the WAN can be significantly different, making it harder to guarantee application performance across a multi-tiered network.
"If you have a Cisco switch and a Nortel router, [turning on QoS] is not that easy. All of it needs to be looked at."
The second myth, that QoS is easy to set up. Though QoS is an interim step before turning on VoIP, it is also the hardest to get right, Whiteley said, because two stages -- definition and implementation -- are required. A bad configuration could undermine the effectiveness of QoS and potentially be more damaging than having no QoS at all.
"We often joke that VoIP is the canary in the coal mine," he said. "You may get it up and running, but in the process you're going to expose all of the bad stuff."
Lastly, Whiteley said, many companies are convinced that QoS is implemented once. Wrong, he said.
"[QoS] requires constant tuning," he said. "Every time a company adds a new enterprise application, touches a significant network component or adds and subtracts nodes, QoS must be revisited."
QoS is just like any other network policy, Whiteley said. It must be treated as an ongoing project and be subject to audits and refreshes to ensure it is working properly.
But, apparently, very few networking pros know that, according to Whiteley. He cited a recent poll of 388 large enterprises, which found that only 11% of respondents use QoS in the LAN and not one has an audit or refresh policy in place.
Whiteley recommends avoiding QoS as a whole whenever possible. "Misconfiguring QoS can do more damage than not having it at all."
While the two assets of QoS -- marking traffic by classes of service and shaping traffic -- are bonuses, Whiteley said. "Shaping is overkill," and good WAN optimization tools can have the same impact.
"To combat the problem, limit QoS to only where it's needed -- like in the WAN -- and use optimization appliances like those from Juniper Networks, Orbital Data and Riverbed Technology to avoid unnecessary QoS requirements," he said.
However, if poor application performance does require QoS implementation, corporations should tackle QoS in the WAN with a managed service and proceed with QoS in the LAN with their switching vendors only if necessary. Lastly, companies should consider working on marking traffic by classes of service first and shaping traffic second, if necessary.