View
218
Download
4
Tags:
Embed Size (px)
Citation preview
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.