WAN Virtualization

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.

Traditional Techniques to Address WAN Application Performance

In my last post, we looked at the various networking-specific factors which affect application performance on the WAN. While an exhaustive review of all the possibilities would take far more than a single blog entry, let’s take a look now at the techniques vendors have implemented over the last 10 - 15 years to address these factors.

Last time, we saw that latency, packet loss and bandwidth are the 3 key factors which drive application performance.  Latency has a relatively fixed component based primarily on the speed of light for the distance a packet must travel on the one hand, and a variable component from the queuing congestion experienced at packet forwarding devices like routers on the other.  Packet loss is most of the time a function of queuing congestion, and partly a result of bit errors on unreliable links. Bandwidth, of course, is typically limited on the WAN simply because it has a monthly charge, and it’s expensive. 

Three other major factors affecting WAN application performance, which themselves are hugely impacted by latency and packet loss, are the bandwidth-delay product, TCP’s congestion avoidance mechanisms, including additive-increase-multiplicative-decrease (AIMD) scheme, and the “chattiness” of certain applications or protocols, especially Microsoft’s CIFS protocol and HTTP.

We know that for best WAN performance, we want to avoid packet loss and high latency as much as possible.  Successful techniques will either address bandwidth limitations or application chattiness, or will hide loss or high latency from the application, or will avoid the loss or high latency (i.e. jitter) occurring in the first place.  The best solutions, of course, will address multiple of these.

 

Link Aggregation – e.g. MultiLink PPP – has been around for a number of years.  Bonding multiple identical WAN connections together, essentially at layer 1, link aggregation allows greater overall bandwidth by combining multiple similar circuits.  Examples include bonded ISDN, and bonded T1 or E1 services.  [In the LAN, bonded Ethernet works similarly].  What these solutions have in common is that each of the links is identical, and has extremely low loss and extremely low jitter.  In such cases, simple layer 1 bonding techniques and MLPPP can work very well to deliver greater bandwidth.  This usually comes, of course, at a near-proportional increase in WAN service cost.

Bandwidth management, also sometimes loosely referred to as “QoS” (Quality of Service), is a way to deal with limited bandwidth to ensure that loss-sensitive or latency-sensitive applications like VoIP, videoconferencing or Citrix get “favored” use of bandwidth, essentially prioritizing certain traffic over others.  QoS/bandwidth management has been available in data networks “forever”. This essential technique for running real-time applications like VoIP can be sufficient if a single provider owns the WAN infrastructure, and can often improve performance for interactive applications like web pages when sharing links simultaneously with file transfers.

Bandwidth management / prioritization usually refers only to the outbound direction of packet forwarding.  All WAN forwarding devices – routers, WAN Optimization products, VPN products, Adaptive Private Networking appliances, etc. – available today do this type of bandwidth management and prioritization.

In the late 1990s, Packeteer (now part of Blue Coat) pioneered a technique known as TCP rate control to improve the use of inbound connections, especially public Internet connections.  By messing with the TCP window size and when it released TCP acknowledgement packets for a given TCP flow, Packeteer was able to reduce congestion and enable better performance of real-time and interactive applications coming into a WAN link.

 

Desktop virtualization – think Citrix remote desktop product, now known as XenDesktop – solves the problem a different way.  By running the entire application remotely, performance issues related to bandwidth and the chattiness of the underlying/original application are rendered moot, as the application now runs entirely on a LAN – or sometimes entirely in a virtual machine – at a data center.  Only the GUI, mouse clicks, key clicks, and screen results are transmitted across the network. Note, however, that desktop virtualization is both a solution to WAN app performance, as well as an “application” itself for which performance over the WAN – especially lossy or very high latency WANs – must be solved/addressed.

 

TCP termination in a networking device solves the bandwidth-delay product issue. Specifically, TCP termination solves the problem where TCP transfers are limited by the 32KB – 64KB maximum TCP window sizes on typical Windows or Linux OS hosts, which impede the ability to use large WAN links for transfers over long distances.  This obviously solves problems with high latency.  Less obviously, it also improves performance in the face of small amounts of loss, since TCP’s AIDM algorithm reduces the TCP window size by half upon a single lost packet.  Under small amounts of loss, the window size of a terminated flow will typically be much larger than the window size of the unterminated flow, and so performance is maintained at a higher rate using TCP termination in this case. [Note that under high packet loss, this benefit is muted, as the window size of the flow using TCP termination is unlikely to be much or even at all larger than the window size for an unterminated flow.]

Caching, e.g. as Akamai is well known for for public Internet applications, can solve the speed of light issues involved in getting objects/data across long distances, and can sometimes help a bit with bandwidth limitation issues, depending on whether the cache is at the local site versus whether it is (as for Akamai) in the network cloud but at a point very close in terms of latency to the client.  Such caching historically is an application-specific solution.

 

WAN Optimization products from companies like Peribit (acquired by Juniper) and  Riverbed Technology  came along early in the 2000s to focus on the issues of WAN application performance.  They first attacked the limited bandwidth available on WANs, freeing up bandwidth by doing data compression.  Initially, the compression was completely memory-based, then Riverbed introduced disk-based compression/caching, improving compression ratios substantially in some cases.  Compression has been around forever, but where in the ’80s and ’90s it might have yielded an average of 40% bandwidth improvement – and at a prohibitive cost in terms of CPU consumption at the time – memory-based compression delivers an average of 2x bandwidth improvement now, and disk-based compression typically delivers improvements in the range of 2x – 4x.

By combining compression with CIFS-specific optimization, WAN Optimization not only delivers a bandwidth benefit on average (with the occasional huge benefit when the same file is transferred then 2^nd, 3^rd, 4^th, etc. time), but also solves CIFS’ notorious chattiness problem.

WAN Optimization products also typically do HTTP-specific optimization, reducing the chattiness problems with that protocol.

Wide Area File Services (WAFS), or more generally distributed files services which do replication, such as Microsoft’s DFS (Distributed File Service) with Replication, are a specific implementation of caching/replication for files.  They deliver true LAN-speed performance for files which have been distributed to remote locations and stored on a hard disk on a server device there.   In the era of very thin WAN pipes that has been the case for the last decade plus, WAFS/DFS was appropriately beaten in the market by WAN Optimization products which not only solved more problems than just file access, but solved them better where downstream bandwidth is at such a premium that pre-positioning of files in a distributed fashion is not practical.

In my next post, we'll look at the innovations Talari is bringing to the table with Adaptive Private Networking technology to address application performance on the WAN.