RemoteFX performance over lossy networks

Just a preliminary and quick video showing RemoteFX performance when loss is there, with and without our IPQ protection.

We have been testing it under several conditions, with different latencies and loss and will be publishing the full results soon. We also have some data on how much bandwidth RemoteFX uses. Just as a quick example, WMV-HD playback takes close to 30MBits; running an app like Google Earth around 9MBits.

My personal take after testing it, RemoteFX CAN be used over the WAN as long as you know exactly what your apps are (meaning, WMV-HD playback is probably a no go) AND also guaranteeing loss is minimized as it does suffer from it, making certain applications unusable.


1,001 total views, no views today

PCoIP performance over lossy networks.

This week as you guys know, I spent quite a lot of time at Citrix Synergy 2010 in San Francisco and during that time we were able to extensively test how all major remote display protocols work over the real world WAN and in a certain way, what we saw simply validated what I was expecting to see.

First of all, let me define real world WAN and explain how we actually know what this is. If you are not familiar with our technology, IPQ, it is a packet loss reduction mechanism that works between two end points. As we adapt according to the network conditions, we must know at any given time what these are. That is the reason why our endpoints exchange a beacon at all times. This gives us over 25 stats that we use to determine the most effective way to deal with packet loss in real time.

Of course all that information gets stored and we can plot what we are seeing right within our web interface. And guess what? During this week we spent in San Francisco, doing our demos from a hotel room using the provided internet connection – the exact same one all of you had in your rooms – we have seen packet loss at all times. How much? From 1% all the way to 15% (burst loss). The bottom line here is simple: loss is guaranteed out there and it is MUCH higher than the 0.5% loss that Brian and Gabe used on their WAN simulator during the VDI Geek Week shootout. That is the reason why ICA, RDP and PCoIP performed relatively well on their ‘WAN’. In the real world, with unpredictable conditions, performance is not really like that. I am not saying that loss will be high and will be there at all times. I am just saying loss will get you several times during the day. When and how much that will be no one knows. But it will be there. For sure.

So back to the topic, how well does PCoIP perform over the real world WAN? Not that well as expected. And here is the living proof of that. Notice how much better PCoIP gets when IPQ is brought to the picture. It gets almost as good as ICA (in case you did not see our tests with ICA, go here).

No matter what VMWare and Teradici tells you, TCP with its retransmission techniques, in this particular type of connection (PPTP VPN), DOES perform much, MUCH better than PCoIP. Just watch the two videos for yourself (the PCoIP is also available in high definition 720p). At 3% loss ICA simply smokes PCoIP (that without our technology is virtually unusable – again, over PPTP. LT2P may change things, making PCoIP closer to ICA over the WAN). The game changes completely when IPQ is on. ICA improves for sure (again, watch the videos) but PCoIP at that point really shines. The improvement is brutal, huge. At the end we turn something that is really unusable over the lossy WAN into something people can actually use. It is that much of an improvement.

In case you want the direct YouTube links, here you have them:


The bottom line is simple. All current implementations for remote display technologies do suffer over the real world WAN. The idea of our technology is to work as ‘Network Insurance’ for your connection. If the conditions are good we know that thanks to our beacon exchange and at that stage we simply turn ourselves off. But when loss comes, we are there to protect you. Exactly like your insurance company. You have it and hope not to use it. Ever. But when you need it, you know it is there and that you can count on it.

That is what we are. Network Insurance for you and your users.


3,244 total views, 2 views today

ICA behavior on lossy networks.

I guess a picture is worth a thousand words. So what about a video?

Yesterday here at Citrix Synergy 2010 I had the time to record a quick video that shows how ICA, normally a very robust protocol for the WAN, suffers from packet loss. Before you go ahead and say the conditions of the test are not really ‘real world’ all I can tell you (and I can show it in person if you want) is the loss I have seen yesterday over the connection provided by the Marriot Hotel in San Francisco spiked during certain moments to more than 15-20%. So on the real world you will face packet loss at one degree or another. Guaranteed it WILL be there.

This quick test (runs for 6 minutes) shows a XenApp 6 server running on Windows Server 2008 R2 with no load whatsoever. We injected a 3% loss but again, were able to see huge spikes on it (remember, our solution, hardware or software based, sends a beacon between both ends all the time to determine how network conditions are at any given time and adjusts how mildly/heavily we do our magic and with all this data we can plot what is going on over the link in real time).

