Quality of Service Henning Schulzrinne Columbia University/Siemens July 2002

Summary the bad news hardly anybody uses it – except for MPLS for TE talking about the same issues since 1984 the good news more than 3,000 papers since 1984 (netbib) TOS support in embedded IP systems renewed interest in light-weight mechanism

Why is QoS unpopular in practice? 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 attacks only displacement applications (such as telephony) need QoS requires cooperation: edge-ISP, transit ISPs, end systems snake oil: add QoS, lose half your bandwidth adds another failure mode bandwidth is cheaper than network administrators will only be used during congestion  hard to predict only really useful if universal

QoS treated as scheduling, measurement, admission problem but primarily a systems problem two kinds: point traffic differentiation  traffic shapers at expensive links delay primarily a point problem (< T1/E1) network traffic differentiation  requires new infrastructure, trust issues need commensurate measures  just bandwidth

QoS as reliability problem average backbone packet loss << 1% worried about 5% packet loss real problem is 5% outage time (> 200 ms) routing failures cause long-lived interruptions OSPF convergence BGP oscillations, delays (> 20') view as reliability problem QoS violation = session failure probability can add and subtract (admission failure) just use multi-homing on both ends?

New developments DOCSIS (cable modems) scarce upstream bandwidth IETF NSIS effort just requirements for now separation into signaling transport and QoS layer IETF IEPREP emergency communications service Internet2 scavenger service worse-than-best-effort service large-scale (physics) file transfer avoids self-interference