Network Requirements

Mark and classify PCoIP traffic the same as real-time interactive traffic according to your quality of service marking scheme. (namely, below VoIP VoIP Real-time Transport Protocol (RTP) but above all other traffic).

This is necessary for the real-time responsiveness of the protocol.

If using Differentiated Services Code Point (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.

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 1/3 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 to decrease serialization time for VoIP packets. 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 packet serialization can sometimes cause high amounts of jitter. This should not be done in most cases as proper CBWFQ usage will enable 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.

On a Cisco device, look for the drop rate on the 'show policy-map interface' command.

Ensure that your classification and quality of service schemes work with your WAN carrier's quality of services schemes. This is especially applicable to Multiprotocol Label Switching (MPLS) networks.

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

On Cisco routers this is the 'random-detect' command. The PCoIP protocol incorporates rate limiting and flow control mechanisms optimized for virtual desktops.

Note: Unlike traditional UDP applications, WRED will work with the PCoIP protocol, and gradual packet loss allows time for the PCoIP protocol to adapt. Tail drop does not allow time for the PCoIP protocol to adapt and alleviate the congestion before user experience is impacted.

Confirm that the network interface is not configured for WRED if you have selected WRED for the service policy on that interface.

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.

Note: 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.

Ensure that network ports are open for the PCoIP protocol and virtual desktops. For details, see the Teradici Knowledge Base article 15134-114.

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

Note: 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 enable 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.

Latency should be less than 250 ms round trip for virtual desktops and PCoIP remote workstation cards.

Ensure the latency variation is less than 30 ms.

Note: About 1 frame for 30 fps (HD video) is a common default for PCoIP software in virtual desktop products.

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. See Configure the PCoIP Session Bandwidth Floor to deal with persistent packet loss that cannot be addressed (for example, wireless networks).

PCoIP packets that arrive sufficiently 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.

Avoid gaps in PCoIP protocol traffic. 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 enable (4172 UDP).

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 Enhanced Interior Gateway Routing Protocol (EIGRP) load balancing, static route load balancing, and MPLS load balancing.

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.

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.

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.

If a VPN is used, confirm that UDP traffic is supported (IPsec, or Datagram Transport Layer Security (DTLS) enabled SSL solutions).

Do not route PCoIP traffic through TCP-based SSL tunnels.

Avoid VPN overhead. If possible, consider a VPN-less secure remote access solution that supports the PCoIP protocol.

Use Quality of Service (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.

Determine other protocol traffic that exists on the network, especially other high priority traffic that could impede PCoIP forwarding.

Determine the network characteristics that are key for a successful real-time protocol deployment, including latency, jitter (latency variation), and packet loss.

Optimize networks for virtual desktop connections.

For details, see the Knowledge Base topics 15134-242 and 15134-880 on the Teradici support site.