Is QoS reemerging from the dead?

Next week at Voicecon, I will be presenting in a track about getting enterprise networks ready for voice and video communications. Which prompts 2 thoughts: First of all, I started my career as a software engineer for Class 5 voice switches, and when I made the switch to data communications I made a career out of talking about QoS (for ATM, I am aging myself now) when it came to those emerging network supporting voice services. And the second thought is that, instead of feeling finally vindicated about the fact that finally and indisputably QoS matters, I feel like we are now facing a whole new challenge: to make QoS seamless. Because that is the only way it will become relevant.
I’ll say something controversial: the QoS naysayers were right all along. Why? We do have very powerful end to end tools to offer QoS across the network. We have RSVP, differentiated services, we have CAC (call admission control), and we have the signaling protocols to invoke all of these. So when it comes to insular network thinking, we have had the QoS problem solved for a long time, end to end across the network.
What I like to call the horizontal QoS dimension.

But the fact remains that the vertical component, the interface towards the applications, remains challenging. The truth is that software programmers have never wanted and still do not want to learn insular network protocols like SIP or RSVP to invoke QoS. And they should not have to, it’s like asking car drivers to be able to understand the innards or their car’s transmission to be allowed to drive an automatic.
The users of the QoS service, just like the car driver, just want to enjoy the convenience of the technology. And in the case of QoS in the network, users do not care about its innards, about weighted fair queuing algorithms or DiffServ configuration – but they do care about high quality video and audio, they care about innovative, rich applications that make them more productive at work and allow them to have more fun when they are done with work. They want what we call QoE, that is, quality of experience. And users *and* application programmers alike want this to be transparent to them. Application programmers want to use their familiar programming environment, and not learn obscure network protocols and APIs.
Which means that to solve the “vertical” QoS issue, that is, the communication to the application layer, the networking community has to offer services in 2 ways: in familiar web application language –be it SOA or more lightweight “RESTful” ways- or transparently, that is, allowing the network to dynamically adjust QoS mechanisms based on application awareness. The problem with QoS is that it has remained an insular networking topic, and application programmers never quite got around to learn about it. Even when they were curious about it and saw its benefits, learning a complex API or a 200-plus protocol specification was understandably not a priority for them. But now we find ourselves in a perfect storm: richer applications that adopt more and more resource hungry services –such as video- combined with a rising awareness among networking companies that we have to offer our services in languages that application architects are fluent in.
It boils down to the simplicity principle: make QoS user friendly and intuitive, and application programmers will leverage it to deliver on what their users want: rich experiences that make them more productive at work, and offer more entertainment outside of it. I am excited about
it: I have been learning QoS protocols in networking since the early 90s, and I feel like now they will finally become key tools with widespread adoption. Because for the first time we are about to truly cover both the horizontal and vertical components of QoS and QoE.

Posted by Paul Liesenberg at 07:58AM PST