1. Deploying Quality of Service Technologies

2. Agenda
QoS Metrics
QoS Architectures
QoS Design Guidelines
A QoS Scenario
Summary

3. QoS Metrics What are we trying to control?
Four metrics are used to describe a packet’s transmission through a network – Bandwidth, Delay, Jitter, and Loss
Using a pipe analogy, then for each packet:
Bandwidth is the perceived width of the pipe
Delay is the perceived length of the pipe
Jitter is the perceived variation in the length of the pipe
Loss is the perceived leakiness if the pipe
Bandwidth
The path as perceived by a packet! A B
Delay

4. QoS Metrics – Bandwidth
The amount of bandwidth available to a packet is affected by:
The slowest link found in the transmission path
The amount of congestion experienced at each hop – TCP slow-start and windowing
The forwarding speed of the devices in the path
The queuing priority given to the packet flow
2Mb/s
10 Mb/s
2 Mb/s Maximum Bandwidth
100 Mb/s

5. QoS Metrics – Delay
The amount of delay experienced by a packet is the sum of the:
Fixed Propagation Delays
Bounded by the speed of light and the path distance
Fixed Serialization Delays
The time required to physically place a packet onto a transmission medium
Variable Switching Delays
The time required by each forwarding engine to resolve the next-hop address and egress interface for a packet
Variable Queuing Delays
The time required by each switching engine to queue a packet for transmission

6. QoS Metrics – Jitter
The amount of Jitter experienced by a packet is affected by:
Serialization delays on low-speed interfaces
Variations in queue-depth due to congestion
Variations in queue cycle-times induced by the service architectures – First-Come, First-Served, for example
~214ms Serialization Delay for a 1500-byte packet at 56Kb/s
60B every 20ms
60B every 214ms
60B every 214ms
Voice
1500 Bytes of Data
Voice
Voice
1500 Bytes of Data
Voice
Voice
1500 Bytes of Data
Voice
10 Mbps Ethernet
10 Mbps Ethernet
56 Kbps WAN

7. QoS Metrics – Loss
The amount of loss experienced by a packet flow is affected by:
Buffer exhaustion due to congestion caused by oversubscription or rate-decoupling
Intentional packet drops due to congestion control mechanism such as Random Early Discard GE
DS-3 GE GE
Oversubscribed
Buffer Exhaustion

8. QoS Architectures

9. QoS Implementation Models
No State
1. Best Effort
Per-Flow State
Aggregated State
2. IntServ/RSVP
3. DiffServ
4. RSVP+DiffServ+MPLS

10. Integrated Services (IntServ)
The Integrated Services (IntServ) model builds upon Resource Reservation Protocol (RSVP)
Reservations are made per simplex flow
Applications request reservations for network resources which are granted or denied based on resource availability
Senders specify the resource requirements via a PATH message that is routed to the receiver
Receivers reserve the resources with a RESV message that follows the reverse path
Sender
Receiver
PATH
RESV

11. IntServ – Components
The Integrated Services Model can be divided into two parts – the Control and Data Planes
Routing Selection
Admission Control
Reservation Setup
Reservation Table
Flow Identification
Packet Scheduler
Control Plane
Data Plane

12. IntServ – Components Control Plane Data Plane
Route Selection – Identifies the route to follow for the reservation (typically provided by the IGP processes)
Reservation Setup – Installs the reservation state along the selected path
Admission Control – Ensures that resources are available before allowing a reservation
Data Plane
Flow Identification – Identifies the packets that belong to a given reservation (using the packet’s 5-Tuple)
Packet Scheduling – Enforces the reservations by queuing and scheduling packets for transmission

13. IntServ – Service Models
Applications using IntServ can request two basic service-types:
Guaranteed Service
Provides guaranteed bandwidth and queuing delays end-to-end, similar to a virtual-circuit
Applications can expect hard-bounded bandwidth and delay
Controlled-Load Service
Provides a Better-than-Best-Effort service, similar to a lightly-loaded network of the required bandwidth
Applications can expect little to zero packet loss, and little to zero queuing delay
These services are mapped into policies that are applied via CB-WFQ, LLQ, or MDRR

14. IntServ – Scaling Issues
IntServ routers need to examine every packet to identify and classify the microflows using the 5-tuple
IntServ routers must maintain a token-bucket per microflow
Guaranteed Service requires the creation of a queue for each microflow
Data structures must be created and maintained for each reservation

