WAN Virtualization

A NEW architecture for the Enterprise WAN

Earlier this year, Keith posted about a report that Peter Sevcik and Rebecca Wetzel of NetForecast wrote called "Flexible IT Networking: An Emerging Trend."

 

Since we’d not yet started using the term WAN Virtualization to describe what Talari does, Peter and Rebecca used the phrase “integrated transport” in referring to technology like ours, but how it fits with the other technologies and the benefits it brings are very much the same.

Server virtualization and WAN Optimization are already being widely deployed for the advantages they bring to server / data center consolidation projects.  By combining these with WAN Virtualization technology and a new, Enterprise intranet-focused use of colocation facilities, the resulting WAN architecture becomes very powerful, enabling a revolution in network architecture of the sort that only happens once a decade or so.

Peter and Rebecca label this new way to deliver IT services “Flex-IT Networking”.  I’m going to refer to it as the NEW architecture – the Next-generation Enterprise WAN architecture – to put the focus squarely on the implications for the WAN, notwithstanding the incredible impact this architecture will most certainly have in supporting, and indeed enabling, enterprise’s moves towards Cloud Computing on the compute side of the IT shop.

While this NEW architecture made possible by leveraging the combination of these four technologies is indeed revolutionary in terms of economics – not since the advent of Frame Relay in the 1990s have enterprises seen this kind of impact on WAN price/performance – because of the flexibility of WAN Virtualization and its support of existing private WAN deployments, it can be implemented in an incremental, evolutionary fashion, no forklift upgrades required.  Further, by providing a pragmatic, evolutionary path to leveraging cloud computing, solving the reliability, predictability and network cost issues, as well as many of the security and IT control issues as well, the Network Manager/team can be heroes to the CIO, the computing/application team and the CFO all at the same time.

Let me quote from Sevcik’s and Wetzel’s Network World article introducing this subject: “Thanks to [this] phenomenon … the power balance is about to shift from network service providers to enterprises.”

I think they’ve got it exactly right.

In the coming months, we’ll lay out the thesis, some of the detail, and as importantly the implications that this NEW architecture will have on the enterprise WAN and on Enterprise computing overall.

Virtualization is Driving IT Savings

Virtualization – server virtualization, and to a lesser extent desktop virtualization – is driving IT savings.  This, of course, is almost self-evident to anyone paying attention to what’s going on at the leading edge of computing these days.  Virtualization technology from companies like VMware has taken us from the days of single CPU, single OS to a single CPU with multiple virtual machines towards cloud computing / utility computing, leveraging the efficient pooling of on-demand server infrastructure to scale to run an almost arbitrary set of applications – be it public cloud computing, private cloud computing, or hybrid cloud computing. 

After talks with a number of industry analysts, we recently settled on WAN Virtualization as the term to describe the new market category that Talari is pioneering with our Adaptive Private Networking technology.

I think the term works well on a couple of levels.  For one, it's in the same vein as, yet distinct from, WAN Optimization, befitting the complementary nature of WAN Virtualization and WAN Optimization technology.  More importantly, just as Enterprise WANs have gone from being composed of point-to-point leased lines, to leveraging reliable public cloud networking (X.25, Frame Relay, ATM and now MPLS) and a bit of unreliable public cloud networking (the public Internet) for remote access and IPSec VPN backup connectivity, WAN Virtualization technology like Talari's is changing enterprise WANs in the same way that VMware and server virtualization are changing enterprise computing, enabling reliable public cloud networking.

WAN Virtualization leverages the economics of the public cloud network that is the Internet, as well as enabling hybrid cloud networking utilizing a combination of private WAN connectivity and public Internet connectivity.

If you've been reading this blog for a while, you've seen previous posts here and here on how Talari's technology is similar to RAID. Since RAID was, after all, essentially storage virtualization phase 1 – or phase 0, I suppose, depending on your point of view – the term works at that level as well.

In future posts, you'll be hearing a lot more from us about the exciting possibilities that result from synergies across WAN Virtualization, server virtualization and WAN Optimization.

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.

The Factors Affecting WAN Application Performance

Let’s take a look at the various networking-specific factors which affect application performance on the WAN.  I.e. We're not attempting to cover here things such as server capacity, or computational complexity, which are independent of “the network”. Said another way, what are the issues which cause application performance on a WAN to be so much worse than performance of the same application run entirely on a LAN?

In future posts, we’ll look more at which networking and computing techniques – Adaptive Private Networking, WAN Optimization, as well as other techniques – address each of these factors.  Before doing any kind of technology deployment to “make the network work better”, it’s useful to understand what the factors impacting network application performance and predictability are.

For those of you familiar with what WAN Optimization products like those from Riverbed Technology, Blue Coat Systems and Silver Peak Systems do, a lot of the below will be old hat; hopefully, you’ll still find some of the detail beneficial.

 

I contend that WAN-specific application performance is driven entirely by 3 factors: latency, packet loss and bandwidth.  While networking geeks might say “duh!”, some people familiar with WAN issues might say “huh? That’s not right”.  These people will argue that there are other factors as well.  I will show below that these other factors – which in fact are very important – matter precisely because of the impact of loss, high latency and/or limited bandwidth.

 

Definitions (from Wikipedia): “Latency is a measure of time delay experienced in a system, the precise definition of which depends on the system and the time being measured.  Latency in a packet-switched network is measured either one-way (the time from the source sending a packet to the destination receiving it), or round-trip (the one-way latency from source to destination plus the one-way latency from the destination back to the source). Round-trip latency [a.k.a. RTT - Round Trip Time] is more often quoted, because it can be measured from a single point.”

"Packet loss occurs when one or more packets of data traveling across a computer network fail to reach their destination.”

“Bandwidth is a measure of available or consumed data communication resources expressed in bit/s or multiples of it (Kbps, Mbps etc).”

Bandwidth is a pretty obvious limiting factor on transfers of large amounts of data, of course.  While it is most definitely not the only reason for poor application performance on the WAN, and in some cases has little or nothing to do with application performance, just as in the LAN, having more bandwidth will make many applications run better and more predictably, and in particular will make the network manager’s life easier. 

We’ll get into the reasons for latency and packet loss problems in WANs in just a second, but before going on, it is worth noting the three other major factors affecting WAN application performance, which themselves are hugely impacted by latency and packet loss.

The "bandwidth-delay product refers to the product of a data link's capacity (in bits per second) and its end-to-end-delay (in seconds). The result, an amount of data measured in bits (or bytes), is equivalent to the maximum amount of data on the network circuit at any given time, i.e. data that has been transmitted but not yet received.” The bandwidth-delay product, which essentially has no effect on LAN performance, is a well-known limit on how fast data transfers can occur over high delay Wide Area Networks.

A closely related issue is the manner by which TCP does congestion control: “TCP uses a network congestion avoidance algorithm that includes various aspects of an additive-increase-multiplicative-decrease (AIMD) scheme, with other schemes such as slow-start in order to achieve congestion avoidance.”  TCP’s congestion control algorithm, and AIMD in particular, is the primary reason why the Internet has not “collapsed” from the weight of everyone using it, and is the amazingly elegant way TCP’s designers came up with to efficiently use available bandwidth, and provide fairness “on average”.  For an individual application’s performance, however, this means that performance suffers notably with packet loss, and for interactive or real-time applications, can frequently have particularly bad performance when packet loss rates exceed ~1%.

Finally, there is the issue of the “chattiness” of certain applications or protocols.  Essentially, chattiness refers to how many multiple round trip communications – largely serialized – between client and server are required to perform a given application function.  A fantastic explanation of this issue can be found here in this NetForecast paper explaining Web performance over the Internet. 

Two common protocols which are very chatty are Microsoft’s CIFS protocol, and HTTP, the dominant protocol used for web applications.  Much like the bandwidth-delay product issue, “chattiness”, which doesn’t hurt performance much on a LAN, can have major consequences on a WAN facing packet loss and/or high latency.  For public Internet applications, including but not limited to web apps, large numbers of DNS (Domain Name System) requests are a form of application chattiness.

While there are other, innumerable application-specific factors, it’s not much of an oversimplification to suggest that in the end, their impact is quite similar to the “chattiness” issue noted above.

Ok, so if all network-specific performance issues can be traced back to bandwidth, latency, and packet loss, let’s look a bit deeper into the causes of latency and packet loss in IP WANs.

[Some sharp-eyed folks might be wondering about now “why hasn’t this guy mentioned jitter yet??  We know jitter is a huge issue in real-time application performance”.  In fact, jitter is a measure of the variability over time of the packet latency across a network.” – i.e. a component of latency!]

If we break down WAN latency into its constituent parts, we see both “fixed” components and variable ones.  The fixed components of WAN latency relate to the number of route miles a packet must travel between source and destination – and thus limited by the speed of light – with a smaller component based on the number of routers the packet must go through, with the small, fixed amount of time it takes to transit the router even when the links are lightly loaded.  The typical one-way latency across the continental U.S. is ~40 ms, meaning a typical RTT across the country and back is ~80 ms.

The variable component of WAN latency – the jitter, in other words – is caused by queuing congestion at the routers (or other IP forwarding devices) anywhere along the way.  Queuing congestion is caused when there is more data entering a device (router) trying to go out a given link than the bandwidth available on that link.  In typical IP WAN routers, queuing congestion at any given router can add up to 100 - 200 ms of latency.  Beyond that amount of delay, packets will typically be dropped – causing packet loss.

Overflowing queues in forwarding devices, as just noted, are the primary reason for packet loss.  Some routers use a technique called WRED to drop a lower percentage of packets when their queues are beginning to fill up, to avoid excessive jitter and better promote “fairness” across flows.  Finally, while less common than in the past, bit errors can also be a cause of packet loss.  Fairly rare on wired networks these days (beyond the occasional flaky DSL connection), bit errors are sometimes responsible for a moderate amount of packet loss on wireless networks.

High latency causes obvious problems in application performance.  Packet loss usually has an even bigger negative impact on WAN app performance.  Why is this?  Given the TCP bandwidth-delay product, loss rates above ~1% mean that the application can only use a very small amount of bandwidth on a WAN, not matter how much is available.  Over longer WAN distances, throughput is lower still.  Because TCP is a windowed protocol, forwarding of additional packets from the source will quickly come to a halt until the lost packet is retransmitted and acknowledged.  Even for applications where the bandwidth-delay product per se is not an issue, the “chattiness” problem has much the same – and often worse – effect.  In the face of packet loss, all data transmission halts until the packet is retransmitted and acknowledged.

Whew!  A lot to digest here, and we’re really only scratching the surface. We know that we want to avoid packet loss and high latency as much as possible.  In my next post, we’ll look at which techniques address which of these factors, combating the negative effects of loss and latency directly and indirectly.

Bet on the long term winners

On Wednesday, I was on the Breakthrough Network Technologies session at Interop New York that Jim Metzler moderated. The panel that Jim assembled had an interesting commonality across a number of us. Namely, leveraging the power of the MIPS available from Intel and the large base of open source code available on Linux.  You can see this in the next generation technology available from Arista Networks, Vyatta and Talari.

Arista is building solutions for large data center and high performance computing environments.  Vyatta is leveraging open source to be the “Red Hat of networking”, and enable customers to take advantage of commodity hardware in more and more parts of their network.

The advent of Linux-on-Intel for networking makes innovation more possible than ever before. Unless perhaps you're building a router for the core of the Internet, the x86 architecture today has plenty of horsepower for networking applications. This lowers costs for customers versus having to pay up for proprietary hardware R&D. Building on top of Linux and open source means that start-ups can begin from a much higher base, and take less time and money to deliver innovation to the market. Besides the obvious opportunity and lower costs for we start-up vendors, for enterprise customers it means that the value (and associated lock-in) of going with only large vendors for your networking purchases is lower than it's been in over a decade. 

The enterprise WAN buyer has not been able to take advantage of Moore’s Law and the ever-continuing price/performance improvements that most of the rest of technology – including the public Internet – have over the last 15 years.  For the reasons for this, see my last post.  Consequently, the last mile of the enterprise WAN has been the biggest bottleneck in networking and networked application deployment for years now.

The WAN Optimization folks like Peribit Networks (acquired by Juniper) and Riverbed Technology at the beginning of this decade had the bright idea to leverage CPU power – and gains in hard disks and DRAM – to alleviate this last mile thin pipe bottleneck.  They have successfully leveraged the power of the x86 architecture, and, I believe, the breadth of Unix/Linux as well, to add value to existing enterprise WANs, reducing bandwidth consumed on these expensive, very thin WAN links.

With Adaptive Private Networking, Talari is leveraging the power of Linux-on-Intel to build our heavy duty measurement,  intelligent forwarding,  bandwidth aggregation and bandwidth management technology which enables enterprises to take advantage of the Internet ecosystem economics and diversity (which has of course benefited from Moore’s Law advances) without sacrificing the reliability or performance predictability of their private WANs.

x86, Ethernet and TCP/IP became the ubiquitous winners of the last 15 years and vanquished their direct competitor technologies due to snowball economics.  Now, x86 and Linux (the rising star of this decade), will allow the Internet – the ultimate public network – to participate in, and in all likelihood, eventually subsume, the high margin proprietary private WAN business.

 

x86.  Ethernet.  TCP/IP.  Linux.  The Internet. 

 

Winners worth betting on.

 

[Note: I’m posting this from my Virgin America flight home to San Francisco, using Gogo Inflight Internet via WiFi (and free right now – thanks, Google!).  While APN will allow enterprises to take advantage of 3G and 4G networks as auxiliary capacity and diversity for their wired WANs, I don’t think Talari will be harnessing this particular WAN service any time soon, beyond its obvious powers to enable blogging!]

 

What would you do with 20 times the branch bandwidth?

by Talari Blogger-in-Chief Andy Gottlieb...

Fish don’t notice water.  It’s just a given of their environment.

Similarly, scarcity of enterprise WAN bandwidth is a "fact" that IT managers have long taken as a given.  Despite 10 Gbps LAN backbone and server links today, and a minimum of a switched 100 Mbps Fast Ethernet link to every desktop, with Gigabit Ethernet desktop connections more and more frequent, network managers – and application developers, too! – live with the reality that a 1.5 Mbps T1 WAN connection shared across 5 to 50 people is frequently all that’s available.  Even at larger sites, average WAN bandwidth per person will often be similar (or even lower). 

This 3 or 4 order-of-magnitude difference in the availability of bandwidth on the WAN has major implications for network design, server deployment and applications which can be run on the corporate WAN.  And in tough economic times like these, spending twice the amount on your WAN to get more bandwidth to run applications is just not an option.  Heck, spending the same amount you did last year is tough for some companies to do.

When we talk to customers about Adaptive Private Networking (APN) and its benefits, some customers pick up on this idea that they can now afford to have 20 or 30 times the WAN bandwidth they’ve been forced to live with, but for many, it’s an idea that’s so foreign they’ve not though much about the possibilities.

A great example of an application APN enables is videoconferencing.  “Gee, I’d never run ‘real’ videoconferences over the public Internet” is what any network manager worth his salt knows, after all.  That’s what QoS on MPLS is for. 

At Interop Las Vegas 2009, we’ll be demonstrating how having a lot of bandwidth changes the way networks are designed and applications are run.  While almost all techniques from WAN Optimization vendors like Riverbed and Blue Coat are about conserving bandwidth, APN actually takes the opposite approach, focusing, much as RAID did with “cheap” PC hard disks for storage, on making inexpensive bits business quality. 

Because of the inexpensive nature of Internet bandwidth, not only does APN make it affordable to have enough bandwidth to run high definition videoconferencing to the smallest of branch offices simultaneously on your now “converged” network with the rest of your data traffic, it actually duplicates videoconferencing and VoIP sessions to enable very high quality even over “pretty good but by no means perfect” public Internet connections. [Note: such duplication is administrator configurable, and can also be done dependent on the availability of bandwidth.]

So if you’re in Las Vegas next week, please stop by booth 1567 and see for yourself the video quality APN enables even in the face of network conditions which would ruin a simple voice call.

And start thinking about the applications you could run, and the centralization redesigns which would be possible, if only you had 20 times the bandwidth on your WAN. 

Because now you can afford to.

Why is this the right time for an Enterprise WAN revolution?

by Talari Blogger-in-Chief Andy Gottlieb...

Welcome.

Talari is doing for Enterprise Wide Area Networks what RAID did for storage – delivering a network with 30 – 100x bandwidth/$, monthly WAN costs reduced by 40% - 90%, and with greater reliability than existing private WANs using Frame Relay or MPLS.

In a carrier pricing environment where a price/bit factor of 2x is enormous, Adaptive Private Networking brings Moore’s Law and Internet economics to Enterprise WAN buyers for the first time in 15 years.

To answer the question in the title, I’d like to start by telling you a story.

It's a story about the market for mainframe computers, with obscenely high margins and dominated by a single vendor, and later minicomputers with a handful of vendors and very high margins as well. Along came the inexpensive personal computer, and not much happened to the proprietary mainframe and minicomputer business – until those “consumer” PCs were connected by LANs, interconnected by WANs, augmented by client-server computing and reliable distributed software – and the PC hardware / software and LAN/WAN industries grew a huge market, built an ecosystem, and took huge dollars out of the hide of the mainframe and minicomputer budgets.

Wait – that story has already played out…

Ok, let’s talk about the market for expensive mainframe attached storage systems, “plug compatible” with their own extremely high margins and “proprietary disk drive technology” and dominated by a single vendor (IBM). Along came Seagate PC hard disk technology. Not much happened at first. But then along came RAID - Redundant Array of Inexpensive Disks. With RAID technology, companies like EMC built bigger, faster, cheaper and more reliable storage subsystems, and built multi-billion dollar businesses leveraging this “consumer” hard disk technology, and grew a huge market and ecosystem out of the hide of the proprietary mainframe and minicomputer storage budgets. Today, no one tries to build big, fast reliable proprietary single disk storage systems any longer.

Hold on – that story has played out, too…

Actually, this is a story about corporate WANs and the extremely high margins of an industry - the telecom SPs - dominated by one or two vendors in each country. And then along came the Internet and broadband, and… well, in fact all these years later, nothing much has happened to the base corporate WAN business. Sure, Internet connectivity and broadband (cable, DSL) have become a large market, first for surfing the web and email, then e-commerce, etc. Internet broadband is actually the growth business for the telecom SPs, and they continue to invest heavily in these networks, focusing on consumer adoption rather than on enterprise needs.

VPN technology came along and business began to use the Internet for remote access, and in some cases for backup connectivity. But private Frame Relay and MPLS WANs, with per megabit prices of $450 - $1500 per month, remain the dominant way to build corporate Intranets, and are just about the last holdouts from the pressures of Moore’s Law and Internet economics. They are a $25B annual business, including $15B+ for higher bandwidth (fract-T1 and above) connectivity.

VPNs make the Internet secure, and Internet and broadband performance and reliability have gotten a lot better over the last several years. But in fact Internet connectivity on its own does not meet the 3½ nines (99.95%), let alone four nines (99.99%), standard of reliability that businesses have come to expect of their Enterprise WANs. And so even though there is now literally a 100x difference in the price/bit of broadband – at $3 - $15 / Mbps – versus the price of private WAN links, very few businesses, especially larger businesses, have moved off of those expensive, proprietary networks they’ve been using for years, despite the fact that pricing has stayed so high, and bandwidth at most branch offices is less than what’s available to the average home broadband user.

Enter Talari Networks and Adaptive Private Networking (APN).

Just as RAID wrapped a layer of hardware and intelligent software around Seagate hard disk technology, APN does something similar with multiple WAN connections - existing private WANs as well as any kind of Internet WAN links, be they DSL, cable, fiber, Metro Ethernet, WiFi/WiMax, etc.

APN technology uses end-end algorithms to do dynamic, real-time, per-packet traffic engineering.

Rather than optimize each application for the network, APN optimizes the network fabric for all applications.

 APN enables businesses to build a WAN that is simultaneously less expensive, much higher bandwidth, much lower cost and with lower ongoing operational costs than today’s proprietary, single vendor WANs.
APN solves the reliability problem with running VoIP safely on your IP WAN, and the cost and reliability issues with running videoconferencing on your IP WAN.

 And APN can be added seamlessly into existing networks, rather than requiring a forklift upgrade per site, as migration between services even from one’s existing carrier can require.

So APN unlocks the stranglehold that AT&T and Verizon have in this country on their customers’ WANs and WAN budgets. And it does this by leveraging those same carriers (and the cable folks, too) “consumer” broadband networks.

The current WAN Optimization industry, led by Riverbed, is built on the long-standing assumption that your existing network is as reliable as you need it to be, but bits are expensive – and the need, therefore, is to squeeze as much out of those thin pipes as you can.

The WAN Optimization companies are focused on using hard disks to do compression, and the issues of getting bits onto and off of hard disks scalably and at high enough rates. They’re also focused on doing application-specific optimizations to deal with the fact that there is so little available bandwidth on today’s corporate WANs, and on selling the soft benefits of “application acceleration”, since they quickly learned that the 2x to maybe 4x price/bit benefit they deliver over existing networks isn’t a compelling enough reason alone for most customers to deploy it everywhere.

Talari’s insight is that in fact, there are lots of cheap bits out there - they just need to be made reliable enough to be business quality.

A 2x change rarely moves markets, but an order-of-magnitude-plus change does.

With Adaptive Private Networking, Talari intends to build a very big business – for ourselves and our ecosystem partners – out of the hide of that $15B+ Enterprise WAN service budget, by enabling customers to attain huge savings on one of the very biggest line items in their monthly IT budget, 2 orders of magnitude bandwidth per dollar, and equal and in fact better reliability and application predictability than their current locked-in WAN delivers.

More – a lot more – to come.