Swan Dives Into WAN Acceleration

The man who brought the PIX firewall to Cisco Systems Inc. (Nasdaq: CSCO) is taking on the WAN accelerator market with what he claims is a unique approach to the problem of speeding up enterprise applications.

Swan Labs, founded by CTO Andrew Foss and carrying 25 employees, announced a $15 million funding round today. Its products include new concoctions that Foss won't reveal until October, but as a staging block, the company has acquired the Netcelera product from ITWorx Inc. (see Swan Intros WAN Accelerator).

Swan is really loading up on the celebrity factor, having signed 3Com Corp. (Nasdaq: COMS) chairman Eric Benhamou to be Swan's chairman as well. His Benhamou Global Ventures had provided some of Swan's seed capital.

The new funding, Swan's Series A, came from Norwest Venture Partners and Doll Capital Management (DCM).

Swan is coining its own term, Enterprise Application Shaping, for its brand of traffic management, which Foss claims is a breed apart from the approaches on the market. Details are slim, but Foss is willing to discuss what EAS isn't.

First, Swan isn't doing the kind of packet inspection offered by companies such as P-Cube Inc., which is getting acquired by Cisco. (See Cisco Plucks P-Cube for $200M.) P-Cube uses custom hardware and software to inspect each packet at the application layer, tracking user sessions flow by flow. But packet-minded QOS "is far short of what you can do when you truly understand what the application is doing," Foss says.

The problem arises from the multiple sessions triggered during an application session. Flow-based networking can deliver uniform QOS to each session, but Swan claims it can do better by keeping the entire session tied together.

"You've got to look up the component parts that make up one of these sessions," Foss says. "It tends to be very transactional in nature, and what's unique about transactions is that you've got to parallelize them to reduce the number of round trips."

Second, Swan claims to go beyond the compression techniques used by other WAN acceleration vendors. Actually, most of that group -- which includes Allot Communications, Expand Networks Inc., Packeteer Inc. (Nasdaq: PKTR), and Peribit Networks Inc. -- already use approaches beyond plain compression, says Michelle McLean, director of product marketing for Peribit.

"You're going to see a lot of folks talking about the space at an application level, so you're going to see a lot of language shifts" in the marketing, McLean says. Peribit, for example, extended its product line significantly in June (see Peribit Plugs In Hard Drive).

To get started, Swan picked up Netcelera, which ITWorx put on the block about six months ago, according to McLean. "They arrived at the same technology we were hoping to build, so we acquired it and got a couple dozen happy customers," as well as revenues on Day 1, Foss says.

But that doesn't necessarily reveal what Swan is doing. "[Customers'] lab tests didn't go well for Netcelera, so they didn't stick around" in competitive trials, McLean says. That's left Peribit and other competitors with little idea of Netcelera's capabilities.

Swan is the third company Foss has created. He founded Network Translation Inc., makers of PIX, in 1994 and saw it acquired by Cisco in 1995.

Foss stayed with Cisco until 1999, then left to form Caw Networks Inc. He says he'd caught on to the WAN performance problem by then, and the new company built test platforms (WebAvalanche and WebReflector) that could measure and analyze the problem. This company got acquired, too, by Spirent plc (NYSE: SPM; London: SPT) in 2002.

— Craig Matsumoto, Senior Editor, Light Reading

For further education, visit the archives of related Light Reading Webinars:

  • Flow-Based Networking: A Better Business Model for IP?
  • IP: QOS – Delivering Carrier-Class Quality
  • QOS Characteristics of New Carrier Services: What’s Required
  • mr zippy 12/5/2012 | 1:19:20 AM
    re: Swan Dives Into WAN Acceleration I wonder whether these sorts of flow / application traffic management boxes will ever really be that useful.

    I tend to subscribe to the "throw bandwidth at it" view, mainly because you configure the additional bandwidth, monitor peak usage, and that is it. In other words, I think simplicity wins out in the end.

    These sorts of boxes can probably allow more "bandwidth" to be squeezed out of the network. To do so at a flow and more specifically at an application level, I think a fair bit of effort needs to be put into understanding the traffic types on the network, and tweaking (ie. micromanaging) the network parameters. The question I have is, does this additional time and effort really provide cost benefits, or is it just hiding "efficiency" costs in operational salaries, rather than visibly showing them in the bandwidth budget ?

    I'd probably be willing to accept the idea that "bandwidth management" is acceptable if its costs can be covered within existing salary budgets. On the other hand, if "real" money is being spent on equipment, would a better purchase be additional bandwidth, baring in mind that bandwidth is constantly getting cheaper at a fast rate ?
    H_ngm_N 12/5/2012 | 1:19:11 AM
    re: Swan Dives Into WAN Acceleration Bandwidth IS getting cheaper by the day.

    The problem though is that modern networking protocols, like the file sharing mechanisms of Kazaa for example are increasingly more adept at consuming as much bandwidth as you can throw at them. So, your additional bandwidth simply gets consumed without adding any additional revenue generating customers.

    Without effective traffic management, you will lose money in the 'throw bandwidth at it' approach. (or at least cut into your margins)

    = K
    dogmeat 12/5/2012 | 1:19:05 AM
    re: Swan Dives Into WAN Acceleration These boxes are costly, limited, and must be deployed at both ends of link to be effective.

    I have deployed very simple traffic policies on my WAN links by using application port based ACL's to put traffic into separate "HOV Lanes" in my infrastructure. It leverages my embedded investment in routers and can be deployed everywhere in my network without thinking too hard...

    Just say NO to appliances.
    rjs 12/5/2012 | 1:19:02 AM
    re: Swan Dives Into WAN Acceleration Imagine this, ALCOA, is the only supplier of
    Aluminum. What do you think would happen.

    My bet is that we would be still be living in a world where Aluminum is used as a precious metal to adorn the Washington monument and the Stirling statues. This inspite of the fact that it is an abundantly available element.

    Infact, ALCOA would keep insisting that there is a shortage of metallic aluminum and how difficult it is to smelt aluminum. This is what happens when there is a monopoly. The monopoly will refuse to take chance on new markets lest it cannibalize its current earnings. Fortunately for us ALCOA is not a DeBeers, and fortunately, gem quality diamonds are useless industrially, except to keep your wife or girlfriend happy.

    But, unfortunately for us, the telecom industry is plagued with monopolies. They keep telling us that there is a shortage of bandwidth and that bandwidth is expensive, and in the same breath they say that there is a glut of bandwidth and that we don't need the bandwidth. This is nothing but politics of monopoly.

    rudy123 12/5/2012 | 1:18:57 AM
    re: Swan Dives Into WAN Acceleration
    The problem with wide area (WAN) sharing of files and many applications has nothing to do with bandwidth!

    Protocols (i.e. CIFS) can be very chatty! They send so many ACK's - ACK's, after each <100 blocks sent that even if you gave it its own OC3 (and higher) the actual file transfer will proceed at around 1.5 Mbits per second.

    Sign In