Interesting Reading

This article was originally published on January 21st, 1999!

Read this carefully. I’m going to explain to you that there is no Quality of Service (QoS) today with packet-based technologies. "No QoS?" you ask? Nope. Not even with ATM. Not yet.

Let’s begin with addressing the two sides of the packet technology debate and technology. Those who support IP technologies being the path forward will be quick to concede they have been working hard to define what real-time services are and how IP-based solutions can indeed achieve QoS. These new developments remain unproven and uninstalled, for the most part. The ATM crowd may find that some of the small hairs at the base of their necks are already at attention. QoS has been their divisor, their head and shoulders differentiator to variable length packet technologies. Strict definition of delay measurement parameters, detailed Class of Service (CoS) definitions and detailed, if not complex, processes for guaranteeing network performance, and thus QoS have always been the strength of their technology. Don’t give up on me. This is not an anti-ATM article. On the contrary, what I submit is that ATM still has that lead. The lead, that is, toward solving QoS problems, but I stiffly hesitate to say it is finalized by any means.

Let’s use ATM as a baseline. ATM has a unique performance advantage in that the design of the packet, called a cell, is fixed in length. This allows network planners, switch manufacturers, and management systems to use mathematics in predicting network performance based on a particular user’s network bandwidth needs. The true way this is done is ATM switches use per virtual circuit prioritization schemes in buffers to provide service level differentiation between user virtual connections on the net.

But, and this is a big one, the ATM manufacturers have all approached the solution to priority levels with differing solutions. I own network A and selected manufacturer X ATM switches with 2000 priority levels. You own network B and chose manufacturer Y ATM switches that have 3000 priority levels. Both networks and switch designs are world class, developed and supported by the sharpest engineering minds in telecommunications. A customer of mine wants to connect their new sales office on your network and is willing to pay for relatively high prices for QoS guarantees (it is always a price/performance trade off). This, on my network, is priority level 7. What is that on your network? Level 7 on my switches provides a maximum delay of 27 microseconds and loss ration of 10E-10 packets. What does this mean on your switches? Bottom line: different vendors have different and innovative queuing and QoS prioritization schemes and therefore no QoS especially if multiple switch vendors are involved in your network connection.

The service providers have to negotiate these differentials while containing their intellectual property, protecting their design approaches, and keep secret why their solutions and approaches are better than the next provider. If they have been successful to date in this task, it is by pure luck, I say. Some believe that it is the duty of the forums and the regulatory bodies to standardize approaches between switch types, and therefore ease the challenges of these types of negotiations. Some believe the newer emerging technologies will solve these issues. Great, bring them on. The bottom line: there is no QoS today, especially when you go across multiple networks.

The ITU defined CoS and QoS parameters when they created Broadband ISDN and ATM. The Internet core technologies disagree with this approach and have begun their own initiatives in flow management. New services like Virtual Private Networking and managed IP networks are offering significant strides toward solving network performance issues. Each of these approaches has its merits and its drawbacks. At the same time, these innovative technologies need to be supported and pushed forward to not just attain the performance of today’s network, but to exceed it. Bottom line: None of the solutions meet the high standard already set by today’s voice network, but that doesn’t mean they can’t do it.

America has built perhaps the best voice telephone network in the world. On the eve of packet technologies revolutionizing this network, we stand poised with no proven tool to match this performance. Some argue the cure is bandwidth (I’ve heard Dense Wavelength Division Multiplexing will provide so much bandwidth, that QoS will be guaranteed to all), some argue simplicity and less call management improve network capacity and performance (I’ve read claims stating Voice over IP will render the traditional phone companies helpless), some argue we don’t need this quality (Cell phones are everywhere with less QoS than plain old telephone service and look at the growth). Bottom line: no agreement, no consensus, and no clear winner with the solution in hand, therefore no QoS today.

That’s right, there is no QoS solution with the packet technologies - not yet. We need to fix these problems and not ‘spin-doctor’ the issues. The Telecommunications Act did not and could not have done it. Government needs to support the industry in innovation and through the changes which are redesigning its infrastructure. We need the technology leaders to stop wasting energy competing (i.e. ATM v. IP, SONET v. DWDM), but rather to rush innovations and improvements on their wonderful designs and technologies which will guarantee when you and I need to make a 911 call, it will work that it will make it through, above all other calls, that we will get dialtone and not be denied because Internet use has dried up dialtone or erlangs. Big and small businesses alike need access to low cost, bandwidth generous, and performance guaranteed solutions for a fair, competitive price.

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