QoS Reality Check “Be careful what you ask for”

1. QoS Reality Check“Be careful what you ask for” Terry Gray University of Washington 5 May 1999 -- NWACC

2. UW Network Overview • 70,000 accounts • 37,000 end systems • 2,000 modems • 50 remote sites • IP-only backbone • 500 Gigabytes/day across backbone • Internet: 45Mbps peak in, 20Mbps peak out • NWNet founder, NOC • Center of statewide K20 net • Home of P/NW Gigapop, SNNAP

3. 3 Kinds of People • Optimists -Bandwidth will be enough • Hedgers -But what if it isn’t? • Pessimists -E2E per-flow guarantees are essential

4. QoS Axioms • QoS doesn't create bandwidth --it just determines who will get poor service at congestion points. • The most important QoS question is: how many "busy" signals constitute success for your network? • Given a busy signal, users will want to proceed anyway. • Network Managers will not trust end systems. • Biggest need is on WAN links, where it’s hardest to do! (scaling, settlements, signalling interoperability). • Best-effort traffic must be protected from premium hogs (there are many ways for net managers to die… !)

5. Simplified Network Topology Core Switch Gigapop 4 Fed Nets Border Router Internet2 Router Router 40 Internet Interior Switch Interior Switch 250 PBX Edge Switch Edge Switch 1000 Branch Site 30,000 Desktop Desktop

6. Subnet --overprovision + CBQ Backbone --subscriptions/quotas (CAR) Wide-Area --quotas, feedback, reservation? Congestion Zones

7. Poor Man’s QoS: Why CBQ WorksEven with 50% hi-priority traffic, delay is constant Low-Priority Delay Hi-Priority Inflection at 30 - 80% load, depending on burstiness 100% Load Multiplexing priorities on a channel improves efficiency at the cost of certainty.

8. Cost of resource vs. cost of controls(control cost must include Policy Jitter!) Flow setup overhead vs. flow length Statistical vs. guaranteed quality? Prioritization via privilege, desire, or need? Price based on usage or quota? Privilege associated with port or user? Design Issues

9. With end-system cooperation Adaptive protocols Adaptive applications Admission control Without end-system cooperation Traffic shaping Traffic policing Eligibility control Behavior shaping (user adaptation) Congestion Avoidance Tools

10. Do you really want one? Event duration is needed in order to schedule Big-chunk reservations require sequestered bandwidth Small-chunk reservations are unnecessary Apps may need problematic bi-directional reservations Reservations invite policy complexity Expect marketplace rather than reservations to dominate. Whither RSVP? Campus net = RSVP-transparent zone End-systems could signal border router/BB if needed (Or other end-systems) Will RSVP become moot? Do you have a Reservation?

11. IETF Diff-Serv Approach • Result of doubts about IntServ/RSVP scalability • Concept: • Abandon end-to-end per-flow reservation/setup • Mark packets at edge of WAN as to equiv class • Current debate: semantics for TOS/DS bits • Prognosis: favorable

12. I2 QoS Working Group • Focus on IETF Diff-Serv approach • Bandwidth Broker at “edge” • Aggregation of flows into classes • No per-flow reservations within core • Some WG members think that: • Diff-Serv+BB is too optimistic/simplistic • Diff-serv+BB is too pessimistic/complex

13. Dual use: Application research Production traffic among members If lots of big-chunk reservations needed: Sequester part of I2 bw for scheduled use Remainder: production + on-demand premium Or… Use quotas for medium-chunk needs Manual reconfiguration for special events Could permanently sequester bw for some apps WAN QoS: Internet 2 Connection

14. Won’t just be best-effort for long Reservation model unlikely Quota/CAR approach seems probable Pricing model unclear Need for recharge likely WAN QoS: Commercial Internet

15. Could provide dedicated bandwidth for different services: IP data, IP video, VoIP. Border routers connect to POTS and videoconferencing gateways. Bounded round-robin queue discipline. Packets need to be marked by service type or queued using gateway source address. WAN QoS: Branch Sites

16. What to do with over-quota packets? Drop rather than downgrade? (Since downgraded packets likely to arrive out-of-order and be dropped by end-system streaming apps anyway.) Incoming Traffic May cause biggest part of NSP charges Respect incoming Premium marking? If so, apply destination quota or recharge? How will subscribers know whether they got what they paid for? Good question! Some “Interesting” Issues

17. Current campus nets are not ready for QoS… Prepare for forklift upgrades. Widespread 802.1p support expected… but vendors assume end-system will set priority. Switching and full-duplex needed… Cat 3 wiring is an issue in older buildings. How much layer-3 support needed at edge? Access from alternate locations implies multiple authentication methods. Reality Check

18. No Guarantees... • Only probabilities! • Choice of: • P (Busy Signal)or • P (Degraded Service) • Still no substitute for adequate bandwidth…and still many ways for Net Mgrs to die! • If you need absolute certainty, don’t share!

19. Summary CAN WAN Raw Bandwidth Raw Bandwidth Optimist CAR + 802.1p DiffServ + BB Hedge Pessimist RSVP RSVP

20. Future peak/aggregate usage patterns are unknown… No one can sayhow much BW and QoS capability will really be needed. Nevertheless, adequate eQoS without per-flow lookups or reservations appears plausible... Campus: Fast/Gigabit Ethernet infrastructure can reduce odds of congestion; multiple queues and CAR policing provide additional headroom. But: even minimalist CoS & DS approaches have worrisome operational implications… vigilance is needed to keep things as simple as possible. Conclusions

21. Recent experience suggests that the most urgent network design goal should be to: reduce policy jitter!! Claim: this requires a solution with a very small set of policy choices… Otherwise, policy management will eat you alive! Epilogue