I've been trying to get together with OnLive for well over a year now, ever since seeing their cloud-based gaming platform. I'm not much of a gamer, though. For me it was the protocol that they use that generated the most interest. For a while my requests fell on deaf ears, but when they announced their OnLive Desktop solution in early 2011, followed by a release during CES in 2012, they joined our desktop virtualization world.
Jack happened to make a contact at CES, and it wasn't more than a week or two later that we had a meeting with OnLive CEO Steve Perlman down at their offices in Palo Alto. We went in armed with the questions that almost everyone has:
- What protocol is OnLive using?
- What platform do the games run on?
- How is the backend brokering done?
- Is OnLive Desktop using Windows 7 or 2008 RDS?
- How is Microsoft Licensing handled since there's no SPLA license for Windows 7?
Since the meeting, I've had a chance to use the product and form some opinions based on what we talked about, what I've seen, and some speculation. What follows is what I know about these questions, as well as my thoughts on the experience and the product in general. Like me, you will still have questions at the end. It's still worth reading…I promise.
What protocol is OnLive using?
Sometime in 2010-2011, I'd heard that OnLive was using HP RGS as their protocol of choice. I actually met with HP earlier in the week, and they confirmed that HP RGS was *not* the protocol behind OnLive. As it turns out, OnLive is leveraging a combination of both their own silicon, their own UDP-based protocol, and partnerships with all the major ISPs in the country.
At the silicon level, OnLive touts a custom board in each of their servers that works in conjunction with their "System" (that's my word for their ambiguous system behind the scenes. It's a recurring theme). The System encodes the video stream as a full screen video, then sends it out via a UDP protocol. What's interesting is that the OnLive client is aware of the capabilities of the client (screen size, bandwidth, local resources, etc…), and OnLive says that they actually have a different protocol for each device. The example they gave was that with Android they get some access to the hardware, so they can send it a stream that encoded better because they can use the GPU or DSP to offload some of the decoding, whereas with iOS devices they have to do everything in software via the CPU, so the video stream sent to iOS is optimized for iOS devices.
Protocol aside, there are still a few challenges in delivering a realtime, 3D gaming experience (or a desktop, for that matter) over the internet. Part of that is addressed by the UDP protocol. As we know, UDP isn't subjected to the same checks as TCP. UDP packets are simply blasted out at the client with no regard for whether or not the packets were received. TCP, on the other hand, will retransmit lost packets to the point where it holds up the flow. In a game, this would be bad. Just talk to VMware about PCoIP :) Still, using UDP means that some packets might not make it to the client side. When asked how that works, I was told that there is technology on the client side that puts something in place to make it look normal. I imagine this like the predictive pixel technology that's built into 120Hz + televisions, where even though the signal is coming in at 60Hz, the processor in the TV knows what the first and second frames look like and can fill in the gaps. In practice, it looks like it's just compression, though.
The last thing that brings all of this together is the relationships OnLive has with all the major ISPs in the country. If you've read their marketing collateral, you'll know that there are bandwidth and distance limitations to using OnLive for games. Those limitations are different (less restrictive) for desktops, but they still exist because the protocol depends on those relationships to provide a good experience. Essentially, OnLive's systems plug directly into all of the major ISPs in the country, which they call "peering." This reduces the number of hops required to get from OnLive's servers to you. It's not a QoS thing, and OnLive isn't getting any preferential treatment on each of the major networks, it's just that the path the information takes is as short as possible. Part of the session initiation process is to identify the shortest path to the servers, and then lock that in.
Before we move on, let's sum up the protocol discussion. Custom graphics boards that feed a System that encodes the video data and delivers it via device-specific protocols on a network with as few hops as possible. It's complex, but if you've played any games via OnLive, it works.
What platform do the games run on?
I asked this question as an aside to my licensing question, and it turns out the answer is fairly complex. Unfortunately the licensing answer wasn't as comprehensive as the platform answer, so we'll go with the good one first. The platform, in a word, "depends." I went in thinking "Windows Windows Windows," because that's the licensing and platform that I cared about. The thing is, they have a backend that's capable of running games from different kinds of systems. Some of the games they provide run on Windows, some on Linux. OnLive actually gets custom games from developers that run on their systems, which makes sense when you consider the number of PS3 and XBox games they have, and the fact that the PS3 runs a Linux derivative. It's not like there are XBox and PS3 consoles sitting in a data center (well, there might be, but I doubt it).
How is the back-end brokering done?
This is a much shorter section, because the answer is "it's all proprietary." OnLive has spent a lot of time assembling their backend, and they claim to not be borrowing bits and pieces from other companies. We went in wondering if they use some sort of packaged or open-source brokering solution, but everything they've done is on their own. There are data centers around the country and in Europe, so when someone signs in, they're pointed to the data center closest to them,. Frankly, with the varied systems they run to support the games, a home-grown brokering solution makes sense. They're leveraging this system for the Windows desktops, too.
Is OnLive Desktop using Windows 7 or 2008 RDS?
Believe it or not, the answer I got here was "It depends," which I thought was weird because I simply asked "What version of Windows am I getting if I connect to OnLive Desktop? Windows 7, or Windows 2008 R2 RDS?" At this point it was like the doors closed and the information flow slowed. In practice, it was pretty easy to find out. I signed up for an account, launched the desktop, and poked around. It looks like Windows 7, but that alone isn't enough since it's possible to make Windows Server 2008 R2 resemble Windows 7. Most of the features were locked down (in fact, for the free version of OnLive Desktop, there isn't even a web browser), but signs throughout the UI point to Windows 7. I thought I'd try some old tricks, like File > Open, right click on CMD, have your way with the machine, but that didn't work.
I finally found my answer when looking at the Help > About screen in Notepad. OnLive Desktop is using Windows 7 Enterprise!
How can this be? Read on...
How is Microsoft Licensing handled since there's no SPLA license for Windows 7?
This is the biggest question I've heard from the people I've talked to because as many of us know, there is no Service Provider License Agreement (SPLA) for Windows 7. A SPLA program would allow organizations to deploy Windows 7 to any user at any organization (think DaaS providers), and it's something that the industry has been waiting for for years. As of today, the only way to deploy the same copy of Windows to users in different organizations is with Remote Desktop Services on Windows Server 2008 R2 (and prior versions).
Ignoring the lack of a SPLA license program for Windows 7, other considerations have to be made for client device access. Currently, OnLive desktop only works on iPads, which for obvious reasons can't have SA entitlements. That means that a VDA license must be purchased for each instance of Windows. Of course, that's not the proper method since we're all accessing this as a cloud service (unless it's running on dedicated hardware, but we'll get to that in a minute), but even if we were all OnLive employees, we'd still have to have that license.
I posed these questions to Steve several times, and never got an answer besides (and I'm paraphrasing) "it depends" or "that's not the hard stuff--the hard stuff is in delivering this experience."
I was told that OnLive has licensing experts that have all this worked out, but I was never told how that could be. I explained the licensing issues, the SPLA, the VDA, the fact that there are dozens of DaaS providers that are trying to accomplish the same thing but can't due to Microsoft licensing restrictions. Each time, my question was deflected and focus shifted over to the device demos.
I even asked about it in the context of games. I assume there are some Windows games in the OnLive library, and each of those would have to have a specific license for remote access as well. It has nothing to do with the fact that it's a game - it has everything to do with the fact that users are accessing applications running on Windows. OnLive has been in the works since 2005, and available to the public since 2009, but this is the kind of thing we've been dealing with for 15 years.
So, there are a few things that could be going on. The most likely solution that would be in compliance is if OnLive was using dedicated hardware for each instance of Windows. This would be entirely legal, but to do so could be very inefficient. It still means that VDA licenses are required, though, which isn't necessarily a small cost. It could be that they may have to run dedicated hardware for each session (game or desktop) to support the gaming side of the operation, in which case they probably have some super-efficient, motherboards-on-a-rack (or blade PC) infrastructure behind the scenes that makes it efficient to pull this off. If that's the case, then perhaps all of the above is true. I'm not necessarily sure if VDA licenses would be valid in this scenario, but I'll call on the licensing nerds to help us out in the comments on that one.
(Update: It's been suggested that you don't need VDA if the remote machine is installed on a physical host, so this is looking more likely. Too bad we still have to guess)
When giving away access to Windows desktops for free (or even $9.99 as the Pro plan will do), it's not easy to make up for that cost, let alone the infrastructure required to support dedicated hardware for each installation of Windows. In the meeting we had, they mentioned that had predictable usage patterns where the games were used more heavily at night and the desktops during the day. If that's the case, perhaps they're leveraging that, and the video game solution is subsidizing the virtual desktop solution (or, in effect, leveraging unused resources during the day). You'd have to think that remoting video games would be subjected to the same license restrictions, so maybe this is something they've already addressed.
Another, albeit less likely, option for a legitimate solution would be if they had some sort of special agreement with Microsoft worked out. If that's the case, Microsoft, there is a large, opinionated group of people that would love to talk to you.
Anything other than these two scenarios is likely not in compliance with current Microsoft licensing.
On top of all of this OS licensing talk, there's also the issue that both the OnLive Desktop Free and OnLive Desktop Pro apps come with Microsoft Office installed. How, again, can this be done? This is less complex than the OS licensing issue, but still one to consider when looking at the overall solution and the licensing cost associated with it.
What's OnLive Desktop like?
If you watch the video that's on YouTube of Steve Perlman giving a demonstration at the NExTWORK conference last summer (link to video, presentation starts around 28:30), you'll see that OnLive is very proud of their product. From a video game standpoint, they should be. They've pulled off an impressive feat by enabling realtime 3D gaming over the internet. I think, though, that OnLive overvalues that technology and just assumes that it will work just fine for desktops, too. In the video I mentioned, you can see Steve comparing OnLive Desktop to Citrix, saying things like OnLive Desktop is "...kinda like what Citrix is doing for the cloud thing…except the remote desktop feels local. In fact, in a lot of ways it's better than local," and, after essentially shadowing a session, he says "...and again, for those of you who've used Citrix, you've never seen anything like this before." He goes on to show a demo of a Flash app from SpeedTest.net running in a session, showing what great speed the datacenter has.
Even if I hadn't seen this before (I've been watching the same basic demo for 13 or 14 years), I'd still be amazed at the fact that to get these features you need to have a minimum 1Mbps connection to the web, and that it would be best to have 2Mbps. Frankly, if Citrix, VMware, or Microsoft's protocols had that much pipe all the time, their stuff would rock, too.
So, I tried OnLive Desktop on my iPad, and short of shooting a video demo of it, you can see where the technology they have that works fine for games falls a bit short when it comes to Windows desktops. The thing is, the compression algorithms used on games (which only go as high as 720p in OnLive's system) can be pretty liberal because there is motion all the time, and motion obscures what's happening on the screen anyway. Compressing that is probably imperceptible, or at the very least usable. With static windows that use very precise, fine lines, Windows desktops expose some of the compression techniques used by OnLive.
I don't know if it works this way on purpose or not, but when the low res, highly compressed image appears on the screen, you can watch it do what VMware calls "build to lossless." There are a few screenshots below. Keep in mind that these are just snapshots, and within a few seconds the screen changed from this to something useable. Also note that this did not happen all the time, but often enough over my 20Mbps home internet connection that it's worth mentioning.
Excel loaded, spent a second or two like this, then turned "normal"
So why does everyone else think this is awesome?
I think we were all sold on the "holy shit" awesomeness of being able to play 3D games online, and, like OnLive, our thinking was that this just has to be the ultimate solution for desktops, too. The general consensus of people in the desktop virtualization industry, though, seems to be "meh." I think the people that are drooling over this technology are the consumers, the users, the gamers, iPad fanboys, and anyone else who hasn't really been exposed to this technology before. To them, this is amazing technology, like having a computer somewhere else with a really long keyboard and mouse cable (or whatever simile you used to use to sell the tech in 1999). Today, though, we want perfect performance on almost any connection, on any device, and that means remotely rendered keyboards and super-lossy compression along with high bandwidth requirements aren't going to cut it.
What about the other versions that OnLive announced?
OnLive Desktop Free is available to anyone with an email address and an iPad by visiting desktop.onlive.com. It's limited to only a few gigabytes of cloud storage (which is owned and operated by OnLive, although they're looking to get out of that business), and it includes some Microsoft Office applications, but no Internet Explorer. It's also subject to system availability, so maybe there's a licensing catch in there, too, like they're only allowed to have a certain number of machines available in this manner. OnLive Desktop Pro, at a cost of $9.99/mo, will give you 50GB of cloud storage, "cloud-accelerated web browsing" (which means that IE is using their datacenter's connection to the internet, not anything as complex as Amazon Silk), and the ability to add PC applications when it comes out "soon." For both editions, non-iPad versions are also coming that will work on other devices, including OnLive set-top boxes.
Beyond those versions, OnLive also has plans for an enterprise version of the solution that will essentially give organizations access to the bare metal, onto which they can install anything they want. In this situation, it's all about using OnLive's network and compute power, and the customer assumes the software acquisition and licensing costs. This solution will be interesting to follow, since there are so many other companies out there that have DaaS solutions and hybrid cloud offerings. OnLive's key attractions at this point are their network peers and their protocol, and if people can get better performance in on more devices with more management capabilities elsewhere, OnLive Desktop Enterprise may never make it out of the gates.
My tone is less than excited about this, as I'm sure you can tell. I love the product for the gaming aspect, but I think that OnLive needs to be more candid when talking about their licensing and protocol. I think it's amazing that they're using full-on Windows 7 but can't answer the question about how it's licensed. Ignoring licensing, though, I can still say that my brief experience with OnLive (compared to how other clients and protocols perform in the same scenario) leads me to believe that this is not enterprise-class desktop virtualization, and that the issues that affect online gaming are not the same ones that we have to deal with day-to-day to deliver applications to users. OnLive believes that if you can do video games, you've already solved the hardest problem in remote access to applications, so desktops are no problem. It sounded good initially, but I'm not sure I can agree with that anymore.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.