Multimedia Requirements Chapter 2: Representation of Multimedia Data Chapter 3: Multimedia Systems Communication Aspects and Services Multimedia Applications and Transfer/Control Protocols Quality of Service and Resource Management Multimedia Operating Systems Chapter 4: Multimedia Systems Storage Aspects 32: Quality of Service (QoS) and Resource Management QoS Parameters Admission Control Traffic Shaping Scheduling QoS Architectures for the Internet Streaming stored multimedia Media stored at source Transmitted to client Streaming: client playout begins before all data has arrived to avoid long waiting times Timing constraint for still-to-be transmitted data: in time for playout ( jitter) Interactive, Real-Time Multimedia Eg IP telephony (Voice over IP, VoIP), video conference End-to-end delay requirements: Eg audio: < 150 msec good, < 400 msec OK Includes application-level and network delays Higher delays noticeable, impair interactivity Page 1 Page 2 Multimedia and Networks Quality of Service End-to-end delay is limited by the speed of light but also by the intermediate network nodes (routers) Real time communication demands end-to-end delays typically less than 200 msec and jitter Multimedia transmissions have also a maximum loss tolerance (depending on encoding, only loss of a certain fraction of all packets can be tolerated) Data rate of multimedia may change due to the encoding mechanism data rate I-frame peak rate average rate sustainable rate time But in today s networks, neither time guarantees nor capacity guarantees are given Which parameters are important in a multimedia transmission? The most important parameters are: Throughput (bits/s) Which minimum/maximum/average data rate is necessary? Transmission delay (ms) Which maximum delay is tolerable? Jitter (ms) Which fluctuations in the transmission delay are tolerable? Availability (%) With which probability the communication service is available? Different application have different requirements to those parameters Multimedia requires changes in the usual network! Page 3 Page 4
Quality of Service E-Mail File Transfer Web Access Application Remote Login Audio streaming Video streaming IP Telephony Video Conference Reliability Delay Jitter Throughput : requirements to the QoS parameter by the application yel: critical parameters; a certain degree of fulfillment of the application s requirement is needed for good application usage, but problems could be tolerated for a short time red: ly critical parameters; if the requirement is not fulfilled, usage is not possible Keeping the QoS Apply resource management: regard a f of packets as stream, guarantee the enforcement of quality requirements for the stream as a whole Over-provisioning: increased router capacities, buffers and line capacity but this does not give real guarantees Scaling: graceful degradation of the quality, eg skip of more B-frames in a MPEG stream, or reduce color depth/frame rate (maybe adaptation to changes in available network capacity) Buffering: temporary store the data within the receiver Thus the delay is increased, but the jitter is ered (audio/video on demand) To achieve real guarantees, different actions are necessary: QoS Negotiation: reserve and allocate resources (end-to-end) during communication establishment Traffic Shaping: prepare a data stream on sender side in a way that it does not flood the network Packet Scheduling: modify routers in the network to differentiate between different streams; priority is given to multimedia data streams Chapter 35: Quality of Service Page 5 Chapter 35: Quality of Service Page 6 Buffering Buffering Delay vs Loss Rate In streaming, data can arrive with variable rate by network delay and jitter Thus: client-side buffering for playout delay to compensate these problems: from network variable fill rate x(t) constant drain rate d to decompression and playout Receiver attempts to playout each packet exactly p msecs after it was generated Packet has timestamp t: play out packet at t + p Packet arrives after t + p: data arrives too late for playout, data lost r: receiving of first packet p: first playout schedule p : second playout schedule But: how long to buffer the data? buffered video Tradeoff for p: large p: less packet loss small p: better interactive experience Page 7 Page 8
Strategies for Guaranteeing QoS QoS Negotiation and Resource Admission Control Problem with eg buffering: packets can take different ways to the receiver jitter Necessary: establish a path through the network and reserve fixed amounts of network capacity, buffer capacity and CPU time with the routers Requirements (Bandwidth, Delay, ) Jitter User 1 User 3 Network Router User 4 User 2 Standardized by the IETF as Resource Reservation Protocol, RSVP RSVP is one example of a protocol using reservations in a negotiation process to ask for sending admission with QoS guarantees: QoS Negotiation and Admission Control: Can the user requirement be accepted? Should reservations be done? Traffic Shaping: How to avoid that the network becomes overloaded by single users? Scheduling Strategies in the routers: How to handle different connections such that deadlines are satisfied? RSVP is not a routing protocol, but only an addition to such one A description of the requirements of the receiver in form of a f specification (Level of the QoS) is needed Categories of f specification are 1) Best Effort: Take all free resources you can get 2) Rate Sensitive: a guaranteed (minimal) data transmission rate is necessary 3) Delay Sensitive: a guaranteed (maximal) delay is necessary RSVP can be used for Unicast and for Multicast Page 9 Page 10 RSVP Traffic Shaping Procedure of RSVP: The sender sends a RSVP Path Message to the receiver Information about the routers on the network path are being collected and communicated to the receiver (Additionally, also f specifications for the receiver are provided) The receiver sends back RSVP Reservation Messages along the collected path, which contain its f specification Every router on the path reserves resources accordingly If a reservation is not possible with a router, an error message is sent back As soon as the RSVP Reservation Message reaches the sender, the complete path is reserved, the sender begins to send its data To delete outdated reservations, timeouts are defined If the receiver does not refresh its reservation before expiration of the timer, it is deleted Traffic Shaping: Description of the f s characteristics is given to the network provider such that the network knows which traffic is to expect (admission control) Given a description of the f s traffic, the network provider can determine if the f should be aled to send Moreover, the network provider can monitor the traffic of the f and check that the f behaves as promised (monitoring and policing) Traffic sent into the network by a source can be shaped due to the f description Traffic Shaping schemes may be characterized by eg: Aled peak rate Maximum burst size Average rate over a determined interval These parameters may be combined Network Traffic shaping Page 11 Page 12
Traffic Shaping by Leaky Bucket Traffic Shaping by Token Bucket Data (possibly bursty) β ρ steady f Bucket with finite capacity Network Simplest way of traffic shaping: Try to shape all traffic into isochronous fs by a bucket scheme (leaky bucket) The bucket can be emptied with a maximum rate ρ: Data is transmitted uniformly with rate ρ transfer is smoothed Bursts bigger than the bucket capacity β are discarded bounded delay Easy to implement (FIFO + timer) Leaky Bucket generates a steady stream but has limitations for bursty traffic But: peak traffic is not considered Data can be lost, even if sufficient capacity is available in the network Data ρ Token β Bucket Network Variation of the leaky bucket scheme: data may be sent if tokens are available in the bucket Tokens are generated with a certain rate ρ (determined by the network) The generation pauses, if the bucket is full When we are now trying to send a packet of size b tokens (b < β): There are B (0 B β) tokens in the bucket at the time we want to send our packet If B b, then the packet is sent immediately If B < b tokens are available, the packet has to wait for the missing (b-b) tokens Token Bucket permits burstiness but bounds it The long term transmission rate will be bounded by ρ Page 13 Page 14 Token Bucket with Leaky Bucket Scheduling Data ρ Token β β Token Bucket C Leaky Bucket Token bucket has a certain problem: If a f stops for a while, then the token bucket will be full When the f restarts then the network could be monopolized for a while by this f This can be avoided by a combination of token bucket and leaky bucket: The f is regulated by token bucket but smoothed by a subsequent leaky bucket both of size β The leaky bucket is emptied with a rate C C should be substantially larger than ρ since the scheme should be basically a token bucket bursty traffic is permitted but the scheme regulates it The long term average rate is bounded by ρ (< C) Scheduling: determining a sending order of data packets in intermediate nodes (routers) Simple scheduling strategies (eg FIFO) are not suitable for QoS based scheduling because strict performance guarantees are not provided There are different scheduling principles which may provide these guarantees: Weighted Fair Queueing Delay Earliest Due Date (D-EDD) Jitter Earliest Due Date (J-EDD) Rate Controlled Static Priority Differences to simple scheduling strategies: More complex queueing Often time-stamped More complex computation eg of deadlines inputs Router Queues Buffers outputs How to do the scheduling? Page 15 Page 16
Scheduling inside the Network How can we guarantee that the system keeps its promises for the connections even if traffic shaping rules are violated? 1 Nagle s algorithm Router in a network keeps a queue for every connection and serves the connections in a packet-wise round-robin strategy Advantages: Connections which offer too many packets will be punished Easy to implement Disadvantages: A very long packet will be dangerous for others Inconvenient for some traffic patterns (if a packet arrives just after the server was there then the waiting time could become substantial) Thus some modifications were proposed input link 1 router input link k Scheduling inside the Network 2 Bit by Bit Round Robin (fair queueing) One queue per connection (as before) But: bitwise round robin (instead as of packet-wise Round Robin) [assume that the connections would be served bit by bit in a round robin manner; take for transmission the full packet which would have the shortest delivery time if this strategy would be applied; thus a long packet might be interrupted by a newly arriving short packet] 3 Weighted fair queueing Fair queueing gives equal fraction of bandwidth per connection (1/n of total bandwidth if n connections are active) But in some cases we would like to give more bandwidth to connections with data rate, thus Divide the bandwidth into cycles of m bits (where m > n = number of active connections) One bit (at least) per cycle is allocated to each connection Allocate the m - n extra bits by some strategy to the connections with er need Page 17 Page 18 Scheduling - Weighted Fair Queueing Scheduling - Weighted Fair Queueing (β 1, ρ 1 ) (β 2, ρ 2 ) (β 3, ρ 3 ) A separate queue per connection Round Robin strategy fairness is provided Queueing delay of connection i is bounded by: hi ( ) β h 1 l l + + i i i a D i, where gi gi m= 1rm Proof of delay bound: D i β hi ( ) h 1 l l i i i a + + gi gi m= 1rm (*) (**) (***) (β 4, ρ 4 ) (β 5, ρ 5 ) (β 6, ρ 6 ) (β 7, ρ 7 ) (β 8, ρ 8 ) r i i denotes the connection number (or f number) D i denotes the delay of f i β i denotes the token bucket size g i denotes the weighted f rate (g i ρ i ) l i denotes the maximum packet size of f i l a denotes the maximum packet size of the network h i denotes the total number of hops of f i r m denotes the outbound bandwidth at hop m Page 19 (*) Delay if each router in the network is fully loaded; in this case the token bucket size β i is served with a rate g i (g i ρ i ) This lasts β i / g i seconds (**) Somewhat mysterious term: delay due to packetization effects (***) A packet may be delayed (in each hop) by l a bit times (l a = maximum packet length) Since hop m serves with rate r m this needs l a /r m seconds Page 20
Scheduling - Weighted Fair Queueing Example: conn 1 conn 2 Let: The link bandwidth r 1 = r 2 = r 3 = 155 Mbit/s (ATM speed) The maximum packet size of each f and of the network l 1 = l 2 = l a = 424 Bit (ATM cell) The weighted f rate g 1 = ρ 1 = 100 Mbit/s and g 2 = ρ 2 = 50 Mbit/s The token bucket size β 1 = β 2 = 1 Mbit F 1 is transmitted over 3 hops (h 1 = 3), f 2 over 2 hops (h 2 = 2) The delay bounds are β ( h1 1 1 ) l1 la D1 + + 3 = 10,0166 ms g g r 1 1 1 r 1 conn 1 conn 2 r 2 ( ) conn 1 β h 1 l l 2 2 2 a D2 + + 2 = 20,01395 ms g2 g2 r1 dominating term (in this example!) r 3 Page 21 Scheduling - Weighted Fair Queueing Implementation Issues: Queueing: Per-Connection-Queueing: needs more complex buffer management Granularity of Queueing: depends on network, eg cell in ATM, byte in packet switched networks, bits in our example Scheduling: Granularity of weights: unit of the weighted f g i? Depends on granularity of queueing! Strategy is non work-conserving: needs timer control if the bandwidth is not completely allocated Advantage: Deterministic delay bounds Disadvantage: Difficult implementation Page 22 Scheduling - Delay Earliest Due Date (D-EDD) Scheduling - Rate Controlled Servers FIFO-ordered time ordered reordering packet with shortest deadline is first in the queue Incoming packets are timestamped Deadline is computed according to average rate or peak rate The new packet is inserted in calendar (time ordered) queue Scheduler serves packet with deadline same as actual serving time non-workconserving discipline D-EDD provides deterministic delay bound with granularity bounded by the timer granularity! Channel 1 Channel 2 Channel n rate controllers bounded delay server To renew the traffic characteristics, in every node of the network rate controllers are added A rate controller may regulate delay jitter (variation of delay) rate jitter (variation of rate) Packets are hold by a defined eligibility time before scheduled by the bounded delay server timestamp ordering additional complexity local delays can be computed according to the traffic characteristics at the entrance of the network buffer space required is distributed to the nodes along the network path Page 23 Page 24
Scheduling - Rate Controlled Static Priority Channel 1 Channel 2 Channel m m rate controllers n FCFS servers Each channel has its own rate controller Delayed packet is inserted in FCFS queues FCFS queues are served with priorities (non-preemptive) n delay bounds are supported computation depends on traffic specification Scheduler is non work-conserving; a first implementation in hardware exists Scheduling - Jitter Earliest Due Date (J-EDD) Channel 1 Channel 2 Channel m m rate controllers In the J-EDD scheme each channel has its own rate controller The difference between the deadline and actual finishing time at current server is carried in a packet This difference is the time the packet is hold back in the regulator of the foling node (ie next hop compensates jitter of previous hop) The deadline in time-ordered queue is computed similar to D-EDD J-EDD provides bounds for local delay and local delay jitter needs additional timestamp field in packet header Page 25 Page 26 Scheduling - Jitter Earliest Due Date QoS in the Internet: Integrated Services A hop has : a queueing budget b a jitter bound j Transmission of a packet may be started at any time in the interval [b - j : b] If the packet is started at time b - τ (ie τ seconds early) then in the next hop τ will be added to the budget of the next hop, ie the transmission in the next hop will be scheduled in the interval [b - j : b ] where b = τ + b Global jitter is limited Technical problem: The actual value τ has to be filled in into the packet s header 1995-1997 standardized by the IETF as an architecture for the transmission of multimedia streams Integrated Services (IntServ) uses RSVP for signaling of f specifications as well as reservations and provides QoS for each data f individually Thus the principle adds a connection-orientation to IP Page 27 Page 28
Integrated Services Classes of QoS: Guaranteed: Data rate, delay and reliability are guaranteed Deviations do not occur, packets are not discarded Suitable for intolerant real-time applications Controlled Load: weak guarantees, small deviations are possible Principle: for data streams of this class the network behaves as best effort for an unloaded network No guarantees are given, suitable for tolerant real-time applications Best Effort: as good as possible, normal Internet traffic Problems: Scalability: for each data f a router has to maintain own f specifications How can authorization and priority be treated for a reservation request? The QoS classes are not sufficient to differentiate reasonably between different types of data streams Possible: use IntServ only at the edge of large networks, where only few data fs are present Page 29 IntServ Router Data RSVP signaling Routing Agent Packet Classifier Reservation Setup Agent (RSVP) Packet Scheduler Packet Classifier: classifies incoming packets regarding QoS class Packet Scheduler: sorts packets regarding basing on QoS class Reservation Setup Agent: configures Packet Classifier and Scheduler for new connections RSVP signaling Policy Control Admission Control Data Routing Agent: instructs classifier about routes for data streams Policy Control: checks the permission for resource reservations Admission Control: decides if a new reservation can be accepted based on resources already used Page 30 QoS in the Internet: Differentiated Services Class-based approach (Differentiated Services, DiffServ): do without guarantees, only manage aggregated data streams Thus, the complexity in routers is shifted at the edge of the network, internal network routers can be kept simpler Divide the network into domains A domain is a part of the entire network, which supports DiffServ It consists of access routers for the domain (Ingress routers, yel) and internal routers (core routers, blue) The domain defines service classes, each data f is assigned to such a class With coming into the domain (at a Ingress Router), each packet is assigned a class, and in the network the forwarding bases on the class parameters (per-hop behavior) Looking only at the aggregated data fs, a better scalability as for IntServ is achieved Page 31 Application of DiffServ with IP Use of the Type of Service field in IPv4 for the classification (DSCP Differentiated Service Code Point) The DSCP value defines the per-hop behavior of the packet from one router to the next one Version IHL Time to Live Identification Type of Service Protocol D M F F Source Address Destination Address Total Length Fragment Offset Header Checksum Precedence DSCP D T R free The code point defines the transmission class, which informs a router, how it has to treat the packet in forwarding free Page 32
Service Classes DSCP free For DiffServ, amongst others the foling classes (for specifying transmission behavior) are defined at the moment: Default Forwarding realizes the usual Best Effort transmission Expedited Forwarding Idea with Expedited Forwarding: there are regular and expedited packets Expedited packets are passed on in such a way, as if there would be no or only little further traffic A minimum data transmission rate is guaranteed Routers can manage two separated queues for these packet types (Weighted Fair Queuing) Possible: loss rate/delay/jitter as well as a guaranteed data transmission rate Expedited Forwarding tries to emulate a rented line Assured Forwarding uses priorities and discarding probabilities used when an overload of a router is given Page 33 Page 34 Assured Forwarding Assured Forwarding Improves differentiation: Definition of four priority classes with own resources (at the moment; there also is room for more classes) For each class, three probabilities for discarding a packet are defined:,, Thus: altogether 12 different service classes Principle: The priority class determines the portion of the transmission capacity of the routers During load packets of er priority would be discarded completely Fairness: packets of each priority class should have chances to survive Therefore definition of the probabilities for each class: by suitable selection of the probabilities, a small part of the est priority level still is still forwarded, while packets of er priority classes are already discarded 1 Classification of the packets in service classes 2 Appropriate choice of DSCP tags 4 Weighted Fair Queuing in accordance to priority classes 3 Bring the data streams in a form according to their f specification Exceeding the specifications leads to discarding data If thereafter still too much data are present, discarding of packets in accordance with their probability Page 35 Page 36
Current Trends in the Internet Today, there are some efforts to bring QoS into the network layer, using the presented principles like RSVP, scheduling, IPv6 Als for treating data streams, maybe assigned with QoS requirements But: will it ever come? Integrated Services Use of RSVP for setting up routes with guaranteed QoS But: not usable for er number of data fs; scalability problems! Differentiated Services Aggregation of data streams with similar characteristics to be scalable But: details of the approach are still not worked out MPLS Adding f labels to protocols like IP to establish paths through the network But: also not full developed in the details Still a long way to really introduce QoS into the networks! Page 37