Quest's EOP "Xtream" does amazing things for RDP latency (with video demo goodness)

Quest recently released version 7.1 of their vWorkspace Desktop Virtualization Suite. One of the cool new features is something called EOP "Xtream," an enhancement to RDP that increases performance in environments with high latency. When Quest visited our office a few weeks ago, we got to spend some time with EOP Xtream and were able to record this conversation and demo video.

I'll come out and say it right now: EOP Xtream is very, very cool. 


In this video, Quest's Rob Mallicoat shows us Microsoft RDP (actually running RemoteFX beta) connecting with a wide open network connection. Then we methodically increase the latency to 20, 40, and 80ms. Since RemoteFX (in its current form) is a LAN-only solution, the high def video we were watching started to break down once the latency got up there.

Then we disconnected and reconnected with EOP Xtream enabled, and we saw that even with 80ms, the video playback was smooth. (And since this was via RemoteFX, it was 100% host-side rendering--no multimedia redirection or anything.

EOP Xtream is amazing. How does it work?

So at first glance, EOP Xtream looked amazing. We had four (!) Quest people in the room during that demo, so naturally I asked them how it worked.

And then things got weird.

All I got were vague answers about it "increasing the efficiency of RDP in highly latent connections" and vague marketing crap like that. No one would actually explain what this was doing. Of course the folks in the room from Quest were huge nerds like Gabe and me, and the said that they wanted to explain it to us, but that their legal team told them they were not allowed to. After laughing for a few minutes about how dumb lawyers are (Like hello?!? This is production software that's for sale to the public. There are no secrets dumbasses!!!), Gabe and I decided to investigate. We noticed that the vWorkspace EOP configuration screen has an option for "maximum number of connections." We also noticed via netstat and a network sniffer that when EOP Xtream was used, the RDP client and host actually opened multiple TCP connections (in our case there were three TCP connections between the host and client with EOP Xtream, and a single one with straight RDP).

Interesting! After some quick Google research, we learned that there is a theory that opening multiple TCP streams can increase performance in environments where latency is an issue. The advantage comes from the "reliable" nature of TCP, and the fact and senders have to wait for acknowledgement packets, and since TCP window sizes can't be too huge across real world WANs, you can get better performance if you take your TCP stream and slice it into a bunch of parallel streams. Of course these same websites also said this would be extremely difficult to build in real life, but based on what we can see by playing with EOP Xtream, this is exactly what they're doing. So congrats to them!

I'll be spending more team with EOP Xtream over the next few months, but in the meantime, here's what we know about what it does and how it works. (Oh, and how cool is RemoteFX?)

View All Videos

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

As a Quest/vWorkspace customer.... I've been really impressed with the performance of EOP Xstream. Although we're not using the feature in production yet. - We have some issues non-performance related and probably something we're doing wrong :)

I had a user from Greece use a VM based in London at around 70ms latency to test and they said the difference was unbelievable. - I only took it to around 40 in our test lab.

Keep up the good work :)

For a different post.... Any scaling info emerging from MS yet for RemoteFX? Or are we still in that "to early" phase? And whats the cheapest GFX card it will support :)


That is exactly what it does. It has multiple TCP streams connecting both ends. Citrix from what I can see is doing the same on Nitro, even though I have never seen it running.

Quest just forgot to mention to you a very small detail on all this and a major show stopper not only for them but for Citrix.

When loss kicks in, how do you guarantee order? If this is LAN only, then isn't 80ms or higher too much for a LAN? If this is supposed to work on the WAN, then again, you cannot guarantee quality, unless their definition of WAN is the same as the Teradici guys, a highly controlled, highly priced MPLS link. Sure in this case it will work.

But bring this to the 'real' WAN, the one you and I have when connecting from a hotspot on the road, from your Cable/DSL connection and as soon as loss kicks in I am certain EOP Xtreme will not be that 'Xtreme' anymore.

Any comments Quest? By the way I do love their work and all they have done so far in the industry (as they are fully aware); I am just wondering/guessing that loss will introduce several issues with order on multistream TCP solutions.



