1 © 2001, Cisco Systems, Inc. All rights reserved. Deploying Quality of Service Technologies

1© 2001, Cisco Systems, Inc. All rights reserved.

Deploying Quality of Service Technologies

22© 2001, Cisco Systems, Inc. All rights reserved. 2

Agenda

• QoS Metrics

• QoS Architectures

• QoS Design Guidelines

• A QoS Scenario

• Summary


Ba

nd

wid

thB

an

dw

idth

Ba

nd

wid

thB

an

dw

idth

DelayDelayDelayDelay

The path as perceived by a packet!The path as perceived by a packet!AA BB

QoS MetricsWhat 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


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


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 DelaysThe time required to physically place a packet onto a transmission medium

Variable Switching DelaysThe time required by each forwarding engine to resolve the next-hop address and egress interface for a packet

Variable Queuing DelaysThe time required by each switching engine to queue a packet for transmission


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

10 Mbps Ethernet 10 Mbps Ethernet

56 Kbps WAN

VoiceVoice 1500 Bytes of Data1500 Bytes of Data VoiceVoice VoiceVoice 1500 Bytes of Data1500 Bytes of Data VoiceVoice VoiceVoice 1500 Bytes of Data1500 Bytes of Data VoiceVoice

60B every 20ms 60B every 214ms60B every 214ms

~214ms Serialization Delay for a 1500-byte packet at 56Kb/s


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

Oversubscribed

GE

GEGE

DS-3

Buffer Exhaustion


QoS Architectures


No State

1. Best Effort

Per-Flow StateAggregated State

2. IntServ/RSVP

3. DiffServ

4. RSVP+DiffServ+MPLS

QoS Implementation Models


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 ReceiverPATH

RESV


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


IntServ – Components

Control 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


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 ServiceProvides 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


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


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


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


DSCP CUDS field

DiffSrv – The DS Field (RFC 2474)

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 Usennnn11 – Experimental / Local Usennnn01 – Experimental / Local Use, possible Standards Use

Class Selector Codepoints occupy the high-order bits (nnn000) and map to the IPv4 Precedence bits


DiffSrv – Forwarding Classes

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

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


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


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


DiffServ – Summary

DiffServ Domain

PremiumPremium GoldGold SilverSilver BronzeBronze

PHBLLQ/WRED

Classification / Conditioning


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


RSVP-DiffServ Integration

The best of both worlds – Aggregated RSVP integrated with DiffServ

No State

Best Effort

Per-Flow State

IntServ

AggregatedState

DiffServAggregated StateFirm Guarantees

Admission Control

RSVP + DiffServ

But – given the presence of a DiffServ domain in a network, how do we support RSVP End-to-End?


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


RSVP-DiffServ Integration

DiffServ Region

Border Routers implement per-flow classification, policing, and marking

RSVP Signaling is propagated End-to End

The IntServ regions contain Guaranteed or Controlled Load Microflows

The DiffServ region aggregates the flows into DS Forwarding Classes


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


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


QoS Design Guidelines


QoS Design Guidelines

1. Investigate and understand application requirements and behaviors

2. Group applications or users together based on their QoS needs – bandwidth, latency, jitter, and packet loss

3. Use the proper QoS tools at the correct places in the network to meet the needs of these groups


VoiceVoice FTPFTPERP andMission-Critical

ERP andMission-Critical

BandwidthBandwidth Low toModerateLow to

ModerateModerateto High

Moderateto High VariesVaries

Loss SensitivityLoss Sensitivity LowLow HighHigh Moderateto High

Moderateto High

Delay SensitiveDelay Sensitive HighHigh LowLow Low toModerateLow to

Moderate

Jitter SensitiveJitter Sensitive HighHigh LowLow VariesVaries

Traffic should be grouped into classes that have similar QoS requirements

QoS Requirements for Applications


The Cisco QoS Architecture

Classification

Identify and SplitTraffic into

Different Classes

Prioritize, Protect and

Isolate Traffic Based on Markings

Mark Traffic According to Behavior and

Business Policies

PolicingMarking

Queuing

Shaping

Discard Misbehaving Traffic to

Maintain Network Integrity

Control Bursts and Conform

Traffic


Classification – Defining a Class

Single users• MAC address

• IP address

Traffic Classes are usually mapped to the IP Precedence or DiffServ DS Fields to control Queuing and Congestion Management Routines

Applications• TCP/UDP Port number

• 5-Tuples

• URLs

Departments, customers• IP Subnet

• Ingress Interface


Link Utilization

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

Classification – NBAR

My Application Is too Slow!

Mark Citrix Real-Time as GOLD Service and Police FTPGuarantee Bandwidth for Citrix!

