<div dir="ltr">With some encouragement from Dave, I'm posting a link to a slide deck with a relevant set of metrics that many of you may find of interest. "Will my Netflix/Lync/whatever work?" is a question that many would like to know in advance of committing to a multi-year contract for some piece of network access. We perform that kind of analysis for large fixed and mobile operators as our day job.<div>

<br></div><div>The relevant slides are 8 and 9 in <a href="http://www.slideshare.net/mgeddes/network-performance-optimisation-using-highfidelity-measures" target="_blank" style="font-size:13px;font-family:arial,sans-serif">this presentation</a><span style="font-size:13px;font-family:arial,sans-serif">. </span>It's an annotated version of a technical sales deck that was designed to be talked through, but should make reasonable sense just being read.</div>

<div><br></div><div>The <i>QoE breach metric</i> (red crosses) is a synthetic one that:</div><div>- takes the <i>probability distribution</i> of loss and delay</div><div>- compares this measurement against a (stochastic) requirement "contract" (<i>quality transport agreement</i>) to quantify the <i>performance hazard</i> </div>

<div>- and as result, the chart indicates the likelihood of an application falling below (or above) its required QoE.</div><div><br></div><div>This process generalises the predictive PESQ type of work done for voice to any application.<br>

</div><div><br></div><div>Red crosses mean the QoE of the application is at risk. (In this case it happens to be voice over a 100Mbps fibre link in a collector arc carrying multiple types of traffic as a single class of service). The green line is the daily usage cycle measured using 5 minute (IIRC) average link utilisation data. There is a correlation, but not a causative relationship.</div>

<div><br></div><div>What makes this data interesting is the robustness of the measurement and mathematics behind this QoE measure. The metric used (ΔQ) is the only (possible) network measure that is also a strong QoE proxy (as relates to application performance).<br>

</div><div><br></div><div>In this case, we were measuring for a client whether over-provisioning was an efficient and effective approach to dealing with QoE issues. The result reflects similar measures from other fixed and mobile operators: over-provisioning is not an effective means of resolving scheduling issues. This should not be any news to anyone involved in the AQM/bufferbloat space; scheduling choices really do matter, and getting them wrong does affect the customer experience. Hence the client is engaging in improving their scheduling choices, rather than spending capex on capacity that doesn't fix the problem.</div>

<div><br></div><div>The tools used to generate this data are described in <a href="http://us1.campaign-archive1.com/?u=f105fd56904428bca9da44a82&id=b3f51d6467">How to X-ray a telecoms network</a>. Critically, you need to measure the <i>same test stream packet</i> passing <i>multiple points</i>, and produce the <i>distribution</i>, and not use averages (e.g. "jitter" or "bandwidth"). How we temporally decompose the data is described in <a href="http://www.slideshare.net/mgeddes/fundamentals-of-network-performance-engineering-18548490">this</a> presentation.</div>

<div><br></div><div>I have a very long deck I'm still working on that introduces the ΔQ resource model, predictive calculus, and network performance science. The terms used are unfamiliar because producing this kind of data has required the development of a fundamental new branch of mathematics to describe the improper random variables and their composite behaviour.<br>

</div><div>
<div><br></div><div>Please don't hesitate to ask questions. I hope the above is of interest and value, since it represents (to the best of our knowledge) the state of the art in measurement and performance analysis techniques. For more information on them, see <a href="http://www.pnsol.com">www.pnsol.com</a>.</div>

</div><div><br></div><div>Martin Geddes</div><div class="gmail_extra"><div><div dir="ltr"><div><a href="http://www.martingeddes.com" style="font-size:x-small" target="_blank">www.martingeddes.com</a><span style="font-size:x-small"> </span><font color="#666666" style="font-size:x-small"><a href="http://www.linkedin.com/in/mgeddes" target="_blank">LinkedIn</a> </font><span style="color:rgb(102,102,102);font-size:x-small"><a href="https://twitter.com/martingeddes" target="_blank">Twitter</a> </span><span style="color:rgb(102,102,102);font-size:x-small">Mobile: <a href="tel:%2B44%207957%20499219" value="+447957499219" target="_blank">+44 7957 499219</a> </span><span style="color:rgb(102,102,102);font-size:x-small">Skype: mgeddes </span></div>


<div><br></div></div></div>
<br><br><div class="gmail_quote">On Mon, Apr 7, 2014 at 7:18 PM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=dave.taht@gmail.com&cc=&bcc=&su=&body=','_blank');return false;">dave.taht@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
This weekend for the first time ever I saw netflix become unusable for<br>
several hours on a friday night. On DSL line capable of over 6mbits<br>
down, it slowed below 1.2Mbit and frequently stopped.<br>
<br>
For a change I was NOT interested in leaping up from the couch to<br>
capture traffic (read a book instead!) to see what was up, but it did<br>
set me to thinking about monitoring congestion and delay on local<br>
network segments, like those you find in cable, where you frequently<br>
see arp requests go by anyway and thus can build<br>
an partial picture of the rest of the wire.<br>
<br>
I was seriously impressed and somewhat scared by the power of zmap:<br>
<br>
<a href="https://zmap.io/" target="_blank">https://zmap.io/</a><br>
<br>
But it would be interesting to be able to collect a periodic picture<br>
of the universe one hop beyond the local gateway.<br>
<span><font color="#888888"><br>
--<br>
Dave Täht<br>
<br>
NSFW: <a href="https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article" target="_blank">https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article</a><br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=Bloat@lists.bufferbloat.net&cc=&bcc=&su=&body=','_blank');return false;">Bloat@lists.bufferbloat.net</a><br>


<a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</font></span></blockquote></div><br></div></div>