IP QoS Principles

1. IP QoS Principles Theory and Practice Dimitrios Kalogeras

2. Agenda • Introduction – History – Background • QoS Metrics • QoS Architecture • QoS Architecture Components • Applications in Cisco Routers

3. A Bit of History • The Internet, originally designed for U. S. government use, offered only one service level: Best Effort. • No guarantees of transit time or delivery • Rudimentary prioritization was available, but it was rarely used. • Commercialization began in early 1990’s • Private (intranet) networks using Internet technology appeared. • Commercial users began paying directly for Internet use. • Commerce sites tried to attract customers by using graphics. • Industry used the Internet and intranets for internal, shared communications that combined previously-separate, specialized networks -- each with its own specific technical requirements. • New technologies (voice over the Internet, etc.) appeared, designed to capitalize on inexpensive Internet technologies.

4. The Demands on Modern Networks • Network flexibility is becoming central to enterprise strategy • Rapidly-changing business functions no longer carried out in stable ways, in unchanging locations, or for long time-periods • Network-enabled applications often crucial for meeting new market opportunities, but there’s no time to custom-build a network • Traffic is bursty • Interactive voice, video applications have stringent bandwidth and latency demands • Multiple application networks are being combined into consolidated corporate utility networks • Bandwidth contention as critical transaction traffic is squeezed by web browsing, file transfers, or other low-priority or bulk traffic • Latency problems as interactive voice and video are squeezed by transaction, web browsing, file transfer, and bulk traffic

5. QoS Background • Video Streaming Services • Video Conferencing • VoIP • Legacy SNA / DLSw QoS development inspired by new types of applications in IP environment:

6. Definitions • Quality of Service (QoS) classifies network traffic and then ensures that some of it receives special handling. • May track each individual dataflow (sender:receiver) separately. • May include attempts to provide better error rates, lower network transit time (latency), and decreased latency variation (jitter). • Differentiated Class of Service (CoS) is a simpler alternative to QoS. • Doesn't try to distinguish among individual dataflows; instead, uses simpler methods to classify packets into one of a few categories. • All packets within a particular category are then handled in the same way, with the same quality parameters. • Policy-Based Networking provides end-to-end control. • The rules for access and for management of network resources are stored as policies and are managed by a policy server.

7. Statistical Behavior: Random Arrival • In random arrival, the time that each packet arrives is completely independent of the time that any other packet arrives. • If the true situation is that arrivals tend to be evenly spaced, then random arrival calculations will overestimate the queuing delay. • If the true situation is that arrivals are bunched in groups (typical of data flows, such as packets and acknowledgements), then random arrival calculations will underestimate the queuing delay. • Our intuition is usually misleading when we think of random processes. • We tend to assume that queue size increases linearly as the number of customers increases. • But, with random arrival, there is a drastic increase in queue size as the customer arrival rate approaches 80% of the theoretical server capacity. There’s no way to store the capacity that is unused by late customers, but early customers increase the queue.

8. Random Arrival and Intuition • The surprising increase in queue length is best shown by a graph:

9. Random Arrival vs. Self-Similar • Although random arrival is very convenient mathematically (it’s relatively simple to do random arrival calculations), it has been shown that much data traffic is self-similar. • Ethernet and Internet traffic flows, in particular, are self-similar. • The rate of initial connections is still random, however. • Self-similar traffic shows the same pattern regardless of changes in scale. • Fractal geometry (e.g., a coastline) is an example. • Self-similar traffic has a heavy tail. • The probabilities of extremely large values (e.g., file lengths of a gigabyte or more) don’t decrease as rapidly, as they would with random distributions of file lengths. • This matches real data traffic behaviours. • Long file downloads mixed with short acknowledgements • Compressed video with action scenes mixed with static scenes

10. Implications of Self-Similar Behaviour • “If high levels of utilization are required, drastically larger buffers are needed for self-similar traffic than would be predicted based on classical queuing analysis [i.e., assuming random behaviour].” [Stallings] • Combining self-similar traffic streams doesn’t quickly result in smoother traffic patterns; it’s only at the highest levels of aggregation that random-arrival statistics can be used.

