Interesting Reading

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.

 

Comments powered by CComment

Find by Tag

4G Networks 5G Networks 6LoWLAN 6LoWPAN 802.11 802.11ah 802.11ax 802.11ay 802.11az Addressing Analysis Ansible Architecture ARP Assessment AToM Baseline BGP Bloom's Taxonomy Broadband Cable cat CellStream Cellular Central Office Cheat Sheet Chrome Cisco Cloud CMD Coloring Rules Computer Consulting Customer Support Data Center Data Networking DHCPv6 DNS Docker Documentation Dublin-Traceroute dumpcap ECMP Ethernet Ethics Evaluation Field Operations Fragmentation G-MPLS GeoIP Git GNS3 Google GQUIC Hands-On History Home Network ICMP ICMPv6 IEEE 802.11p IEEE 802.15.4 India Interface Control Internet IoT IPsec IPv4 IPv6 IRINN IS-IS L2VPN L3VPN LDP Linux LLN LoL M-BGP MAC Macro Microsoft mininet Monitoring MPLS mtr MTU Multicast Name Resolution Netcat Netmiko NetMon netsh Networking Network Science nmap NSE Observations Online School OpenFlow OSPF OSPFv2 OSPFv3 OSX OTT Paris-Traceroute Parrot PIM PMTU Policy POTS POTS to Pipes PPP Profile Programming Project Management PW3E Python QoS QUIC Remote Desktop Requirements Resume Review RIP Routing RPL RSVP Rural SDN Security Service Provider Small Business SONET Speed SS7 SSH SSL Subnetting SYSCTL T-Shark TCP TCP/IP Telco Telecom 101 Telecommunications Telephone termshark Testing TLS Tools Traceroute Traffic Engineering Training Travel Tunnel Ubuntu Utility Video Virtualbox Virtualization VoIP VRF VXLAN Wi-Fi Wi-Fi 4 Wi-Fi 5 Wi-Fi 6 Windows Wireless Wireless 5G Wireshark Wireshark Tip WLAN Writing Zenmap ZigBee

Twitter Feed