1 Summary of QoS Principles Scheduling And Policing Mechanisms - PDF document

Multimedia Networking Improving QOS in IP Networks Last time Principles Thus far: “making the best of best effort” � Classify multimedia � Multimedia Networking Applications Future: next generation Internet with QoS guarantees applications � Streaming stored audio and video � Identify the network � RSVP: signaling for resource reservations � Real-time Multimedia: Internet Phone services the apps study � Differentiated Services: differential guarantees need � Protocols for Real-Time Interactive � Making the best of � Integrated Services: firm guarantees Applications - RTP,RTCP,SIP best effort service � simple model � Distributing Multimedia: content � Mechanisms for for sharing and providing QoS distribution networks congestion Protocols and Today Architectures studies: � Beyond Best Effort � Specific protocols � Scheduling and Policing Mechanisms for best-effort � Integrated Services and � Architectures for Differentiated Services QoS � RSVP 16/5-05 Datakommunikation - Jonny Pettersson, UmU 1 16/5-05 Datakommunikation - Jonny Pettersson, UmU 2 Principles for QOS Guarantees Principles for QOS Guarantees (more) � Example: 1Mbps IP phone, FTP share 1.5 Mbps link. � what if applications misbehave (audio sends higher � bursts of FTP can congest router, cause audio loss than declared rate) � want to give priority to audio over FTP � policing: force source adherence to bandwidth allocations � marking and policing at network edge: Principle 1 packet marking needed for router to distinguish Principle 2 between different classes; and new router policy provide protection ( isolation ) for one class from others to treat packets accordingly 16/5-05 Datakommunikation - Jonny Pettersson, UmU 3 16/5-05 Datakommunikation - Jonny Pettersson, UmU 4 Principles for QOS Guarantees Principles for QOS Guarantees (more) (more) � Allocating fixed (non-sharable) bandwidth to flow: � Basic fact of life: can not support traffic demands inefficient use of bandwidth if flows doesn’t use beyond link capacity its allocation Principle 3 Principle 4 Call Admission: flow declares its needs, network may While providing isolation, it is desirable to use block call (e.g., busy signal) if it cannot meet needs resources as efficiently as possible 16/5-05 16/5-05 Datakommunikation - Jonny Pettersson, UmU 5 Datakommunikation - Jonny Pettersson, UmU 6 1

Summary of QoS Principles Scheduling And Policing Mechanisms � scheduling: choose next packet to send on link � FIFO (first in first out) scheduling: send in order of arrival to queue � real-world example? � discard policy: if packet arrives to full queue: who to discard? • Tail drop: drop arriving packet • priority: drop/remove on priority basis • random: drop/remove randomly Let’s next look at mechanisms for achieving this …. 16/5-05 Datakommunikation - Jonny Pettersson, UmU 7 16/5-05 Datakommunikation - Jonny Pettersson, UmU 8 Scheduling Policies: more Scheduling Policies: still more round robin scheduling: Priority scheduling: transmit highest priority queued packet � multiple classes � multiple classes , with different priorities � cyclically scan class queues, serving one from each class (if available) � class may depend on marking or other header info, e.g. IP source/dest, port numbers, etc.. � real world example? � Real world example? 16/5-05 Datakommunikation - Jonny Pettersson, UmU 9 16/5-05 Datakommunikation - Jonny Pettersson, UmU 10 Scheduling Policies: still more Policing Mechanisms Weighted Fair Queuing: Goal: limit traffic to not exceed declared parameters � generalized Round Robin Three common-used criteria: � (Long term) Average Rate: how many pkts can be sent � each class gets weighted amount of service per unit time (in the long run) in each cycle � crucial question: what is the interval length: 100 packets per � real-world example? sec or 6000 packets per min have same average! � Peak Rate: e.g., 1500 pkts per min. (ppm) avg.; 6000 ppm peak rate � (Max.) Burst Size: max. number of pkts sent consecutively (with no intervening idle) 16/5-05 16/5-05 Datakommunikation - Jonny Pettersson, UmU 11 Datakommunikation - Jonny Pettersson, UmU 12 2

