Understanding Quality of Service (QoS) in Networking

1. IntServ and DiffServ School of Electronics and Information Kyung Hee University. Choong Seon HONG <cshong@khu.ac.kr>

2. Quality of Service (QoS) • A major driving force in Internet evolution • Not simply defined - means many things to many people • Has sense of predictable network behaviour • Central idea is provision of network resources that an application requires to perform adequately

3. Quality of Service (QoS) • What is Quality-of-Service?• Quality of service (QoS) is a concept by which applications may indicate and even negotiate their specific service requirements to the network • Why is this an issue? • The default service in many packet networks is to give all applications the same service, and not consider any service requirements to the network. This is called a best-effort service.

4. Quality of Service (QoS) • Who needs Quality-of-Service? – Video and audio conferencing  bounded delay and loss rate – Video and audio streaming  bounded packet loss rate – Time-critical applications (real-time control)  bounded delays – “valuable applications”  better service than less valuable applications

5. Quality of Service (QoS) • How are Quality-of-Service requirements specified? • QoS parameters are – Delay – Delay Variation (Jitter) – Throughput – Error Rate

6. Quality of Service (QoS) • What is the granularity of QoS? – Per-flow QoS  Guarantees are specified and enforced for single end-to-end data flow – Aggregate QoS Guarantees are specified and enforced for groups of flows

7. Types of QoS guarantees • Deterministic QoS – Service guarantees are enforced for all traffic • For example, deterministic delay guarantees have the form: Delay of a packet from flow X ≤ D (D is called a delay bound) • Statistical QoS • Allows a certain fraction of traffic to violate the service guarantees • Prob [Delay of a packet from flow X ≤ D ] ≥1 - ε Where e is a small number (e.g., ε = 10-6)ε

8. Classification and Scheduling • Routers need to be able to 1. classify arriving packets according to their QoS requirements  Packet Classification 2. isolate traffic flows and provide requested QoS  Packet Scheduling

9. QoS CoS RSVP Intserv GMPLS MPLS QoS is Generating a Confusing Array of Acronyms Diffserv

10. Why Do We Need Such a Revolutionary Change? • Current ‘best effort’ technology is essentially a quarter of a century old • Two factors driving the development of a new generation of multimedia applications • commercialisation of the Internet • Increasing availability and decreasing cost of bandwidth • No evidence of ‘free bandwidth’ scenario emerging • rejected in RFC1633 (1994) - still true • demand always rises to meet supply

11. QoS is Not New • Telephone network has QoS • economics and technology based on a single application • highly developed engineering • but one size fits all • BISDN - an attempt by telephony world to generalise network to encompass diverse applications • ATM technology - first full exploration of QoS on demand concepts

12. Quality of Service and Resource Management • Fundamental resource is output link rate • Access managed via scheduling discipline • Bursty input traffic held in buffers • adds delay and jitter • overflow causes packet loss • These factors determine QoS at network level • Optimise via buffer management and scheduler parameter setting

13. QoS in the Internet • Internet Engineering Task Force (IETF) is evolving QoS support mechanisms for the Internet - two approaches • The Integrated Services Internet • QoS for individual microflows • perhaps too complex for large networks - won’t scale easily • Differentiated Services - more scaleable • lose sight of individual microflows - Behaviour Aggregates

14. Integrated Services (Intserv) • QoS approached via end to end services • best effort - current performance standard • controlled load - lightly loaded network performance - ‘soft’ delay bound • Guaranteed - ‘hard’ bandwidth and delay bounds • Traffic conformance to agreed form expected • ‘token bucket’ model - policing if nonconforming • Resources reserved in routers - RSVP • more complex set of functions than ATM

15. RSVP is Dead! • Earlier reports of RSVP’s death were somewhat exaggerated • Nevertheless there is a major problem with Intserv- fatal in the eyes of some • Management of router resources requires each router to maintain per flow ‘state’ • Creates ‘state explosion’ in the interior routers of core networks - perhaps confine to edges

16. Differentiated Services (Diffserv) • Driving philosophy of the Internet has been to minimise complexity in the core network - push complexity and intelligence to the edge nodes. • Differentiated Services concept strives to maintain this philosophy while recognising the need to provide some levels of Quality of Service • First widely deployed QoS mechanism

17. Differentiated Services

18. Content • Intserv/RSVP • Differentiated Service Paradigm • Per-Hop Behavior & Codepoint • Premium Service • Assured Forwarding PHB Group • Resource Manager : Bandwidth Broker(BB) • Boundary Mechanisms • Diffserv WG

19. Internet Integrated Service Model Guaranteed Quality of Service • Motivation • for applications intolerant of late data • hard real time requirements • End-to-End behavior • an assured level of bandwidth • a delay-bounded service with no queueing loss • firm maximum on end-to-end delay • not control the minimal or average delay • no jitter control

20. Internet Integrated Service Model • In order for a router to invoke Guaranteed Service for a specific data flow it needs to be informed of the traffic characteristics of the flow, Tspec, along with the reservation characteristics, Rspec • Tspec parameters • p ; peak rate of flow (bytes/second) • b ; bucket depth (bytes) • r ; token bucket rate (byes/second) • m ; minimum policed unit (bytes) • M ; maximum datagram size (bytes) • Rspec parameters • R ; bandwidth, i.e. service rate (bytes/second) • S ; Slack Term (ms)

21. Internet Integrated Service Model Controlled - Load Service • Motivation • for adaptive real-time applications (today’s internet) • work well on unloaded nets but degrade quickly under overload conditions --> mimics unloaded nets • If the flow is accepted for Controlled-Load Service then the router makes a commitment to offer the flow a service equivalent to that seen by a best-effort flow on a lightly loaded network

22. Internet Integrated Service Model Controlled - Load Service (cont’d) • End-to-End behavior • Tightly approximates the behavior visible to applications receiving best-effort service under unloaded conditions • A very high percentage of packets delivered successfully • Controlled Load has some fairly simple implementations, in terms of the queuing systems in routers • It is not suited to applications that require very low latency (e.g. distributed VR systems and so forth).

23. RSVP RSVP Design Principles • Receiver-Initiated Reservation • a receiver • choose the level of reservation • initiate/keep reservation • more flexible and scaleable than source-initiated reservation • heterogeneous receivers • dynamic membership change • Separating reservation from packet filtering • reservation • amount of resources reserved for an entity • packet filtering • dynamically select packets that can use the resources

24. RSVP Design Principles (cont’d) • Maintain “Soft-state” • dynamic status change (membership change) • soft-state in switches and maintained by end users • state in switches • path state -- periodic path message from the source • reservation state -- periodic reserv. msg from the receivers • timeout driven deletion • Reservations timeout if not refreshed periodically • adaptability and robustness • Protocol overhead • reduce refreshing frequency • merging path/reservation messages

25. Receiver generates reservation Sender generates connection request Soft state ( refresh / timeout ) Hard state ( explicit delete ) Separate from route establishment Concurrent with route establishment QoS can change dynamically QoS is static for life of connection Receiver heterogeneity Uniform QoS to all receivers RSVP Comparison of RSVP and ATM signaling RSVP ATM

26. RSVP Message Types 1. Path_msg S1 2. forwarding Path_msg R1 R2 D1 S2 R3 3-1.Resv_msg 4. forwarding Resv_msg D2 3-2. Resv_msg

27. Internet Integrated Service Model Integrated Services over Specific Link Layers(ISSLL WG) • RSVP designed to work with any protocol • - Protocol must provide QoS support • - Examples: ATM, IP with Integrated Services • IP integrated services with RSVP over ATM • VC management ( traffic flow-VC) • Data VC, RSVP signaling VC • QoS translation • mapping a QoS from the IIS model to a proper ATM QoS • IIS over POTS • IIS over LAN

28. Intserv / RSVP QoS Approach • Scalability problem • Have to maintain forwarding state between receiver and transmitter

29. Integrated Services Model • Flow specification • Routing • Admission control • Policy control • Resource reservation • Packet scheduling

30. RSVPD Routing Process Application Policy Control Policy Control Admissions Control Admissions Control Packet Classifier Packet Scheduler Packet Classifier Packet Scheduler RSVP Functional Diagram Host Router RSVPD D A T A DATA DATA

31. What is a flow? • Equivalent packets by some classification • RSVP: Set of packets traversing a network element that are all covered by the same QoS request • Packet classifier determines which packets belong to which flows • IPv6 includes a flow label to ease classification • ISP usage (UUNET) • Microflow: TCP or similar bandwidth connection • Macroflow: Large aggregates of packets flowing between two superhubs

