Skip to content

Network and System Requirements

The following sections outline the important network requirements and guidelines to take into consideration when setting up a PCoIP session. This section covers the following areas:

General Network Guidelines

  • Consider quality of service options such as Class-Based Weighted Fair Queuing (CBWFQ) or Low Latency Queuing (LLQ) on switch uplinks and on Layer 3 WAN/LAN links.
  • Mark and classify PCoIP traffic the same as real-time interactive traffic according to your quality of service marking scheme. (namely, below VoIP RTP but above all other traffic). This is necessary for the real-time responsiveness of the protocol.

Packet Management

  • If using DSCP markings, PCoIP traffic should be marked to DSC AF41 or AF31. This ensures low drop probability inside each queue if weighted random early drop (WRED) must be configured for the queue servicing the PCoIP protocol. The choice of which DSCP value to use is influenced by the presence of possible video and/or VoIP control packets.

    End-to-End priority mapping

    Not all switches support the same number of priority queues. Work with service providers to ensure proper end-to-end priority mapping.

  • Avoid using LLQ for PCoIP packets on links that do not carry VoIP and have availability greater than 1.544 Mbps. Consider the 33% LLQ rule, which limits the amount of strict priority queuing configured on an interface to no more than ⅓ of the link's capacity. The strict priority queue should only be considered if performance is suffering and there are many different types of traffic competing with PCoIP.

  • Avoid adjusting the maximum transition unit on low bandwidth links. PCoIP protocol packets should not be fragmented. It may be difficult to guarantee high-quality conversations with both VoIP and PCoIP on links with less than 1.544 Mbps of bandwidth.

  • Consider tuning the hardware transmit ring to '1' to ensure that software queuing takes place if LLQ is not possible, and PCoIP or VoIP are experiencing high jitter.

    Large pack serialization

    Large pack serialization can sometimes cause high amounts of jitter. This should not be done in most cases as proper CBWFQ usage will allow for acceptable guaranteed session quality.

  • Increase the queue depth settings in the PCoIP queue if tail drops are experienced. If you are near the maximum recommended queue depths, consider optimizing PCoIP for lower bandwidth or increasing the link bandwidth.

  • Packet loss should be zero for properly configured LAN/WAN deployments. Packet loss within a single PCoIP session should target less than 0.1%. Users typically notice performance degradation if the session packet loss is greater than 0.1%, although higher loss may be tolerated.

  • PCoIP packets that arrive excessively out of order may be considered as lost packets by the PCoIP protocol. Avoid packet re-ordering in the network. This will show as packet loss in the PCoIP session logs, but not in network device logs.

  • Ensure that PCoIP packets are not fragmented at any point in the network path.

  • Ensure that the maximum transition unit in network devices is not below the PCoIP packet maximum transition unit size. Defaults are 1200 or 1300 bytes for PCoIP software (depending on the vendor), and 1400 bytes when connecting PCoIP zero clients to PCoIP remote workstation cards. Increase router maximum transition unit before reducing PCoIP packet maximum transition unit, as lower PCoIP protocol maximum transition unit can impact desktop performance. Keep in mind that network devices may add additional encapsulation and increase the PCoIP packet size.

  • Do not use per-packet load balancing for any load balancing decisions along the path of traffic, including but not limited to EIGRP load balancing, static route load balancing, and MPLS load balancing.

    Out of order packets

    Out of order packets adversely affect the quality of the PCoIP protocol.

  • For load balancers, ensure affinity (or related) is set to '1'. Ensure that the same Source Address/Destination Address is sent on the same path.

  • Ensure that small packets are not prioritized over larger packets. This can cause PCoIP packet reordering, as small PCoIP packets jump ahead of larger ones.

WAN Guidelines

  • Ensure that your classification and quality of service schemes inter-operate with your WAN carrier's quality of services schemes. This is especially applicable to MPLS networks.

    MPLS networks

    Most WAN carriers only offer three or four different classes of traffic on MPLS networks.

  • Configure WAN optimization devices to bypass PCoIP packets, unless the devices explicitly support the PCoIP protocol. Some WAN optimization products can impact PCoIP packets, causing increased latency and packet loss, as well as packet reordering.

