Topic 4: Quality of Service

Need for QoS If we don’t use QoS, the following problems may arise: Jitter Insufficient Bandwidth Delay Information Loss

VoIP Call Bandwidth Requirements Different codecs use different bandwidth requirements. G.729 bit rate is 8 Kbps To find out the total bandwidth for a voice call, we have to add G.729 Voice Payload, RTP/UDP/IP headers, and also the Layer 2 Header ( Ethernet, Frame Relay, PPP and so on).

VoIP Call Bandwidth Calculations: Voice packet size = Layer 2 header + IP/UDP/RTP Header + voice payload size Voice packets per second (PPS) = codec bit rate / voice payload size (in bits) Bandwidth (Kbps) = voice packet size*PPS During this calculation, make sure you convert bytes to bits.

VoIP Call Bandwidth Values You can use the following bandwidth requirements for VoIP design: G.729 calls use 24 Kbps G.723 calls use 24 Kbps G.711 calls use 80 Kbps

Serialization Delay Example A 1500 byte packet takes (1500 * 8 / 64,000) = 187 ms of serialization delay on a 64 Kbps circuit. If the circuit is increased to 512 Kbps, the serialization delay changes to (1500 * 8/512,000) = 23.4 ms.

Methods to reduce Serialization Delay Data-link fragmentation using Link Fragmentation and Interleaving (LFI) or FRF.12 mechanisms reduces the serialization delay by reducing the size of the larger data packets. This arrangement reduces the delay experienced by voice packets as data packet fragments are serialized and voice packets are interleaved between the fragments. A reasonable design goal is to keep the serialization delay experienced by the largest packets or fragments on the order of 10 ms at any interface.

Reducing the Bandwidth

Network Requirements The goal: - Ensure voice quality by designing to minimize loss, delay, delay variation and echo. The solution: - Use QoS tools to protect voice from data and protect voice from voice

QoS Models Two models or Approaches: Integrated Services (Intserv) Differentiated Services (Diffserv)

IntServ Model Follows the signaled-QoS model, where the end- hosts signal their QoS need to the network IntServ provides for a rich end-to-end QoS solution, by way of end-to-end signaling, state- maintenance (for each RSVP-flow and reservation), and admission control at each network element

