Teradici execs discuss the future of PC-over-IP, zero clients, and the pressure of RemoteFX

We've discussed Teradici and their PC-over-IP protocol quite a bit over the years on BrianMadden.com.

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

Aqua Connect?

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

Cisco?

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!

Join the conversation

6 comments

Send me notifications when other members comment.

Please create a username to comment.

Apart the "ask them" answers, the good news is that "they're working on"...


;-)


Cancel

Hahahaha, gotta love their phrase, "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...".


Jokes aside, I do agree with them that most loss on the wide open internet is bursty BUT I can point several other cases, other than the hotel one they mentioned, that they learned from me last BriForum if they remember, when I showed the real loss we had at the conference floor.


I also agree it is a matter of the use case. I have seen and used PCoIP over the WAN (real WAN) in several different scenarios and in some it does work just fine. In many others, terrible performance.


That is where HDX gives a more consistent performance. It may not be as great as PCoIP in certain cases but wins hands down if we consider several scenarios including ones with latency/loss/bandwidth limitations all at the same time (what is a scenario that many road warriors face big time). As an example Shawn/Benny/Myself just got back from São Paulo, Brazil. Any ideas on the speed of the 3G network available there when tethering? Around 300-400kbps. That is what businesses have available. Pretty much all Fortune 100 have offices over there and some have VDI efforts on the way. Guess what? PCoIP does not work well in that scenario...


Happy to see Teradici finally agreeing that PCoIP is not the silver bullet and that it does have its flaws. Like anything else.


Welcome to the real world Neo. I mean Teradici.


Cancel

This is why most people will continue to use RDP with View and why VMW does not buy them. The realize just like RTO it was a mistake. VMW will I predict continue to back away from VDI slowly will they channel all their efforts into cloud based apps and mobile and try to change the conversation. There is reason they renamed desktop to end user computing and hired a security GM to help make this happen. The VDI stuff will be marketing BS to sell vSphere EAs for as long as they can and disrupt MS and Citrix.


Cancel

Since I'm being called out, let me add a few points:


1) I never tested, nor did I state that we used 1% random packet loss.  That would be retarded.  What we used was random 0.01% packet loss.  That's considered a pretty acceptable standard for MPLS style WAN circuits.  I wasn't trying to reproduce Internet style connectivity here, just branch office WAN circuits.


2) Regarding the use of Wordpad.  Are you freggin' kidding me?  Do you really think I deliberately devised a test that would only make PCoIP look bad where all other protocols would look good?  First of all, I didn't secretly choose Wordpad.  I picked it because it was there in the OS, it could open up a Word Doc / RTF doc so I could illustrate basic document navigation and it helped me avoid deploying Office in all my fresh OS builds.  When you end up building Win7 systems and deploying apps numerous times you try to minimize the time that it takes to do so.  My apologies that I happened to pick an app you guys are apparently not that good at.  My advice, make your protocol better, don't try and assume what your end users will or will not do.  Or at least put together a dislclaimer telling customers what types of apps they shouldn't run.


3) I have no idea what Flash video you're talking about that didn't work.  I know that when I was recording the videos there was one or two scenarios that I couldn't get recorded because I was getting everything done down to the wire before presenting it at BriForum.  I believe that we did disclose any time that there were missing videos that it was due to our inability to get all of the videos recorded in time for the conference and not a fault of any given technology.  In fact, I thought we avoided showing any of those types of video mixes, but perhaps one slipped by.  My apologies there and a public acknowledgement that it isn't any of the remoting protocols fault if something said "No video found".


Finally, regarding our cooperation, etc.  Teradici was very helpful in working with me on the PCoIP hardware and pointers on the test setup, etc.  I regret not having tons of time to work with their engineering staff before these videos were presented.  Benny and I have both said we welcome Teradici's input/assistance to prove where we've gone wrong with any of our results.  The only caveat I supplied is that I'm not going to go around tweaking the heck out of any protocol to make it look better in particular conditions.  The only thing I'm willing to do is make a basic client side protocol hint to say I'm on a WAN circuit or something like that.  Beyond that I expect the protocol will sense and respond to conditions.


