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

989 total views, 1 views today

Leave a Reply

Your email address will not be published. Required fields are marked *