Cisco ClearPath

Whitepaper


Solutions Practices Team
January 2011
Contents


Cisco ClearPath Whitepaper Jan 2011 Page 2


Contents
Introduction ......................................................................................................................... 3
What is ClearPath? .............................................................................................................. 4
ClearPath design goals ...................................................................................................................... 4
Packet loss descriptions ..................................................................................................... 5
How ClearPath works .......................................................................................................... 6
Dynamic bit rate adjustment............................................................................................................... 6
Long Term Reference Frames ............................................................................................................ 8
Forward Error Correction ................................................................................................................... 9
Packet loss technology comparison ................................................................................................. 12
Packet loss scenarios, and technologies used ................................................................................. 13

Figures
Figure 1: How ClearPath uses the RTCP Receive Report .................................................................... 7
Figure 2: Video stream without LTRF ................................................................................................. 8
Figure 3: Video stream with LTRF and Repair-P frames ..................................................................... 9
Figure 4: Video stream with no FEC applied ..................................................................................... 10
Figure 5: Video stream with added video aware FEC ....................................................................... 10
Figure 6: Illustrates different types of FEC levels .............................................................................. 11

Introduction


Cisco ClearPath Whitepaper Jan 2011 Page 3


1 Introduction
With the introduction of High Definition (HD) video and the quality of a TelePresence experience,
user expectations of video quality have dramatically increased when communicating visually. Users
expect to communicate using TelePresence with internal colleagues and with external customers,
suppliers and partners, in addition to staying visually connected while on-the-road. Today, with
video becoming pervasive and more and more people using video as mobile workers, one often
never knows what type of network they are connected to, nor the quality of that network. Also,
Business to Business communication is increasing over the public internet. The quality of the call will
then depend on both enterprises links to the Internet, as well as the Internet backbone transport
quality.

Making TelePresence calls in a non optimal IP network environment can degrade the experienced
video quality. There are a number of mechanisms on the network layer that can address these
challenges, and these should be implemented. However, in some cases that is not enough. This is
where Ciscos new Clear Path technology comes into play. ClearPath defines a set of media
resilience mechanisms that greatly increase the video quality experienced by the user in the event of
disruptive network conditions.

The objective of ClearPath is to radically optimize the video quality in non optimal IP network
environments to ensure an optimal video experience even when connected to a non-QoS enabled
network.

What is ClearPath?


Cisco ClearPath Whitepaper Jan 2011 Page 4


2 What is ClearPath?

Not all packet loss occurs for the same reason therefore ClearPath is a dynamic technology which is
the implementation of a number of media resilience mechanisms that reduces the negative effects of
packet loss. Good meeting experience in conditions with up to 15% packets loss will be achieved by
the ClearPath implementation. The media resilience mechanisms in ClearPath can be divided into
three main sets of tools:
Dynamic bit rate adjustment related to the severity of packet loss. This means adapting the call
rate to the variable bandwidth available: downspeeding or upspeeding the call based on the
packet loss situation.
Long Term Reference Frames: A method for encoder/decoder re-synchronizing after a packet
loss without the use of an intra frames. A Repair-P frame can be used instead of a traditional I
frame when packet loss occurs, resulting in approximately 90% less data being transmitted to
rebuild the frame.
Video aware Forward Error Correction (FEC): Protecting the most important data (typically the
Repair-P frames) to make sure that they are being received by the receiver.
Depending on the situation, ClearPath will use the different technologies above to give the best
possible user experience.
All the media resilience mechanisms within ClearPath are H.264 standard based, and the resulting
encoded bit stream is H.264 compliant.
ClearPath is designed to be independent of the call setup protocol, and can be used by endpoints
using H.323, SIP and XMPP.
2.1 ClearPath design goals
React quickly to an available bandwidth lower than that provisioned/configured.
Make the quality (as experienced by a user) appear stable over time in conditions of up to 15%
packet loss.
Detect whenever a significant reduction in produced bit rate does not reduce the packet loss
observed on the link, and do not reduce bit rate in this case.

Packet loss descriptions


Cisco ClearPath Whitepaper Jan 2011 Page 5


3 Packet loss descriptions
Loss is defined as packets that did not arrive (that is, they were dropped somewhere along the
network path), and is measured by each TelePresence System by comparing the sequence numbers
of the RTP packets it receives against the sequence numbers it expected to receive. Packet loss can
occur anywhere along the path for a variety of reasons of which the three most common reasons
are:
Layer-1 errors on the physical interfaces and cables along the path, such as a malfunctioning
optical interface.
Mis-configured network interfaces along the path, such as Ethernet speed/duplex mismatches
between two devices.
Bursts of packets exceeding the buffer (queue) limit or policer configurations on network
interfaces along the path, such as Ethernet switches with insufficient queue depth or
oversubscribed backplane architectures, or WAN router interfaces which police traffic to
conform to a Service Providers contractual rates.
A closely related metric is late packets, which are packets that arrive, but exceeded the jitter buffer
(that is, they arrived too late to be decoded) and therefore were discarded (dropped) by the
receiving TelePresence System. Lost packets and late packets both result in the same outcome
noticeable pixelization of the video.
The traditional approach to solving these issues could be divided into the types of packet loss
technologies:
Decoder concealment hiding artifacts when receiving video with packet loss.
Down speeding reducing the call rate to remove packets loss.
Use of Intra Frames traditional way of handling video with packet loss.
The next sections describe how the ClearPath technology works to optimize the video quality in non-
optimal IP networks.


