Interesting Reading

Rate this content:
0 of 5 - 0 votes
Thank you for rating this article.

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.

Add comment


Did you learn something?
Did I save you time? 

Buy me a coffeeBuy me a coffee!

Find by Tag

5G Networks 6LoWLAN 6LoWPAN 802.11 802.11ah 802.11ax 802.11ay 802.11az ACL Addressing Analysis Ansible Architecture ARP Assessment AToM Backup Bandwidth BGP Bibliography Biography Briefings CBRS CellStream Cellular Central Office Cheat Sheet Chrome Cisco Clock Cloud Computer Consulting CPI Data Center Data Networking Decryption DHCPv4 DHCPv6 Display Filter DNS Documentation ECMP EIGRP Ethernet Flipping the Certification Model Follow Me Fragmentation Git GNS3 Google GQUIC Hands-On History Home Network HTTPS ICMP ICMPv6 IEEE 802.11p IEEE 802.15.4 In A Day Internet IOS Classic IoT IPv4 IPv6 L2 Switch L2VPN L3VPN LDP Learning Services Linux LLN Logging LoL M-BGP MAC MAC OSx Macro Microsoft mininet Monitoring Monitor Mode MPLS Multicast Name Resolution Netflow NetMon netsh Networking Network Science nmap Npcap nslookup Online Learning Online School OpenFlow OSPF OSPFv2 OSPFv3 OSX Parrot pcap pcap-ng PIM Ping Policy Port Mirror POTS POTS to Pipes PPP Profile Profiles Programming Project Management Python QoS QUIC Requirements RFC RIP Routing RPL RSVP Rural SAS SDN Security Self Certification Service Provider Small Business Smartport SONET Span Port SSH SSL Subnetting T-Shark TCP TCP/IP Telco Telecom 101 Telecommunications Telnet Terminal TLS Tools Traceroute Traffic Analysis Traffic Engineering Training Travel Troubleshooting Tunnel Utility Video Virtualbox Virtualization Voice VoIP VXLAN Webex Wi-Fi Wi-Fi 4 Wi-Fi 5 Wi-Fi 6 Wi-Fi 6/6E Windows Wireless Wireless 5G Wireshark Wireshark Tip WLAN ZigBee Zoom

Twitter Feed