15. Differentiated Services (DiffServ)
The DiffServ Model specifies an approach that offers a service better than Best-Effort and more scalable than IntServ
Traffic is classified into one of five forwarding classes at the edge of a DiffServ network
Forwarding classes are encoded in the Differentiated Services Codepoint (DSCP) field of each packet’s IP header
DiffServ routers apply pre-provisioned Per-Hop Behaviors (PHBs) to packets according to the encoded forwarding class 5 4 3 2 1 5 4 3 2 1

16. DiffServ – Compared to IntServ
DiffServ allocates resources to aggregated rather than to individual flows
DiffServ moves the classification, policing, and marking functions to the boundary nodes – the core simply forwards based on aggregate class
DiffServ defines Per-Hop forwarding behaviors, not end-to-end services
DiffServ guarantees are based on provisioning, not reservations
The DiffServ focus is on individual domains, rather than end-to-end deployments

17. DiffSrv – The DS Field (RFC 2474)
DSCP CU
The DS field is composed of the 6 high-order bits of the IP ToS field
The DS field is functionally similar to the IPv4 TOS and IPv6 Traffic Class fields
The DS field is divided into three pools:
nnnnn0 – Standards Use
nnnn11 – Experimental / Local Use
nnnn01 – Experimental / Local Use, possible Standards Use
Class Selector Codepoints occupy the high-order bits (nnn000) and map to the IPv4 Precedence bits

18. DiffSrv – Forwarding Classes
DSCP
Codepoint
000000
CS0 (DE)
001000
CS1
001010
AF11
001100
AF12
001110
AF13
010000
CS2
010010
AF21
010100
AF22
010110
AF23
011000
CS3
011010
AF31
011100
AF32
011110
AF33
100000
CS4
100010
AF41
100100
AF42
100110
AF43
101000
CS5
101110 EF
110000
CS6
111000
CS7
The DS Field can encode:
Eight Class Selector Codepoints compatible with legacy systems (CS0-7)
An Expedited Forwarding (EF) Class
Four Assured Forwarding Classes, each with three Drop Precedence (AFxy, where x=1-4, and y=1-3)
Packets in a higher AF Classes have a higher transmit priority
Packets with a higher Drop Precedence are more likely to be dropped

19. DiffServ – Per-Hop Behaviours
A Per-Hop Behaviour (PHB) is an observable forwarding behaviour of a DS node applied to all packets with the same DSCP
PHBs do NOT mandate any specific implementation mechanisms
The EF PHB should provide a low-loss, low-delay, low-jitter, assured bandwidth service
The AF PHBs should provide increasing levels or service (higher bandwidth) for increasing AF levels
The Default PHB (CS0) should be equivalent to Best-Effort Service
Packets within a given PHB should not be re-ordered

20. DiffServ – Boundary Nodes
DiffServ Boundary Nodes are responsible for classifying and conditioning packets as they enter a given DiffServ Domain
Classifier
Marker
Meter
Remarker
Shaper
Dropper
Classification
Conditioning
Classifier Examine each packet and assign a Forwarding Class
Marker Set the DS Field to match the Forwarding Class
Meter Measure the traffic flow and compare it to the traffic profile
Remarker Remark (lower) the DS Field for out-of-profile traffic
Shaper Shape the traffic to match the traffic profile
Dropper Drop out of profile traffic

21. DiffServ – Summary DiffServ Domain Classification / Conditioning PHB
Premium
Gold
Silver
Bronze
PHB
LLQ/WRED
Classification / Conditioning

22. The Trouble with DiffServ
As currently formulated, DiffServ is strong on simplicity and weak on guarantees
Virtual wire using EF is OK, but how much can be deployed?
DiffServ has no topology-aware admission control mechanism

23. RSVP-DiffServ Integration
The best of both worlds – Aggregated RSVP integrated with DiffServ
No State
Best Effort
Per-Flow State
IntServ
Aggregated State
DiffServ
Firm Guarantees
Admission Control
RSVP + DiffServ
But – given the presence of a DiffServ domain in a network, how do we support RSVP End-to-End?

24. RSVP-DiffServ Integration – How?
Routers at edge of a DS cloud perform microflow classification, policing, and marking
Guaranteed Load set to the EF, Controlled load set to AFx, and Best Effort set to CS0
Service Model to Forwarding Class mapping is arbitrary
RSVP signaling is used in both the IntServ and DiffServ regions for admission control
The DiffServ core makes and manages aggregate reservations for the DS Forwarding Classes based on the RSVP microflow reservations
The core then schedules and forwards packets based only on the DS Field