How ClearPath works


Cisco ClearPath Whitepaper Jan 2011 Page 6


4 How ClearPath works
This section discusses the different media resilience mechanisms within ClearPath in more detail.
4.1 Dynamic bit rate adjustment
The need for dynamic bit rate adjustment generally comes from two facts:
Typical networks (public networks in particular) offer an available capacity for carrying UDP data
that varies with time. Generating more traffic than the network can handle leads to packet loss,
possibly having unfavorable effects on the audio/video channels rendered at the receiving end.
Overly aggressive bandwidth settings at call start up may cause the produced (or received)
traffic to overshoot the capacity of the current host network. Typically this happens if a system is
moved from one network (for example, a corporate LAN) to a different network (such as a home
DSL connection) without making changes to either provisioned or configured bitrates.
The traditional approach to solving these issues is to have systems observe packet loss on incoming
streams and issue a request for the far end system to perform downspeeding (reducing the call
rate to a new lower value) if packet losses are severe and persist over time. The requests to the far
end system are either sent as a SIP Re-Invite message or a H.323 Flow Control message, depending
on the systems native protocol. Some of the issues that are experienced with this approach include
interworking control messages (SIP/H.323) and delay/responsiveness. The end result of this is that
the experienced quality becomes poor.
Because most modern implementations now support RTCP; therefore it is a possible to change this
approach from having the receiver actively request call rate changes to making the sender side take
action proactively. By inspecting RTCP Receiver Reports (hereafter called RRs), the sender is
regularly notified of the reception statistics at the far end system. If RRs indicate packet losses, it is
likely that the network is overloaded and that the traffic generated by the sender should be reduced.
With ClearPath, the sender side automatically adjusts its produced bit rate by using RRs. An
advantage of this approach is that it does not involve any additional signaling (decisions are taken at
the sender side without explicitly informing the receiver). Also, if RRs are scheduled fairly frequently
(~5sec intervals are common), this potentially provides a system that is more responsive to changes
in available capacity. Cisco also uses RRs to dynamically increase the bandwidth subsequently when
no packet loss is detected.


How ClearPath works


Cisco ClearPath Whitepaper Jan 2011 Page 7



Figure 1: How ClearPath uses the RTCP Receive Report
How ClearPath works


Cisco ClearPath Whitepaper Jan 2011 Page 8



4.2 Long Term Reference Frames
A Long Term Reference Frame (LTRF) is a reference frame that is stored in the encoder and decoder
until they receive an explicit signal to do otherwise. (LTRFs are supported by H.264.)
Typically (without LTRF) an intra-frame is used for encoder/decoder re-synchronization after packet,
loss which can result in repainting the whole image on the screen which is noticeable, in addition to
the video degradation caused by the packet loss. Usually, you see a pulsing of the video image
when this happens.


Figure 2: Video stream without LTRF

This is where the LTRF comes in; it provides an alternative method for encoder/decoder re-
synchronizing after a packet loss without using intra frames. Typically, the encoder inserts LTRFs
periodically and at the same time instructs the decoder to store one or more of those LTRFs.
A Repair-P is a frame that uses a previous LTRF that has been decoded correctly as a reference.
The Repair-P frame is used in response to a missing frame or of its reference frame. Because the
acknowledged LTRF is known to have been correctly received at the decoder, the decoder is known
to be back in-sync if it can correctly decode a Repair-P frame.
Time
ntra frame ntra frame
X
Good video Artifacts Frozen video Good video again
Large amounts of data sent
- Poor video quality while data is being sent
- Packet loss while sending data will result in
a new ntra. And so on.
Packet
loss
P-frames
How ClearPath works


Cisco ClearPath Whitepaper Jan 2011 Page 9





Figure 3: Video stream with LTRF and Repair-P frames