IntServ The IntServ model relies on the Resource Reservation Protocol (RSVP) to signal and reserve the desired QoS for each flow in the network. A flow is defined as an individual, unidirectional data stream between two applications, and is uniquely identified by the 5-tuple (Source IP address, Source Port#, Destination IP address, Destination Port#, and the Transport Protocol).

IntServ Drawbacks Every device along a packet's path, including the end systems like servers and PCs, need to be fully aware of RSVP and capable of signaling the required QoS. Reservations in each device along the path are "soft," which means they need to be refreshed periodically, thereby adding to the traffic on the network and increasing the chance that the reservation may time out if refresh packets are lost.

IntServ Drawbacks Maintaining soft-states in each router, combined with admission control at each hop adds to the complexity of each network node along the path, along with increased memory requirements, to support large number of reservations. Since state information for each reservation needs to be maintained at every router along the path, scalability with hundreds of thousands of flows through a network core becomes an issue.

Simpler Middle Ground IETF realized that per-flow QoS (IntServ) is difficult to achieve end-to-end in a network without adding significant complexity. Instead, classifying flows into aggregates (classes), and providing appropriate QoS for the aggregates should minimize signaling and state maintenance requirements on each network node.

ToS/IP Precedence Solution The three precedence bits in Type of Service (TOS) byte of the IP Header are used to classify packets in eight possible categories. Packets of lower precedence (lower values) can be dropped in favor of higher precedence when there is congestion on a network. Further, each packet may be marked to receive one of two levels of delay, throughput, and reliability (DTR) in its forwarding (RFC-791).

ToS in IPv4 and IPv6 Headers

The Original IPv4/ToS Field

Limitations of ToS/IP Precedence Not granular enough The 3 bits restrict the number of possible priority classes to eight. Neither IP-Precedence, nor the DTR bits are implemented consistently by network vendors today.

Solution: DiffServ Type of Service (ToS) Field In order to deliver end-to-end QoS, this architecture (RFC-2475) has two major components—Packet Marking using the IPv4 ToS byte, and Per Hop Behaviors (PHBs). Packet Marking done using a 6-bit bit-pattern (called the Differentiated Services Code Point [DSCP]) in the IPv4 ToS Octet or the IPv6 Traffic Class Octet is used to this end as shown in Figure on next slides

Diffserv Code Point (DSCP) Field

DiffServ Components Two major components of DiffServ Traffic Classification Classification Policing Marking Shaping Per-Hop Behaviour Queuing Dropping

DiffServ Classify Shape (optional) Queuing Drop Policy Edge Device (CED or SED) Traffic Classification Ingress Interfaces Per-Hop Behaviour Egress Interfaces Every Node in Network Police & Mark

Traffic Classification: Classification Trust boundary Define “interesting” traffic Create “classes” of traffic Determine service level required for each class (DSCP) Determine how to group traffic in classes Match on IP source or destination address, access-control list, protocol (port) number, RTP port range (for voice) Oldest and most common is ACL

Traffic Classification: IPv4 ToS vs. DS-Field DSCP bits

Traffic Classification: Classification (cont.) As mentioned earlier, the DSCP indicates the PHB throughout the entire network 4 types of classifications Default (all bits set to 0) Class Selector Backwards compatible with IP Prec Assured Forwarding (AF) Expedited Forwarding (EF)

Traffic Classification: Classification (cont.) Class Selector DSCP Upper 3 bits map to IP Prec levels Lower 3 bits are all set to 0 Class SelectorsDSCP IP Prec IP Prec IP Prec IP Prec IP Prec IP Prec IP Prec

Traffic Classification: Classification (cont.) Assured Forwarding Four services classes are defined AF1, AF2, AF3, AF4 AF1 maps to IP Prec 1, AF2, maps to IP Prec 2, etc. Upper 3 bits define the class and class priority, the next 2 bits define packet drop precedence, and the last bit is always 0.

Traffic Classification: Classification (cont.) Expedited Forwarding Highest level of service Single class also known as EF DSCP value is

Traffic Classification: Classification (cont.) Example DiffServ values Gold – EF (DSCP 46) Silver – AF31 (DSCP 26) Bronze – AF11 (DSCP 10)

Traffic Classification: Policing and Marking Involves defining a “policer” that specifies BW limits for each traffic class Traffic that exceeds configuration Known as out-of-profile or nonconforming traffic Actions include: Forwarding packet without changes Dropping packet Modifying (remarking or marking down) the packet before forwarding Assigning a different DSCP

Traffic Classification: Policing and Marking (cont.) Types of Policers Individual Apply BW limits separately to an individual traffic class Aggregate Apply BW limits in a cumulative manner to all traffic classes Policing Mechanisms Committed Access Rate Class-Based Policing

Traffic Classification: Shaping Used to rate-limit previously created classes of traffic Requirement is to meter traffic rate Shaping involves delaying excess traffic in order to remain within acceptable limit Shaping Mechanisms Generic Traffic Shaping Class-Based Shaping

Per-Hop Behaviour: Queuing Two locations: Ingress (on a Catalyst 3750) Due to fact that aggregate BW on ports may exceed BW of switch stack, traffic may be queued before reaching switch fabric Egress (all switches that support QoS) Due to fact that multiple ports sending packets to uplink port can cause congestion

Per-Hop Behaviour: Queuing Mechanisms Weighted Tail Drop (WTD) If congestion occurs, packets are dropped at intervals depending on their DSCP value Example (below) When queue is 40% full, Bronze traffic begins to be dropped When queue is 60% full, Silver traffic then is eligible to be dropped Not until the queue is 100% full can Gold traffic be dropped An option to configure on ingress switch ports in LAN or workgroup egress switch ports

Other Queuing Mechanisms Weighted Fair Queuing – no classes defined by user, the IOS instead uses weights assigned by itself Class Based Weighted Fair Queuing (CBWFQ) – classes for each traffic type configured by user and appropriate QoS parameters assigned Low Latency Queuing (LLQ) – Same as CBWFQ but has a priority queue. Suitable for VoIP traffic as VoIP traffic is assigned the priority queue

50% 35% 15% Gold Silver Bronze Step 1: Define bufferingStep 2: Define bandwidth CBWFQ Per Hop Behaviour Guaranteed: latency, delivery Guaranteed: delivery Best effort

LLQ/CBWFQ + Traffic Shaping shape average CBWFQ LLQ CBWFQ Child Policy Gold Silver Bronze Traffic Parent Policy

QoS on Cisco Devices Three basic steps Classify the traffic – create a class map Create a policy map – associate a class map with one or more QoS policies Assign the policy to an interface Use Modular QoS Command-Line- Interface (MQC)

Catalyst Switch QoS Configuration Step 1: Enable QoS globally interface range port-range Disabling flowcontrol on all ports is a prerequisite and the above command allows you to configure multiple ports at a time flowcontrol receive off flowcontrol send off mls qos

Catalyst Switch QoS Configuration (cont.) Step 2: Trust Boundaries If you have a number of workgroup switches connecting to a central core switch you may wish to configure a trust boundary interface interface-id mls qos trust |cos | dscp | ip-precedence}

Catalyst Switch QoS Configuration (cont.) Step 3: Trusting IP Phone Traffic cdp run interface [range] interface-id cdp enable mls qos trust device cisco- phone Note: Auto-QoS available as well for configuring QoS parameters automatically (not recommended)

Catalyst Switch QoS Configuration (cont.) Step 4: Define “interesting traffic” using extended ACLs access-list number {deny | permit} protocol source source-wildcard destination destination-wildcard

Catalyst Switch QoS Configuration (cont.) Step 5: Define and create class- maps and policy-maps class-map [match-all | match-any] class- map-name match {access-group acl-number- or-name | ip dscp dscp-list | ip precedence ip- precedence-list Create as many class maps as required

Catalyst Switch QoS Configuration (cont.) Step 5 (cont.) create the policy map policy-map policy-map-name class class-map-name set {cos new-cos-value | ip dscp new-dscp- value | ip precedence new-ip-precedence- value police { aggregate name | rate-bps burst-byte exceed-action {drop | policed-dscp-transmit} }

Catalyst Switch QoS Configuration (cont.) Step 6: Apply policy map to an interface interface interface-id service-policy {input policy-map- name output policy-map-name}

QoS Router Configuration Step 1: Create class maps class-map class-map-name match ip dscp [dscp-value |dscp-name] There can be multiple dscp values entered in same line

QoS Router Configuration Step 2: Define and create policy map for inbound interface policy-map policy-map-name class class-name interface f 0/0.2 service-policy input policy-map-name

QoS Router Configuration Step 3: Define and create policy map for outbound interface Create a priority queue policy-map policy-map-name class class-name priority kilobits-per-second burst-in –bits- per-second Assign BW to other classes class class-name bandwidth percent percentage-of- remaining-bandwidth

QoS Router Configuration Step 4: Apply to an outbound interface interface interface-type interface-number service-policy {input | output} policy-map- name An option is to Traffic shape on the egress interface traffic-shape rate bits-per-second