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.

CR

995 total views, no views today

PCoIP Session at BriForum

So here I am sitting at BriForum watching the PCoIP session (20 Common Myths and Useful Facts about the PCoIP Protocol). Before you decide to stop reading this, let me clarify what I think about PCoIP and what I was able to see first hand about it when doing all the tests we did with both ICA and PCoIP (and RDP for that matter).

First of all in certain cases and scenarios I do think the end-user experience is better with PCoIP. Yes, I said it. There may be some caveats though like more CPU utilization, more bandwidth (not really the 10X one that Citrix mentions on that Miercom report). But as we know from the old SBC days, how many times we deployed faster, better servers and loaded less users per box to improve the user experience? The bottom line is no matter what your project is, VDI, SBC, etc if the user experience suffers and you know you can improve it, you will do it. You may load less users per link to guarantee more bandwidth as an example. And then, does bandwidth (assuming you can increase at a reasonable cost) is really an issue? If there is more load on the servers, if I use faster, more powerful ones or even more servers, that issue is addressed. Sure, at a higher cost, lower density per box. But again, my point is how far are you willing to go to give your users that ‘almost local’ experience, especially on VDI that many people are praising as a desktop replacement solution in the long run? Some companies will do whatever they can to provide the best experience possible, no matter the resources/costs required. Others may not go that far. Really gets down to what you want to do.

Then we have what we have seen in the real world. Connections made from anywhere over the Internet or your off-the-mill WAN card. Again, if the conditions are right and depending where you are in the world, the experience will probably be good or even great to be honest. I do think the statement that PCoIP does not work on the WAN is not accurate (what I have never said). What I said on my previous posts is very clear. When things like packet loss come to the picture, PCoIP does suffer and suffers way more than the other ones. If you do not believe me, simply stop at our booth at BriForum. We have it connected live to a VMWare ESX environment hosting both XenDesktop 4 and VMWare View 4 environments. Over a real connection provided by Hilton to all exhibitors. Loss is there. Period. And all protocols suffer. PCoIP suffers more. Once we reduce the loss to 0.5% or less (and we have seen spikes over 8% here at BriForum), I do think PCoIP shines. My ‘visual’ feedback says it looks better than ICA in that case. Smoother experience.

I guess the main problem is the use of the word WAN. For some this means a highly controlled environment provided under a very restrict SLA. For others, like me, it can be a connection that I will have available from anywhere I am like a hotel connection, a rented 3G card, etc, over the Internet.

Considering that please do not try to tell me that the packet loss in the real world is between 0.01% and 0.1%. Again, for sure in a controlled environment, with a very tight SLA (that usually comes with a high sticker price) that is indeed the case. The reality is there are several companies trying to provide a way for their employees to work from home over the Internet or for that matter, trying to work from anywhere, from a train over a WAN card and so on. These connections do not have the same SLAs and quality as a high price MPLS. Simple as that. And more than that, differently from what people in Europe tend to think, the world is bigger than Europe and not every single part of the world has access to the high quality connections they have access to. Have you ever tried connecting from a not so remote location in Brazil back to your datacenter somewhere in the US? Have you tried to work off Tanzania or Kenya over an Internet connection? I tried and can tell you exactly what the experience is. If you agree with Teradici that there is no loss on the internet you probably never did any of that.

If Teradici really thinks the packet loss over the Internet is that low, sorry, they are ignoring the reality, living in an unicorn world.

Ignoring what is right in front of you with several researches showing you are wrong, just to make you look good is not only stupid but giant, mega bullshit.

So Teradici, let’s get together and run some tests from South America, Africa and Asia using PCoIP over the Internet and publish the findings together. I can guarantee you your magical mystical number of 0.1% packet loss is highly inaccurate.

CR

807 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:

ICA: http://www.youtube.com/watch?v=Yw5lBk-bdv8
PCoIP: http://www.youtube.com/watch?v=AXpbawlg90Y

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.

CR

3,236 total views, 3 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,027 total views, 1 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.

CR

986 total views, no views today