Can your network handle a HD Zoom call?

Can your network handle a HD Zoom call?

From geeky network metrics to understandable statements about application outcome, Domos’ Magnus Olden takes Broadband Forum’s network quality framework QED on a ride

Broadband Forum’s Broadband Quality Experience Delivered (Broadband QED) is an initiative that looks beyond conventional measurements to improve overall broadband experience and improve management of network latency, consistency, predictability and reliability. It’s helping give users what they want; seamless broadband connectivity, so that their applications can work optimally. The initiative is gathering momentum and is providing operators with the tools they need to meet current user requirements.

The QED framework allows us to confidently make precision statements about application outcomes caused by a network. For example, we can make easily understandable declarations such as “This network will not cause Google Stadia to fail”, or, “This network will cause Google Stadia to have insufficient response time for First-Person Shooters and poor animation fluidity.” “This network is sufficient for Zoom at 720p” is another example with extra relevance to WFH-ers of the past 18 months.

Statements like these are no doubt clearer for the average end-user (or perhaps even an ISP executive) than the alternative, which might sound something along the lines of: “This network has 832 Mbps, 90ms round-trip latency, 93ms jitter, 0.001% packet loss.”

The reason we can make the translation from complex networks to statements about complex application requirements is the QED’s concept of Quantitative Timeliness Agreements (QTA). This can, in turn, let us understand whether a network is, for example, good enough for an HD Zoom call.

Distributing blame

In any network environment, latency will vary not just due to resource sharing but also application loading. That changing latency will, in turn, affect application outcomes. A key insight one can derive from this is that measuring a single point of latency (such as average, median, different percentiles, jitter, etc.) will be insufficient to make definitive statements about the application outcome.

You can have identical jitter or 99 percentile latency and different application outcomes caused by the network. For example, a Zoom call will struggle with 100ms average latency and 400ms 99 percentile latency. But it will work perfectly with 100ms average latency and 101ms 99 percentile latency.

Most applications, like video-on-demand streaming, video conferencing, web-browsing, gaming, and many more, are intimately entangled with time and timeliness. What happened a few seconds ago defines what happens now. This leaves snapshots of the network quality insufficient to reveal much about the application outcome.

To counter these time-related issues, the QED Framework looks at distributions of latency, which lets us determine the likelihood of any particular latency value at this moment of time. As an example Use Case, we could say that “there is an 0.001% chance that the latency will be over 200ms”. These distributions can easily be visualized in a Cumulative Distribution Function (CDF).

“I will be home by seven” – QTAs with your parents

Quantitative Timeliness Agreements, or QTAs, are application Quality of Service (QoS) requirements that can be mapped to a latency distribution. A QTA captures how much latency and packet loss the network can introduce without hurting the user experience for an application.

For example, it could tell us something like “Zoom, at 4 Mbps load, needs 23% of packets to arrive at the server within 50ms, 53% of packets within 100ms, 97% of packets within 200ms, it can tolerate 3 % packet loss,” or “Google Stadia, at 0.5 Mbps load, needs 50% of packets to arrive at the server within 100ms, 75% of packets within 120 ms, 100% of packets within 150ms, no packet loss is acceptable.”

Or, to use a simpler analogy, a Mother says to her children: “John, be home by 10. Jane, be home by 11. No sibling loss is acceptable.”

The blue line is an example of measured latency distribution. As it is on the left of the QTA, this application will work well (we can call the network invisible for the application). If the measured latency crosses the QTA, the application will have network issues.

“You are late”… “YOU ARE LATE!”… “you are grounded”: Quantifying ‘badness’

 Say Zoom’s requirement is 100% packets delivered within 200ms. There is obviously a difference between the scenarios, A) that all packets have 201ms and B) that all packets have 1200 ms latency for zoom. Scenario A) is annoyingly bad while B) won’t work at all.

We would therefore have to quantify the degree of ‘badness’ by calculating the area between the QTA and the CDF.

Lateness in the modern family: when things get complicated

 When playing with networks and application outcomes you quickly learn that you can simultaneously have:

1. Good outcome: p90 150ms latency and 1 % packet loss
2. Good outcome: p90 100ms latency and 2 % packet loss
3. Poor outcome: p90 150ms latency and 2 % packet loss

So neither 2% packet loss nor p90 150ms are sufficient thresholds. Therefore we can expand to multiple QTAs, and state that if you are within either:

• p90 150ms latency and 1% packet loss
• p90 100ms latency and 2% packet loss

You will have a good application outcome. Luckily, we can apply as many QTAs to the distribution as we need.

There can also be multiple quality levels for the application, for example a VoD 720p, 1080p, or 4K, or Zoom with or without video. Again, we can use multiple (even hundreds or thousands of) QTAs. Although we don’t have perfect QTAs yet, it is achievable. The behavior of the application is deterministic and governed by the rules set by the application developers. QTAs have a viable path for perfection and lets us start simple and expand without starting from scratch.

Make sure you watch our QED webinar recordings ‘Quality of Experience: Real-life Examples, Implementations & Technical Deep Dive’ and ‘Quality of Experience: Why Broadband Speed is not Enough’ to learn more.