The results? Well see for yourself. My take on this is XenDesktop/XenApp do suffer. Period. In certain cases your users would experience serious lags when typing, very choppy video/audio and so on. Unusable? I would not go that far. Fixable? Yes as the video clearly shows. And also keep in mind this was all done over a hotel internet connection (the type you get on your room) in a conference where probably every single person IS using the hotel link AND this was done on a XenApp 6 box running in Ottawa, Canada, a couple miles from San Francisco (probably around 3,000 miles).

If you want to understand how we do this (remember, we are a layer 2 solution so we fix ICA, RDP, PCoIP, etc – we do not care what you run; we fix it) feel free to stop me at Citrix Synergy for a chat or just follow me on Twitter (crod).

Bottom line: even though these protocols do have their mechanisms to cope with packet loss, ICA, the king of the kings in the VDI world IMHO, does suffer. If it does, I can only imagine PCoIP will suffer even more (and RDP too). Oh we have tested them.

Yes, they suck.

2,034 total views, no views today

Packet Loss Reduction. How we do it.

Now that our BETA program is open (please join it by emailing us at BETA at IPeakNetworks dot com) of course I keep getting questions on how our solution works, what is required and so on. So here you have it, right from the source.

First of all, as mentioned before we are completely protocol agnostic. We do not care if you are PCoIP, ICA, RDP, RDP with RemoteFX or even if you are doing video conferencing only. Our solution works in all cases as we are at a lower level.

Secondly, the solution exists in two forms: a software driver (for Windows XP/Vista/7, Windows Server 2003/2008 and Linux at this stage – yes, no Mac OS X until the market shows us it makes sense) and a hardware appliance (in this case it can be physical or a VM – we are working on having it ready for ALL major virtualization platforms, ESX, XenServer and Hyper-V). The two ends being protected must of course run our solution.

So let’s see a couple examples. One would be a field worker with his laptop running our driver, connecting back to the main office where our appliance sits. Anything going from his PC to the appliance will have the packet loss reduction in place. So if he hits a XenDesktop, XenApp, video conferencing, whatever solution that is now behind our appliance (that is really a bridge, not routing anything), he gets protected. Another example would be a remote office to main office connection with two appliances, one on each end. Easy enough?

Now, the main question everyone is asking is “How the hell do you do it?”. Here is the quick explanation (well not so quick).

Basically it works by first monitoring network flows. Then, when it detects a flow that can benefit from protection against packet loss, it adds a non-disruptive beacon to the flow. This beacon has no impact on end-devices but is detected by other IPQ systems. When our system detects a beacon from a far end system, it knows that it can communicate directly with that the IPQ peer.

All communications between IPQ pairs including control and data messages are inserted directly into the existing network flow in a manner that is entirely friendly to NAT and firewall systems. With both peers of the IPQ ‘pair’ connected and communicating, there is a negotiation session to determine the best way to protect the network flow based on the following analysis:

  • Current Network Conditions. How good or bad is the network at this moment?
  • Application Sensitivity to Loss. How much loss can the network application tolerate before the quality of experience is impacted?
  • Packet Size. What size are the packets in this flow?

Using the results of the analysis, IPQ divides each packet, one packet at a time, into the optimum number of segments. An extra segment is also generated to provide protection for the other segments. Should an original segment fall victim to packet loss, the extra segment is used to recreate it.

One more thing worth mentioning is our Real Time Optimization techniques.

The IPQ peer on the receiving end of the pair is able to recreate the original packets as long as enough of the segments are received. By comparing the number of segments received to the number transmitted, the receiving IPQ peer is able to detect changes in network conditions. Those changes are communicated to the transmitting peer as they occur and the level of protection applied to the network flow is adjusted and optimized in real time. This critical monitoring function is ‘always on’ but when network conditions are excellent, IPQ suspends the protection function and no extra segments are created. Monitoring continues, however, and IPQ is ready to apply optimum protection when network conditions deteriorate.

And again, this is all truly Plug ‘N’ Play. If you are coming to Synergy, PLEASE I ask you to join our BETA and stop by to see the demos we will have ready to go! I am sure you will be impressed.


988 total views, no views today