We've discussed Teradici and their PC-over-IP protocol quite a bit over the years on BrianMadden.com. Back in 2009, I shared a video of my first impressions, and later Teradici was heavily involved in the VMware View portion of our Geek Week: VDI event. We've questioned their blade-PC focus in a world of VDI. We've wondered whether they can survive against Microsoft's RemoteFX (and published the thoughts of their CTO Randy Groves). We've received an education from VMware's Warren Ponder & Randy Groves about how the software implementation of PCoIP really works. And at VMworld last year, we learned that they'd finally be releasing a multi-VM server offload card (demo video).
I visited Teradici in Vancouver a few weeks ago to shoot the video for the offload card, but while I was there I had a long discussion with their executive team about the company, PCoIP and the VDI industry in general. I also asked the community (via twitter) for questions they'd like to get answered.
Today's article is the edited transcript of that conversation. I wasn't exactly sure of the best way to share it, so I decided to take a bit of creative license and paraphrase all of Teradici's answers into in a single voice. So while the actual answer might have been provided by any of several Teradici folks, for the purposes of today's interview, I'm collectively labeling them "Teradici."
The "Teradici" in this interview was CEO Dan Cordingley, CTO Randy Groves, VP of marketing Trent Punnett, product marketing manager Ziad Lammam, director of biz dev Stuart Robinson, system specialist Mark Pryce, and marketing manager Mabel Louie.
Brian: Seriously? You're a chip company in today's world? Yikes... good luck with that!
The collective Dan/Randy/Trent/Ziad/Stuart/Mark/Mabel paraphrased response: We now think of ourselves as a protocol company. While we started with chips for the high-end workstation market and zero clients, as we expanded into software we realized what we're doing is actually driving the protocol, building the ecosystem, and delivering chips and software to partners. Investing in the core PCoIP protocol will be our primary focus.
Teradici has always said the deal with VMware is non-exclusive. But after two years, we’ve only seen VMware. So does non-exclusive actually mean anything? Who else out there could you partner with?
Who else? Anyone who would want to!
Who wants to?
When we announced the partnership with VMware, we already had prototypes of PCoIP running on XenServer, so there’s nothing inherently tied to ESX about it.
(from a different Teradici employee) We could partner with Microsoft when they wake up about RemoteFX. :)
The bottom line is that even though the deal with VMware is non-exclusive, the reality is that VMware is dominant in terms of the hypervisor market. For desktops, VMware & Teradici provide a compelling view (hah!) and we get very few requests to port our offering to Hyper-V or XenServer. So could we? Yes. Do we want to? Meh. The option is there, but right now there’s no customer demand to.
Could you just do PCoIP on your own? ESX with no View?
Yeah, but we're not in the broker business. So what would we hook into? Certainly Citrix or Microsoft wouldn’t go for it.
How about the cloud providers? SaaS providers? Desktops and apps out of the cloud?
They would be more natural partners.
What about Quest?
Yeah, we’d love to
Yeah, we’d love to also. Tell them to call us.
Let’s talk about the WAN use case. Isn’t that the one thing that you’re most “dinged” for... that PCoIP doesn’t work over the WAN?
Well, there’s no such thing as a single “WAN use case.”
There’s a big difference between using PCoIP for a remote office versus a teleworker versus a corporate office versus using it from a hotel room or a wireless network. That said, we’ve made huge progress on WAN so far and still believe we can extend it even further. View 4.5 has huge enhancements on WAN. Before 4.5 people were trying really extreme WAN use cases that we ultimately want to enable, but 4.5 was a huge improvement.
That said, we did have the WAN in mind from day one, and in fact the majority of Teradici’s engineers came from the networking industry.
And the WAN use cases actually drive a lot other requirements besides low bandwidth and latency, like soft phones, traffic prioritization, multiple PCoIP session optimization, sub channel QoS, PCoIP gateways without VPN, local printers.. all of which are capabilities we are working with networking vendors to solve. And we want to drive the protocol’s capabilities across the WAN without worrying about whether it’s software or hardware.
By the way, this is a great time to point out that the customers who bought the first chip three years ago -- that's the same chip we use today and if they update the firmware then they can get all the latest WAN improvements.
The other "ding" for PCoIP on the WAN is from the vendors. Because PCoIP is encrypted, WAN optimization appliances can’t dig into it to do any meaningful inspection or traffic shaping.
We're working with networking vendors to enable them to add value around the PCoIP protocol, both enhancements to the protocol and to let the WAN folks do things.
Which WAN optimization vendors are you working with?
We are definitely working with some, but we can’t disclose which ones as they are not announced yet.
Is it Riverbed?
We can’t comment
We can’t comment
Yeah, but the new Cisco VXC zero client has a PCoIP chip in it, so it would make sense if…
Seriously, no comment.
Okay, let's shift gears to soft thin clients. Why should someone buy a dedicated chip-based PCoIP thin client when they can buy a soft client for the same price that also has future flexibility for other protocols or products?
You mean zero client?
Right. Zero client. Why should I buy a zero client instead of a thin client with a software implementation of PCoIP?
Well the hardware chip-based PCoIP zero clients are implemented in silicon. So you get the absolute highest end performance, dual high res monitors, full frame rate, etc. And they’re very secure. There’s no Linux or Microsoft embedded anything. But the #1 reason to use chip-based zero clients is because they're zero management. You only flash them only if you need a new feature -- they have never had a patch that was a security update.
And if you’re just looking at price, yeah there are some really cheap thin clients that can run the PCoIP soft client, but take a look at the horsepower of those clients and see if you can really do all the same stuff on them that you can do with a PCoIP chip-based client. So by the time you take a $200 thin client and figure that it doesn’t support all you need and you have to patch and manage it and everything, if you look at the integrated PCoIP monitor that is only $200 more than a standard monitor then it’s really not any more expensive.
What about the Wyse Xenith? They’re saying that’s a zero client, and it’s software-based and very cheap?
Well, first of all that’s only for HDX, and it’s locked to HDX so you can’t repurpose it to do other things.
Ok, but Wyse announced a zero client software-based effort with the HDX-based Xenith as the first model. What if they made a PCoIP version? Wouldn’t that be cheaper than a chip-based version?
Their zero thing is certainly better than having Windows or Linux on the client.
Does Wyse have plans to make a software-based PCoIP zero client?
You’d have to ask them, but of course we’d love a Wyse zero client based on the software PCoIP. We want to support all types of clients. Some people want software, some want hardware -- we really don't care which you do. But today it’s soft thin clients and zero clients. Some like one, some like the other.
What about vendor lock-in with PCoIP hardware thin clients? Isn’t that a better reason to go with software clients?
Desktop virtualization is a big infrastructure project anyway, so it’s not like anyone is going to do a full deployment of VMware View and then decide two years later that they’re going to rip out everything and rebuild for XenDesktop. We don’t hear lock-in as a problem for people. If people do eventually change in the future, they’ll buy new clients regardless of which vendor they choose.
And again, that goes back to the price-to-performance thing. The hardware zero client is the best performance for the lowest price. That’s what’s important to people, not some hypothetical future vendor change out.
But getting back to the zero thing, Wyse, Pano, and now Microsoft have done a great job validating the zero client message we’ve been saying for years, and in general we’re seeing a very high attach rate to zero clients versus full soft clients running on PCs. Because really with VDI you don’t want anything on the desk. You want to get all the management off the desk. So when you just repurpose a PC, you’re not really achieving that purpose. But a zero client helps you go all the way.
How about soft clients for the mobile OSes, like Apple iOS or Android?
A soft client for client for iOS has been demoed on the iPad at VMworld.
Oh right. When do we get that?
You’d have to ask VMware about that.
And for Android?
You’d also have to ask VMware about that.
But we're evaluating support for all the alternative clients
Why do I have to ask VMware about that?
VMware brokers the software client using VMware View and Teradici doesn’t build brokers. But at the end of the day, we want to provide the broadest client so, whether it’s through VMware, Teradici or a partner, our goal is to support as many platforms as possible.
What about an pure HTML5 client?
Pure HTML5 as it's currently defined won’t have sufficient performance, so some sort of plug-in or new HTML5 tag would be required. But as a general statement, we're evaluating it and there may be a browser client in the future. These are all things we’re evaluating and prototyping. But in some cases we don't have a defined partner or release vehicle.
Let’s talk about RemoteFX. Reading about RemoteFX, it’s almost like Microsoft copied your strategy and message word-for-word. But they’re Microsoft. How can you possibly expect to compete against them?
First of all, we’re glad that Microsoft has finally seen the light. If anything, they validate our host rendering / zero client strategy. But now that they’re out there talking about host rendering we’re watching them try to build a zero client ecosystem, and with Microsoft you know they’re throwing their muscle and huge dollars around. But for us, we already have over 50 different hardware device SKUs with PCoIP chips in them.. clients, displays, monitors, phones, etc… and more unique devices are coming. We were small and the only reason the OEMs and ecosystem came to us is because they wanted to.
Ok fair enough. But Microsoft’s muscle and money is the reality, so you have to deal with them regardless of how they got here?
If you look at what RemoteFX will offer out of the box, there are a lot of missing features when compared to PCoIP. RemoteFX doesn’t do any image decomposition, doesn't differentiate between image types, it uses the same codec for all pixels, there’s no dynamic quality adjustment for network congestion, it’s TCP-based, so there are a lot of unnecessary retransmits.
All of this means that it’s a LAN-only protocol. Combine that with the fact that it’s locked to Hyper-V and Microsoft’s strategy with it is to push Hyper-V, and the use case for RemoteFX is super narrow.
And we’re already talked before about the economics of it too. Right now the “per screen” cost of RemoteFX is just very, very high.
Yeah but it’s a v1 thing now. Microsoft has said they plan to make it more WAN-friendly, and of course you could use WAN accelerators with it.
That will require dramatic changes to the protocol that will obsolete any v1 zero clients that are developed. Just look at the Riverbed blog from Microsoft TechEd. According to them: “The un-optimized session displayed video that was very choppy, and interaction with the user interface was practically impossible.” The Steelhead appliance was required to provide “a more acceptable experience” for a single user on a 10Mbps link. WAN accelerators are not going to make v1 RemoteFX usable over most WAN links
From twitter: Ask Teradici why they still don't have a Win7 display driver for PCoIP thin clients?
(They didn’t understand exactly what the question was about.) Win7 is already fully supported as a remote host in VMware View 4.5 using PCoIP zero clients or software clients.
From twitter: Will there be a way for software clients (in addition to the zero client) to work with their hardware PCoIP host card?
This works now in an experimental mode with the PCoIP firmware 3.2 and VMware View 4.5. It will be fully supported in PCoIP firmware 3.3 which will be released inthe first quarter of 2011.
From twitter: When will they help PCoIP become a true competitor to ICA/HDX?
We’re already way past it. :)
From twitter: You should ask Teradici why VMware does not buy them and why their apples to apples video is complete BS versus the Shawn/Benny work.
Why doesn't VMware buy us? You’re asking the wrong guys. :)
For the Shawn & Benny testing, those guys used 1% random packet loss. Random packet loss almost never happens unless you have a faulty line. Packet loss on the Internet is almost always burst and 1% is not really realistic. The only time we see packet loss sustained that high is wireless hotel connections which are not the dominant use cases for VDI today. There are other solutions for those use cases today and the PCoIP protocol can be enhanced with standard “forward error correction” techniques to address these use cases in the future.
Also, Shawn & Benny used Wordpad instead of Word, which doesn’t use MS “CopyBLT” calls. In the software encoder case, PCoIP uses CopyBLT calls to detect motion, but Shawn & Benny used an old app that almost no one uses.
Finally, we couldn’t understand how Shawn & Benny made the Flash demo fail (with the “no image found” error). We tried to reproduce the results internally but couldn’t, so we think it’s not our problem. This is a great example of how to bias a demo. We asked Shawn & Benny to send their logs, but they haven’t sent them.
That's it! Thanks to all the Teradici folks for taking the time to talk, and thanks to those readers who submitted questions via twitter!