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

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

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

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

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

Voice quality vs. packet loss

MOS vs. loss for FEC and LBR

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

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

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.

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

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