EOP Xstream indeed does the job. But to say that "we can't talk about it" is a bit of a stretch.

To understand the challenges of RDP over WAN connections, one must refer back to articles such as, specifically the first couple of sections, "Window Size Limitations" and "Slow Start by Design". By reading this article, one is led to conclude that the problem is, for the most part, inherently attributed to TCP/IP.

Using a network monitor, it's easy to notice that what Xtream is doing is this: it's breaking down the RDP stream into multiple connections in order to get around the problems of TCP window size and slow start. Therefore, that's why Brian and Gabe have noticed and commented on the increase in bandwidth usage.

As for the patentability of the solution, I'd refer the reader to this Wiki entry,, in which it's clear that Xtream is nothing but a flavor of PEP (Performance Enhancing Proxy). In fact, the Wiki entry begins by saying:

"Performance Enhancing Proxies (PEPs) are network agents designed to improve the end-to-end performance of some communications protocol such as Transmission Control Protocol. PEPs function by breaking the end-to-end connection into multiple connections..."

Get it? " breaking the end-to-end connection into multiple connections..."



I'd envision that by tagging the data packets sent across the multiple connections, one could reconstruct the original packet on the receiving end.


Ok Claudio, I'll bite... Since you've hooked up with iPeak you've been all over this packet loss "problem" and really attacked Teradici and VMware and Quest with your "hotspot on the road" example. Fine.

But isn't iPeak's packet loss solution a PHYSICAL appliance? Isn't it a pair of physical boxes I plug into each end of the network? If so, how the hell do I use iPeak from a mobile hotspot? Do I need to carry a power strip and the iPeak appliance into the coffee shop and somehow route my wifi connection out and then back into my laptop through it?


Correction to previous post -

The article depicting TCP/IP's performance challenges in WAN environments is:


Article titled: The cold hard truth about TCP/IP performance over the WAN


No Brian, that is not the case. The solution is simply a piece of software. It can be loaded on a box, on a virtual appliance or as a driver on several OSs. For example we have it running on a Google phone as a driver loaded into the OS.

You can load it on your Windows 7 physical box, VDI, TS server, whatever. Again, software.

The same way I point what may not work or be an issue with WANs, I do it for other things. Remember my issues, now addressed by Citrix, with XenDesktop 4? Or my several posts/presentations about how poorly designed I do think RDS is on its current form (not the foundation but the management layers on it)?

The thing is as of today everyone is talking about LAN only protocols thanks to RemoteFX and PCoIP. It is only natural that all of us will debate/comment on the 'word-of-the-day'. Simple as that.

And to wrap it up, keep in mind I have way more things on my plate than IPeak. WTSLabs is a good example.



@claudio It would be helpful if you could point people to a whitepaper etc that would show the bandwidth overhead of iPeak. Nothing is free in WAN performance, and the performance I think will vary based on the type of network you are on. In other worlds rading your bits may not be optimal or offer marginal improvement in many network situations. Would be good to see some more real world data, so people can make up their minds if this FEC like solution fits their use case.

Also IMO, I think the multiple TCP connection is a smart thing to do, will help will network QoS as well. Actually it would be even smarter to use TCP/UDP on multiple channels for different use cases. AKA Multimedia UDP, TCP across many ports for QoS.

For the record I am skeptical about this whole server side rendered thing. I still don't think it will be as good as client side rendered. Sure if you want think clients if will help, but already know that thin clients are marginal corner cases not the mass market desktop replacement they promise to be. If we therefore have CPU on the client for a long long time then why not use is and make the server thinner where the data center occupancy cost is higher than a desktop client.


As Claudio wrote, there is a very important factor missing in the equation: packet loss. When sending huge numbers of bytes down a pipe indeed a saturation limit is reached (its height depending on latency), but that can be helped with multiple pipes as was mentioned in the article. So you can effectively send any amount of data any pipe, as long as packet loss is at 0%.

It would be very interesting to see numbers with latency AND packet loss.