Cisco Certified Hell

Also available as a PDF here

Introduction to QoS

Converged Network Issues Related to QoS

• Acceptable end-to-end delay for VoIP packets ~ 150 to 200 ms
• 4 major challenges/concerns with converged networks
  • Available bandwidth
  • End-to-end delay
  • Delay variation (jitter) – difference in amount of delay
  • Packet loss – usually caused by sudden burst or failures
• Available bandwidth
  • Maximum bandwidth of a path is equal to the bw of the link with the lowest/smallest bw
  • Available bandwidth = MaxBW/Number of Flows
  • Possible remedies include:
    • Increase link bandwidth – not always beneficial for bursty traffic
    • Classify and mark traffic
    • Deploy queuing mechanisms
    • Use compression techniques
      • Link compression
      • TCP header compression
      • RTP header compression
• End-to-end delay
  • 4 types of end-to-end delay
    • Processing – the time it takes for a device to perform all tasks necessary to move packet from ingress interface to egress interface
    • Queuing – time that the packet spends in the output queue
    • Serialization – time it takes to put the bits of frame on the wire
    • Propagation – time it takes for the frame to cross the physical link
• Jitter/Delay Variation
  • For voice and video, packets must be released to the application in the correct order and same rate at which they were released at the source
  • De-jitter buffer compensates for the delay variation using the RTP time stamp on the packets
  • 5 ways of compensating for jitter
    • Increase link bandwidth
    • Prioritize delay-sensitive packets and forward important packets first
    • Re-prioritize packets – usually when a packet leaves a domain
    • L2 payload compression – reduces size of IP packet
    • Use header compression – cRTP – improves the overhead to payload ratio
• Packet Loss
  • Occurs when buffer space is exhausted (output queue) and device ends up dropping incoming packets
  • Interface resets may cause packet loss as well
  • Fragile flows – application flows that don’t use TCP and are more drop sensitive
  • Use show interface command to show interface counters
    • Output drop – number of packets dropped because the output queue was full (aka tail drop)
    • Input queue drop – CPU may be over utilized or input buffer is full
    • Ignore – total number of frames ignored due to lack of buffer space
    • Overrun – shows number of packets dropped when CPU is too busy to allocate buffer space to incoming packets
    • Frame Error – frames with CRC errors, runts, or giants
  • Methods for guarding against packet loss include
    • Increase link bandwidth – results in faster packet departures from interfaces
    • Increase buffer space – large buffer space allows better handling of bursty traffic
    • Provide guaranteed bandwidth – CBWFQ and LLQ can reserve bandwidth for specific traffic classes
    • Perform congestion avoidance – RED and WRED can drop packets before queue fills up
      • Packets can be dropped from specific flows whereas tail drop will drop all packets

Definition of QoS and Three Steps to Implementing It

“QoS is the ability of the network to provide better or special service to a set of users or applications (or both) to the detriment of other users, applications, or both”

• RTP priority queue ensures voice packets are given the right of way (protects voice from data)
• Strict priority queue (in LLQ) limits the bw of the priority queue (protects data from voice)
• Call admission control – prevents voice calls from saturating the link (prevents them from going beyond a specified limit)

Three steps to implement QoS

1. Identify traffic types and their requirements
2. Classify traffic based on the above requirements
3. Define policies for each traffic class

Step 1: Identify Traffic Types and Their Requirements

• Perform a network audit
  • Run audit during the busiest time of day but also at other times as well
• Perform a business audit and determine each application’s importance
  • Consider whether delaying or dropping packets of each application is acceptable
• Define appropriate service levels for each class of traffic

Step 2: Classifying Traffic Based on the Requirements Identified

• The defined classes must be in line with business objectives
• Traffic/applications in the same class must have common requirements
• VoIP traffic is usually given its own class
• Different classes as defined by many case studies include:
  • VoIP – delay and drop is to be minimized
    • Packet loss < 1%
    • End-to-end delay of 150ms
  • Mission-critical
    • Critical business applications
  • Signaling traffic
    • Usually its own class
    • Minimum bandwidth expectations
  • Transactional applications
    • Database driven apps
  • Best effort
    • All unidentified traffic
  • Scavenger
    • All traffic that is to be classified lower than best effort (p2p traffic for example)

Step 3: Defining Policies for Each Class

• Set a max bandwidth limit for each class
• Set a min bandwidth guarantee for each class
• Assign a relative priority level
• Apply congestion management, avoidance, and other QoS techniques to a class

Identifying and Comparing QoS Models

Best effort

• Pros
  • Easily scalable
  • Ease of implementation – none!
• Cons
  • Lack of service guarantee
  • Lack of service differentiation

Integrated Services Model (IntServ) [RFC 1633]

• Pros
  • Explicit end-to-end resource admission control
  • Per-request policy admission control
  • Signaling of dynamic port numbers
• Cons
  • Each flow has continuous signaling resulting in lots of overhead as the number of flows increased
  • Hard to scale because each flow is tracked and maintained
• Often called Hard QoS
• Based on explicit signaling and managing/reserving network resources
• Guarantees bandwidth, delay, and packet loss – predictable service level
• Uses RSVP (resource reservation protocol) – RSVP travels the network and requests bandwidth for the application flow
  • If RSVP succeeds, the application can begin operating
  • If RSVP fails the app cannot begin operating
• Mimics the PSTN model
• In addition to RSPV, enable the following:
  • Admission control – if resources cannot be made available, the application is denied
  • Classification – traffic belonging to an application that has made resource reservations must be classified and recognized by transit routers
  • Policing – measure and monitor applications to ensure they do not exceed resource usage above their profiles
  • Queuing
  • Scheduling – works in conjunction with queuing – this is the relative attention each queue gets if multiple queues are configured – referred to as the scheduling algorithm

Differentiated Services Model (DiffServ) [RFC 2474 2475]

• Pros
  • Highly scalable – able to handle 1000’s of flows
  • Flexible framework to define as many service levels as business demands dictate
• Cons
  • Does not provide an absolute guarantee of service
  • Somewhat complex to configure across many devices
• Based on a per-hop behavior – does not require signaling like IntServ
  • Each device in the network must be programmed to provide a specific level of service for each class of traffic
• Network traffic is classified
• QoS policies enforce differentiated treatment of defined classes
• Classes and policies are based on business requirements
• Often called Soft QoS

QoS Implementation Methods

Legacy command line

• Difficult to maintain consistency across many devices
• Error prone
• Does not completely separate classification from policy definition

Modular QoS CLI (MQC)

• Traffic classification and policy definition are done separately
  • Policies are defined after classes are defined
  • Different policies might reference the same classes
• Greater consistency across devices

Implementing QoS with MQC – 3 Major Steps

1. Define traffic using the class-map command (Case sensitive)
   1. Divides identified traffic into a number of named classes
2. Define QoS policies for traffic classes using policy-map (Case sensitive)
   1. Defines the treatment of defined classes from step 1
   2. Can define QoS policies for up to 256 traffic classes
3. Apply the policies in the inbound or outbound direction using the service-policy command
   1. Defines where the policies are applied


class-map MyVoipMap
match access-group 100


match-any vs. match-all

• In order to bind the packet to the class
  • Match-any – Only one access-list entry needs to be matched
  • Match-all – All entries in an access-list must be matched

policy-map MyPolicyMap ! defines a policy map
class MyVoipMap ! associates MyVoipMap (above) with this policy
priority 256 ! VOIP traffic has bandwidth guarantee of 256Kbps

int s0/0
service-policy output MyPolicyMap ! applies policy map defined above to this interface

AutoQoS

• Analyzes network traffic for as long as you let it run
• Generates traffic classes based on traffic it has processed (Auto QoS Discovery)
• Generates policy maps based on the classes it has defined
• Applies the appropriate policies to an interface
• Simplifies task of QoS configuration
• Prerequisites include:
  • Enable CEF
  • Enable NBAR
  • Verify that the correct bandwidth is configured on the interface

Related AutoQoS Commands

• auto qos voip - first generation of auto QoS – automated generation of QoS commands to get the device ready for voice over IP
• auto discovery qos – must be enabled for the router to discover and analyze network traffic entering the interface using NBAR
• auto qos – router builds class maps based on discovery and applies a policy map on the interface

SDM QoS Wizard

Step 1: Click Configure
Step 2: Click Quality of Service
Step 3: Click Create QoS Policy
Step 4: Click Launch QoS Wizard