Big Bandwidth on Campus

FRAMINGHAM (07/24/2000) - Next-generation applications - telephony, building management and the like - are on their way to the campus network. Key to their success is whether the critical enabler will have adequate resources or the use of adequate resource controls. Or, put in context, big bandwidth or quality of service (QoS).

As much as I'm a believer in the value of QoS, all indications are that network managers will use bandwidth to solve the problem.

The problem is as voice, data and building security networks merge into a "data utility," there is not only a greater volume of traffic, but a greater diversity of traffic characteristics.

Not all of the streams are equally important - in terms of delivery at least.

Yet some less time-critical streams, such as file transfer, can gobble up whatever bandwidth is available. In the worst case, this robs bandwidth from time-sensitive applications, such as telephony, causing their performance to degrade to unacceptable levels.

There are those who say implementing bandwidth management, such as QoS, and making switches monitor and alter the traffic flow can make these converged networks work. Others say by throwing bandwidth at the problem, you'll solve the difficulty because, in the virtual sea of bandwidth, the traffic streams will never collide. Much as I favor control, I think the bandwidth side is going to win.

The problem is not with QoS. It works. It is, however, complex.

The only way to avoid that complexity is to solve the problem using the "raw bandwidth" approach. While it may not sound elegant, there is ample precedence.

Our technology culture has become quite accustomed to solving problems using firepower rather than finesse. From micro, to mini, to mainframe, the way to guarantee better performance has been to fork over money for more powerful hardware.

The networking analogue is to overprovision bandwidth - bring Fast Ethernet to the desktop and Gigabit Ethernet or aggregated Fast/Gigabit links between the switches.

There is still a need for QoS. Even with a massively overprovisioned network, streams-bursting can cause congestion at aggregation points. Time-critical traffic could be delayed or discarded. Bad news should it happen - but how much exposure is there?

Clearly, the more bandwidth I build into my network, the less likely the scenario. But, without QoS, there are no guarantees. The problem is so few users have gotten burned by not having QoS that it seems like rolling the big-bandwidth-only dice is safe.

As I see it, until network equipment vendors can prove unequivocally to network managers that a non-QoS campus network is exposed to unacceptably high risk, it is going to be "big bandwidth" all the way as we build out our next-generation applications.

Tolly is president of The Tolly Group, a strategic consulting and independent testing firm in Manasquan, N.J. He can be reached at ktolly@tolly.com or www.tolly.com.

Join the newsletter!

Error: Please check your email address.

More about Tolly Group

Show Comments

Market Place