This article was originally published on May 21st, 1999!
I was working several months ago on a network design consulting effort which underscored the main point of this article – that bandwidth is the simplest cure to all networking problems, and in particular to Quality of Service (QoS). I had spent weeks looking at the expected service requirements: the mix of constant bit rate (CBR), real-time variable bit rate (RT-VBR), variable bit rate (VBR) and unspecified bit rate (UBR) bandwidth. At several points I was frustrated enough to consider what a learned colleague always says: forget that stuff, a simple connectionless IP network will always perform better. Deep down I knew I had to press forward. The client certainly wanted to support Internet Protocol (IP) technology, but they were also in favor of ATM as the underlying transport because they were sold on the multimedia strengths of ATM and service offerings of what I will call Private Virtual Channel bandwidth.
Network planning ATM is not for the faint of heart. There are no proven traffic mix scenarios to use as a basis to work from. Everyone I have asked or spoken to have said they had little oversubscription issues and were not aggressively planning bandwidth. Most seemed to err on the side of conservatism so customer satisfaction remained high: to undersubscribe bandwidth. Throw in a question or two about Switch Virtual Circuit (SVC) bandwidth and conservatism faded to tight lips which meant to me either no knowledge or high risk mistakes and no one wants to talk. I pondered this on several crammed flights sitting in center seats. “The guy on the left is selecting conservative bandwidth management practices and the guy on the right isn’t talking…hmm. Should I, Could I, Would I be the one to develop a strategy? The right mix? What if I am wrong? Will I ever work in this business again?”
Hours led to days, modeling spread sheets, and further contemplation. Another colleague called me, an old friend, and asked me how I was doing. All was well I explained, except for the groping for an answer in planning an ATM network. Simple, he responded, just double the estimated bandwidth, you’ll sleep like a puppy! That was it!
Eureka! Bandwidth is the cure. If I have plenty of bandwidth, who cares about the QoS? As I was checking in for my next flight, it became clear. When the airline over books a flight…wait they always overbook if they can, so perhaps I should say that when everyone shows up for a flight and there are not enough seats (as there was on this day to Raleigh-Durham), wouldn’t it have been easier for them to just push the MD-80 away from the gate and roll up – say – a 757? Everyone would get a ride. There would be plenty more seats and the passengers would probably high-five the staff on their way on the plane. It sounds so easy, but the logistics would be a nightmare. Aside from that, the thought is a good one. Rather that go crazy planning complex ratios of bandwidth utilization forecasting based on class of service use and delays and queuing issues in switches, just make so much bandwidth available that everyone gets across the network. Back to the modeling spreadsheets. Let’s double the bandwidth, and recalc the costs. OOPS. Ouch, way over the clients budget. We can eliminate the complexity of ATM deployment, maybe just put IP straight over the SONET links. Adjust the model again. Things are looking up.
The client calls to ask me how things are going. “Tough haul” I respond. I am looking at alternatives. Expect a call in a couple more days. Then I read this news bulletin from ENRON – have you heard? They are just putting IP over what they term Layer 0 (zero), the Photonic layer. There you go, That sounds like where I’m headed so I modify the models yet again. I now have three sets of models, so many numbers swimming in my head, network designs which are completely different and less than 24 hours before a call to the client. Maybe I should flip a coin. I contemplate this and wonder how many others have done just that.
Bandwidth is a wonderful solution which simplifies network design issues for certain. But one bothersome issue is how much bandwidth is the right amount. Two major issues exist: when has a new bandwidth implementation actually been enough for more than, say 1 year, and what is the cost? I have listened to so many IP ‘experts’ tell me that traditional time division multiplex thinking people just ‘don’t get it’. True enough perhaps. But the real issue is that bandwidth comes at a price and if you boil it down to cost per megabit, the client doesn’t always want to pay. This is especially true when one forecasts (conservatively) that they should plan for a 10X bandwidth increase in the next 2-3 years. Ouch. Take a look at the Terabit switches interfaces, management systems. The technology is cool, so are Ferraris, and they aren’t cheap.
So theory is great. Bandwidth is a magical pill – an antidote for network performance. But today we must factor in great queuing techniques with little processing delay (now there is an oxymoron) a solid routing design, CoS and QoS, and bandwidth management to design the optimum network solution. There is no ‘one-stop shopping’ solution quite yet.