When we talk to customers about VDI in general and Unidesk (which is very open to almost all connection brokers and VDI protocols), we are often asked which remote protocol is “the best” for VDI.
Well, everyone has preferences, knows certain tools and may have used them in the past, so it is understandable that such questions arise in relation to VDI. The question “what is best” depends more on how the ideal situation should actually look like in your particular environment.
Basic questions
At this point, we would like to address some basic questions that should always be asked at the beginning in order to provide users with the best possible VDI experience.
The answers will give you the respective evidence for choosing the right remote protocol:
Do users use multiple monitors per workstation?
Are HD audio and video needed? And if so, how many channels or which resolution?
Do additional devices have to be supported on the end device, such as external hard drives, printers, scanners, webcams, DVD writers or the like?
Is security guaranteed by encryption?
The first question is intended to find out which overall resolution has to be transmitted to the end device or calculated on the end device, and how this affects the required bandwidth. Most modern remote protocols support two monitors — through improvements, some manufacturers can now control up to four monitors. This sometimes requires special configurations or some tuning to make the result acceptable to users.
Once the audio and video requirements are known, it should be checked whether additional bandwidth is required for certain programs. For example, if you want to use dictation software that requires four stereo channels, each with 16 kHz, or unified communication systems such as Microsoft Lync with a webcam, you should take a closer look at the requirements of these programs.
Close attention should also be paid to the requirements for certain end devices: Do certain users need to copy files, scan with peripheral devices, use local printers or USB devices? A closer look ahead can save IT support a lot of hassle and effort. If the peripheral device only runs with USB 3.0 support, you should rely on a remote protocol that also supports this.
Terminal devices
Speaking of terminal devices: It is not wrong to think about what the terminal devices should look like in the future. Usually, “zero clients” are used in connection with VDI that have a minimal (hardly manageable) OS, so that the future effort is close to zero. If you prefer to continue using the old PCs (e.g. with Stratodesk) or thin clients, you should think about how often and with what amount of time maintenance is necessary.
Basically, for most remote protocols, data traffic is initially not encrypted. However, if this is necessary, the cost of any additional hardware or virtual appliances should be taken into account. Here too, necessary updates can result in costs due to maintenance time windows. One way or another: You will probably need a few tries to design the protocol so that all users are satisfied with it.
The Top Dogs
Now let's take a look at the three most popular remote protocols and see how they affect a VDI project: HDX (Citrix), RemoteFX (Microsoft) und PCoIP (Teradici/VMWare).
TCP vs. UDP
The entire OSI model is not to be unravelled here, but these basics are important to find out what is “best” for the project. Remote protocols use Transport Layer 4 to implement “Flow Control”, “Error Detection”, “Error Recovery” and “Data Delivery”. The two protocols used in Layer 4 are TCP and UDP. The main difference is that everyone considers TCP to be particularly reliable, but not UDP. In short, TCP is reliable because computers are not or cannot be reliable. Each time a program sends data, these packages are grouped together and an acknowledgment of receipt (“ACK” - short for “acknowledgment”) is sent back to the sender to let him know that all packets in the group have arrived. If the sender does not get an ACK of a package group, the package group is sent again (retransmit). And that is exactly the reason why TCP is particularly reliable. However, this reliability is paid for with a reasonable overhead (via several ACK and retransmits). UDP, on the other hand, does not send an ACK. This confuses some administrators because the ACK gives them the certainty that the data have arrived at the users. The question may be permitted: Is this really what you need?
Imagine you want to transfer a PDF or Word document: The file must be exactly the same on both sides, otherwise you would not be able to open the file on the recipient side. So you primarily need reliability. However, when you watch a video, the data must arrive as quickly as possible — and UDP can do that pretty well. You don't want stuttering movie scenes or distorted sounds. But this can happen when using TCP.
History
At the beginning of the Internet there were restrictions on the number of monitors a user could have :-). Citrix’ HDX is based on the ICA protocol, which was launched in 1990 (at that time, for example, there was no Adobe Flash). Citrix has continued to develop the ICA protocol and added new functions. Calista Technologies was purchased by Microsoft in 2008 to introduce features required by RDP such as DirectX support, USB forwarding, and acceleration on WAN connections. Teradici developed PCoIP in 2004, and VMWare has licensed the protocol since 2008. Since PCoIP was developed only relatively recently, the main goal was to establish the most secure remote connection possible (even if security creates additional overhead).
Current
In 2015 there are no significant differences between them all — at least in the LAN area (provided that no more than four monitors per session are needed). The question is rather how high your effort may be. Because to properly support the user sessions, you should take a closer look at the existing network for each remote protocol. Each protocol will need to be adjusted in terms of package sizes, prioritisation and security so that users receive an acceptable performance.
Light and shadow
Basically, encryption is not built into HDX and RemoteFX. If you come from the banking or government sector, this could be a requirement for your VDI project. Devices such as the NetScaler Gateway from Citrix or Cisco's WAAS help here. Please note: If you use such devices, either your employees should be allowed to familiarise themselves with it or you should hire external consultants (which might make the project a little more expensive). In the vast majority of scenarios, such devices are designed redundantly, so that there is reliability and thus firmware/OS updates can also be imported without downtime. Most admins find that the devices can be configured and used relatively quickly — close to an “out of box” implementation.
There are basically standardised monitor resolutions for HDX and RemoteFX. Therefore, the screens of the terminal devices should be configured correctly. In order to be able to use monitor functions such as EDID, adjustments may have to be made in the ThinClient or in the VDI-OS. Frame rates are also important and you may not be able to get beyond 1080p without dampening the user experience.
Those who use PCoIP mostly do so because of the built-in security. But also here a lot has to be tested in order to properly tune the existing network for LAN or WAN connections. “"Quality of Service” rules and prioritisation are very important here, so that the tunnel is large enough for video, audio and USB redirection. For this reason, you can usually only find devices connected via USB 1.1 in the PCoIP sessions. This is important to know, because if, for example, webcams are to be used with Microsoft Lync, it must be ensured that they also work with USB 1.1. PCoIP also sends a 1080p resolution as standard — which, however, can be a hindrance compared to other protocols with WAN connections. (Here Citrix is still hard to beat, especially at high latencies (> 250ms).)
Each protocol has its strengths and weaknesses when it comes to media formats such as DirectX, Flash, H.264 or MPEG. You should find out which program has which requirements and you should definitely include this in the decision for a protocol.
Test, test, test
As with all innovations, all initial requirements should be tested and if possible all future requirements should be identified so that users are happy to accept the changes and the whole thing is scaled for all requirements. Remember to test, write down benchmarks and test again. Attentively track/write down the workload for configuration, tuning and maintenance.
If you go through all the points shown, you should see tendencies for one or the other protocol.
We are happy to help you to make your choice — just contact us without obligation.
Yours sincerely,
Gordon Kirstein
