|
Multinational enterprises are experiencing relentless pressures from inside and outside their organizations fueled by “the perfect storm” of multiple forces colliding – application development, technology advancements, more savvy and demanding customers and the economics of an increasingly competitive marketplace. Utilizing Class of Service (CoS) functionality is one method of optimizing network performance so that it aligns with the enterprise agenda. There has been much discussion about the valuable benefits of CoS; however, there are also some common myths, which unless challenged, can impact the success of the CoS implementation. The focus of this paper is to expose the common misconceptions of what CoS can and cannot do. We will also discuss an approach to ensure a successful CoS implementation in the enterprise – and tame “the perfect storm.”
Myths and Misconceptions
CoS Adds Bandwidth and Relieves Congestion
CoS is a powerful network design tool to aid in performance engineering for your network. Used properly, these features often allow you to forgo bandwidth upgrades while maintaining the performance of mission critical applications. However, CoS is not a substitute for insufficient bandwidth, nor does it replace the need for careful capacity planning. CoS is intended to provide deterministic behavior during periods of access facility congestion. This behavior represents a tradeoff usually favoring mission critical applications during congestion over less time-sensitive or less critical applications. If sustained congestion occurs for a given network link, then additional capacity may be the only way to assure satisfactory performance for the applications supported across the connection.
CoS Does Not Change the Laws of Physics
There are four sources of packet delay in a typical enterprise environment – forwarding delay1, queuing delay, propagation delay2 and serialization delay3. Assuming that the enterprise has deployed the industry standard for hardware-based routers and the access bandwidth is fixed, you have no real control over forwarding delay, propagation delay or serialization delay. The only aspect of packet delay across the network that can be actually controlled is queuing delay. Queuing delay (1/1-U) is best observed by understanding the load across the network in both directions. This utilization will increase the overall time a packet has to wait in transit for the line to clear. Load on the network can quickly start to increase packet delay; > 70% (for <T1 ports) will increase serialization delay exponentially as shown in Figure 1.
Without CoS, queuing delay can easily represent the largest delay component across the network. When CoS is properly deployed, the queuing delay is minimized and the end-to-end delay is primarily a function of the fixed delay components. The deployment of CoS in the network does not impact the speed of light in optical fiber, the switching time of networking equipment or the time taken to transmit a large packet onto a low speed link. Therefore, even with a proper CoS strategy, any of these remaining delay components can still lead to marginal performance of response-time critical applications.
CoS Controls All Aspects of the End-User Experience
The end-user’s experience is controlled by factors other than CoS. Some applications perform poorly across WAN facilities even with optimized CoS. In fact, some applications will perform poorly when there is no competing traffic on the WAN. These applications are often performance bound by application level windowing and/or back-end processing that cannot be overcome by CoS optimization. Microsoft Networking, native database operations and many file transfer utilities are a few of the examples of applications whose inherent implementation limits network performance.
Additional factors can skew response time results including performance of user workstations, performance of the DNS server, protocol windowing, stability of the LAN environment and performance of the target application servers.
Every Application Needs its Own Class
At the outset of the network design, it is necessary to identify the different characteristics of the traffic on the network. Voice traffic typically requires specific latency, jitter and bandwidth characteristics. ERP is less susceptible to jitter, but still requires low latency to prevent the session from timing out, and typical bandwidth of 25Kbps per user. In comparison, Microsoft Exchange database replication has no strict latency or jitter requirement, but will consume as much bandwidth as is available, often to the detriment of other applications.
|