Citrix 25%Netshow 15%Oracle 10%FTP 30%HTTP 20%


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

Separate “Conform” and “Exceed” Actions

VolPVolP HTTP FTPFTP

Gold ClassBronze Class

Platinum ClassVolPVolPHTTPFTPFTP

VolP HTTP FTP


Router(config)# class-map Gold

Router(config-cmap )# match ip rtp 16384 17383

Router(config-cmap)# exit

Router(config)# class-map Silver

Router(config-cmap)# match protocol Citrix

Router(config-cmap)# exit

Classification – Configuration


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


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


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


Policing – Single-Rate, Three-Color Marker


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

Policing – Configuration (SRTC)


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


Policing – Two-Rate, Three-Color Marker




Router(config-pmap-c)# police cir cir bc burst-normal pir bps be burst-max conform-action action exceed-action action violate-action action


Policing – Configuration (TRTC)


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

1Frame Relay DE Bit

1ATM CLP Bit

3Ethernet CoS Bits

3MPLS Experimental (EXP) Bits

6Differentiated Services Code Point (DSCP)

3IP Precedence

# of Bits

Type of Marking

Marking – Marker Locations and Size




Router(config-pmap-c)# set ip dscp 26


Marking – Configuration


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)


40%

25%

10%

Gold

Silver

Bronze

Step 1: Define Classes Step 2: Define Bandwidth

High Bandwidth, Low-DelayHigh Bandwidth, Low-Delay

Bounded Bandwidth and DelayBounded Bandwidth and Delay

Best EffortBest Effort

Queuing / Scheduling – CBWFQ

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


WFQWFQ

Interface

33

44 33 22 11 11VV

44

PQPQ

VVVVPriority Class

Class 1

Class 2

Class 3

Class-Default

33

22

44

11

66

33

22

44

11

55

33

44

77

Queuing / Scheduling – LLQ

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


Router(config)# policy-map wan_policy

Router(config-pmap)# class Gold

Router(config-pmap-c)# priority 128



Router(config-pmap-c)# bandwidth 256


Router(config-pmap)class class-default

Router(config-pmap-c)# fair-queue

Queuing / Scheduling – Configuration


policy-map Multiservice class VoIP priority percent 10 (OR prior class business

bandwidth percent 30 class data

bandwidth percent 20

policy-map Multiservice class VoIP

priority percent 10 class business

bandwidth remaining percent 80 class class-default

bandwidth remaining percent 20

Absolute Percent Specifications for LLQ

Queuing / Scheduling – Configuration

Relative Percent Specifications for LLQ


Router(config)# policy-map access-out


Router(config-pmap-c)# shape {average | peak} cir bc be


Shaping – Class-Based Generic


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

Shaping – Class-Based Frame-Relay


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


0

5

10

15

20

25

30

35

40

45

0 10 20 30 40 50

Slow StartExponential Growth

Congestion Avoidance PhaseLinear Growth

TCP Slow Start / Congestion Control


Time

Queue Utilization

100%

Tail Drop

3 Traffic Flows Start at Different Times

Another Traffic FlowStarts at this Point

Congestion Avoidance: The Problem


Average Queue Depth

1

0

DropProbability

Min 1 Max 1Min 3Min 2 Max 2 Max 3

Max QueueLength(Tail Drop)

1/m

Weighted Random Early Detect (WRED)


Router(config)# policy-map wan_policy


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)


WRED Configuration


policy-map policy-name

Enters configuration sub-mode for policy definition (marking, policing, shaping, queuing, etc.)

class-map [match-any | match-all] class-name

Enters configuration sub-mode for class definition

service-policy {input | output} policy-name

Command in interface configuration sub-mode to apply QoS policy for input or output traffic

Configuring QoS in IOSMQC Abstractions and Syntax


A University QoS Scenario


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)


Receiver

RPSource

Traffic FlowInternet

GW

T1

University Scenario—Topology


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


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 224.0.0.0 31.255.255.255

University Scenario – Configuration

On the router closest to the source:


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


Queuing configuration multicast-tree routers:


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 153600

Router(config)# interface serial0

Router(config)# bandwidth 1536

Router(config-if)# service-policy input limitnapster

Router(config-if)# service-policy output limitnapster


On the Gateway (GW) Router:


Useful Information

• CCO QoS page

http://www.cisco.com/go/qos

• Cisco IOS 12.2 QoS documentation

• “IP Quality of Service” book

http://www.ciscopress.com/book.cfm?series=1&book=173

http://www.cisco.com/go/qos

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

Documents

1 © 2001, Cisco Systems, Inc. All rights reserved. Deploying Quality of Service Technologies