People are always arguing about which remote desktop protocol is best: PC-over-IP versus HDX versus RDP versus RemoteFX, etc. All of these remoting protocols are "Layer 7" protocols on the OSI stack, but I'd like to focus on Layer 4, which for remoting protocols, can be either TCP or UDP.

By submitting your personal information, you agree to receive emails regarding relevant products and special offers from TechTarget and its partners. You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

Citrix points out that HDX (or High Definition Experience) is "TCP-based," while VMware boasts that PC-over-IP (PCoIP) is "UDP-based," and each claims that its protocol is best. But which one is truly better?

The answer isn't black or white. But first, a Layer 4 protocol primer:

The main difference between TCP and UDP is that Transmission Control Protocol is reliable, and User Datagram Protocol is not. You might think, "Well, duh ... this is a no-brainer then. Of course we want TCP because we want our remote protocol to be reliable!" But for desktop virtualization, we have to dig a bit deeper.

TCP is a reliable protocol. Applications that communicate via TCP can just send whatever they want to the protocol stack, and the stack will ensure that 100% of the data actually makes it to the client, in the right order, without any errors. And if it doesn't, the protocol stack will report back to the application that some packets were lost.

Of course, computer networks themselves are not reliable, so the reliability of TCP is actually built into the TCP stack. The way this works is that every TCP packet that's sent out has a sequential identification number in it. The receiving computer receives a stream of packets and reassembles them into the original data stream based on those sequence numbers. Every so often, the receiving computer sends a status acknowledgement to the sending computer (known as the "ACK") that basically lets the sending computer know that everything has been received.

These ACKS are not sent for every single packet. Instead, they're sent only after groups of packets. The exact number depends on what operating system you're using and what the current network conditions look like. The sending and receiving computers constantly tune how many packets are received before an ACK is sent. (This is known as the TCP window.)

So the sending computer is sending a stream of packets while receiving the ACKs in return, and everything is OK. But if the sending computer doesn't get back one of the ACKs it was expecting, then it thinks, "Uh-oh, there's a chance the receiving computer missed a packet. And since TCP is 'reliable,' I had better resend it."

So there you have it: All these ACKs and confirmations and resends work together to ensure that TCP packets are 100% confirmed to have been received, or else the app is told otherwise.

UDP, on the other hand, is not reliable because the sending computer assumes that the packets made it to the receiving computer. And if a packet doesn't make it, the sending computer has no idea. It just keeps on sending whatever's next.

While TCP is more reliable, that reliability comes at the expense of more overhead for all the ACKs and retransmits. UDP has less overhead, but there's a chance that some packets will never show up to their destination or that they will show up out of order.

Which is better? It depends on your application.

More on protocol

In the simplest case, if you're transmitting a file from one computer to another, you need the entire file to get there. If you need it to be a perfect copy, then you need something reliable like TCP. But if you're streaming a video, it's more important to get the data there fast, so UDP is better.

In the case of video streaming with UDP, if you lose a packet, so what? So a few pixels of the video glitch for a few frames -- no big deal! In fact, if the video were transmitted via TCP, by the time the sending computer would realize that it hadn't received an ACK for certain packets and resent them, the video on the receiving computer would be long past the part with the missing packets, and the retransmitted packets would be worthless by the time they showed up anyway. So why waste all that effort on "reliability?"

Now let’s apply this all to remoting protocols.

PC-over-IP is UDP-based, which, given the video example above, probably makes more sense for a remote display protocol. However, certain aspects of the remote protocol must be reliable, such as client-to-host file transfers and client USB device redirection. This means that the makers of PCoIP had to write their own reliability algorithms into the protocol that are invoked when it's doing certain things. So it could be said that PCoIP is reliable when it needs to be and unreliable when reliability isn't priority.

There's one major problem though: When users connect to their virtual desktop infrastructure (VDI) environment from outside the firewall, they connect through a virtual private network (VPN), and the vast majority of VPNs in the world today are TCP-based.

TCP-based VPNs still work with UDP-based protocols like PCoIP, but they do so by "wrapping" the UDP communications inside TCP while they traverse the VPN. And since TCP is always reliable, now you have the overhead of reliability for a protocol that doesn't expect it, and performance suffers. And of course, PCoIP has no idea that it's being wrapped in TCP, so the reliable parts of PCoIP that are used for USB and stuff are doing all their work and adding all their overhead for nothing!

The bottom line is that performance suffers when PC-over-IP it is used with a TCP-based VPN. VMware is trying to solve this releasing its own Security Gateway SSL-VPN add-on for View. That might be a challenge for companies to implement because many of them already have a VPN solution, and it's sometimes hard to convince security people that you need to use a separate VPN just for a virtual desktop project.

This is something that Citrix plays up. It says, "Hey, since your VPN is TCP-based anyway, why not use a remoting protocol that's already TCP so you don’t add all this overhead?"

Of course, there are other differences between PC-over-IP and HDX, and it's unlikely that you’re going to choose one based solely on what Layer 4 protocol it rides on. Actually, it's unlikely that you're going to choose VMware View or Citrix XenDesktop based solely on PCoIP or HDX, but at least you are now able to talk about the relative advantages and disadvantages of a remoting protocol using TCP versus RDP.

ABOUT THE AUTHOR:Brian Madden is an independent industry analyst and blogger, known throughout the world as an opinionated, supertechnical desktop virtualization expert. He has written several books and more than 1,000 articles about desktop and application virtualization. Madden's blog,BrianMadden.com, receives millions of visitors per year and is a leading source for conversation, debate and discourse about the application and desktop virtualization industry. He is also the creator of BriForum, the premier independent application delivery technical conference.

E-Handbook

E-Handbook

4 comments

E-Mail

Username / Password

Password

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy