Transcript QoS Reality Check 31 July 98

QoS Reality Check
“Be careful what you ask for”
Terry Gray
University of Washington
21 October 1998 -- ESCC
UW Network Overview
•
•
•
•
•
•
•
•
•
•
70,000 accounts
30,000 end systems
2,000 modems
50 remote sites
IP-only backbone
350 Gigabytes/day across backbone
Internet: 30Mbps peak in, 15Mbps peak out
NWNet founder, NOC
Center of statewide K20 net
Home of P/NW Gigapop, SNNAP
2
3 Kinds of People
• Optimists
-Bandwidth will be enough
• Hedgers
-But what if it isn’t?
• Pessimists
-E2E per-flow QoS is essential
3
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… !)
4
Simplified Network Topology
Core
Switch
4
Fed Nets
40
Router
Router
250
Interior
Switch
Interior
Switch
Border
Router
Gigapop
Internet2
Internet
PBX
1000
Edge
Switch
Edge
Switch
30,000
Desktop
Desktop
Branch
Site
5
Congestion Zones
• Subnet --overprovision + CBQ
• Backbone --subscriptions/quotas (CAR)
• Wide-Area --quotas, feedback, reservation?
6
Poor Man’s QoS: Why CBQ Works
Even with 50% hi-priority traffic, delay is constant
Low-Priority
Delay
Hi-Priority
Inflection at 30 - 80% load,
depending on burstiness
100%
Load
7
Multiplexing priorities on a channel improves efficiency at the cost of certainty.
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?
8
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)
9
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?
10
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
11
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 is too optimistic/simplistic
– Diff-serv is too pessimistic/complex
12
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
13
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
14
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.
15
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!
16
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.
17
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!
18
Summary
CAN
Optimist
Hedge
Pessimist
Raw Bandwidth
CAR + 802.1p
RSVP
WAN
Raw Bandwidth
DiffServ + BB
RSVP
19
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.
20
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!
21