25. RSVP-DiffServ Integration
Border Routers implement per-flow classification, policing, and marking
The DiffServ region aggregates the flows into DS Forwarding Classes
DiffServ Region
RSVP Signaling is propagated End-to End
The IntServ regions contain Guaranteed or Controlled Load Microflows

26. RSVP-DiffServ Integration – Summary
The forwarding plane is still DiffServ
We now make a small number of aggregated reservations from ingress to egress
Microflow RSVP messages are carried across the DiffServ cloud
Aggregate reservations are dynamically adjusted to cover all microflows
RSVP flow-classifiers and per-flow queues are eliminated in the core
Scalability is improved – only the RSVP flow states are necessary – Tested to 10K flows

27. MPLS Traffic Engineering – A Summary
Uses Constraint-based routing for path selection – IS-IS or CSPF
MPLS tunnels are setup via RSVP
Utilizes DiffServ-aware forwarding based on MPLS EXP bits
Traffic can be managed based on both bandwidth or administrative metrics

28. QoS Design Guidelines

29. QoS Design Guidelines
Investigate and understand application requirements and behaviors
Group applications or users together based on their QoS needs – bandwidth, latency, jitter, and packet loss
Use the proper QoS tools at the correct places in the network to meet the needs of these groups

30. QoS Requirements for Applications
ERP and Mission- Critical
Voice
FTP
Low to Moderate
Moderate to High
Bandwidth
Varies
Moderate to High
Loss Sensitivity
Low
High
Low to Moderate
Delay Sensitive
High
Low
Jitter Sensitive
High
Low
Varies
Traffic should be grouped into classes that have similar QoS requirements

31. The Cisco QoS Architecture
Queuing
Classification
Policing
Shaping
Marking
Identify and Split
Traffic into
Different Classes
Discard Misbehaving Traffic to
Maintain Network Integrity
Mark Traffic According to Behavior and Business Policies
Prioritize, Protect and Isolate Traffic Based on Markings
Control Bursts and Conform Traffic

32. Classification – Defining a Class
Applications
TCP/UDP Port number
5-Tuples
URLs
Single users
MAC address
IP address
Departments, customers
IP Subnet
Ingress Interface
Traffic Classes are usually mapped to the IP Precedence or DiffServ DS Fields to control Queuing and Congestion Management Routines

33. Classification – NBAR
Network Based Application Recognition (NBAR) can:
Analyze application traffic patterns in real time
Classify packets based on:
L4-L7 protocols which dynamically assign TCP/UDP ports
HTTP Traffic by URL or MIME
Provides per-interface, per-protocol, bi-directional statistics
My Application
Is too Slow!
Link Utilization
Citrix 25%
Netshow 15%
Oracle 10%
FTP 30%
HTTP 20%
Mark Citrix Real-Time as GOLD Service and Police FTP
Guarantee Bandwidth for Citrix!

34. Classification – Rules
Classify Packets as close to the network edge as possible
Classify locally generated voice packets using ‘dial-peer’ commands
Use Class-Maps or Network-Based Application Recognition (NBAR) to classify packets
Avoid Host-Based Packet Marking
VolP
HTTP
FTP
VolP
HTTP
FTP
VolP
Platinum Class
Separate “Conform” and “Exceed” Actions
HTTP
Gold Class
FTP
Bronze Class

35. Classification – Configuration
Router(config)# class-map Gold
Router(config-cmap )# match ip rtp
Router(config-cmap)# exit
Router(config)# class-map Silver
Router(config-cmap)# match protocol Citrix

36. Policing – Monitoring Service Levels
Policing is used to compare packet arrival rates to provisioned service agreements
Policers identify flows as either conforming, exceeding, or violating the service agreement
Different actions can be taken for conforming, exceeding, and violating packets
Two types of Policers are available:
RFC 2697: A Single-Rate, Three-Color Marker
RFC 2698: A Dual-Rate, Three-Color Marker

37. Policing – Monitoring Service Levels
Conform / Exceed / Violate Actions
drop
set-dscp-transmit
set-mpls-exp-transmit
set-prec-transmit
set-clp-transmit
set-de-transmit
set-qos-transmit
transmit

38. Policing – Single-Rate, Three-Color Marker
Usage:
Mark conforming traffic with a low drop precedence
Mark exceeding traffic with a high drop precedence
Drop violating traffic
Definitions:
CIR – Committed Information Rate
CBS – Committed Burst Size (max)
EBS – Excess Burst Size (max)
Tc – Current size of CBS bucket
Te – Current size of EBS bucket

39. Policing – Single-Rate, Three-Color Marker

40. Policing – Configuration (SRTC)
Router(config)# policy-map access-in
Router(config-pmap)# class Silver
Router(config-pmap-c)# police bps burst-normal burst-max conform-action action exceed-action action violate-action action
Router(config-pmap)# exit

41. Policing – Two-Rate, Three-Color Marker
Usage:
Mark packets within CIR as conforming
Mark packets between CIR and PIR as exceeding
Drop packets above the PIR
Definitions:
CIR – Committed Rate
PIR – Peak rate
CBS – Committed burst size (max)
PBS – Peak burst size (max)
Tc – Current size of CBS bucket
Tp – Current size of PBS bucket

42. Policing – Two-Rate, Three-Color Marker

43. Policing – Configuration (TRTC)
Router(config)# policy-map access-in
Router(config-pmap)# class Silver
Router(config-pmap-c)# police cir cir bc burst-normal pir bps be burst-max conform-action action exceed-action action violate-action action
Router(config-pmap)# exit

44. Marking – Marker Locations and Size
Frame Relay header
ATM Cell header
ISL or 802.1q/p header
Part of 20 bit MPLS label
Six most significant bits of TOS byte in IPv4 and IPv6 headers
Three most significant bits of TOS byte in IPv4 and IPv6 headers
Bits Location 1
Frame Relay DE Bit
ATM CLP Bit 3
Ethernet CoS Bits
MPLS Experimental (EXP) Bits 6
Differentiated Services Code Point (DSCP)
IP Precedence
# of Bits
Type of Marking

45. Marking – Configuration
Router(config)# policy-map access-in
Router(config-pmap)# class Silver
Router(config-pmap-c)# set ip dscp 26
Router(config-pmap)# exit

46. Queueing / Scheduling
Determines the placement of packets in Queues and the Queue Servicing algorithms
Class-Based Weighted Fair Queuing (CB-WFQ) makes the scheduler aware traffic classes instead of just traffic flows
Low Latency Queuing (LLQ) adds a priority queue to Class-Based Weighted Fair Queuing
When there is no congestion the schedular uses First-In-First-Out (FIFO)

47. Queuing / Scheduling – CBWFQ
Gold
40%
High Bandwidth, Low-Delay
Silver
Bounded Bandwidth and Delay
25%
Bronze
10%
Best Effort
Step 1: Define Classes
Step 2: Define Bandwidth
Queue weights are assigned to traffic classes instead of flows
Class definitions allow the specification of minimum bandwidth
Unused capacity in one class is made available to traffic in other classes
Queues can be configured differently for each class

48. Queuing / Scheduling – LLQ
WFQ
Interface 3 4 2 1 V PQ
Priority Class
Class 1
Class 2
Class 3
Class-Default 6 5 7
LLQ adds a guaranteed priority queue to CB-WFQ
Allows strict priority queuing to be applied to any traffic class, not just RTP/UDP (IP RTP Priority)
Bandwidth assigned to the priority queue is not shared with other classes

49. Queuing / Scheduling – Configuration
Router(config)# policy-map wan_policy
Router(config-pmap)# class Gold
Router(config-pmap-c)# priority 128
Router(config-pmap)# exit
Router(config-pmap)# class Silver
Router(config-pmap-c)# bandwidth 256
Router(config-pmap)class class-default
Router(config-pmap-c)# fair-queue

