Service Level Agreement (SLA) for TelepresenceService Level Agreement (SLA) for Telepresence

Your WAN service provider is a critical component of a telepresence deployment. Much of the responsibility for delivering low packet loss, low jitter traffic to your locations around the globe lies in their hands. The instrument that allows you to manage their delivery is the Service Level Agreement (SLA) and it needs to reflect the critical nature of delivering telepresence traffic properly. Here is what I think your SLA should specify.

Your WAN service provider is a critical component of a telepresence deployment. Much of the responsibility for delivering low packet loss, low jitter traffic to your locations around the globe lies in their hands. The instrument that allows you to manage their delivery is the Service Level Agreement (SLA) and it needs to reflect the critical nature of delivering telepresence traffic properly. Here is what I think your SLA should specify.The telepresence traffic has to be delivered with low loss, low jitter and low latency. This means a higher class of QoS service is required. Work with your service provider to determine which level of service you will need to get the required specifications. My guess is it's the best one they have.

Packet loss needs to be 0.1% or less. Cisco specifically asks for 0.05% or less to keep their systems happy. This is a pretty tight specification. But the percentage value is only half of the spec; the other half is the measurement period.

The measurement period determines over what time frame the measurement must be true. Many SLAs will say 0.1% packet loss "over the measurement period*", and when you find the footnote in tiny font somewhere on the 10th page it will say that the measurement period is a month. This means that if the packet loss averaged over a month is less than 0.1% they are within spec.

So with this specification it is possible for the carrier to deliver excellent performance during nights, weekends and holidays, to deliver poor performance during business busy hours and still meet their specification. This is not what you want because it is during business busy hours that your most important telepresence sessions take place.

So work hard to get the carrier to agree to a much lower measurement period like 1 minute or 15 minutes at the most.

Jitter needs to be below about 40 milliseconds (ms). Jitter is the variation in latency that is caused by temporary queue congestion experienced along the network path. Each packet has data that represents audio for a specific instant of time or data that is part of a video frame for a specific instant of time. The time to 'play' that data will come up shortly after that packet is supposed to arrive. If it is unduly late (more than about 40 ms) then its play window has gone and the data is useless. The receiving codec then drops the packet and the impact is the same as if the packet were lost in the network.

The 40 ms number represents the size of the jitter buffer on the receiving codec. If your codec has a larger buffer, the spec can be relaxed. But don't allow this buffer to be too large, as it impacts latency (described next.)

A better way to specify jitter is to say that packets with jitter greater than 40 ms should not occur more than 0.1% of the time as measured over the (preferably short) measurement period. This is consistent with the loss specification and with the quality impact of jittered packets.

Both packet loss and jitter cause direct degradation in the quality of the video and audio reproduction. Latency is a little harder to get a handle on.

Increased latency causes an interactive video conference to be more difficult. The delay makes a back and forth repartee difficult because the response or interruption comes later in the speakers conversation than was intended. If one party asks a question, there can be a noticeable delay before the other party responds. This can be interpreted as reluctance to answer, or a lack of intelligence or understanding, where in fact it is just a delay in the technology.

If a conference is primarily one party speaking, such as a lecture or an update on the company's standing by the president, latency has little impact. But telepresence is often about a face-to-face discussion, and there it will have a noticeable effect.

Network latency should be kept below 150 ms if possible. There are geographic distances that don't allow this specification to be met. But where possible, keep the number low.

Lastly of course the SLA needs to specify the required bandwidth. Earlier posts described how to calculate the bandwidth in detail. The WAN service provider must be able to supply the needed bandwidth on a constant usage basis. Telepresence systems are very demanding because of their constant high-bandwidth transmission rate and their need for tight delivery specifications.

Lastly, test the initial installation to ensure the service provider is really delivering what the SLA specifies. If there are problems with the network, debugging the telepresence installation will be much more difficult because it is not always obvious what problems are equipment problems and what problems are network problems. An ongoing test capability is also vital. This is sometimes provided by the WAN service provider, but may not be. Having an ongoing test of the ability of the whole infrastructure to deliver low-loss, low-jitter packets is a critical part of managing a high-quality telepresence service.