Sponsored By

QoS Has Four PartsQoS Has Four Parts

I work with a lot of enterprises who are just implementing QoS for the first time. At first blush, implementing QoS looks like it means just turning on the QoS mechanisms that are already available in their routers and switches. But of course real life is more complicated than that! I always tell them there are four parts to implementing QoS, and you have to do all four to get it right.

John Bartlett

January 16, 2008

3 Min Read
No Jitter logo in a gray background | No Jitter

I work with a lot of enterprises who are just implementing QoS for the first time. At first blush, implementing QoS looks like it means just turning on the QoS mechanisms that are already available in their routers and switches. But of course real life is more complicated than that! I always tell them there are four parts to implementing QoS, and you have to do all four to get it right.

I work with a lot of enterprises who are just implementing QoS for the first time. At first blush, implementing QoS looks like it means just turning on the QoS mechanisms that are already available in their routers and switches. But of course real life is more complicated than that! I always tell them there are four parts to implementing QoS, and you have to do all four to get it right.First is the QoS in the routers and switches. The predominant QoS mechanisms used today are DiffServ for the routed infrastructure, and IEEE 802.1p for the switched infrastructure. These mechanisms are in most enterprises' network infrastructure, and are waiting to be turned on if they are not already on. Turning them on isn't hard. What takes some time is determining the right plan for what traffic will use which levels of service, how many levels of service to have, and what markings to use for each class. Also how to map the priority classes across the layer 2 to layer 3 boundary, and how well that plan fits with the services offered by the WAN vendors.

The second part of QoS is classification. Packet streams need to be marked so that the switches and routers can recognize them as higher or lower priority. Think of this as an airline agent who meets you at the door of the airport, and gives you a red jacket or a blue jacket indicating you are flying first class or coach. Now the agents inside the airport can quickly identify which line you should be in without having to engage every person in a conversation.

The third part of QoS is bandwidth management. When we look closely we find that DiffServ and IEEE 802.1p are really class-of-service mechanisms, which means they know how to provide different levels of service but they don't know how to control a rush of traffic or oversubscription. So additional mechanisms are needed to ensure that we don't overutilize the classes of service we have established in the network. This is especially important for voice and video streams, because their quality can degrade quickly when oversubscription occurs.

The fourth part of QoS is monitoring. We have to know that our network is continuing to provide high quality transport for voice and video streams, and we would prefer to know about issues before our users find them through poor application performance. Because voice and video have special needs, new types of monitoring tools are required for this task. This part of the process is both a technology investment as well as a new process to be learned and managed by the IT team.

I'll take a closer look at each of these areas over the next few weeks--watch this space!

About the Author

John Bartlett

John Bartlett is a principal with Bartlett Consulting LLC, where he provides technical, financial, and management leadership for creation or transition of Unified Collaboration (UC) solutions for large enterprises. John discovers the challenges in each enterprise, bringing disparate company teams together to find and execute the best strategy using Agile-based methodology to support quick wins and rapid, flexible change. John offers deep technical support both in collaboration solutions and IP network design for real-time traffic with global enterprises world-wide.

 

John served for 8 years as a Sr. Director in Business Development for Professional & Managed Services at Polycom. In this role he delivered, defined and created collaboration services and worked with enterprises to help them shorten time-to-value, increase the quality and efficiency of their UC collaboration delivery and increase their collaboration ROI.

 

Before joining Polycom, John worked as an independent consultant for 15 years, assessing customer networks for support of video applications and other application performance issues. John engaged with many enterprises and vendors to analyze network performance problems, design network solutions, and support network deployments.

 

John has 37 years of experience in the semiconductor, computer and communications fields in marketing, sales, engineering, manufacturing and consulting roles. He has contributed to microprocessor, computer and network equipment design for over 40 products.