When going through the decision process for a bandwidth solution … for example, T1 or DS3 bandwidth … QoS is AND should be an important consideration.

What does (and should) QOS mean to you?

Definition of quality of service (QoS):

In computer / telecommunications networks, traffic engineering term. It refers to the resource reservation control mechanisms, not to the quality of the service itself. Ability to prioritize applications, users, data flows or guarantee data flow performance.

But you knew / you know.

The alternative to QoS is “best effort” high quality network communication by providing excess capacity so that it is sufficient for the expected peak traffic loads. But high quality of service is often confused with high-level performance or achieved quality of service (eg, high bit rate, low latency, low probability of bit error, and other mysterious measures).

However, from the perspective of the user, QoS in telephony and video transmission, it is necessary to try to measure the quality that the user actually experiences, called “Quality of experience” (or QoE), based on the user’s perception or its level. of satisfaction. Therefore, QoS needs to track subscriber satisfaction, which is obviously subjective and varies based on a number of factors at the end of the user.

And when combined with experience, you get a kind of hybrid measure that can be called “Quality of Service Experience” (or QoSE), which attempts to measure user experience in relation to quality delivered, regardless of bit rates. or other arcane measures. None of that matters if the user is not satisfied.

That is what QoS means to me.

I believe that QoS is meant to measure the performance of the application delivered to the end user. If we refer to QoE when we talk about QoS, we can now apply an experience-based model (QoE) to traditional network measures of quality of service provision (QoS). Adding QoE to traditional QoS measurements allows us to rephrase my first line to “QoE is intended to measure application performance experienced by the end user.”

Since QoS measures application performance, the QoS measure varies by application (Voice, VoIP, Video, Data, etc.). I think that while QoS provides a good indication of application delivery performance, the metric should be used hand in hand with some kind of experience-based model where available, such as QoE.

I guess QoS in the eye of the beholder. It depends on the application, the network, the level of traffic and (not sure about this) the phase of the moon. Yet another measure of QoS is the MOS or Mean Opinion Score used in an attempt to quantify subjectivity in the Voice app space. Then there’s the ITU-Ts Emodel … (so how was that phone call for you?)

Thousands of research papers have been written and discussed in academia. In the industry, we have seen a large number of IEEE specifications regarding QoS that are based on one assumption: Put a best-effort CPU / software-centric repair mechanism over IP that understands one or the other packet prioritization scheme and you will have QoS. The industry calls this soft QoS.

Neither of these schemes is suitable for traffic that crosses multiple carrier domains. MPLS over IP is a core technology, what we need for end-to-end QoS is an end-to-end solution. Hard QoS.

So how about starting with a clean design for global QoS? My ten-fold initial (to avoid unnecessary complexity) would be to insist on only two classes of QoS: best effort and best quality. Best effort needs no introduction, that’s what bogs us down on the internet today, with no guarantees of any kind, you get what you get, take it or leave it. By definition the best quality should allow IP networks for all latency critical applications such as voice, video conferencing, game database replication … on a global scale.

And that’s where the next killer applications could come from if we can implement two classes of QoS in a globally scalable and self-managing way.