QoS (Quality of Service) Chapter 6 Multimedia Networking. MM Networking Applications. Streaming Stored Multimedia

Transcription

1 Cumulative data QoS (Quality of Service) Chapter 6 Multimedia Networkg Multimedia, Quality of Service: What is it? Multimedia applications: network audio and video ( contuous media ) A note on the use of these ppt slides: We re makg these slides freely availale to all (faculty, students, readers). They re powerpot form so you can add, modify, and delete slides (cludg this one) and slide content to suit your needs. They oviously represent a lot of work on our part. In return for use, we only ask the followg: If you use these slides (e.g., a class) sustantially unaltered form, that you mention their source (after all, we d like people to use our ook!) If you post any slides sustantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Thanks and enjoy! JFK / KWR All material copyright J.F Kurose and K.W. Ross, All Rights Reserved Computer Networkg: A Top Down Approach Featurg the Internet, 2 nd edition. Jim Kurose, Keith Ross Addison-Wesley, July QoS network provides application with level of performance needed for application to function. MM Networkg Applications Classes of MM applications: 1) Streamg stored audio and video 2) Streamg live audio and video 3) Real-time teractive audio and video Jitter is the variaility of packet delays with the same packet stream Fundamental characteristics: Typically delay sensitive end-to-end delay delay jitter But loss tolerant: frequent losses cause mor glitches Antithesis of data, which are loss tolerant ut delay tolerant. Streamg Stored Multimedia Streamg: media stored at source transmitted to client streamg: client play egs efore all data has arrived timg constrat for still-to-e transmitted data: time for play Streamg Stored Multimedia: What is it? Streamg Stored Multimedia: Interactivity 1. video recorded 2. video sent network delay 3. video received, played at client time streamg: at this time, client playg early part of video, while server still sendg later part of video VCR-like functionality: client can pause, rewd, FF, push slider ar 10 sec itial delay OK 1-2 sec until command effect OK RTSP often used (more later) timg constrat for still-to-e transmitted data: time for play

2 Examples: Streamg Live Multimedia Internet radio talk show Live sportg event Streamg playack uffer playack can lag tens of seconds after transmission still have timg constrat Interactivity fast forward impossile rewd, pause possile! Interactive, Real-Time Multimedia applications: IP telephony, video conference, distriuted teractive worlds end-end delay requirements: audio: < 150 msec good, < 400 msec OK cludes application-level (packetization) and network delays higher delays noticeale, impair teractivity session itialization how does callee advertise its IP address, port numer, encodg algorithms? Multimedia Over Today s Internet TCP/UDP/IP: est-effort service no guarantees on delay, loss?????? But you said multimedia apps requires QoS and level of performance to e? effective!?? Today s Internet multimedia applications use application-level techniques to mitigate (as est possile) effects of delay, loss?? Improvg QOS IP Networks Thus far: makg the est of est effort Future: next generation Internet with QoS guarantees RSVP: signalg for resource reservations Differentiated Services: differential guarantees Integrated Services: firm guarantees simple model for sharg and congestion studies: Prciples for QOS Guarantees Example: 1MpsI P phone, FTP share 1.5 Mps lk. ursts of FTP can congest rer, cause audio loss want to give priority to audio over FTP Prciples for QOS Guarantees (more) what if applications misehave (audio sends higher than declared rate) policg: force source adherence to andwidth allocations markg and policg at network edge: similar to ATM UNI (User Network Interface) Prciple 1 packet markg needed for rer to distguish etween different classes; and new rer policy to treat packets accordgly Prciple 2 provide protection (isolation) for one class from others

3 Prciples for QOS Guarantees (more) Prciples for QOS Guarantees (more) Allocatg fixed (non-sharale) andwidth to flow: efficient use of andwidth if flows doesn t use its allocation Basic fact of life: can not support traffic demands eyond lk capacity Prciple 3 While providg isolation, it is desirale to use resources as efficiently as possile Prciple 4 Call Admission: flow declares its needs, network may lock call (e.g., usy signal) if it cannot meet needs Summary of QoS Prciples Schedulg And Policg Mechanisms schedulg: choose next packet to send on lk FIFO (first first ) schedulg: send order of arrival to queue real-world example? discard policy: if packet arrives to full queue: who to discard? Tail drop: drop arrivg packet priority: drop/remove on priority asis random: drop/remove randomly Let s next look at mechanisms for achievg this. Schedulg Policies: more Priority schedulg: transmit highest priority queued packet multiple classes, with different priorities class may depend on markg or other header fo, e.g. IP source/dest, port numers, etc.. Real world example? Schedulg Policies: still more round ro schedulg: multiple classes cyclically scan class queues, servg one from each class (if availale) real world example?

4 Schedulg Policies: still more Weighted Fair Queug: generalized Round Ro each class gets weighted amount of service each cycle real-world example? Policg Mechanisms Goal: limit traffic to not exceed declared parameters Three common-used criteria: (Long term) Average Rate: how many pkts can e sent per unit time ( the long run) crucial question: what is the terval length: 100 packets per sec or 6000 packets per m have same average! Peak Rate: e.g., 6000 pkts per m. (ppm) avg.; 1500 ppm peak rate (Max.) Burst Size: max. numer of pkts sent consecutively (with no terveng idle) Policg Mechanisms Token Bucket: limit put to specified Burst Size and Average Rate. Policg Mechanisms (more) token ucket, WFQ come to provide guaranteed upper ound on delay, i.e., QoS guarantee! arrivg traffic token rate, r ucket can hold tokens tokens generated at rate r token/sec unless ucket full over terval of length t: numer of packets admitted less than or equal to (r t + ). ucket size, per-flow rate, R WFQ D = /R max IETF Integrated Services architecture for providg QOS guarantees IP networks for dividual application sessions resource reservation: rers mata state fo (a la VC) of allocated resources, QoS req s admit/deny new call setup requests: Question: can newly arrivg flow e admitted with performance guarantees while not violated QoS guarantees made to already admitted flows? Intserv: QoS guarantee scenario Resource reservation call setup, signalg (RSVP) traffic, QoS declaration per-element admission control QoS-sensitive schedulg (e.g., WFQ) request/ reply

5 Arrivg session must : Call Admission declare its QOS requirement R-spec: defes the QOS eg requested characterize traffic it will send to network T-spec: defes traffic characteristics signalg protocol: needed to carry R-spec and T- spec to rers (where reservation is required) RSVP Intserv QoS: Service models [rfc2211, rfc 2212] Guaranteed service: Controlled load service: worst case traffic arrival: leakyucket-policed source "a quality of service closely approximatg the QoS that simple (mathematically provale) ound on delay [Parekh 1992, Cruz 1988] same flow would receive from an unloaded network element." arrivg traffic token rate, r ucket size, per-flow rate, R WFQ D = /R max IETF Differentiated Services Concerns with Intserv: Scalaility: signalg, matag per-flow rer state difficult with large numer of flows Flexile Service Models: Intserv has only two classes. Also want qualitative service classes ehaves like a wire relative service distction: Platum, Gold, Silver Diffserv approach: simple functions network core, relatively complex functions at edge rers (or hosts) Do t defe defe service classes, provide functional components to uild service classes Diffserv Architecture Edge rer: - per-flow traffic management - marks packets as -profile and -profile Core rer: - per class traffic management - ufferg and schedulg ased on markg at edge - preference given to -profile packets - Assured Forwardg markg r schedulg. Edge-rer Packet Markg profile: pre-negotiated rate A, ucket size B packet markg at edge ased on per-flow profile Rate A B User packets Classification and Conditiong Packet is marked the Type of Service (TOS) IPv4, and Traffic Class IPv6 6 its used for Differentiated Service Code Pot (DSCP) and determe PHB that the packet will receive 2 its are currently unused Possile usage of markg: class-ased markg: packets of different classes marked differently tra-class markg: conformg portion of flow marked differently than non-conformg one

6 Classification and Conditiong may e desirale to limit traffic jection rate of some class: user declares traffic profile (eg, rate, urst size) traffic metered, shaped if non-conformg MPLS (MultiProtocol Lael Switchg) Defed RFC 3031 Different forwardg method Similar to VCs (ATM, FR, etc.) Called also lael switchg, tag switchg New message header (a.k.a tag): 20 its lael 3 its QoS 1 it S (stackg) 8 its TTL Supports aggregation of tags called FEC (forwardg equivalence class) MPLS VC construction Data driven approach: VC is itialized on demand a recursive way Possile prolem of loops Control driven approach: when rer oots it creates laels for the destation its rg tales Signalg the Internet connectionless (stateless) forwardg y IP rers est effort service + = no network signalg protocols itial IP design New requirement: reserve resources along end-to-end path (end system, rers) for QoS for multimedia applications RSVP: Resource Reservation Protocol [RFC 2205] allow users to communicate requirements to network roust and efficient way. i.e., signalg! earlier Internet Signalg protocol: ST-II [RFC 1819] RSVP Design Goals 1. accommodate heterogeneous receivers (different andwidth along paths) 2. accommodate different applications with different resource requirements 3. make multicast a first class service, with adaptation to multicast group memership 4. leverage existg multicast/unicast rg, with adaptation to changes underlyg unicast, multicast res 5. control protocol overhead to grow (at worst) lear # receivers 6. modular design for heterogeneous underlyg technologies RSVP: does not specify how resources are to e reserved rather: a mechanism for communicatg needs determe res packets will take that s the jo of rg protocols signalg decoupled from rg teract with forwardg of packets separation of control (signalg) and data (forwardg) planes

