Department of Computer Science Institute for System Architecture, Chair for Computer Networks Internet Services & Protocols Quality of Service Architecture Dr.-Ing. Stephan Groß Room: INF 3099 E-Mail: stephan.gross@tu-dresden.de
QoS in IP Networks So far: Do the best with best effort Use of UDP instead of TCP (slow-start, retransmission) Client sided buffer, delayed playback to avoid jitter Adapt compression accordingly to available bandwidth Now: Beyond best effort Next generation of Internet providing level of performance needed for application to function Quality of Service QoS Foundations: Basic mechanisms QoS Architectures: Integrated Services: Promised guaranties Differentiated Services: Differentiated QoS guaranties RSVP: Negotiate (signalling) of QoS requirements 2
Why we need QoS: New Applications One Network Integration of several data streams/services with Different volume of traffic (traffic load) Demands of quality (delay, jitter) Provided by the network: Quality of Service (QoS): Differentiated handling of services and Support in end systems Overprovisioning 3
QoS Basics 4
Fundamentals of QoS Mechanism Consider a phone application at 1Mbps and a FTP application sharing a 1.5 Mbps link. FIFO: bursts of FTP can congest the router and cause audio packets to be dropped. Want to give priority to audio over FTP PRINCIPLE 1 Marking of packets is needed for routers to distinguish between different classes of traffic; and new router policies to treat packets accordingly 5
Fundamentals of QoS Mechanism cont. Applications misbehave, e.g. send packets at a rate higher than the 1Mbps assumed above Require policing mechanisms to ensure sources adhere to bandwidth requirements; Marking and Policing need to be done at the edges (end system or edge router) PRINCIPLE 2 Provide protection (isolation) for one class from another 6
Fundamentals of QoS Mechanism cont. Alternative to marking and policing: allocate a set portion of bandwidth to each application flow; can lead to inefficient use of bandwidth if one of the flows does not use its allocation PRINCIPLE 3 While providing isolation, it is desirable to use resources as efficiently as possible 7
Fundamentals of QoS Mechanism cont. Cannot support traffic beyond link capacity PRINCIPLE 4 Need a call admission process: application flow declares its needs, network may block call if it cannot satisfy the needs 8
QoS Foundations QoS for networked application Classification mark packets according to classification rules Queuing and Scheduling Cache packets before sending, choosing the next packet for transmission on a link Policing Verifying and ensuring conformances of data as described Admission Control Decide whether transmission of guaranteed quality is permitted or not Packet classification Queuing, scheduling Policing Call admission 9
Scheduling Goal: Choosing the next packet for transmission on a link can be done following a number of policies: FIFO (first in first out) scheduling strategy: Send in order of arrival to queue Simple implementation Common in IP routers Does not provide differentiated handling of packet streams Discard policy: if packets arrive to full queue: who to discard? Tail drop: drop arriving packet Priority: drop/remove on priority basis Random: drop/remove randomly 10
Scheduling Strategies Prioritized FIFO Transmit packet from the highest priority class with a non-empty queue Several classes of different priorities Class may depend on explicit marking or other header info, e.g. IP source or destination, TCP Port numbers, etc. A queue is FIFO scheduled No guarantees among one priority class 11
Scheduling Strategies cont. Round Robin scheduling: Several classes Scan class queues serving one from each class that has a nonempty queue Queues with bigger packets are overreached against classes with packets of lower length Weighted Fair Queuing: Variation of Round Robin Generalized RR which tries to provide a class with a weighted amount of service over any period of time 12
Policing Goal: limit traffic to not exceed declared parameters (aka traffic shaping) Three common-used criteria: (Long term) Average Rate: how many pkts can be sent per unit time (in the long run) Crucial question of interval length: A flow whose average rate is limited to 100 packets per sec is more constrained than one limited to 6,000 packets per min, even though both have the same average! Peak Rate: 6,000 pkts per min. (ppm) avg.; 1,500 pkts per sec peak rate (Max.) Burst Size: max. number of pkts sent consecutively (with no intervening idle) 13
Policing Mechanisms Leaky Bucket: Data bursts are flattened and sent with a average rate of R Leaky Bucket arriving packets Waiting area ( Bucket ) with size of b Packets are cached in the Bucket and sent at constant rate of R Drop packets if bucket is full Packets are cached until sending becomes conform Problem: inefficient handling of burst traffic network rate R bucket size b Maximum delay d max = b/r 14
Policing Mechanisms cont. Token Bucket: Limit input to specified burst size and average rate. Bucket holds b token at maximum New Tokens are generated at a rate of r token/sec unless bucket is full of tokens. Packets are transmitted only if a token is available in the bucket Packets are delayed, dropped or marked if bucket is empty Packet rate is regulated by parameters b, r b Defines maximum burst length r Controls average data rate Over interval of time of length t: max. number of packets admitted = r t + b conform packets arriving packets buffer remove token network token rate, r bucket size b nonconform packets 15
Leaky Bucket vs. Token Bucket Case 1: Short burst arrival Case 2: Large burst arrival 0 1 2 3 4 5 6 0 1 2 3 4 5 6 Arrival time 0 1 2 3 4 5 6 0 1 2 3 4 5 6 Time of service leaky bucket Leaky bucket rate = 1 packet / 2 time units Leaky bucket size = 2 packets 0 1 2 3 4 5 6 Time of service token bucket Token bucket rate = 1 token / 2 time units Token bucket size = 2 token 0 1 2 3 4 5 6 16
Internet QoS Architectures 17
IETF Integrated Services (IntServ) Developed by the IETF since 1994. Providing QoSguarantees for individual data streams in IP networks Two key features: Resource reservations... managed by routers establishing soft states, which are refreshed periodically Admission control... can a new connection be established with requested quality without restricting quality aspects of existing connections? Reservation protocol (signalling) for negotiating and refreshing of connection parameters Provides multiple QoS models: Best-effort, Controlled Load, Guaranteed 18
IntServ: QoS Service models [rfc2211, rfc2212] Best Effort Service: No guarantees at all Guaranteed Service: Envisioned for hard real-time applications Guarantees: bandwidth, delay Application specifies traffic parameters (Token Bucket) Net nodes: admission control, policing, reshaping Controlled Load Service: Envisioned for tolerant realtime applications (soft QoS) A quality of service closely approximating the QoS that same flow would receive from an unloaded network element. Queuing delay in routers almost zero Net nodes: admission control, Policing 19
IntServ: Call Setup Process Sender Admission control Traffic (T-spec) & QoS declaration (R-spec) Call setup signalling (RSVP) Per-element admission control QoS-sensitive scheduling (e.g., WFQ) request/ reply Receiver 20
IntServ: Call Admission Arriving session must specify the data flow: declare its QoS requirement R-spec (Reservation characteristics): Defines the QoS being requested: what guarantees are needed? QoS model (best effort, controlled load...) characterize traffic it will send into network T-spec (Traffic descriptor): Defines traffic characteristics: what does the traffic look like? e.g. Token bucket algorithm parameters signalling protocol: needed to carry R-spec and T-spec to routers (where reservation is required) RSVP 21
IntServ: Basic Architecture Architecture elements: Signalling (RSVP) Classifier Admission Control Policy Scheduler Picture by Prof. Schmidt, FH Offenburg 22
IntServ: Problems and Concerns Scalability Signalling and maintenance of connection states in router grows with the number of connections Flexible Service Models IntServ only provides two service classes. More differentiation needed Need for qualitative service classes: Behaves like a wire Relative service distinction like Platinum, Gold or standard credit cards 23
IETF Differentiated Services (DiffServ) Aims at scalable and flexible service differentiation Scalability: DiffServ provides ability to handle different classes of traffic in different ways Flexibility: DiffServ does not define service classes (this up to the network operator) but instead provides functional components to build service classes Two functional elements: Network core provides only simple functions (i.e. forwarding) Edge routers (or hosts) provide more complex functions (i.e. packet classification and traffic conditioning) Domain concept: group of routers implementing policies administratively defined using Service Level Agreements (SLA) 24
DiffServ: Architectural Overview Edge router: Per-flow traffic management Marks packets as in-profile or out-profile Set Differentiated Service Code Points (DSCP) in DiffServ (DS) field to distinguish between traffic classes Core router: Per class traffic management Buffering & scheduling of aggregated data streams based on marking at the edge Assured forwarding based on DSCP specified by PHB * : Preference to in-profile packets Scheduling... SLA DiffServ domain r b Mark 25 * per hop behavior
Edge Router: Packet Marking profile: pre-negotiated rate A, bucket size B packet marking at edge based on per-flow profile Rate A B User packets Possible usage of marking: class-based marking: packets of different classes marked differently intra-class marking: conforming portion of flow marked differently than non-conforming one 26
Edge Router: Packet Marking cont. DS Field 0 4 8 16 19 31 Version HLen TOS Length Identification Flags Fragment offset TTL Protocol Header checksum Source address Destination address IPv4-Header Data DS field uses former Type Of Service (TOS) byte (IPv4) and traffic class (IPv6) 6 bits used for Differentiated Service Code Point (DSCP) and determine per-hop behaviour (PHB) that the packet will receive, i.e. up to 2 6 =64 different traffic classes available 27
Edge Router: Classification and Conditioning May be desirable to limit traffic injection rate of some class: user declares traffic profile (e.g., rate, burst size) traffic metered, i.e. compare incoming traffic flow with negotiated traffic profile, shaped if non-conforming 28
Core Router: Per Hop Behavior (PHB) The per hop behaviour is a description of the externally observable forwarding behaviour of a DiffServ node applied to a particular DiffServ behaviour aggregate. [rfc 2475] PHB is a description of handling one DS stream or a bundle of DS streams PHB does not specify what mechanisms to use to ensure required PHB performance behaviour DSCPs are mapped to PHBs and vice versa. Three PHBs are already defined and standardized: Best effort Expedited Forwarding (Premium Service) [RFC 2598] Assured Forwarding (Assured Service) [RFC 2597] 29
Core Router: Per Hop Behavior (PHB) cont. Expedited Forwarding Also called Premium Service or Virtual Leased Line Service : Pkt departure rate of a class equals a specified rate Provides a class with a link or bundle of links with a minimum guaranteed bandwidth Implies some form of isolation among traffic classes, guarantee is made independently of other traffic class intensities Suitable for real time apps Assured Forwarding Also called Assured Service More complex than EF Four traffic classes, each with three drop preference partitions Each AF class is guaranteed some minimum amount of bandwidth Congestion within an AF class leads to packet discarding based on drop preferences Varying amount of resources allocated to each class to provide different service levels (e.g. golden, silver, bronze) 30
Summarizing DiffServ Simple, efficient model to integrate multiple, flexible services into the Internet Pros Easy to implement in routers Scalable for large networks Cons No guarantees for individual application streams but for application classes If congestion occurs in the core QoS cannot be guaranteed (SLA needed) No signalling, manual configuration required 31
Comparing IntServ & DiffServ I nternet I ntserv/ RSVP DiffServ Guarantees No Per datastream Type of Guarantee Length of Gurantee No Soft, individual Aggregated No I n the short run (per session) Aggregated (per class) I n the long run Signalling No RSVP Not defined yet Per session Configuration No Between domains end-to-end Services Best effort Guaranteed Controlled load Best effort Premium, Assured (high, medium or low priority) 32
Signalling in the Internet connectionless (stateless) forwarding by IP routers + best effort = service no network signaling protocols in initial IP design New requirement: reserve resources along end-to-end path (end system, routers) for QoS for multimedia applications RSVP: Resource Reservation Protocol [RFC 2205] allow users to communicate requirements to network in robust and efficient way. i.e., signaling! Resource = Bandwidth (and router buffers) Receiver oriented simplex protocol, i.e. reserves resources in one direction (receiver sender) 33
RSVP: Resource Reservation Protocol Used to carry and coordinate setup information (e.g., T-spec, R-spec) Reserves resources along a path with the help of a routing protocol Uses IP Transmission over reserved path Reserving through allocating IP-datagrams to IP-addresses and ports Features: Supports multicast Unicast handled as a degenerated case of multicast Heterogeneous receivers Receiver initiated reservation protocol Router establish connection Soft State Supports multiple applications with different levels of QoS requirements 34
RSVP: Actions Senders, receivers join multicast group Functionality not covered by RSVP Sender do not need joining the group Sender network signalling Path message: informs router and receiver involved in communication about the presence of a sender Path teardown: delete sender s state saved in a router Receiver network signalling Reservation message: reserves resources between sender(s) and receivers Reservation teardown: deletes receiver s reservations Network end system signalling Path error Reservation error 35
RSVP: Sender Signalling (Path Message) Sender sends path message containing following information: Sender s description: Sender Template, specifies packet format to be sent Destination address: Unicast or multicast addresses, ports Sender s traffic characteristics: T-spec, token rate, token-bucket depth, peak rate, minimum policed size, maximum packet size Previous Hop: Reverse-path-to-sender routing information (upstream router/host ID) Refresh Time: Time until entry is out of date Sender periodically transmits path messages: Build up multicast tree Refresh (path) states, stored by router 36
RSVP: Simple Audio Conference H1, H2, H3, H4, H5 senders as well as receivers Address: multicast group m1 Forward packets of every sender Audio rate: b Multicast routing tree possible H2 H3 H1 R1 R2 R3 H5 H4 37
RSVP: Building Path States H1,, H5 send all path messages to m1: (address=m1, Tspec=b, refresh=100) Consider that H1 starts to sends a path message m1: in out L1 L2 L6 in m1: out L5 L6 L7 m1: in out L3 L4 L7 H2 H1 L2 L1 R1 L6 R2 L7 R3 L5 L4 L3 H3 H4 H5 38
RSVP: Building Path States cont. Then H5 sends path message, also establishing states stored by router m1: in out L1 L1 L6 L2 L6 m1: in out L5 L5 L6 L6 L7 m1: in out L3 L4 L7 H2 H1 L2 L1 R1 L6 R2 L7 R3 L5 L4 L3 H3 H4 H5 39
RSVP: Building Path States cont. H2, H3, H4 send path message, completing path-state table m1: in out L1 L1 L2 L6 L2 L6 m1: in out L5 L5 L6 L6 L7 L7 m1: in out L3 L3 L4 L4 L7 L7 H2 H1 L2 L1 R1 L6 R2 L7 R3 L5 L4 L3 H3 H4 H5 40
RSVP: Receiver Signalling (Reservation Message) Reservation message contains flow descriptor: Flow Spec: QoS class R-spec (QoS parameter) and T-spec (traffic parameter) Filter Spec: different reservation models, which consider following aspects : Reservation: for one or all senders Set of senders: explicit control of a set of senders Reservation models: No filter: Each packet addressed to the multicast group may use the reservation Fixed filter: Only packets of a specified sender may use the reservation Shared Explicit: Shared use of resources by a specified set of senders Reservation message: Reserves resources along the path specified by R-spec and T-spec from receiver to sender Establishes additional receiver based states in router 41
RSVP: Reservation Example No Filter H1 requests to receive audio from all senders H1 reservation message is delivered to all sender (upstream) H1 reserves enough bandwidth for one audio stream Reservation type: no filter every sender is allowed to use reserved bandwidth. Routers and sender reserve bandwidth b on the way to the receivers m1: in out L1 L1(b) L2 L2 L6 L6 in m1: out L5 L5 L6 L6(b) L7 L7 in m1: out L3 L3 L4 L4 L7 L7(b) H2 H1 b L2 b L1 b b R1 L6 L7 R2 R3 b L5 H5 b L3 b L4 H3 H4 42
RSVP: Reservation Example No Filter Next step: H2 requests no-filter reservation (bandwidth 2b) H2 forwards reservation to R1, R1 forwards to H1 and R2 etc. R2 and R3 mix requirements reservation for peak requirement m1: in out L1 L1(b) L2 L6 L2(2b) L6 in m1: out L5 L5 L6 L7 L6(2b) L7 in m1: out L3 L3 L4 L4 L7 L7(2b) H2 H1 b b L2 b bl1 b b R1 L6 L7 R2 R3 b L5 b L3 b L4 H3 H4 H5 43
Conclusion Best-Effort is no longer good enough for new applications QoS is founded on 4 principles: Classification, Queuing & Signalling, Policing, Admission control Basic techniques and mechanisms: Scheduling: (Prioritized) FIFO, Round Robin, Weighted Fair Queuing Policing: Leaky Bucket, Token Bucket Internet QoS Architectures: IntServ vs. DiffServ RSVP for signalling, i.e. informing nodes about new requirements Coming next: Network Layer Basics 44