Buffering and jitter? Network intelligence beats bandwidth brawn

Bandwidth is not the best longterm cure for complex networking issues

When networks fail to perform in ways that cause users to complain - buffering, delays, stuttering video, poor quality VoIP calls - there's a time-honoured solution beloved of network engineers: throw some more bandwidth at it. The great thing about this is that it really does eliminate many of the symptoms; the bad thing is it does little to address the underlying causes which will re-emerge in time. It is neither a sustainable nor a cost-efficient approach.

Very often the causes of bottlenecks are to do with past decisions made with perfectly good intentions, such as moving to SIP trunking in order to consolidate voice and data and reduce telecoms bills as well as opening up new possibilities and functionality around VoIP, video-conferencing and unified communications and collaboration (UC&C).

But simplifying the procurement of these services can have the opposite effect on the network, such as with application performance management. Certain services and applications need to be prioritised over others, and when problems occur, the cause may be anywhere from the SIP providers systems, to gateways to cables to software. The more types of traffic that flow down the pipe and the higher the data volumes, the trickier diagnosis becomes.

Throwing bandwidth at SIP trunking issues will work for a time but when more voice users are added or new applications are deployed that gobble up a greater share of network capacity this is likely to be reveaed as a sticking plaster solution. It doesn't take much to upset the throughput of voice and video traffic which, unlike most other data streams, need to flow in real-time and without the glitches that so frustrate end users.

The long-term answer is to apply some intelligence to the matter at hand, rather than resorting to bandwidth muscle every time. What's needed is to obtain a holistic and real-time overview of the network, with feedback mechanisms that allow it to self-adjust, tackling quality of service (QoS) isses before they become noticable. In the case of hosted SIP trunks this kind of QoS and traffic management will be handled by the service provider. However, the metrics provided by service providers can be quite basic, making it difficult to gain the end-to-end visibility necessary to identify issues and act upon them. The figure above, part of a recent Computing study, demonstrates this.

So do you spend more on dedicated tools to monitor and manage traffic and QoS or do you stick with what you've got, boosting the bandwidth every now and again? The increased workloads handled by networks and the rising importance of real-time data suggest the balance is tipping in favour of the former.