By extending the backchannel messaging so that the decoder can acknowledge reception of a
complete LTRF, re-synchronizing after a packet loss can be achieved by forcing the encoder to use
an acknowledged LTRF for temporal prediction instead of inserting an intra frame. This allows for
significantly faster recovery because temporal prediction from a LTRF requires fewer bits than using
an intra frame. The observed quality will be better and you do not see the video image pulsing when
re-painting the screen because the entire screen does not need to be re-painted.
The Repair-P media resilience mechanism means that the decoder has a back channel to the
encoder for synchronizing LTRFs. This is done using the ClearPath feedback messages. The Repair-
P frame is a repair frame that is only sent when there is packet loss.
4.3 Forward Error Correction
Forward Error Correction (FEC), is accomplished by adding redundancy to the transmitted
information using a predetermined algorithm. The redundancy allows the receiver to detect and
correct a limited number of errors occurring anywhere in the message without the need to ask the
sender for additional data. FEC gives the receiver an ability to correct errors without needing a
reverse channel to request retransmission of data, but this advantage is at the cost of a fixed higher
forward channel bandwidth.

Time
ntra frame
Repair-P frame
X
Good video Good video again
Less data sent
- Shorter time with disturbed video
- Lower risk for multiple resending of data

Packet
loss
P-frames
How ClearPath works


Cisco ClearPath Whitepaper Jan 2011 Page 10



Figure 4: Video stream with no FEC applied

The ClearPath implementation uses a fixed percentage of the bandwidth for FEC/redundancy. There
are rules for applying FEC: Cisco will not use FEC on bandwidths lower than 768kbit/s and there
must also be at least 1,5% of packet loss before FEC is introduced. Our current FEC implementation
does not affect the overall latency. We also monitor to effect of the FEC. If FEC is not efficient, our
implementation will then make a decision of not doing FEC.


Figure 5: Video stream with added video aware FEC
Within FEC you can specify different dynamic FEC levels, which are applied based on the importance
of the video frame.
A priority order of FEC actions exists in low to high priority; for example, FEC protect Repair-P
frames might be the highest priority and FEC protect long term reference frames next, through to
FEC protect disposable frames as low priority.
Example: The video encoder tags the video packets to be one of:
high importance
medium importance
low importance
Packets of high importance are protected with FEC level 1, packets of medium importance are
protected by FEC level 4 and packets of low importance are not protected at allapplying an unequal
error protection based on the level of importance of the video packets.

With FEC packet loss will not affect the overall video quality
FEC FEC FEC
FEC will fix a lost frame Loosing a FEC frame is not a problem
Packet loss will affect the overall video quality
How ClearPath works


Cisco ClearPath Whitepaper Jan 2011 Page 11



Figure 6: Illustrates different types of FEC levels

Therefore, with FEC level 1 you can lose 1 out of 2 packets without reducing the video quality. On
level 2 you can lose 1 out of 3 packets, while on level 4 you can lose 1 out of 5 packets without a
reduction in video quality.
Figure 5 above shows an example with FEC level 1. FEC level 1 is typically used to protect video
packets of high importance such as Repair-P frames.
FEC
FEC
FEC
FEC
Level 1
Level 2
Level 3
Level 4
How ClearPath works


Cisco ClearPath Whitepaper Jan 2011 Page 12



4.4 Packet loss technology comparison

Packet loss technology Strength Weakness
Decoder concealment Receiver-only functionality, does not
require support on sender side.
Will help maintain frame rate, but does
not work that well on artifacts.
Down speeding Standards-based, works in mixed
environment
Works only when congestion is caused
by a too high call rate.
Does not up speed if packet loss was
temporary.
Dynamic Bit Rate
Adjustment
The best solution to remove packet loss.
In some scenarios down speeding is the
best solution.
Works only when congestion is caused
by a too high call rate.
LTRF Reduces the amount of data sent by up
the 90%. Helpful in all packet loss
scenarios.
Requires support on both sender and
receiver.
Video aware FEC Very effective when the call rate is high
in two ways:
- Low packet loss: removes quality
reduction
- High packet loss: protects Repair-P
frames for great overall performance
Not efficient in low call rate scenarios.


This table shows that a robust packet loss technology must make use of the variety of the packet
loss technologies, not just a single approach, and must do so in a dynamic fashion because packet
loss is dynamic in nature.
How ClearPath works


Cisco ClearPath Whitepaper Jan 2011 Page 13



4.5 Packet loss scenarios, and technologies used

Mixed environment Decoder concealment and down speeding
ClearPath capable products Long Term Reference Frames should always be used. No
negative side effects.
Bursty packet loss Repair-P frames
Packet Loss in Low bandwidth calls (768 kbit/s or
lower)
Repair-P frames
Packet Loss in High bandwidth calls (above 768
kbit/s)
Repair-P frames and FEC
Constant packet loss Dynamic bit rate adjustment if it helps, if not Repair-P frames
and FEC

How ClearPath works


Cisco ClearPath Whitepaper Jan 2011 Page 14


THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE
WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE
ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL
RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE
INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF
YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO
REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of
California, Berkeley (UCB) as part of UCBs public domain version of the UNIX operating system. All rights reserved. Copyright
1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE
PROVIDED AS IS WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES,
EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL
DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE
OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing
of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of
their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other
company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and
phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the
document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is
unintentional and coincidental.
2010 Cisco Systems, Inc. All rights reserved.