1. Quality of Service - applications Henning Schulzrinne with Wenyu Jiang Dept. of Computer Science Columbia University NSF QoS workshop, April 2002

2. Application requirements What kind of applications? What matters? What doesn't? How do we know?

3. Applications – the diminishing set (or the cynics view of QoS) video-on-demand  80 GB disk + P2P- over-TCP voice-over-IP  where? multimedia conferencing  still waiting, after 50 years... network games  latency kills

4. Why is QoS unpopular? need to admit failure – “bandwidth too cheap to meter” undemocratic: some traffic is more equal than other reminds you of your mom: no, you can’t have that 10 Mb/s now socialist: administer scarcity - we like SUVs (or to drive 100 mph)! “risky scheme”: security (DOS) only displacement applications (such as telephony) need QoS requires cooperation: edge-ISP, transit ISPs, end systems snake oil: add QoS, lose half your bandwidth

5. QoS evaluation Problem: no tool for reliably evaluating quality end-to-end network (PSTN & Internet) + hardware + operating system depends on packet loss, jitter (playout buffer), FEC, loss correlation need subjective evaluation, but too expensive applicability of objective measures (PSQM, etc.) use speech recognition as measure e-model

6. Voice quality vs. packet loss

7. MOS vs. loss for FEC and LBR

8. Myth: TCP loves lossy networks Lakshman/Madow/Suter ToN 2000

9. R rel as Universal MOS Predictor Mapping from relative recognition ratio R rel to MOS

10. Human Recognition Results Listeners are asked to transcribe what they hear in addition to MOS grading. Human recognition result curves are less “smooth” than MOS curves.

11. Research infrastructure After 10 years, still no low-latency audio research application existing applications (rat/vat) have erratic latency behavior no good access to audio queuing information for lip-sync no good diagnostic tools  blame network

12. QoS is about reliability can’t sell premium service that’s unavailable one day a year auxiliary cost of failure: people scheduling, interruption, embarrassment,... consistent 5% packet loss is much better than 5% probability that network is unavailable for seconds BGP convergence time ~ minutes conjecture: applications (conferencing, VoIP) don't migrate for lack of predictability