WAN optimisation, or acceleration as it is sometimes called, is a hot and growing area in networking. Though vendor implementations vary, the general concept is the same. The technology is designed to enhance application performance and improve the user experience without having to increase bandwidth or reduce latency.
But the introduction of these new devices brings with it a dilemma: which group in your organisation is on the hook for ownership, configuration and management?
The appliances use a mix of techniques that goes beyond simple caching to manipulating application traffic flow. Appliances by vendors such as Riverbed, Expand and Blue Coat provide solutions that are technically slick yet, if you consider the recurring cost for circuit upgrades, relatively inexpensive. So far, the results seem positive.
But in many organisations there is an administrative division between the network group and the systems group. The division somewhat follows the 7-layer Open Systems Interconnection (OSI) model. Network engineers spend most of their time working on circuits, switches and routers in OSI layers 1 to 3, venturing into layer 4 for access lists or quality of service configurations. You tend to find your IT staff further up the stack busy working on PCs, servers and applications.
Sure, network engineers tend to know something about operating systems and upper layer protocols. And IT engineers usually know some networking. But the level of knowledge one has of the other is usually limited to just what is needed to complete work in their main functional area. Even though you'll find exceptions, staff expertise tends to be one way or the other.
WAN optimisation appliances tend to configure like a router or switch. They generally contain a Command Line Interface (CLI) and Graphical User Interface (GUI) for configuration and management. In some implementations you must make network configuration changes on routers or switches to redirect traffic to the appliances. Routing protocols, load balancing and asymmetric traffic flows all must be considered during the design.
On the other hand, the appliances also behave like an application proxy. They contain application-layer intelligence and are aware of many upper-layer protocols. They insert themselves in the application flow and manipulate traffic in ways routers do not. The appliances alter TCP window sizes, cache data for future retrieval and only forward data blocks that have changed rather than entire files. They usually have hard drives. To implement the appliances properly, you must understand your applications' behaviour and configure the devices accordingly. The vendors do a good job of making it as simple as possible, but it is not exactly plug-and-play.
So who administers these devices? Do they belong in Network Engineering like a router or in the Information Technology group with the folks who manage systems? Is it a joint effort requiring collaboration between the groups? Where is the demarcation point for operational issues?
I mean, how much do network engineers know about mysterious protocols like CIFS (Common Internet File System) and MAPI (Messaging Application Programming Interface)? Well, probably about as much as IT staff knows about PBR (Policy Based Routing) and WCCP (Web Cache Communication Protocol).
Certainly engineers can always expand their knowledge base. The convergence of voice, video and data has blurred the lines before. Domain Name Systems (DNS) and Network Management Systems (NMS) tend to require a blend of network and system skills. But can you expect your network engineers to become experts in applications while your IT staff becomes versed in networking? Do you cross-train and deal with the impact while staff climbs the learning curve? What do you do if the two groups are not in the same management chain?
If Network Engineering and Information Technology are under common management, perhaps the ownership dilemma is minimal. But if the two groups are in parallel organisations then you may be in for a debate. One group may be keen to take on new responsibilities in order to expand their role in the organisation. Or, they may want to defer the responsibility because of already constrained resources or budget.
Don't forget about the cost to purchase the devices or the recurring charge for the maintenance agreement. Someone needs to pay. You also need to allocate cycles for your staff to perform the initial design and integration as well as operate the appliances long-term.
Hopefully you can work through these issues and find the best solution that meets everyone's needs. Regardless, the dilemma still exists as to which individuals are best to develop the architecture, perform the implementation and manage the overlay network.
Fortunately, the appliances are not incredibly complicated to work with. The vendors have done a good job to make most of the magic happen inside the box. Configuration scripts and GUIs with simple check boxes and drop-down menus help you through a lot of the configuration. Some of the default settings are sufficient for most implementations, which helps to automate the process. Still, how these devices operate will be new to your staff for a while. It will take time and training.
Moving forward, WAN optimisation will be an excellent if not necessary technology to meet performance expectations without having to break the budget for circuits or attempt to exceed the speed of light. Yet, by spanning multiple layers in the OSI model, the appliances seem to blur the traditional lines of management responsibility between network and systems.
Tossing the ball to one side of the fence or the other will likely lead to a sub-optimal implementation and operational issues. It will take a collaborative effort between Network Engineering and IT to make sure it works properly. Those organisations that collaborate well should reap the rewards that the technology has to offer.
Dan Campbell is the director of network engineering at satellite services provider Intelsat.