32. Describing and Identifying a Flow • Flowspec defines traffic parameters • Traffic parameters: bandwidth, buffering requirements • Uses token bucket specification • Filterspec identifies packets in flow • Simplest filter: Source, Dest address/port pair • Data filter: classifies packets according to contents

33. Resource Reservation • Senders advertise using PATH message • Receivers reserve using RESV message • Flowspec + filterspec + policy data • Travels upstream in reverse direction of Path message • Merging of reservations • Sender/receiver notified of changes

34. RSVP UDP Reservation (1)

35. RSVP UDP Reservation (2)

36. Client Traffic Shaping • Issue: Need traffic shaping to meet allocated resources • Source promises that data traffic will conform to a particular shape • Why describe and shape traffic? • Network knows what to expect, can manage traffic better • Better admission control decisions • Network can police flows • Bursty traffic is costly to router, network

37. Traffic Shaping Example Data Queue Flow 1 Flow 2 Data Queue

38. Traffic Shapers • Simple leaky bucket • Isosynchronous flow: regular intervals between packets • Token bucket • Bursty flow

39. Simple Leaky Bucket Data • Sends data at fixed intervals onto network • Bursts bigger than b are discarded • Traffic never injected faster than r • Can be used with cells or datagrams b b = bucket size r = rate data is sent onto network r

40. Token Bucket r • Sends bursty traffic onto network • Bucket filled with tokens at rate r • Data transmitted when enough tokens exist • Allows bursts, but enforces upper bound b = bucket size in tokens r = rate tokens are added to bucket b Data Queue Data

41. Restrictions on Reservations • Admissions • Is bandwidth available? • Policy • Service guarantees give preferential access to network bandwidth • Permissions • Pricing issues • What are the policies of nodes on the path? • Policy data represents a scaling and security issue

42. Resource Reservation Model • Senders advertise using flowspecs • RSVP daemons forward advertisements to receivers, update available bandwidth, minimum delay • Receivers reservations use flowspec, filterspec combination (flow descriptor) • Sender/receiver notified of changes • Reservations are merged in multicast case

43. Reservation Styles • Wildcard Filter (WF) • Shared reservation, select all upstream senders • Traffic from upstream senders shares a single pipe • Appropriate for audio • Shared Explicit (SE) • Shared reservation, explicit sender selection • Appropriate for audio • Fixed Filter (FF) • District reservations, explicit sender selection • Appropriate for video

44. RSVP Flowspecs Sender TSpec, Controlled Load Flowspec . . . Token Bucket Rate [r] Token Bucket Size [b] Peak Data Rate [p] Minimum Policed Unit [m] Maximum Policed Unit [M] Guaranteed Flowspec . . . Token Bucket Rate [r] Token Bucket Size [b] Peak Data Rate [p] Minimum Policed Unit [m] Maximum Policed Unit [M] Rate [R] Slack Term [S]

45. Packet Scheduling • Implemented in hosts/routers to control link allocation • Queuing algorithms • Weighted Fair Queuing (WFQ) • Class Based Queuing (CBQ) • Queue management • Random Early Detection (RED)

46. Packet Scheduling • Fair Queueing • Attempts to implement a scheduler that serves all flows with a backlog at the same rate • Emulates a bitwise Round Robin scheduling algorithm • Not completely trivial to implement Fair Queuing in a packet network

47. Weighted Fair Queuing (WFQ) • Traffic placed into queues according to flow specification, flow filter • Fair queuing • Implements fairness of bit by bit scheduling on a per packet basis • Gives queues a fair share of total bandwidth • Weighted • Queue are not weighted evenly for scheduling • Proven: adequate for Guaranteed Service

48. Class Based Queuing (CBQ) • Combines scheduling and link sharing • Hierarchical link sharing • Hierarchical queues • Enables protocol, organization isolation • Scheduling • Does not define a particular scheduling algorithm • General scheduler for low latency when no congestion • Link-sharing policing scheduler when congested • Scheduling per hierarchy

49. CBQ Example LINK 60% 40% Company A Company B 30% Real- Time HTTP FTP telnet IP DECnet 10% 20% 20% 20% Video Audio 20% 10%

50. Random Early Detection (RED) • Random Early Detection (RED) • Queue management algorithm for congestion control • Random packet drops as average queue length increases • Can use Explicit Congestion Notification bit instead of dropping packet • Works well for TCP • Useful for congested Controlled Load service