"If TV were as complicated as remoting protocols, we would all read a lot more books." This was Desktone CTO Clint Battersby's first words when I asked for his thoughts on last Friday's Version 1.
“If TV were as complicated as remoting protocols, we would all read a lot more books.” This was Desktone CTO Clint Battersby’s first words when I asked for his thoughts on last Friday’s Version 1.0 release of the Net2Display protocol specification by VESA.
As longtime readers of BrianMadden.com know, Net2Display was conceived in 2006 to be an open specification (with source code) for a remote display protocol. After hoping, wanting, waiting, hoping, praying, and wanting, this 1.0 specification release had potential to be a big deal.
Too little, too late?
Unfortunately the three years it took to develop, while a typical timeframe for open standards development, might have been too long. Everyone who needs a remote display protocol has one. Citrix is fine-tuning ICA/HDX, VMware has thrown their remote protocol eggs into the PC-over-IP basket, and Microsoft bought Calista and is doing great things with RDP 7. It appears that the Net2Display specification doesn’t really matter to anyone right now.
Part of the problem is the fact that at this point, Net2Display is just a specification—there’s no actual code and no one has any products that make use of it. While lack of implementation might not be a problem per se, there’s also the problem that the protocol specification is vague. The Net2Display specification is only 276 pages, while even the old RDP spec (before Calista, client-side mics, and multimedia redirection) weighs in at over 2500 pages!
The Net2Display spec, needless to say, leaves a lot out. “Simply delve into the spec and find out if it describes how to handle 3D graphics, multimedia, WPF, etc.?” said Peter Ghostine when I asked him about the spec. “It doesn’t.” The Net2Display spec “describes how to endpoints communicate, how data are compressed, encrypted, etc. It also includes provisions concerning keyboard, monitor geometries, peripheral devices, virtual channels, etc...I can say with a high degree of certainty that anyone who may look to implement this spec isn't going to achieve any magic with it.”
And true enough, searching for “multimedia” in the protocol spec only produces three hits, with most of them referencing that the virtual channel architecture is based on the multimedia conferencing protocol T.120. (Which, incidentally, is the same architecture that RDP’s virtual channels were originally based on.)
In other words, the Net2Display spec is essentially saying, “you can write your own virtual channels to implement multimedia, and here’s how they will communicate with each other.” But as for how the data actually gets to and from the virtual channel is left up to each vendor. This reminds me a lot of the fact that third party vendors can write their own virtual channels for RDP or ICA. So ThinPrint and UniPrint can both write virtual channel drivers that are “ICA compliant,” but you can’t have a UniPrint client talk to a ThinPrint remote host.
The Net2Display standard is so vague that there’s a high probability that multiple products from different vendors will not be compatible with each other, despite both technically meeting the standard.
Who will adopt Net2Display?
That’s a good question, and really the answer depends on how you define “adopt.” I mean really, the Net2Display protocol is just a framework. It wouldn’t actually be that hard to modify ICA or RDP or PC-over-IP to be “Net2Display compliant.” But then again, what does that get you? The Citrix extensions of ICA would still be proprietary to Citrix, and an RDP “Net2Display compliant” client sure isn’t going to talk to an ICA “Net2Display compliant” host. (For the record, I don’t actually think that Citrix or Microsoft would ever do this, or that they care one bit about Net2Display. I’m just pointing out that any existing protocol could be made “Net2Display compliant.”
If you read the specification, the first few pages list the names of all the people who contributed to its development and the committee. There are a lot of names of companies that we’d recognize. (Wyse, VMware, Quest, Calista, Desktone, Teradici...) I contacted every single person I knew on that list to ask for their thoughts on the protocol specification, and wow did I get an earful!
Wyse released this statement:
This protocol, while good, is like any protocol. It must have an ecosystem of support, or no matter how good it is, it won't be adopted. Wyse's strategy is to assist in the development and optimization of protocols, using our significant technical depth and IP portfolio, and this is why we're part of Net2Display, just as we have also added features to RDP, ICA/HDX, and PCoIP. However, without the support of one of our major partners (C/M/V), we won't be including the protocol in our support strategy. This, of course, can change as our partners review and test the protocol, if they choose to.
While we were involved and support open standards in general, we don't have any additional comments about this in particular.
Neal Margulis, founder of Calista and now Microsoft employee, shared these thoughts: (He stressed that these are his own personal views, not Microsoft’s official views.)
In the early Calista days we attended a couple of meetings. With limited resources, we put them all into an RDP oriented solution instead of Net2Display--which then and now seemed like the right choice. RDP seemed to be more and more open and extensible so its not surprising more momentum went in that direction.
There were a lot of really great sound-bites interspersed in the responses. Here are some more which capture the general sentiment of the folks I talked to (although I’m keeping these anonymous):
“In my opinion, it's a non-event.”
“I don't think Citrix or MS even care, and I bet they're laughing it off.”
“I think it is impractical to create a compelling OS independent protocol that is also an optimal solution for remote Windows desktops...”
“I would say that VESA has hit a significant milestone in getting a standard out but that there is still a lot of work to get interoperable products on the market.”
Even twitter was light. I posted a few tweets on Friday when the spec was released, and apart from two or three retweets, there was nothing. No blogs. No conversation. Nothing. A total non-event.
Where could Net2Display go?
So now what? If no one (even people on the committee) seem to care about Net2Display, what happens next? Gabe Knuth wondered if there’s a greater purpose to it? Like if it’s not just for VDI? Clint Battersby agreed, writing, “the real opportunity and proper packaging of remoting protocols is integrated with the hypervisor. (Current examples include VirtualBox with RDP and Qumranet with Spice).” Clint said this has three advantages:
- Guest OS independent (no guest OS software required)
- Much closer to normal desktop experience (you watch the machine boot)
- Eliminates the complex feature matrix in current protocol/guest OS/client device implementations
Clint went on to say that he’s surprised Citrix didn’t integrate ICA into XenServer already, he feels RDP7/Calista integration into Hyper-V would be a big win for them, and that VMware appears to be on the right track of integrating PC-over-IP with ESX. That leads him to believe the best opportunity for Net2Display would be to integrate with an open source version of XenSource and/or KVM.
Regardless of what happens, Peter Ghostine’s last sentence to me sums it up best: “I think the protocol situation is going to continue to be the ‘wild wild west’ for quite some time.”
[TECH NOTE: As an experiment, I recorded myself reading today's article and attached the MP3 to this post. (You'll find it listed as an "attachment" up at the top of the page to the right of my avatar.) While I don't think anyone will right-click and download the MP3, attaching the MP3 to the post modifies the RSS feed so that it includes the MP3 enclosure--essentially turning the main BrianMadden.com feed into a podcast. What do you think? Is there any value to this?]