Sponsored By

Quality of Service (QoS) Design for TelepresenceQuality of Service (QoS) Design for Telepresence

Telepresence is an interactive real-time application, which means it is delay sensitive, loss sensitive and jitter sensitive. This sounds familiar: it is just like VoIP, with the one difference being that it has huge bandwidth requirements. VoIP is treated as the highest priority application in the QoS hierarchy, but it uses relatively small amounts of bandwidth. How do we deal with an application that requires very high priority and might be consuming half or more of the bandwidth on a link?

John Bartlett

July 1, 2008

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

Telepresence is an interactive real-time application, which means it is delay sensitive, loss sensitive and jitter sensitive. This sounds familiar: it is just like VoIP, with the one difference being that it has huge bandwidth requirements. VoIP is treated as the highest priority application in the QoS hierarchy, but it uses relatively small amounts of bandwidth. How do we deal with an application that requires very high priority and might be consuming half or more of the bandwidth on a link?

Telepresence is an interactive real-time application, which means it is delay sensitive, loss sensitive and jitter sensitive. This sounds familiar: it is just like VoIP, with the one difference being that it has huge bandwidth requirements. VoIP is treated as the highest priority application in the QoS hierarchy, but it uses relatively small amounts of bandwidth. How do we deal with an application that requires very high priority and might be consuming half or more of the bandwidth on a link?QoS is of course required if we expect to get consistent high-quality images and audio. To work correctly, real-time applications like Telepresence need the high priority that QoS provides. Packets need to be delivered with low loss and jitter so that the real-time images and audio can be reproduced as they happen. QoS is required both for an overlay network as well as for a converged network.

In an overlay network, the voice and video streams only compete with the signaling and management traffic that supports telepresence. QoS is still needed, but a simple 2-level strategy is sufficient. This is a key reason to go with an overlay if you have a short schedule and a grumpy boss.

In a converged network, telepresence has to be integrated with the other applications requiring priority service including VoIP, interactive data applications like Citrix, and mission critical Web-based applications. Telepresence needs to be higher in the priority stack than all these applications except the VoIP.

Here is where the details about bandwidth become most important. The QoS we most often use in our networks today is DiffServ, which by its strictest definition is a Class of Service (CoS) technology. CoS will provide a known forwarding behavior to a class of traffic, such as the telepresence, but will not manage its bandwidth. The routers will establish a maximum bandwidth for the telepresence class on each link. If that bandwidth is exceeded, the routers begin to drop packets, and thus impact the quality of the telepresence call.

The bandwidth design must be done carefully as described in an earlier post. If there is insufficient bandwidth for the telepresence, quality will suffer. Likewise if there is insufficient bandwidth for the data applications when the telepresence is running, the data applications will exhibit slow response and users will complain.

What class of service should be used for telepresence? Older literature from Cisco recommends that video conferencing traffic use an Assured Forwarding class (AF41). VoIP uses an Expedited Forwarding (EF) class. The difference between these two is that an assured forwarding class guarantees bandwidth, but does not guarantee that each packet in the AF queue will be forwarded immediately. The router uses a weighted round-robin algorithm to give just enough favor to the AF queue to ensure it is able to transmit at its designed bandwidth maximum. The EF queue, on the other hand, always gets to forward its traffic as the next packet to go. An EF queue ensures the lowest latency and jitter for a real-time application.

More recent Cisco literature and the presentations they have been using at the VoiceCon session on Voice-Ready Data Networks have a different story. Here they show telepresence being integrated into the EF queue with special thresholds to ensure that both the voice and video passing through the queue get EF priority but can still be bandwidth-managed separately. Interesting that video gets a better priority now that Cisco is in the video business.

RFC-4594 is a set of guidelines for sorting out the priority of each application in your QoS strategy. This RFC is the aggregated knowledge of some of the best network minds in the industry who have been thinking about this issue for many years. Understand in detail the QoS support provided by your WAN service provider and what markings they expect. Start with those two reference points and work out the best QoS strategy for your specific deployment and needs.

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.