Policing Mechanisms Policing Mechanisms (more) Token Bucket: limit input to specified Burst Size � token bucket, WFQ combine to provide and Average Rate. guaranteed upper bound on delay, i.e., QoS guarantee ! arriving token rate, r traffic bucket size, b per-flow � bucket can hold b tokens rate, R � tokens generated at rate r token/sec unless bucket WFQ full � over interval of length t: number of packets admitted less than or equal to (r t + b). 16/5-05 Datakommunikation - Jonny Pettersson, UmU 13 16/5-05 Datakommunikation - Jonny Pettersson, UmU 14 Intserv: QoS guarantee scenario IETF Integrated Services � Resource reservation � architecture for providing QOS guarantees in IP � call setup, signaling (RSVP) networks for individual application sessions � traffic, QoS declaration � resource reservation: routers maintain state info � per-element admission control (a la VC) of allocated resources, QoS req’s � admit/deny new call setup requests: request/ reply Question: can newly arriving flow be admitted with performance guarantees while not violated � QoS-sensitive QoS guarantees made to already admitted flows? scheduling (e.g., WFQ) 16/5-05 Datakommunikation - Jonny Pettersson, UmU 15 16/5-05 Datakommunikation - Jonny Pettersson, UmU 16 Intserv QoS: Service models Call Admission [rfc2211, rfc 2212] Guaranteed service: Controlled load service: Arriving session must : � worst case traffic arrival: � "a quality of service closely leaky-bucket-policed source approximating the QoS that � declare its QOS requirement same flow would receive � simple (mathematically from an unloaded network � R-spec: defines the QOS being requested provable) bound on delay element." [Parekh 1992, Cruz 1988] � characterize traffic it will send into network arriving token rate, r � T-spec: defines traffic characteristics traffic � signaling protocol: needed to carry R-spec and T- bucket size, b spec to routers (where reservation is required) per-flow � RSVP rate, R WFQ 16/5-05 16/5-05 Datakommunikation - Jonny Pettersson, UmU 17 Datakommunikation - Jonny Pettersson, UmU 18 3

Diffserv Architecture IETF Differentiated Services Concerns with Intserv: Edge router: marking � Scalability: signaling, maintaining per-flow router r scheduling � per-flow traffic management state difficult with large number of flows � marks packets as in-profile � Flexible Service Models: Intserv has only two b and out-profile . classes. Also want “qualitative” service classes . . � “behaves like a wire” � relative service distinction: Platinum, Gold, Silver Core router: Diffserv approach: � per class traffic management � simple functions in network core, relatively complex functions at edge routers (or hosts) � buffering and scheduling based on marking at edge � don’t define service classes, provide functional � preference given to in-profile components to build service classes packets 16/5-05 Datakommunikation - Jonny Pettersson, UmU 19 16/5-05 Datakommunikation - Jonny Pettersson, UmU 20 Signaling in the Internet RSVP Design Goals accommodate heterogeneous receivers (different 1. no network connectionless bandwidth along paths) signaling protocols best effort (stateless) + = accommodate different applications with different 2. service forwarding by IP in initial IP resource requirements design routers make multicast a first class service, with adaptation 3. to multicast group membership � New requirement: reserve resources along end-to-end path (end system, routers) for QoS for multimedia leverage existing multicast/unicast routing, with 4. adaptation to changes in underlying unicast, applications multicast routes � RSVP: Resource Reservation Protocol [RFC 2205] control protocol overhead to grow (at worst) linear 5. � “ … allow users to communicate requirements to network in in # receivers robust and efficient way.” i.e., signaling ! modular design for heterogeneous underlying 6. � earlier Internet Signaling protocol: ST-II [RFC 1819] technologies 16/5-05 Datakommunikation - Jonny Pettersson, UmU 21 16/5-05 Datakommunikation - Jonny Pettersson, UmU 22 RSVP: does not… RSVP: overview of operation � senders, receiver join a multicast group � specify how resources are to be reserved � senders need not join group � rather: a mechanism for communicating � done outside of RSVP needs � sender-to-network signaling � path message: make sender presence known to routers � determine routes packets will take � path teardown: delete sender’s path state from routers � that’s the job of routing protocols � receiver-to-network signaling � reservation message: reserve resources from sender(s) to � signaling decoupled from routing receiver � interact with forwarding of packets � reservation teardown: remove receiver reservations � network-to-end-system signaling � separation of control (signaling) and data � path error (forwarding) planes � reservation error 16/5-05 16/5-05 Datakommunikation - Jonny Pettersson, UmU 23 Datakommunikation - Jonny Pettersson, UmU 24 4