WRED and VLAN Layer Configuration

  • Configure WRED in the path of all PCoIP conversations. On Cisco routers this is the 'random-detect' command. The PCoIP protocol incorporates rate limiting and flow control mechanisms optimized for virtual workloads such as VDI or cloud-based graphics applications.

    NDP Protocol

    The Neighbor Discovery Protocol (NDP) is a protocol in the Internet protocol suite used with IPv6. Unlike most NDP traffic, PCoIP protocol benefits from WRED mechanics. When an WRED algorithm causes packet loss PCoIP protocol adapts to network congestion with minimal impact on the user experience. If a Tail Drop scheme is deployed, large bursts of PCoIP data may be suddenly dropped by the network before PCoIP protocol has time to adapt to congestion.

  • Confirm that the network interface is not configured for WRED if you have selected WRED for the service policy on that interface. Configuring WRED on the physical interface overrides all other quality of service queuing configurations.

  • Consider segmenting PCoIP traffic via Layer 2 VLAN and/or class of service types at the access layer of your network.

  • Only use Layer 2 quality of service class of service prioritization if there is noted congestion at the access layer or between the access and aggregation (distribution) layer. Consider adding Layer 2 uplink bandwidth before applying Layer 2 quality of service, if possible.

  • Avoid the use of AutoQoS features at the Layer 2 layer for devices that do not explicitly support AutoQoS for PCoIP packets, as this may result in WRED being applied at the switchport layer through the use of Shared/Shaped Round Robin (SRR) queues. When using the AutoQoS feature, SRR queues are automatically configured on many access layer platforms. By default, these enforce WRED for all but trunked packets marked with class of service 5 (generally VoIP packets from a hardphone). Often PCoIP packets are treated as scavenger class traffic, which can negatively impact desktop performance.

  • Avoid traffic shaping unless absolutely necessary. Shaping works to smooth traffic bursts and achieve a defined committed access rate (CAR) by buffering packets. Traffic shaping increases PCoIP packet latency and can impact user experience. If necessary, consider traffic policing as an alternative.

  • Ensure that a full-duplex end-to-end network is used.

    Monitoring older switches

    Older switches may incorrectly default to half-duplex when connected to a link with auto-negotiation. In this case, explicitly set the switch link to full-duplex.

Network Port Guidelines

  • Ensure that network ports are open for the PCoIP protocol and virtual desktops. For details, see the Knowledge Base article FAQ - What are the required TCP/UDP ports for PCoIP technology?

  • Ensure that PortFast is enabled on all network ports that have PCoIP end points connected to them.

    PortFast mode on an IP phone

    If an IP phone is connected between the client and the switch, you may need to set a different PortFast mode because of the internal switch inside the phone. This ensures that the port is immediately configured to forward traffic in the event of a spanning tree recalculation.

  • Ensure intrusion protection services (IPS) in network devices and/or laptop/desktop software have been disabled or configured to allow the PCoIP protocol and other virtual desktop network ports. IPS can block some or all network ports and/or throttle bandwidth for the PCoIP protocol.

  • Avoid gaps in network connectivity. PCoIP sessions will disconnect after 30 seconds of loss in traffic in either network direction or the PCoIP port (4172 UDP). Intrusion protection services (IPS) or intrusion detection services (IDS) should be disabled, or configured to allow (4172 UDP).

Latency Guidelines

  • Ensure that the round trip network latency is within specification. Excessive latency will impact desktop performance.
  • Latency should be less than 250 ms round trip for virtual desktops, HP Anyware and PCoIP remote workstation cards.
  • Ensure the latency variation is less than 30 ms.

    Latency variation for a remote workstation implementation

    For a remote workstation implementation, ensure that the latency variation is limited to approx. 1 frame when playing a 30 fps (HD) video.

VPN Guidelines

