Teradici enables PCoIP deep packet inspection for network QoS vendors.

One of the cool things I saw at VMworld 2013 San Francisco a few weeks ago was a demo from Teradici showing off how PCoIP now has the capability to write packet priority tags into its UDP headers which can then be read by network QoS products. The specific example showed PCoIP integrated with Cisco's NBAR (Network Based Application Recognition) QoS solution, and we shot a video showing three PCoIP screens on a busy network—one with no QoS, one with the generic Cisco QoS that Teradici and VMware have been recommending for years, and one with the new NBAR-enabled QoS.

Here's a video of the demo and a quick conversation I had with Teradici's Simon Le Conte. Keep reading after the video though because there's a lot going on here we have to discuss.

Why are we only getting this now?

To be clear, I like Teradici. I like PCoIP. Teradici deserves a lot of credit for seeing the need for a new protocol to do the "entire" desktop (browsers, multimedia, VoIP) and building that with UDP in the mid-2000s when everyone else was still using ICA and RDP via TCP to connect to remote client-server apps. Teradici also gets points in my book for staying cool despite that fact that VMware just licensed their stuff instead of buying them outright. (You all know that expression, "Why buy the cow when the milk is free?" Now imagine that from the cow's perspective!) And I really like that Teradici brought PCoIP into the RDSH world on their own when VMware wouldn't. (That took balls. Now make it so we can buy this without using Horizon View as the connection broker and we've really got something here!)

All that said, the main thing I don't like about Teradici is their protocol has been an encrypted black box all these years. Network tools can't see inside it. You can't rip it apart and reassemble it based on what you want to do on your network. You can't see whether the PCoIP traffic on your network is full of pixels or USB data or audio or what. Teradici's basic attitude has been, "Our protocol is awesome and completely self-tuning. We're using UDP port 4172, and that's all you need to know." (Then they tap your cheek with a cupped-hand a few times and call you 'doll.')

So why is this? I don't know exactly. My sense is it's a combination of (a) Teradici wanting to get more money by licensing these details to partner companies, (b) not wanting to expose the technical details of their products to the competition, and (c) part of the overall brand of "PCoIP self-tuning and just works. (After all, if you have to get into these technical weeds, that's because something isn't auto-tuning.)

Unfortunately the effect of these collective policies has been injurious to customers over the years. I can't tell you how often I have conversations with customers about crappy PCoIP performance that involve jokes around, "What? I thought it was self-tuning? <smile>" And it's almost offensive that they tell us how awesome PCoIP is again and again, and then suddenly release an update to fix what we've been wanting for years. (PCoIP over the WAN is a great example of that. They talked about how PCoIP over the WAN was fine, then they release v2.1 or whatever, and then all of the sudden all you hear from them is, "as you know PCoIP didn't always perform that well over the WAN, so in this release we...." And I'm like, "What? I've been saying that for years and you've been market-spin denying that and saying I'm misguided, and now you release an update and all of the sudden you admit it? "Welcome to our new update. *NOW* it works over the WAN..."

This is kind of the case with this Cisco NBAR QoS announcement. They spent so much effort over the years talking about how PCoIP is auto-tuning and writing white papers about how to do it with regular QoS based on their UDP port, and then they release this and suddenly they admit what everyone had been saying all along—that QoS from the "outside" isn't effective.

This Cisco NBAR QoS integration is just Step 1. We need a few hundred more.

Again, I love that Teradici is going down the path of tagging their UDP packet headers so that Cisco NBAR-enabled devices can do better QoS. But why is that only available to Cisco devices? Why can't Teradici put information in their packet headers that everyone can read? There are plenty of standards out there. And why can't admis specify what makes it into those headers? I'd love to let my network know that I have one app which reads from a USB-device that I want to have the highest priority over everything, or that when a member of the 'doctors' group logs that his or her session has higher priority than other users.

So this is a great first step. It's better late than never. But how about opening it up a bit more? It's 2013. Teradici's PCoIP packet prioritization is not customizable and only works with one vendor? Seriously? (Also thanks for this first step!) But seriously: Seriously?

View All Videos

Join the conversation

1 comment

Send me notifications when other members comment.

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

Please create a username to comment.

@Brian I'm not aware of anybody who with Citrix ICA multi streaming who's even considered it outside the context of branch repeater traffic shaping which is now effectively the replacement for Cisco WaaS. Not sure how well it would even work and I discount Riverbed claims as mostly marketing.


So I suspect this is an attempt to the level the Cisco VXI playing field more than anything else.


Anybody else actually using this capability outside of these parameters?


Cancel

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close