Regarding some of the View Soft PCoIP performance numbers, I really don't know why they were so bad.  I certainly didn't expect them to be as horrible as they were.  I thought that my test results seemed poor on the WAN conditions so I completely reproduced the entire environment on different hardware in Germany before Synergy Europe.  After reproducing the same results on two separate sets of hardware with two separate installs of View 4.5 there's either a flaw in my methodology (which I'm open to be shown) or there's issues.  The future will prove out which it is and I'm not too proud to say I was wrong if I am.


Shawn


Cancel

True, there’s no such thing as a single “WAN use case”.  It is also true is that there is always someone "trying really extreme WAN use cases..." (and thank goodness for that, obviously.)  And as great as it is that Terradici "ultimately wants to enable" those really extreme WAN use cases, what are they, exactly?  Is it possible that they are considered “really extreme” only because they are not yet enabled?


According to research from Gartner and Information Week and others, virtualization over the WAN has gone mainstream and some specific use cases are driving serious business for WAN optimizers.  IW says more than 20% of WAN optimization projects last year were driven by VDI.  Gartner says the leading WAN Optimization vendors are successfully increasing their focus on cloud and data center-to-data center deployments, on supporting the increase in data transported over the WAN among remote offices as well as remote workers, and on the exploding need to support mobile users.  IW calculates that almost 30% of VDI users are mobile-first (and LAN only occasionally.)  And Citrix recently reported that 46% of their users are connecting to their desktops with tablets.


These kinds of numbers tell us that these are not “really extreme WAN use cases.”  These are here-and-now operating requirements.  The takers for our free evaluations of IPQ-RC solution (a part of our QoS for the Cloud offering) among VMWare users tells us the same thing.  Our testing of IPQ-RC with the big three remote display protocols (www.ipeaknetworks.com/ipq4rds) underlines the fact that there is much room for improvement with these protocols in WAN scenarios.


What's going on?  Simple... with some of the bigger WAN optimization vendors beginning to offer partial solutions, many enterprises are showing a preference for WAN optimizer-based answers to the challenges of VDI over the WAN because no protocol can meet the end-to-end QoS requirements for these business-critical use cases.


If I needed further validation I would share the fact that IPeak Networks is now working directly with a large WAN optimization vendor to integrate our patented WAN performance and quality solution technology.  It makes a lot of sense, doesn’t it?


Now, I’ll close this comment with a few words about a couple of things that do not make sense.  It does not make sense to dismiss 1% random packet loss as a freak phenomenon you only find on a wireless hotel connection.  (And what if it was?  A remote worker connecting to his or her desktop from a hotel is pretty darned high on the WAN use case list, isn’t it?)  Fact: 1% random packet loss is far more common in North American business corridors than Terradici seems prepared to admit and, as Claudio says above, other geographies face much, much worse.


And finally, no matter what you want to use as the realistic number, it is not at all realistic to add standard forward error correction and think you have a solution for packet loss because standard forward error correction adds latency—a lot of latency—and latency absolutely kills virtual desktops.  IPeak Networks solves the packet loss problem without adding latency and that is a big part of the work we are doing with the WAN optimization crowd.  It makes a lot of sense.


Cancel

I am new to this things so trying to understand how this stuff works.


Any where in the discussion, I do not find Teradici needing a GPU on the Server while RemoteFX requires a GPU. Why is that?


If there is a server side rendering, there has to be something to render the screens for each VM.  If I understand correctly Teradici PCoIP is a protocol to send pixels from server to clients and RemoteFX is also a similar protocol.


What am I not understanding here? Does it mean that in Teradici (PCoIP) the rendering is done by the server CPU? And this means it may be only supporting Windows7 Basic modes while the RemoteFX may be supporting WIndows7 Aero?


Please help. Please do not kill me. I am asking this as I do not understand this.


thanks,


Cancel

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close