7 RSVP: overview of operation senders, receiver jo a multicast group done side of RSVP senders need not jo group sender-to-network signalg path message: make sender presence known to rers path teardown: delete sender s path state from rers receiver-to-network signalg reservation message: reserve resources from sender(s) to receiver reservation teardown: remove receiver reservations network-to-end-system signalg path error reservation error Path msgs: RSVP sender-to-network signalg path message contents: address: unicast destation, or multicast group flowspec: andwidth requirements spec. filter flag: if yes, record identities of upstream senders (to allow packets filterg y source) previous hop: upstream rer/host ID refresh time: time until this fo times path message: communicates sender fo, and reversepath-to-sender rg fo later upstream forwardg of receiver reservations RSVP: simple audio conference RSVP: uildg up path state,,,, oth senders and receivers multicast group m1 no filterg: packets from any sender forwarded audio rate: only one multicast rg tree possile R1,, all send path messages on (address=m1, Tspec=, filter-spec=no-filter,refresh=100) Suppose sends first path message R1 RSVP: uildg up path state RSVP: uildg up path state next, sends path message, creatg more state rers,, send path msgs, completg path state tales R1 R1

8 reservation msgs: receiver-to-network signalg reservation message contents: desired andwidth: filter type: no filter: any packets address to multicast group can use reservation fixed filter: only packets from specific set of senders can use reservation dynamic filter: senders who s packets can e forwarded across lk will change (y receiver choice) over time. filter spec reservations flow upstream from receiver-to-senders, reservg resources, creatg additional, receiverrelated state at rers RSVP: receiver reservation example 1 wants to receive audio from all other senders reservation msg flows uptree to sources only reserves enough andwidth for 1 audio stream reservation is of type no filter any sender can use reserved andwidth R1 RSVP: receiver reservation example 1 reservation msgs flows uptree to sources rers, hosts reserve andwidth needed on downstream lks towards RSVP: receiver reservation example 1 (more) next, makes no-filter reservation for andwidth forwards to R1, R1 forwards to and (?) takes no action, sce already reserved on () () () () () R1 () R1 () RSVP: receiver reservation: issues What if multiple senders (e.g.,,, ) over lk (e.g., )? aritrary terleavg of packets flow policed y leaky ucket: if ++ sendg rate exceeds, packet loss will occur () () () R1 () RSVP: example 2, are only senders send path messages as efore, dicatg filtered reservation Rers store upstream senders for each upstream lk will want to receive from (only) R1

9 RSVP: example 2, are only senders send path messages as efore, dicatg filtered reservation RSVP: example 2 receiver sends reservation message for source at andwidth propagated upstream towards, reservg, (-via- ; -via- ) (-via- ) (-via- ), (-via- ; -via- ) (-via- ) (-via- ), (-via- ;-via-()) (-via- ) (-via- ), (-via- ; -via- ) (-via-62 ) (-via- ()) R1, (-via- ) (-via-r1 ) R1, (-via- ()) (-via-r1 ) RSVP: soft-state RSVP: soft-state senders periodically resend path msgs to refresh (mata) state receivers periodically resend resv msgs to refresh (mata) state path and resv msgs have TTL field, specifyg refresh terval suppose (sender) leaves with performg teardown eventually state rers will time and disappear!, (-via- ;-via-()) (-via- ) (-via- ), (-via- ; -via- ) (-via-62 ) (-via- ()), (-via- ;-via-()) (-via- ) (-via- ), (-via- ; -via- ) (-via-62 ) (-via- ()) R1, (-via- ()) (-via-r1 ) R1, (-via- ()) (-via-r1 ) gone fishg! The many uses of reservation/path refresh recover from an earlier lost refresh message expected time until refresh received must e longer than time terval! (short timer terval desired) Handle receiver/sender that goes away with teardown Sender/receiver state will time and disappear Reservation refreshes will cause new reservations to e made to a receiver from a sender who has joed sce receivers last reservation refresh E.g., previous example, is only receiver, only sender. Path/reservation messages complete, data flows jos as sender, nothg happens until refreshes reservation, causg to forward reservation to, which allocates andwidth RSVP: reflections multicast as a first class service receiver-oriented reservations use of soft-state