Tinsley said MPLS is gaining popularity over the old and expensive system of using private telco lines for multisite backup and data replication, and distance replication is increasingly replacing the practice of shipping tapes for remote data protection. But when he sat down with SearchStorage.com for a Q&A about his company's products, Tinsley warned about packet loss and security issues that go with the new methods of WAN connectivity.
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 going out and buying a dedicated circuit from a service provider, but of course there are some quality and security
The dirty little secret of MPLS and Internet VPN WANs is that unlike a lot of those private line networks we used to use, they have loss, and they're designed, actually, not to deliver all the packets that enter the network. All MPLS and Internet VPN WANs also routinely deliver packets out of order. Most applications don't really care. Certain applications, like data replication, care very much.
The fact that some of the packets get dropped and don't get through, the fact that some don't get through in the correct order, those increasingly are becoming the limiting factors in terms of how fast certain apps can run on wide-area networks. Two years ago, wide-area networking used to be all about bandwidth and latency. Now, you have users saying, 'I went from an OC3 to an OC12, and it doesn't run any faster.' But it's not about bandwidth -- it's diminishing returns in network quality that's 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 its impact on the application. With replication and backup, those applications see dropped packets, and 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 September 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 [service level agreement] that most service providers offer their customers, which usually guarantees 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 that's the average calculation per month -- you can have 36 straight hours of 2% packet loss and still meet that monthly SLA.
How does your product address these issues?
Tinsley: For a network with 5% loss, we can reduce that to 1% or so, and for 1%, we can bring that down to a fraction of a percent. We eliminate 80% to 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 said you can cut out 80% to 90% of the losses. What is represented by that other 10% to 20%?
Tinsley: It depends on how clustered and bunchy the losses are. Generally, they're spread out, but there are some 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.
The subject of cloud computing and bandwidth as a barrier to entering the cloud has been a topic of discussion lately. Some vendors are looking at ways to optimize bandwidth between individual clients and the cloud. How would you address that?
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 storage data deduplication recently. Is this something Silver Peak might also get into?
Tinsley: How should I answer this? Hell, no is our answer. 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 those 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. We continue to leverage rather than compete with them.