Sponsored By

Telepresence Might Require Router and Switch UpgradesTelepresence Might Require Router and Switch Upgrades

The constant high-bandwidth barrage of packets created by a telepresence system can be too much for some routers and switches to handle. This can be a final-hour unwanted surprise for a telepresence deployment, so it merits some early investigation. Let's look at why this happens and how to avoid having the headache this problem provides when it appears at the trials stage.

John Bartlett

July 15, 2008

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

The constant high-bandwidth barrage of packets created by a telepresence system can be too much for some routers and switches to handle. This can be a final-hour unwanted surprise for a telepresence deployment, so it merits some early investigation. Let's look at why this happens and how to avoid having the headache this problem provides when it appears at the trials stage.

The constant high-bandwidth barrage of packets created by a telepresence system can be too much for some routers and switches to handle. This can be a final-hour unwanted surprise for a telepresence deployment, so it merits some early investigation. Let's look at why this happens and how to avoid having the headache this problem provides when it appears at the trials stage.A router that has perfectly good performance for data traffic may fail for telepresence. What is going on here? Like other aspects of the network, designers were not planning for the constant high bandwidth demand of the telepresence application. If the router or switch gets just slightly behind when a burst of data traffic comes through, it will have time to recover during the next lull. But telepresence has no lull; it provides a constant demand for the duration of the conference.

Packet sizes for telepresence traffic vary. Some systems use full-size packets for the video stream, and some use smaller packet sizes. But even those using full-size packets are going to have smaller packets intermixed as well. The sending video system is capturing frames of data and compressing them. This compressed data is then sent as soon as the compression is complete. Some vendor's systems send this compressed frame as a series of full-sized packets followed by a smaller packet to finish off the frame. Other vendor's systems send the packets as a group of medium-sized packets because of the way they are generated by separate signal processors in the codec. In addition to the video, there will be an audio stream using small packets, and there may be a separate video stream containing the data from a shared presentation.

Routers are often designed with small buffers and large buffers, and these buffers are allocated to receiving ports. If the router does not have the right mix of buffers allocated, or cannot get new buffers allocated in a consistent way, the buffer pool will be emptied by the constant demand of telepresence. Once the buffer pool is empty, incoming data is discarded until the router recovers.

Quality of Service is another issue for these devices. Most routers have a 'fast path' and a 'slow path'. The fast path is the hardware enabled path where once the forwarding for a particular flow is understood, the hardware can do the packet switching with no intervention from the local processor. The slow path is the path taken by packets that the hardware does not know how to handle. These go to the router's processor where they are handled in software.

Some routers are not able to handle QoS classification and marking on the fast path. This means that the telepresence traffic will have to pass through the processor of the router (the slow path). This will limit the total performance of the router and may cause packet loss if the demand exceeds the router's ability to reliably forward QoS-marked packets. This is the same processor, by the way, that is managing the buffer allocation mentioned above. An over-busy processor can cause problems in numerous ways.

So what to do? I recommend both research and testing. In my opinion, every telepresence deployment should include network verification. This test should be done with the full expected telepresence load with QoS markings. The test should verify that the appropriate bandwidth can be delivered and that packets remain within the required low packet loss, jitter and latency specifications. Use a synthetic traffic generation tool and simulate the mix of packet sizes created by telepresence. Remember that the network can fail two ways, either through insufficient bandwidth, or through insufficient ability to forward the packet rate provided. So packet size is important.

The research approach is to call in your router and switch vendors and ask very direct questions about which products will or won't support the packet rates, QoS and bandwidth you need. My experience is that the answers can be very product specific, down to the particular slots in the backplane or extender of specific devices. Ask the tough questions and get the real answers to ensure your network will carry telepresence in a consistent, high quality way.

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.