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

2. 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 3 Kinds of People Optimists -Bandwidth will be enough Hedgers -But what if it isn’t? Pessimists -E2E per-flow guarantees are essential

4. 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. 5 Simplified Network Topology Router Border Router Core Switch Edge Switch Edge Switch Interior Switch Interior Switch Gigapop Internet2 Desktop Internet Fed Nets 4 40 250 1000 Branch Site 30,000 PBX

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

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

8. 8 Design Issues 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?

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

10. 10 Do you have a Reservation? 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?

11. 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. 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. 13 WAN QoS: Internet 2 Connection 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

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

15. 15 WAN QoS: Branch Sites 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.

16. 16 Some “Interesting” Issues 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!

17. 17 Reality Check 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.

18. 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. 19 Summary CANWAN Optimist Hedge Pessimist Raw Bandwidth CAR + 802.1pDiffServ + BB RSVP

20. 20 Conclusions Future peak/aggregate usage patterns are unknown… No one can say how 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.

21. 21 Epilogue 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!