QoS Reality Check“Be careful what you ask for”

Terry Gray

University of Washington5 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

Router Router

BorderRouter

CoreSwitch

EdgeSwitch

Edge Switch

InteriorSwitch

InteriorSwitch

Gigapop Internet2

DesktopDesktop

Internet

Fed Nets4

40

250

1000Branch Site

30,000

PBX

6

Congestion Zones

• Subnet --overprovision + CBQ

• Backbone --subscriptions/quotas (CAR)

• Wide-Area --quotas, feedback, reservation?

7

Poor Man’s QoS: Why CBQ WorksEven 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

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

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

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

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

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

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

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

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

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

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

Optimist

Hedge

Pessimist

Raw Bandwidth Raw Bandwidth

CAR + 802.1p DiffServ + BB

RSVP RSVP

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

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!