11. B A The path as perceived by a packet! Bandwidth Delay 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

12. 100 Mb/s 2Mb/s 10 Mb/s 2 Mb/s Maximum Bandwidth 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

13. 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

14. 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

15. 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 DS-3 GE GE GE Oversubscribed Buffer Exhaustion

16. QoS Architecture Models • Best Effort Service • Integrated Service • Differentiated Service

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

18. Best Effort Service What exactly IP does: • All packets treated equally • Unpredictable bandwidth • Unpredictable delay and jitter

19. IntServ (RFC1633)

20. RESV Sender Receiver PATH 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

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

22. 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

23. 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

24. 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

25. DiffServ (RFC2474/2475)

26. 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 1 2 3 4 5 1 2 3 4 5

27. 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

28. 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 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 DSCP CU DS field

29. 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

30. 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

31. Conditioning Remarker Classification Meter Shaper Classifier Marker Dropper DiffServ – Boundary Nodes DiffServ Boundary Nodes are responsible for classifying and conditioning packets as they enter a given DiffServ Domain • 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

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

33. 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

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

35. 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

36. 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

37. 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

38. QoS Architecture Components • Classification • Coloring • Admission Control • Traffic Shaping/Policing • Congestion Management • Congestion Avoidance • Signaling

39. Traffic Classification • Most fundamental QoS building block • The component of a QoS feature that recognizes and distinguishes between different traffic streams • Without classification, all packets are treated the same

40. Traffic Classification/Admission Control Issues • Always performed at the network perimeter • Makes traffic conform to the internal network policy • Marks packets with special flags (colors) • Colors used afterwards inside the network for QoS management

41. Meter Admitted Shaper/Policer Classifier Marker Packet Dropped Classification/Admission Control Scheme

42. Classification Criteria • IP header fields • TCP/UDP header fields • Routing information • Packet Content (NBAR)i.e. HTTP, HTTPS, FTP, Napster etc.

43. Traffic Coloring Options • IP Precedence • DSCP • QoS Group • 802.1p CoS • ATM CLP • Frame Relay DE

44. Type-of-Service (RFC791) Precedence D T R Unused Version Length ToS Field Total Length … 0 8 15 31

45. IP Precedence Values

46. DSCPDiffserv Code Point DSCP (6 bits) Unused

47. Classification mechanisms • MQC ( Modular Qos Command Line Interface) • CAR ( Commited Access Rate)

48. Modular QoS CLI Modular QoS CLI (MQC) • Command syntax introduced in 12.0(5)T • Reduces configuration steps and time • Uniform CLI across all main Cisco IOS-based platforms • Uniform CLI structure for all QoS features

49. router(config)# class-map [match-any | match-all] class-name • 1.Create Class Map - a traffic class( match access list, input interface, IP Prec, DSCP, protocol (NBAR) src/dst MAC address, mpls exp). router(config)# policy-map policy-map-name • 2. Create Policy Map (Service Policy) - Associate a class map with one or more QoS policies(bandwidth, police, queue-limit, random detect, shape, set prec, set DSCP, set mpls exp). router(config-if)# service-policy {input | output} policy-map-name • 3. Attach Service Policy- Associate the policy map with an input or output interface. Basic MQC Commands

50. Basic MQC Commands • 1. Create Class Map – defines traffic selection criteria Router(config)# class-map class1 Router(config-cmap)# match ip precedence 5 Router(config-cmap)# exit • 2. Create Policy Map- associates classes with actions Router(config)# policy-map policy1 Router(config-pmap)# class class1 Router(config-pmap-c)# set mpls experimental 5 Router(config-pmap-c)# bandwidth 3000 Router(config-pmap-c)# queue-limit 30 Router(config-pmap)# exit • 3. Attach Service Policy – enforces policy to interfaces Router(config)# interface e1/1 Router(config-if)# service-policy output policy1 Router(config-if)# exit