Too many application acceleration vendors are barking up the wrong tree, by optimising the applications and protocols of yesterday and ignoring those of tomorrow, claims Craig Stouffer, world-wide marketing VP at one of the newer entrants on the scene, Silver Peak Systems.

Instead, Stouffer says that in the future WAN optimisers will need to cover IP as a whole - not just TCP/IP, which he points out is only one of 45 or so assorted IP protocols. If they only handle TCP, that could jeopardise your ability to do server consolidation, he argues.

"There's two ways to look at application acceleration - tactical, to speed up an application, or strategic, to do server consolidation," he says. "I think the desire to centralise the branch infrastructure will be the third inflection point in this market.

"The big financial justification for CIOs is they can pull all the servers out of branch offices. There's also benefits of user satisfaction from application acceleration, but they're less tangible."

Accelerating VoIP
He adds that the next big question buyers need to ask of application acceleration vendors is how well they support VoIP, which is based on UDP, not TCP.

"90 percent of companies have consolidation projects underway, many have VoIP projects too, so the chances are if you have one you also have the other," he says. "It turns out that 40 percent of enterprise traffic is not TCP - it's VoIP, or streaming data.

"These are things we all overlook, but UDP is one of the fastest growing traffic types. It's a completely different architecture - you can't just terminate UDP, you have to handle it differently."

A corollary is that application accelerators need to be application-independent, he adds: "If they interface directly with the application, as Riverbed does, working as an Exchange client, what happens if Microsoft changes the protocol? I think the lack of application-agnosticism or independence has limited market acceptance."

Stouffer notes that this is why the founders of Silver Peak, which was started in 2004 and shipped its first products in September 2005, decided to create technology that operates down at the network level instead. It works by caching byte patterns rather than actual files, he says.

Memorising the traffic
"Our brand is called Network Memory," he explains. "We maintain a network memory of all the traffic that's gone on those links. It's transparent to the user - a request goes to the data centre which identifies the byte pattern and issues a command to fulfil from local cache. Yes, it requires network traversal but the TCP optimisation makes that OK.

"There is a background reconciliation process so the boxes know the information in each store. It means they only need to send the changes if the other box already has that file. So only one instance is kept of a file - at the data centre - no matter how many branch 'copies' there are."

He adds that the capabilities of the different application acceleration vendors are converging, but says that even so there are important questions for buyers to ask of would-be suppliers.

"All the application acceleration companies do advanced compression, and we're all about the same at it," he says. "Some have QoS, some don't - you're sitting at a contention point so that's where QoS and bandwidth allocation needs to be.

"We all do TCP optimisation - there's four or five RFCs that are enhancements for TCP. Some focus more on this than others, but the RFCs are moving forward so it's becoming a must-have feature, and the opportunity to innovate moves elsewhere.

"For VoIP, we do header compression and packet combination. One thing we do that some don't is loss mitigation - we add a small amount of forward error correction. The only others doing it are Juniper, on a flow by flow basis.

"Most will do security on the link, we also secure data at rest - the cache isn't structured content but you can't pass a security audit without security on it."

Late entrants must run faster
And he says that Silver Peak's ability to look at and accelerate all traffic "was just an architectural decision, as a benefit of coming to market later," but adds: "We also have five patents filed on real-time processing mechanisms."

Of course, there are trade-offs to be made in finer grained caching. For example, if the blocks get too small, you might end up passing more metadata to and fro as byte patterns than you would transfer if you simply sent the real data itself.

Stouffer admits that this can be an issue, but says there are still advantages to be had from refining the granularity of the data flow.

"Block caching algorithms need to accumulate a reasonable amount of information, whereas a Citrix flow might only be 20kB/sec, say," he notes. "There is a point where the unit size is so small it's not worth asking - our architecture can go down to a single byte - but the minimum useful size (tens or hundreds of bytes) is still smaller."