Application and Network Analytics--Asking the Bandwidth Question from your Service Provider

The key to achieving high performing and responsive applications is to ensure sufficient bandwidth has been provisioned in the network. But many questions arise:

• How much bandwidth does an application really need?
• How do you know if it will be enough or too much?
• If the application has a problem, how do you know if it’s a bandwidth issue?
• If it is a bandwidth issue, how can you see where the congestion is?

We have been providing precise answers to these questions to our customers for the past several years using a suite of real-time application and network analytics we provide as part of the Corvil platform. In our experience, it is interesting to note that people rarely get good answers to the above questions from their service providers? At best, the answers are vague. At worst, they are meaningless, misleading and self-serving. However is it not completely the service provider’s fault. Many times, the question posed is as vague as the answer provided.

How to ask the bandwidth question?

We must first realize we are looking for the bandwidth, which gives us the desired network quality of service (QoS) for the application. Therefore asking the question of how much bandwidth is needed without specifying the QoS objective is inviting a vague answer.

For a network the QoS objective should be expressed in the form of latency and loss. Let’s start with latency. The bandwidth needed to deliver a specific latency objective is directly dependent on traffic load. If the traffic load spikes, then latency will increase. Therefore the bandwidth required must deliver the specified latency objective even in the presence of traffic spikes, i.e microbursts. Last but not least, to fully express the question, you need to specify the compliance level of the requirement? For example, do you want the bandwidth to deliver the latency objective for 100% of packets or perhaps 99.99% of packets is sufficient. Our experience shows that this 0.01% delta in compliance factors can result in significantly different bandwidth requirements and hence a lot of money can be saved.

An unambiguous and fully specified way to ask the bandwidth question for latency is:

"For this application traffic, how much bandwidth is needed for no more than 10 milliseconds of latency to be experienced by 99.99% of packets during the busy 1 minute of the business day."

In this example:

• 10 milliseconds is the latency objective
• 99.99% is the compliance level i.e. confidence level
• 1 minute is the busy period for the service level objective, i.e. corresponds to the maximum message rate or packet rate
• Business day is the period of time over which the service level agreement applies. This could also be the trading week.

In Corvil we refer to this method of describing bandwidth requirement for latency as the Corvil Bandwidth (CB) where the latency objective, compliance level, busy period and measurement interval are input parameters that can be specified by the end user.

What about loss?

For applications, it is equally important to protect against packet loss. Sometimes it is even more important. Unfortunately, it is not unusual to see network service providers utilize small buffers in routers and switches in an attempt to minimize queuing latencies. This comes at the expense of increased packet loss when microbursts occur. Lost packets cause retransmissions at the TCP and application layers and ultimately results in much larger latencies being experienced.

Therefore, when asking the bandwidth question it is important to specify a loss objective as well as a latency objective if you want to optimize application performance. For example:

"For this application traffic, how much bandwidth is needed to protect 99.99% of packets from loss with no more than 10 milliseconds of latency to be experienced during the busy 1 minute of the business day."

We recommend using this type of structure when looking to specify the bandwidth requirement with service providers.

The Corvil application and network analytics technology referenced above and used in the Corvil platform computes the Bandwidth Requirement (BWR) for both latency and loss targets for any given application load. Two bandwidth numbers are produced, one for latency and one for loss. The highest of the numbers should be used when provisioning a network. When the Latency BWR dominates then it is useful to add bandwidth, but when the Loss BWR number dominates, it is often more cost effective to increase buffer sizes rather than adding bandwidth.