50. Queuing / Scheduling – Configuration
Absolute Percent Specifications for LLQ
policy-map Multiservice
class VoIP
priority percent 10 (OR prior
class business
bandwidth percent 30
class data
bandwidth percent 20
Relative Percent Specifications for LLQ
policy-map Multiservice
class VoIP
priority percent 10
class business
bandwidth remaining percent 80
class class-default
bandwidth remaining percent 20

51. Shaping – Class-Based Generic
Router(config)# policy-map access-out
Router(config-pmap)# class Silver
Router(config-pmap-c)# shape {average | peak} cir bc be
Router(config-pmap)# exit

52. Shaping – Class-Based Frame-Relay
Router(config)# interface serial 0
Router(config-if)# frame-relay traffic-shaping
Router(config-if)# interface s0.1 point-to-point
Router(config-subif)# frame-relay interface-dlci 100
Router(config-fr-dlci)# class frts
Router(config)# map-class frame-relay frts
Router(config-map-class)# frame-relay cir 56000
Router(config-map-class)# frame-relay bc 560
Router(config-map-class)# frame-relay be 0
Router(config-map-class)# frame-relay mincir 56000
Router(config-map-class)# no frame-relay adaptive-shaping

53. Congestion Avoidance
If a queue becomes full, all of the packets that overflow the queue get dropped – Tail-Drop
Tail-Drops cause the TCP congestion control algorithms to activate on a large number of sessions, causing global synchronization
A mechanism is needed to prevent queue exhaustion, thereby preventing global synchronization

54. TCP Slow Start / Congestion Control45 40
Congestion Avoidance Phase
Linear Growth 35 30 25 20 15 10
Slow Start
Exponential Growth 5 10 20 30 40 50

55. Congestion Avoidance: The Problem
Queue Utilization
100%
Time
Tail Drop
3 Traffic Flows Start at Different Times
Another Traffic Flow
Starts at this Point

56. Weighted Random Early Detect (WRED)
Drop
Probability 1
1/m
Min 1
Min 2
Min 3
Max 1
Max 2
Max 3
Average Queue Depth
Max Queue
Length(Tail Drop)

57. WRED Configuration Router(config)# policy-map wan_policy
Router(config-pmap)# class Silver
Router(config-pmap-c)# bandwidth percent 20
Router(config-pmap-c)# random-detect dscp-based
Router(config-pmap-c)# random-detect dscp dscpvalue min-threshold max-threshold (mark-probability-denominator)
Router(config-pmap)# exit

58. Configuring QoS in IOS MQC Abstractions and Syntax
class-map [match-any | match-all] class-name
Enters configuration sub-mode for class definition
policy-map policy-name
Enters configuration sub-mode for policy definition (marking, policing, shaping, queuing, etc.)
service-policy {input | output} policy-name
Command in interface configuration sub-mode to apply QoS policy for input or output traffic

59. A University QoS Scenario

60. University Scenario – Requirements
Guarantee 512 Kb/s to multicast traffic across my campus
Application is video-on-demand – requires guaranteed bandwidth, low loss, bounded delay and jitter
Guaranteed priority service is not necessary
Limit Napster to 10% of my internet link (T1)

61. University Scenario—TopologyGW RP
Source T1
Traffic Flow
Internet
Receiver

62. University Scenario – Design
Use policy-based routing or class-based marking to mark IP precedence bits for multicast traffic as close to source as possible
Use class-based weighted fair queuing (CBWFQ) to guarantee bandwidth
Use NBAR to recognize Napster and then traffic policing to limit it to 10% of the T1 Internet link

63. University Scenario – Configuration
On the router closest to the source:
Router(config)# class-map ipmc
Router(config-cmap)# match access-group 100
Router(config)# policy-map markipmc
Router(config-pmap)# class ipmc
Router(config-pmap-c)# set ip precedence 4
Router(config)# interface ethernet0/0
Router(config-if)# service-policy input markipmc
Router(config-if)#
Router(config)# access-list 100 permit udp any

64. University Scenario – Configuration
Queuing configuration multicast-tree routers:
Router(config)# class-map multicast
Router(config-cmap)# match ip precedence 4
Router(config)# policy-map univq
Router(config-pmap)# class multicast
Router(config-pmap-c)# bandwidth 512
Router(config-pmap-c)# !
Router(config)# interface ethernet0/0
Router(config-if)# service-policy output univq

65. University Scenario – Configuration
On the Gateway (GW) Router:
Router(config)# class-map Napster
Router(config-cmap)# match protocol napster
Router(config)# policy-map limitnapster
Router(config-pmap)# class Napster
Router(config-pmap-c)# police
Router(config)# interface serial0
Router(config)# bandwidth 1536
Router(config-if)# service-policy input limitnapster
Router(config-if)# service-policy output limitnapster

66. Useful Information CCO QoS page Cisco IOS 12.2 QoS documentation
Cisco IOS 12.2 QoS documentation
“IP Quality of Service” book

67. Session IPS– _05_2001
© 2001, Cisco Systems, Inc. All rights reserved. 67