Wan acceleration is more than just a bandwidth issue

As employees of companies become more dispersed and more mobile, one of the issues that organisations are struggling with is providing adequate speed of response for those accessing centralised applications and services over the wide area network (Wan).

The first option is always to just throw more bandwidth at the problem; if an application is working slowly, then surely providing it with a fatter pipe will alleviate the problem?

This generally doesn't work, as the problems lay far deeper in the complexities of how the internet's transport protocol works. Let's look at the many problems that we are up against:

• The latency of the network is a major problem. With the internet having been built to enable path redundancy so that connections can be maintained should a breakage occur on the network, it can take some time for packets to reach their destination. Using a 'ping' command can show the problem here; latencies of a quarter of a second are normal, a full second is not unheard of. Think of the problem that this causes to such traffic as voice: a second's lag between saying something and being heard results in a system that's unusable.

• Quality of service (QoS) can also be an issue. The use of 802.1q/p internally for the setting up of virtual Lans is now being complemented with virtual Wans, and the use of Multi-Protocol Labelling Services helps to maintain QoS across the Wan.

• The need for packets to be put back together at their destination. As the internet sends out each packet separately, these all have to reach the destination and be re-constructed as the overall data stream. Tunnelling can help here, ensuring that the packets all follow the same route.

• There's the size of data packets; the internet tends to use small packets, whereas many applications can be best suited to large packets. Unfortunately, dynamic packet shaping is not supported by the majority of operating systems or applications, so we just have to put up with non-optimised traffic.

• There's the different type of protocols that are used, such as the fairly ubiquitous TCP and UDP. These need to be dealt with differently, as do the different types of traffic – SMTP, HTTP, FTP, VoIP, VPN and application specific traffic. 'Flow control', which maintains control of a complete session, can help to maintain an overall quality of service.

• Information reuse can be utilised to optimise traffic. For many users in remote offices, the same information is pulled from the central system time after time. Basic caching can help response here, with advanced, bite-based caching adding real benefits.

• Information can be compressed. A lot of what we pull and send across the network is capable of being compressed – often by a factor of 2 or 3 times – so less data to send should result in better performance.

So, we need a solution that brings as many of these capabilities together as possible in order to minimise the impact of just utilising the internet.

There are a number of players in this market, each of which has slightly different approaches. But Wan acceleration specialist companies, including Riverbed, Expand Networks, BlueCoat, Packeteer and Silver Peak, are up against the networking companies such as Cisco (which acquired P-Cube) and Juniper (which acquired Peribit).

This is a big possible market, but many businesses are unaware of the problem, and many techies shy away from addressing it. Solutions have become far more affordable in the past year or so, and many of the companies involved are coming through with very affordable small office solutions.

If your company has more than one office, and is dependent on providing Wan access to centralised solutions, Quocirca recommends that you look at what the Wan acceleration vendors have to offer.

Author: Clive Longbottom, service director, Quocirca