QoS and QoE – The Yin and Yang of Network Performance

Team Teridion

Central to any discussion on Internet content delivery is quality, and two common terms:  Quality of Service (QoS), and Quality of Experience (QoE or sometimes referred to as QX). These terms differ in important ways. We think of QoS as something that can be better measured and more objective, while we think of QoE as something subjective. Both quantifiably provide visibility into the network and into the client.

For a given application, you can’t be told what your QoE is or should be. It is personal, based on your experience and expectations. It can mean the difference between service abandonment and upsell; between a SaaS provider succeeding or failing.

QoE must deliver on your Quality of Expectation. Whether, to you or the end-user, the application just works. For completeness, we’ll throw in another term – performance – that is even harder to quantify. But we use performance as part of the whole QoS and QoE discussion, which we look at in the following way: QoS is looking outward from the network, from the provider, and QoE is looking inward from the end-user.

Cloud providers such as SoftLayer and AWS attempt to manage the QoS provided to their customers by properly provisioning and managing capacity. In turn, SaaS content, collaboration, and commerce providers leverage this infrastructure to provide services for their end-users.

SaaS providers have local visibility into their cloud provider and any connected transit providers they partner with. Using monitoring tools, they can garner some information of what is happening further out, but have no way to influence this on a global level to all of their end-users. In the absence of an engineered backbone connecting their servers to their users, their view of QoS is strictly local.

QoE, on the other hand, is an end-to-end function of the path from the user to his or her data and applications. This requires deep visibility, and some way to influence performance. Given Internet routing limitations and no true end-to-end QoS model, we require an overlay – a way to bypass best-effort links and congestion. Therefore, delivering scalable QoE requires an overlay.

Given a management and monitoring system with global Internet visibility, a semblance of QoE control can be provided via this overlay. A SaaS application developer will then have confidence that their application will perform worldwide with good end user experience.

Share:

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp

Send Us A Message

    Interested in (please select all that apply):

    Do you require:



    More Posts

    Book a Demo

      Interested in (please select all that apply):

      Do you require:



      Interested in (please select all that apply):
      Do you require: