With Application and Visibility Control (AVC) providing Cisco network equipment the ability to recognize PC-over-IP (PCoIP) traffic, users can now extend the internal priorities of PCoIP-based virtual desktop traffic across the Cisco network, optimizing the Virtual Desktop Infrastructure (VDI) user experience end to end.
This white paper will explain the technologies involved in this solution, and provide detailed guidance for network administrators to configure and deploy it. Please note: this white paper does assume moderate knowledge of network Quality of Service (QoS).
Network professionals who manage networks (LAN and WAN) with Cisco routers, where PCoIP is deployed.
The Teradici PCoIP® protocol is an innovative remote display technology that allows the user's desktop operating system, applications, and data to reside in the datacenter, eliminating the need for traditional desktop workstations, PCs and thin clients. It delivers an uncompromised user experience to each person, anywhere, over any network and to any type of device without incurring the security risks associated with having data reside in remote PCs, laptops, or tablets. PCoIP technology provides high resolution, full frame rate 3D graphics and high-definition media, with full USB peripheral interoperability, locally over a LAN or remotely over a high-latency WAN. The PCoIP protocol compresses, encrypts and encodes the entire computing experience at the datacenter and transmits it `pixels only' across a standard IP network to secure, stateless PCoIP zero clients, PCoIP Optimized™ software clients, thin clients, and mobile devices.
The PCoIP protocol is implemented in several software configurations, including VMware® Horizon View™ virtual desktops, as well as in custom designed Teradici silicon for hardware accelerated performance and enhanced security. A growing ecosystem of over 30 third-party vendors provide a wide variety of PCoIP products, including server offload cards, rack and tower workstations, blade PCs, zero clients, optimized software clients, integrated monitors, and touch-screen devices.
The following diagram illustrates a typical VDI implementation over WAN, connecting to various endpoints such as hardware-based PCoIP zero clients, thin clients and software clients.
Application Visibility and Control (AVC) Overview
There are several trends in the enterprise today that drive requirements to build application awareness within the network.
Private clouds are fully virtualized data centers including virtual compute, storage and networking. VDI is a private cloud service that hosts users desktop environments. Virtualization technology simplifies IT so an organization can more effectively use storage, their network, and computing resources to control costs and respond faster to the ever-changing landscape. The PCoIP is a VDI protocol that provides real-time delivery of a rich user desktop experience in virtual desktop and remote workstation environments. VDI clients can be in the same building as the server, or across the WAN. This creates additional requirements on the network to ensure a proper delivery of the desktop environment to the end-user.
The network must now carry a greater volume of both business and recreational traffic. Network admins need to gain visibility into different types of traffic (business and recreational) to be able to quickly isolate and troubleshoot application performance issues. They need the ability to granularly define policies to control and tune the performance of these different applications.
What is AVC?
Cisco Application Visibility and Control (AVC) is a solution that leverages multiple core technologies found in Cisco Aggregation Services Routers (ASR) 1000 Series, Cisco Integrated Service Routers Generation 2 (ISR G2) and Cisco wireless controllers.
The Cisco AVC solution offers a truly innovative approach to enable application awareness in the network. AVC incorporates application recognition with performance monitoring capabilities that were traditionally only available as dedicated appliances into the WAN router platform. Specific application policies can be applied to improve user experience efficiently over the network. This integrated approach greatly reduces the network footprint, simplifies network operations, and reduces total cost of ownership. The application information collected by Cisco AVC is exported in an open standard format such as NetFlow Version 9 and IPFIX, which allows both Cisco and third-party network management to support the Cisco AVC solution.
The Cisco AVC solution leverages multiple technologies to recognize, analyze, and control over 1000 applications including voice and video, email, file sharing, gaming, Peer-to-Peer (P2P), and cloud-based applications.
Cisco AVC consists of four functional components:
• Application Recognition: With Cisco AVC, Cisco ASR 1000, ISR-G2 and Cisco wireless controllers, can identify over 1000 applications within the traffic flow using NBAR2, an innovative Cisco Deep Packet Inspection (DPI) technology. In order to address the evolving nature of applications, NBAR2's application signatures can be updated through protocol pack while the router is in-service.
• Performance Collection and Exporting: Cisco AVC utilizes an embedded monitoring agent to collect application statistics, Application Response Time (ART) metrics such as transaction time and latency for TCP applications, and packet loss and jitter information for voice and video applications. These metrics are aggregated and exported using a standard flow export format such NetFlow Version 9 and IPFIX.
• Management Tool: With open flow export formats such as NetFlow Version 9 and IPFIX data export, Cisco Prime Infrastructure and other third-party network management tools can consume data exported by AVC for application and network performance reporting. This gives users flexibility to utilize Cisco management tools or to leverage other management tools of their choice.
• Control: By utilizing NBAR2, AVC devices can reprioritize critical applications or enforce application bandwidth use using industry-leading Cisco Quality of Service (QoS) capabilities. In addition, the routers can provide intelligent application path selection based on real-time performance with Cisco Performance Routing (PfR)
The PCoIP protocol provides real-time delivery of a rich user desktop experience in virtual desktop and remote workstation environments. To ensure a responsive desktop, the PCoIP protocol must be deployed across a properly architected virtual desktop network infrastructure that meets bandwidth, QoS, latency, jitter, and packet loss requirements.
PCoIP uses UDP packets similar to other real-time protocols (VoIP, video conferencing, etc.) but unlike typical UDP transport, it implements intelligent packet reliability and flow control similar to TCP. The protocol itself, with no outside QoS assistance, performs traffic shaping on PCoIP packets and dynamically adapts image and audio quality, depending on available network resources. PCoIP, along with all other traffic in the networks today, is subject to loss, latency and Jitter, which is where network based QoS guarantees are necessary. In order to provide network based QoS, the first step is to classify the application in question.
Until today, PCoIP identification has been loosely based on the TCP or UDP port number 4172, without consideration for the internal applications passing through the sessions. The typical ACL match is shown in Example 1 below. This example illustrates a single marking for PCoIP traffic, in which case the application differences are not known, therefore the applications are not individually given what they need to thrive in the network. In certain circumstances, latency sensitive voice applications may be crushed by bandwidth intense applications like video, this illustrates the need for more granular classification.
Example 1: PCoIP ACL based Classification
With the advent of NBAR2, PCoIP based applications can now be directly identified through deep packet inspection, regardless of the port, and thereafter controlled at high granularity. Application visibility is specified via a class-group or session-priority match protocol commands, which are detailed in section: Providing QoS for PCoIP using NBAR2. Providing application visibility allows network operators to circumvent the situation described above, where all PCoIP traffic is marked identically. With NBAR2, classification of voice, video, and other applications as separate entities based on the class-group or session-priority identifier, provides the application, not the protocol, with what it needs to thrive in the network.
In the instance that users are provided with voice, video and USB based services, all of the users traffic would be classified as a single type, without the support of PCoIP traffic in NBAR2, and would therefore be marked with only one value, meaning that there would be no way to provide varying treatment between the streaming video and USB transfer traffic. When congestion occurs, the users traffic would be subject to drop, without preference to the latency sensitive video streaming traffic - making video choppy and less effective.
An example to illustrate why traffic separation is vital, is when several users on the same network are vying for bandwidth. Several users making USB transfers or even HD video calls (which consume large amounts of bandwidth), while another user is watching a video on another virtual desktop, potentially hosted on another data center, could easily cause video traffic to be dropped. By blindly recognizing only that the traffic is PCoIP based, all of these traffic types would be placed into the same queue and serviced packet by packet, with no reference to the applications latency, loss or jitter requirements.
Examples cited above are easily remedied by using application visibility to classify the traffic and controlling the traffic by provisioning the correct amount of bandwidth to the individual applications as illustrated in subsequent sections.
Providing QoS for PCoIP using NBAR2
Starting with Protocol Pack 6.0 (PP6.0), NBAR2 includes enhanced support for detecting PCoIP granularly, to provide per session and per packet QoS. Using this feature, users can assign different types of traffic to different QoS queues and treat them with different priorities, assuring that the higher priority traffic gets better treatment, and improving the end user's quality of experience.
The basic level of support is detecting PCoIP through AVC or protocol discovery, and the next level of support includes defining match statements and a QoS policy to define the granular way traffic should be treated. Both per session and per packet granularity is supported.
For the granular QoS classification, PP6.0 adds the following parameters:
The session-priority parameter is determined at the beginning of the flow and is then applied to the rest of the packets in the flow. It can be used in cases where differentiation among sessions of different priority is sufficient (e.g. different users or application type).
The packet-priority parameter is calculated separately for each packet. It allows differentiating types of traffic across the same session or multiple sessions (e.g. file-transfer vs. HD video)
Class-group is a parameter that combines the packet priority and the session priority into a single value that is calculated per packet. It is useful to make sure that higher priority traffic always gets treated as higher priority, based on the session's priority or the packet's priority. For example, a file transfer will not disrupt a video stream, but at the same time, video from a display screen in the lobby will not be disrupted by video traffic from one of the stations in the hotel lounge.
The Legacy parameter can identify streaming traffic of older versions of PCoIP, where the granular classification like session-priority, packet-priority and class-group are not available.
The session-initiation parameter allows for classification of the SSL traffic that performs the `handshake' between the PCoIP server and client. Please note: the session-initiation parameter matches the SSL traffic of legacy deployments as well. See the Session-Initiation section for details on session-initiation caveats.
Installation and Configuration
The NBAR2 enhanced PCoIP support is introduced through a protocol pack into existing IOS and IOS-XE releases. For future releases, this support will be built into the IOS/IOS-XE images.
See the "versions" section for more information on supported versions.
Loading the Protocol Pack
In the case where a protocol pack needs to be loaded, use the following commands:
Protocol discovery provides a quick way to apply NBAR on the network interface, and see the traffic that runs through it, without the need for external integrations (such as a NetFlow collector).
It is not mandatory to use protocol discovery, but when first deploying it can help to quickly check that the basic classification function works well.
• Choose the network interface on which you wish to apply NBAR:
– Router (config)#interface gigabitEthernet 0/0/0
• Apply protocol discovery on that interface:
– Router (config-if)#ip nbar protocol-discovery
• After some traffic goes through, view the NBAR protocol-discovery counters (packets and bytes):
– Router #show ip nbar protocol-discovery
The virtual desktop traffic delivered through the PCoIP protocol should be identified as `pcoip'. This portion includes both the control flows and data flows. Depending on the deployment, you may see other related protocols such as vmware-view, which represents the VMware view connection server related traffic.
Using NBAR2 in QoS (Sub-classification)
NBAR Sub-classification is an additional parameter to the protocol ID. This is the NBAR functionality that classifies portions of the protocol that match more granular criteria and may be applied per packet as opposed to being applied to the entire flow.
NBAR2 enhanced PCoIP support adds a number of sub-classification parameters, depending on the release:
• Session-priority-the priority of the VDI session, as indicated by the PCoIP software. The following parameters are available:
• Packet-priority-The priority of the specific packet, as indicated by the PCoIP software. Currently, possible values are:
– 6 = Highest priority
– 5 = High Priority
– 4 = Low Priority
– 3 = Lowest priority
• Class-group-1 through class-group-12-the combined session and packet priority. This value can be used to map PCoIP traffic into the QoS queues. See Table1 below for details.
Note: older versions of NBAR support only 5 class groups - see the Applicable Versions/Platforms section.
• Session-initiation-matches the SSL sessions used for PCoIP session initiation.
• Legacy-matches traffic of PCoIP clients/servers that do not support the NBAR2 enhanced QoS.
Note: When using class-group based classification, it is not recommended to use packet-priority or session-priority. There is no error message when this misconfiguration is done, but it may not result in the expected behavior.
The following tables depict the possible values of the class-group parameters and their meaning.
Table 1. Class-group mappings to traffic type for NBAR releases that have 12 values
Default PCoIP traffic type
PCoIP session priority
Sub-classification parameter name
Recommended DSCP equivalence
802.1D User Priority
High-compression audio (future)
Keyboard, mouse, pointer
Real-time virtual channels
Table 2. Class-group mappings to traffic type for NBAR releases that have 5 values
Default PCoIP traffic type
PCoIP session priority
Sub-classification parameter name
Recommended DSCP equivalence
802.1D User Priority
High-compression audio (future)
Keyboard, mouse, pointer
Real-time virtual channels
Note: Class-groups 9-11 may contain a mix of traffic types such as large file transfers and smart card traffic. If smart card or similar devices are in use, consider modifying the DSCP marking to AF21 to be more technically accurate. The default recommendation for these groups is a DSCP marking of AF11 based on the BULK data transfers included.
To apply QoS, you need to define a class-map, include the class-map in a policy-map, apply some action for that class-map in the policy-map, and attach the policy-map to an interface, as follows:
1. Define a traffic class using the class-map command and match the desired sub-classification.
Note: match-any is used in the examples, it is non-default, and seems more useful in this context, e.g. when few groups are to be mapped to the same the same way.
In order to see the results of the policy map, the "show policy-map" command can be used, as above.
The output looks like this:
Review the output to identify whether packets reach the class-maps representing PCoIP traffic, and whether the expected type of traffic indeed increments (e.g. run some video traffic on the virtual desktop and see that the video class-map counters increment).
If the counters don't increment as expected, follow the following steps for further troubleshooting:
1. Verify that the PCoIP is properly classified:
a. Look at the protocol-discovery or AVC counters and see that the traffic is classified at high level as PCoIP
b. If it's not, check for these potential causes:
i. Traffic goes on another interface (or through an asymmetric path)
ii. The protocol pack installed doesn't contain the enhanced PCoIP support (use `show ip nbar protocol pack active' to view the PP version and make sure it's > 6.0)
2. If traffic is properly identified as PCoIP, but not properly sub-classified, check for these potential reasons:
a. Session-priority may not be detected properly when NBAR2 doesn't see the traffic from the initiation phase. Try closing all sessions and start them again, when the NBAR policy is already configured.
b. If the PCoIP traffic is of an old version of the PCoIP protocol, sub-classification will not work. Use the `legacy' parameter to identify that traffic specifically.
Performance Implications of NBAR2 for PCoIP
NBAR2 and DPI in general is CPU intensive, as it requires inspection into the payload rather than specific known locations in the headers. It is always a good idea to verify that the system has sufficient resources for the deployed configuration, as the specific configuration significantly affects the resource requirements.
When no sub-classification is turned on (e.g. protocol-discovery or AVC reporting only are enabled), the enhanced PCoIP support has no additional impact on performance.
In general, when applying QoS and specifically sub-classification based rules, there will be some impact on CPU utilization in the order of ~10%, (this will vary significantly depending on the platform and specific configuration).
When sub-classification based on session-priority is applied, the system will only need to inspect the beginning of the flows and will not need to inspect packet by packet, the impact will be minimal.
However, when configuring sub-classification based on packet-priority or class-group, the system has to inspect every packet and sub-classify it differently. Therefore, the higher the amount of PCoIP traffic running through the box, the higher the impact on CPU utilization.
To summarize, use per-packet (e.g. class-group) sub-classification only in situations where the device has enough free CPU resources to handle the additional load, compared to the amount of PCoIP traffic expected.
In other situations, session-priority could be the preferred option.
For more information, refer to "Session-priority Configuration Limitation" in the "Caveats and Limitations" section.
Example Configuration for QoS with PCoIP
This example is based on QoS concepts presented in the document: WAN Aggregation QoS Design 4.0. The QoS concept in the WAN aggregation QoS design guide mentions 3 models for QoS - 4-class, 8-class and 12-class models.
For simplicity, in this example, we will demonstrate adding an NBAR2 based policy for PCoIP to the 4-class model. Basically, the voice and video traffic is mapped to the highest priority and the signaling traffic to the signaling class. More granularity could be added by splitting the PCoIP class-groups into additional parts (the example is based on XE3.9).
Please note: The following text includes only the class-map definitions, not the policy map. The exact policy map can be found here in the original page.
First define the PCoIP related classes:
Providing Visibility for PCoIP with AVC
Cisco AVC utilizes embedded monitoring agents to collect and export application statistics and performance. That includes traffic statistics such as byte and packet count, URL collection, application response time and also media monitoring like voice or video.
With AVC providing the ability to recognize PCoIP traffic, a network administrator can define and use an application statistics profile to collect PCoIP traffic statistics. The following screenshot illustrates the AVC configuration with Cisco Prime 2.0.
At this time, AVC is unable to retrieve jitter and loss statistics from the PCoIP packets themselves. A good option is to use IP SLA probes. This will give jitter, loss and delay, but can also be used to assess a network prior to a deployment of a PCoIP solution.
Performance Routing will also be able to leverage IP SLA probes results and make an appropriate path selection decision.
Path Optimization and PCoIP
What is Performance Routing?
Performance Routing allows network administrators to minimize bandwidth costs, enable intelligent load distribution, improve application performance, and improve application availability. Other routing mechanisms can provide both load sharing and failure mitigation, however Cisco IOS PfR makes real-time routing adjustments based on application criteria such as response time, packet loss, jitter, path availability, interface load, and circuit cost minimization.
Performance Routing is used is various cases that are summarized below.
Better Use of WAN Links
Many customers have multiple links to the WAN, being privately held or managed by a service provider.
In many cases, one link is considered as the primary, while the other one is considered a backup that leads to a waste of resources:
• Traffic increases are badly load-balanced across central site uplinks
• Expensive backup links are under utilized
• Load-sharing through complex BGP tricks or PBR
• Manual check of NetFlow stats, IP SLA probes and prefix utilization
PfR can be used to alleviate and help solve these problems and distribute the traffic based upon load.
Better Application Performance and Availability
Many users would like to be aware of fluctuating service levels, soft errors or brownouts. Routing protocols are not aware of these types of events. In the case of a VDI deployment, this could lead to bad user experience and application performance degradation.
PfR can be used to track the performance issues and fallback the traffic (including the PCoIP traffic) to a secondary link based upon application delay, loss, jitter and bandwidth.
One of the key requirements is to be able to route not only based on the prefix, but also based on the type of application. Forwarding should take the best path for an application rather than a prefix. Deep packet inspection engine NBAR2 plays a key role here and especially for the PCoIP protocol support.
PfR Classification and PCoIP NBAR2 Support
PCoIP traffic has to be assigned to the critical service class of the enterprise WAN deployment use case.
The main challenge with PfR and PCoIP traffic is that NBAR2 cannot be used today directly within PfR to classify the traffic. The current generation of PfR only supports a small subset of all signatures that are part of the NBAR2 protocol pack.
But there is a `workaround' that can be deployed and leverages the support of NBAR2, and the support of the PCoIP protocol:
• Configure NBAR2 with QoS marking on ingress. Refer to the class-group to DSCP table mapping defined previously.
• Configure PfR learning based on DSCP value, which is a very common use case in current deployments.
This workaround has a few pre-requisites:
ISR-G2 - workaround:
• Disable NetFlow in PfR border routers global configuration
• Enable NetFlow ingress/egress on the WAN interfaces
To gather PCoIP performance measurements, it is recommended to use an active measurement mode called Fast mode with a probe frequency that matches the application requirements. Refer to the PfR Technology overview located here for more information on the measurement modes. To acquire performance metrics, the router will need to inject instrumented synthetic traffic and derive the required information from there. PfR makes use of the IOS IPSLA feature to generate probes and collect information about the state of the network.
Performance Routing is using a feature called Target Discovery to simplify the configuration and deployment of the active monitoring mode and the need for an IP SLA responder address configuration. A peering session is configured between the Master Controller (MC) on the central site and the MCs on the remote sites. The MCs that participate in this peering will exchange the list of inside prefixes and IP SLA probe responder addresses that belong to the sites, along with the site name (configurable).
To enable PfR Domain and Target Discovery on the central site:
To enable PfR Domain and Target Discovery on the branch offices:
To enable Learning:
Then define the policies for the critical traffic (including PCoIP). Values given below are examples that should be tuned according to the users' needs:
• Match command is to specify that this policy should be applied to all the traffic-classes learned under list: LEARN_CRITICAL
• Monitor mode is set to fast. This means probe all external interfaces all the time. When an Out-of-Policy (OOP) condition is detected on the current exit results, an alternate exit is available for quick decision. In other modes, alternate exits are probed only when the current link is determined to be OOP. The fast mode helps in switching the path quickly when the problem is detected.
• Re-evaluate the exit every 90 sec (periodic 90)
• Delay threshold is configured as 200 msec. The delay measured by PfR is Round-Trip-Time (RTT).
• Loss threshold is configured as 5%
• Probe frequency is set to 8 seconds and can be changed to a lesser value if the application being controlled is critical.
• Probes are automatically configured and generated by Target Discovery
• The preferred path is SP1 and the secondary path is SP2. This is usually the case where SP1 is a primary IP-VPN with given SLA, and SP2 is a secondary path over the public Internet using some form of encryption such as DMVPN. Remove this command to just load-balance the critical traffic over all external interfaces.
Caveats and Limitations
The PCoIP session initiation traffic is an SSL flow. It can only be identified by the server certificate used. In most deployments, the default certificate from Teradici is used, but in some deployments it may be replaced by a local certificate. In order to allow the "session-initiation" parameter to match this SSL traffic, the certificate name must have the string "PCoIP" in the common-name field. Otherwise, the session initiation traffic would be classified as "SSL".
Legacy PCoIP Traffic
In an older PCoIP client/server, the PCoIP protocol cannot be classified to a higher granularity than just PCoIP. See the Applicable Versions/Platforms section for the PCoIP products that support this enhanced functionality.
In the case where the network contains a mix of the old and new protocols, it is recommended to assign high enough priority to the legacy protocol, so that the users of legacy clients would still get the best user experience.
Depending on the collector type and version, application visibility of PCoIP is only possible at the protocol level and not along with the different sub-classification parameters such as "class-group".
NBAR2 may need more than a single packet in order to classify traffic as PCoIP. Therefore, the policy can be applied only from the packet where the classification is performed, and it may be that the results of the policy would not be seen for the first few packets of each flow.
On ISR-G2 with versions of Cisco IOS Software Release 15.2(4)M or 15.3(1)T or 15.3(2)T and on IOS-XE based with versions of 15.2(4)S and 15.3(1)S, there are 5 available class-groups according to Table 2 in this document. However, starting from ISR-G2 with versions of 15.3(3)T and IOS-XE based with versions of 15.3(2)S, there are 12 available class-groups, as described in Table 1 in this document.
On a version upgrade, the sub-classification will match different types of traffic under the pre-configured class-group. After the upgrade, the class-group sub-classification configuration needs to be re-evaluated according to tables 1 and 2 and the desired traffic type.
Session-priority Configuration Limitation
• ISR-G2 with Cisco IOS Software Release 15.2(4)M or 15.3(1)T or 15.3(2)T
• IOS-XE based with 15.2(4)S and 15.3(1)S
When the option of using only session-priority sub-classification is chosen in order to avoid performance issues, the configuration limitation is:
• If desired to match also session-initiation or legacy sub-classification along with session-priority, make sure to configure "match" for all available session-priority options.
• If session-initiation or legacy is not needed, "match" only the desired session-priority, this will not result in CPU impact.
• In a case where CPU utilization is not an issue, all configurations are valid.
• Under any configuration, there won't be any classification differences.
!--- Matching legacy or session-initiation according to needs.
!--- All parameters of session-priority are configured.
Please note: On IOS-XE versions earlier than IOS-XE3.9 (15.3(2)S) and IOS versions earlier than (15.3(2)T), the number of parameters is limited due to engine limitations. The following table shows which parameters are supported on which platforms/versions:
Table 3. PCoIP parameters supported per version/platform
ISR-G2 with 15.2(4)M or 15.3(1)T or 15.3(2)T
IOS-XE based with 15.2(4)S and 15.3(1)S
ISR-G2 with 15.3(3)T and later
IOS-XE based with 15.3(2)S and later
PCoIP Solutions for VDI and Remote Workstation Deployments
VMware Horizon View 5.1+
PCoIP Remote Workstation Solution
Tera2 host card with firmware 4.1+
PCoIP Zero Clients
Tera1 PCoIP zero clients with firmware 4.0.2+
Tera2 PCoIP zero clients with firmware 4.0.3+
VDI Software Clients
VMware View Client 5.1.0+ (Windows)
VMware View CRT Client 1.5.0+ (Linux, Mac OS X, iOS, and Android)
For more information, please refer to the following: