Tinsley said that MPLS is gaining popularity over the older and more expensive system of using private telco lines for multisite backup and data replication. He also said that distance replication is replacing the practice of shipping tapes for remote data protection. But when he sat down with SearchStorage.com to discuss the market for WAN acceleration, Tinsley warned about packet loss and security issues that go with the new methods...
of WAN connectivity.
SearchStorage: What's the biggest networking challenge facing storage applications today?
Rick Tinsley: Most enterprise organizations have already started to implement MPLS. It's a standard for WAN connectivity that was standardized eight to 10 years ago. Three-quarters of the customers and prospects that we routinely communicate with also said they plan to use Internet VPN tunnels. Compare this to the older means, like private lines, where essentially you bought circuits that were designed and built for telephone calls. MPLS and Internet are a lot cheaper than buying a dedicated circuit from a service provider. But of course there are quality and security concerns when you're running on the public Internet.
The dirty little secret of MPLS and Internet VPN WANs is that, unlike a lot of the private line networks we used to use, they have loss. They're designed not to deliver all the packets that enter the network. All MPLS and Internet VPN WANs also routinely deliver packets out of order.
Now, most applications don't really care. But certain applications, like data replication, care very much.
That some of the packets get dropped and don't get through, and that some don't get through in the correct order, these are becoming the limiting factors in terms of how fast certain apps can run on WANs. Two years ago, wide-area networking used to be all about bandwidth and latency. Now, users are saying, "I went from an OC3 to an OC12, and it doesn't run any faster." But it's not about bandwidth. Diminishing returns in network quality are the biggest problem.
Tinsley: It's not so much about the amount of data in a packet, which tends to be a maximum of 1,500 bytes, but the impact on the application. When replication and backup applications see dropped packets, they're going to retransmit, which means you get lower effective throughput and extend the amount of time it takes to do it. Some applications are written to be more tolerant of packet loss, but replication and backup apps were developed to run on real-time local networks.
Since 9/11, there's been an increasing trend of replicating data over distance. But we're using applications written to run on internal Fibre Channel networks and stretching them across the WAN. They're very sensitive to variations in network quality. It can also limit the use of thin-client applications that centralize servers, storage and workstation hardware because even a modest level of loss makes the applications really perform differently.
By a "modest level of loss," I mean the SLA that most service providers offer their customers, which usually guarantees that no more than 1% of packets will be dropped in a month's time. That averages out to no more than one in 1,000 packets. But the fine print is that's the average calculation per month. You can have 36 straight hours of 2% packet loss and still meet that monthly SLA.
How do your products address these issues?
Tinsley: For a network with 5% loss, we can reduce that to 1% or so. For a network with 1% loss, we can bring that down to a fraction of a percent. We eliminate 80-90% of the loss on a network in two ways: forward error correction and packet order correction.
Since we sit at both ends of the wire, we can tell when a packet has been dropped or received out of order. Forward error correction starts adding parity packets to mathematically reconstruct lost ones. With packet order correction, we apply sequence numbers to packets, and if they're coming across in the wrong order, we can either wait to receive all the packets and put them in order, or use parity calculations to just reconstruct the missing packet.
You can cut out 80-90% of the losses. What is represented by that other 10-20%?
Tinsley: It depends on how clustered and bunchy the losses are. Generally, they're spread out, but there are times there'll be three dropped in a row. We don't add that overhead every time we send a packet. We add that in once we've detected some loss. We could add more overhead and treat more loss, but our approach gives you the maximum benefit with the minimum amount of overhead. It can make an otherwise unusable WAN usable for loss-sensitive applications.
Lots of folks are discussing bandwidth as a barrier to entering the cloud. How do you address ways to optimize bandwidth between individual clients and the cloud?
Tinsley: We're already in use today between service provider data centers -- AT&T, for example. We're not interested in consumer offerings or making client software. If you're talking about one user at home or on the road, they're going to have Citrix, Microsoft or VMware Desktop Infrastructure [VDI] for that. Customers always buy best-of-breed products, and they're rarely or almost never from the same vendor. But we're also anticipating there being outsourced offerings for hosted VDI, and to the extent the clients for the service are in one location, they'd be eligible for use of our product as well.
Riverbed previewed its Atlas product for primary storage deduplication recently. Is this something Silver Peak might also get into?
Tinsley: Hell, no. We've done very well partnering with storage vendors. EMC is our largest channel partner, and the last thing we want to do is compete with our storage partners. Most Riverbed deployments are a few small boxes to accelerate email delivery in a few small locations. They have thousands of customers but aren't deeply penetrated, that's why they're expanding their focus. We're thrilled that they're increasingly competing with our partners.