QoS Reality Check Be careful what you ask for

1
QoS Reality CheckBe 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 isnt?
• 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 its 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
Congestion Zones

• Subnet --overprovision CBQ
• Backbone --subscriptions/quotas (CAR)
• Wide-Area --quotas, feedback, reservation?

7
Poor Mans 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
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-ServBB is too optimistic/simplistic
• Diff-servBB 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

• Wont 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 bandwidthand
  still many ways for Net Mgrs to die!
• If you need absolute certainty, dont share!

19
Summary
CAN
WAN
Raw Bandwidth
Raw Bandwidth
Optimist
CAR 802.1p
DiffServ BB
Hedge
Pessimist
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!