The following are a list of VPN guidelines that we encourage users to follow:

  • The PCoIP protocol provides end-to-end AES-256 encryption of all traffic. When used in conjunction with a security gateway, corporate security compliance objectives can generally be achieved without the need for a VPN. However, PCoIP may be used with UDP-compatible VPN solutions. TCP-based VPNs are not supported.
  • If a VPN is required, confirm that UDP traffic is supported (IPsec, or DTLS-enabled SSL solutions). Do not route PCoIP traffic through TCP-based SSL tunnels.
  • Use QoS Pre-Classify if CBWFQ or LLQ is necessary on the outgoing interface of the VPN device. This may not be available on many platforms or in many designs.
  • PCoIP does not support packet fragmentation so avoid using a VPN that restricts the MTU for packets transiting the VPN.
  • Confirm the VMware ESXi virtual switch traffic shaper is turned off.
  • Determine the nature of other protocol traffic that exists on the network, especially other high priority traffic that could impede PCoIP forwarding.
  • Ensure the network meets the requirements for real-time protocol deployments, including latency, jitter (latency variation), and packet loss within specified PCoIP limits.
  • Optimize your network for virtual desktop connections. For details, see the following KB articles:
  • When deploying ZScaler Private Access (ZPA), follow ZScaler recommendations for UC traffic and configure ZPA to bypass IP addresses configured for PCoIP connections. Sending PCoIP traffic to ZPA interferes with PCoIP network adaptation and increases latency. Consider a VPN alternative described below.

Why avoid TCP-based VPN or TCP Display Protocols?

TCP-based protocols (including TCP-based VPNs) provide guaranteed packet delivery. All dropped packets are retransmitted by network layer protocols regardless of their attributes; this increases interactive latency and more seriously, can cause a phenomenon termed congestion collapse when multiple connections are streamed over a shared high latency network. Additionally, PCoIP uses packet loss statistics as a feedback parameter for intelligent network bandwidth adaptation, if the VPN masks the true network capability, bandwidth management is impeded, and the user experience is compromised.

VPN Alternatives

HP Anyware and the Anyware Connector offer highly secure encrypted remote access to enterprise desktops without the need for VPN technology. Cloud Access Manager includes multi-factor Authentication (MFA), secure connection management and a secure network address translation (NAT) gateway allowing public IP addresses for PCoIP traffic. Consult the HP Anyware Architecture Guide for further details on:

Session Establishment

For troubleshooting tips, FAQs and specific documentation around PCoIP Session Establishment, see FAQ - PCoIP Session Establishment in our knowledge base. This article includes guidelines, troubleshooting checklists, and links to the connection instructions found in component guides.

Cisco Router Configuration Example

The following example contains marking and Class-Based Weighted Fair Queuing (CBWFQ) with Low Latency Queuing (LLQ) for VoIP. SIP traffic is not treated. The example assumes a LAN Ethernet interface and a WAN Serial T1 interface. Quality of service is configured to guarantee the following:

  • Strict priority for four G.729 VoIP calls marked as EF.
  • Reserved bandwidth for two 'task worker' PCoIP sessions marked as AF41 (500 kbps minimum peak bandwidth, limited ability for over-subscription).
  • The default class gets all the remaining bandwidth and is fair queued.

Sample Cisco router configuration settings:

!match PCoIP packets

access-list 100 permit tcp any any eq 4172
access-list 100 permit udp any any eq 4172

class-map match-all VOIP-IN
match ip rtp 16384 16383
class-map match-all PCOIP-IN
match access-group 100

class-map match-all VOIP-OUT
match ip dscp EF
class-map match-all PCOIP-OUT
match ip dscp AF41

policy-map ETH-IN
class VOIP-IN
set ip dscp EF
class PCOIP-IN
set ip dscp AF41

policy-map SERIAL-OUT
class VOIP-OUT priority 128
class PCOIP-OUT
bandwidth 1000
class class-default
fair-queue

interface Serial 0/1
bandwidth 1544
no fair-queue
service-policy output SERIAL-OUT

!trust dscp markings coming into this router from across the WAN
!do this if you need Layer 2 COS QoS and have a DSCP-COS map defined or set COS on e0/1

mls qos trust dscp

interface Ethernet 0/1
service-policy input ETH-IN