APN's Innovations to Improve WAN Application Performance

In my first post in this trilogy, we looked at the factors which affect application performance on the WAN. In the second, we enumerated the various techniques vendors have implemented historically to address these issues.  Here, we'll take a look at what Talari’s Adaptive Private Networking (APN) solution brings to the table, and how these new techniques complement the existing solutions that the WAN Optimization, Virtual Desktop and WAFS/caching vendors deliver today.  

In addition to doing bandwidth management/QoS for outbound traffic essentially as any modern middlebox does, and offering TCP termination to address the bandwidth-delay product issue as many existing solutions do, APN innovates in a number of areas in addressing WAN application performance.

Most obviously, of course, APN's Resilient Multipath Connectivity enables link aggregation of diverse IP WAN connections while still delivering predictable and reliable performance.  Inexpensive Internet connections can now be used to reliably augment and/or replace expensive WAN connections like MPLS.

APN also offers innovation in a number of other application performance and performance predictability areas as well.  APN’s techniques for reliable packet delivery mitigate the effects of loss on TCP applications, buffering and retransmitting packets to make the WAN look like a zero-loss network, with occasional bouts of jitter.  Of course, the jitter introduced is no worse than a TCP application on the WAN has to be able to handle in case a packet is stuck in a queue in some WAN router behind a congested WAN link.  This enables TCP window sizes to stay at maximum, without negative impact on the WAN itself.  Further, in the face of more than moderate loss, or in the face of bursts of jitter, APN will move traffic, especially timing sensitive traffic, to a better path with lower loss, and/or latency.  By making this move away from “flaky” bandwidth sub-second (< ~250 ms across the continental U.S, < ~600 ms even for traffic going halfway around the world), APN delivers reliable predictable application performance even while using the “pretty good but not business quality" public Internet for its sources of bandwidth.

For real-time traffic like VoIP or videoconferencing applications (or even low-bandwidth, time-sensitive interactive applications like Citrix), APN will first put the real-time traffic on the best path with the lowest loss and lowest jitter to the destination.  As per above, if loss or congestion (jitter) is detected, it will switch the traffic, sub-second,  to a better path.  But for “platinum” quality voice – or for that matter, platinum quality videoconferencing, if you’ve got the bandwidth – it will send a replica of the packet stream on a different paths, as unrelated in terms of local and remote WAN links as possible; the replica is discarded at the receiving APN appliance.  Routing, of course, has always taken care of up/down network availability issues.  With this technique, even if what is usually the best performing path suddenly starts experiencing 68% loss or even a 150 ms burst of jitter, the same packet will show up at the destination along the other path, a few milliseconds later, and the application will never miss a beat.  APN counts on there being jitter buffers in the receiving hosts for this scheme to work, and in fact this is exactly how VoIP and videoconferencing work.

On the bandwidth mgmt/QoS front, APN delivers superior results for outbound traffic over existing solutions because, as a two-ended solution which continuously knows the state of all the network paths to the destination, it gets priority packets not just out the local link first – which is all existing solutions in practice do, since RSVP and IntServ never really “happened” – but to the other end of the WAN first, which is what you really want.

For inbound WAN bandwidth mgmt, in addition to doing a cruder version of what Packeteer PacketShapers have always done for limiting generic public Internet traffic on links shared with APN connections, it does far more sophisticated inbound management than any prior IP forwarding devices for inbound traffic coming from other APN sites, avoiding most last mile-based loss and congestion in the first place.  I.e. unlike TCP, which, as one sees with the famous TCP sawtooth, is actually designed to cause congestion and loss before backing off, APN will sometime temporarily attempt to send 3.1 or 3.2 Mbps into a 3 Mbps link, say, but will never try to offer 5 or 6 Mbps of load to the link, as standard TCP will habitually do, especially if there is inbound traffic from two or more locations.

WAN Optimization products, as a whole, combat the effects of limited bandwidth and high average latency.  WAN Opt typically delivers a 2x – 4x bandwidth benefit by freeing up bandwidth with its compression/caching techniques.  WAN Opt addresses high average latency with its generic TCP termination capabilities, and with its application-specific chattiness reduction optimizations for CIFS and HTTP.  WAFS and caching products generally combat the speed-of-light latency problem as well, in a less general, more focused fashion, but have historically achieved less success in the marketplace, in large part because of the extremely limited bandwidth available at most smaller locations.

Adaptive Private Networking is quite complementary to WAN Optimization, since it not only cost effectively enables much more bandwidth, but excels at combating the effects of packet loss and jitter (i.e. worst case latency), as well as frequently preventing loss and high jitter from occurring at the last-mile in the first place.  APN is also complementary – indeed, even an enabling technology – for distributed, replicated file services by enabling the provision of large amounts of inexpensive bandwidth, a solution not heretofore cost effective.

WAN Opt, WAFS, caching, Citrix and other application-specific solutions help some for bandwidth and are great at addressing speed-of-light latency issues; APN, while doing little to address speed-of-light issues, is unique in its approach to addressing the effects of WAN packet loss and congestion-based latency/jitter, as well as in preventing much of that performance-killing packet loss and congestion from occurring in the first place.

Comments

[Voip providers]

Of course there are different means of communication except of IP phone, but you should compare them to make the conclusion about their efficacy. After comparing you will understand that IP-phone is the most practicable for you or your company. http://www.voip-catalog.com/ Voip providers

[WAN optimization]

It's been really great going through your blog post, very well informed and described. Great to read and know more about such kind of stuff.