1. CS 414 - Spring 2012 CS 414 – Multimedia Systems Design Lecture 18 – Multimedia Transport Subsystem (Part 3) Klara Nahrstedt Spring 2012

2. CS 414 - Spring 2012 HW1 due March 1 Midterm: MONDAY, March 5, 11-11:50 in class Midterm: 1 side of cheat-sheet + calculator Midterm Material:  MP1 Question(s) (see TA’s lecture on MP1)  until Friday, February 24, Lectures 1-16  Multimedia Coding and Content Processing Book Chapter 2, 3, 5, 7  Multimedia Systems Book Chapter 2 Administrative

3. Covered Aspects of Multimedia Image/Video Capture Media Server Storage Transmission Compression Processing Audio/Video Presentation Playback Audio/Video Perception/ Playback Audio Information Representation Transmission Audio Capture A/V Playback Image/Video Information Representation

4. Multimedia Transmission Networks CS 414 - Spring 2012

5. What we will talk today Establishment Phase  Negotiation, Translation  Admission, Reservation Transmission Phase  Traffic Shaping Stream Shapes – Strongly/Weakly Regular, Strongly/Weakly Periodic, Asynchronous, Synchronous, Isochronous Streams Isochronous Traffic Shaping – Leaky Bucket Shaping Bursty Traffic – Token Bucket  Rate Control  Error Control CS 414 - Spring 2012

6. CLASSIFICATION, MARKING AND TRAFFIC SHAPING CS 414 - Spring 2012

7. Limitations of Isochronous Traffic Shaping In case of (r,T)-smooth traffic shaping, one cannot send packet larger than r bits long, i.e., unless T is very long, the maximum packet size may be very small. The range of behaviors is limited to fixed rate flows Variable flows must request data rate equal to peak rate which is wasteful CS 414 - Spring 2012

8. Isochronous Traffic Shaping with Priorities Idea: if a flow exceeds its rate, excess packets are given lower priority If network is heavily loaded, packets will be preferentially dropped Decision place to assign priority  At the sender – Classification and Marking Application classifies and marks its own packets since application knows best which packets are less important  In the network (policing) Network marks overflow packets with lower priority CS 414 - Spring 2012

9. Shaping Bursty Traffic Patterns (Token Bucket) CS 414 - Spring 2012

10. Token Bucket The effect of TB is different than Leaky Bucket (LB) Consider sending packet of size b tokens (b<β):  Token bucket is full – packet is sent and b tokens are removed from bucket  Token bucket is empty – packet must wait until b tokens drip into bucket, at which time it is sent  Bucket is partially full – let’s consider B tokens in bucket; if b ≤ B then packet is sent immediately, Else wait for remaining b-B tokens before being sent. CS 414 - Spring 2012

11. Comparison between TB and LB Token BucketSimple Leaky Bucket TB permits burstiness, but bounds itLB forces bursty traffic to smooth out Burstiness is bounded as follows: - Flow never sends more than β+τ*ρ tokens worth of data in interval τ and - Long-term transmission rate will not exceed ρ Flow never sends faster than ρ worth of packets per second TB does not have discard or priority policy LB has priority policy TB more flexibleLB is rigid TB is easy to implement -Each flow needs counter to count tokens, - each flow needs timer to determine when to add new tokens to the counter LB is easy to implement CS 414 - Spring 2012

12. Token Bucket Limitation Difficulty with policing  At any time the flow is allowed to exceed rate by number of tokens Reasoning  At any period of time, flow is allowed to exceed rate ρ by β tokens  If network tries to police flows by simply measuring their traffic over intervals of length τ, flow can cheat by sending β+τ*ρ tokens of data in every interval.  Flow can send data equal to 2β+2τ*ρ tokens in the interval 2τ and it is supposed to send at most β+2τ*ρ tokens worth of data CS 414 - Spring 2012

13. Token Bucket with Leaky Bucket Rate Control TB allows for long bursts and if the bursts are of high-priority traffic, they may interfere with other high-priority traffic Need to limit how long a token bucket sender can monopolize network CS 414 - Spring 2012

14. Composite Shaper CS 414 - Spring 2012

15. Composite Shaper Combination of token bucket with leaky bucket Good policing  But remains hard, although confirming that the flow’s data rate does not exceed C is easy More complexity for implementation  Each flow requires two counters and two timers (one timer and one counter for each bucket) CS 414 - Spring 2012

16. QUEUING CS 414 - Spring 2012

17. Queuing and Queue Management Every traffic management needs QUEUE MANAGEMENT (QM) Statistical versus Deterministic Guarantees Conservation of Work  QM schemes differentiate if they are work conserving or not  Work conserving system – sends packet once the server has completed service (examples – FIFO, LIFO)  Non-work conserving scheme – server waits random amount of time before serving the next packet in queue, even if packets are waiting in the queue CS 414 - Spring 2012

18. Rate Control Multimedia networks use rate-based mechanisms (conventional networks use window-based flow control and FIFO) CS 414 - Spring 2012 Work-conserving schemesNon-work-conserving schemes Fair QueuingJitter Earliest-Due-Date Virtual ClockStop-and-Go Delay Earliest-Due-DataHierarchical Round-Robin

19. Earliest Due Date (EDD) [Ferrari] Based on Earliest Deadline First Scheduling Policy EDD works for periodic message models  Packet has end-to-end deadline D i EDD partitions end-to-end deadline D i into local deadlines D i,k during connection establishment procedure CS 414 - Spring 2012

20. Delay EDD Upon arrival of Packet j of connection i:  Determine effective arrival time: a e i,j = max(a e i,j-1 + p i, a i,j )  Stamp packet with local deadline: d i,j = a e i,j + D i,k  Process packets in EDF order Delay EDD is greedy Problem with EDD: jitter CS 414 - Spring 2012

21. Weighted Fair Queuing CS 414 - Spring 2012

22. Weighted Fair Queuing CS 414 - Spring 2012

23. WFQ vs FQ Both in WFQ and FQ, each data flow has a separate FIFO queue.FIFO In FQ, with a link data rate of R, at any given time the N active data flows (the ones with non-empty queues) are serviced simultaneously, each at an average data rate of R / N.  Since each data flow has its own queue, an ill-behaved flow (who has sent larger packets or more packets per second than the others since it became active) will only punish itself and not other sessions. WFQ allows different sessions to have different service shares. If N data flows currently are active, with weights w 1,w 2...w N, data flow number i will achieve an average data rate of R * w i /(w 1 +w 2 +…+w n ) CS 414 - Spring 2012

24. Class-based WFQ CS 414 - Spring 2012 PQ – Priority Queue

25. Comparison between WFQ and Jitter Control WFQ guarantees packet delay less than a given value D, but as long as delay is within bound it does not guarantee what the delay will be Example: send packet at time t0 over a path whose minimum delay is d  WFQ guarantees that packet arrives no later than t0+d, but packets can arrive any time t0+ x between [t0+d, t0+D].  x is jitter CS 414 - Spring 2012

26. Jitter Control Non-Work- Conserving Schemes CS 414 - Spring 2012

27. Implementation of Stop-and-Go CS 414 - Spring 2012

28. Jitter-EDD Delay-EDD: does not control jitter. This has effect on buffer requirements. Jitter-EDD is non-greedy. Jitter-EDD maintains Ahead Time ah i,j, which is the difference between local relative deadline D i,k-1 and actual delay at switch k-1. Ahead time is stored in packet header Upon receiving j-th packet of connection i with ah i,j at time a i,j :  Calculate ready time at switch k: a e i,j =max(a e i,j-1 + p i, a i,j ) r i,j = max(a e i,j, a i,j + ah i,j )  Stamp packet with deadline d i,j =r i,j +D i,k and process according to EDF starting from ready time r i,j. CS 414 - Spring 2012

29. ERROR CONTROL: AVOIDANCE, DETECTION, CORRECTION CS 414 - Spring 2012

30. Congestion Avoidance via Random Early Drop (Active Queue Management) RED = Random Early Drop Refined RED based on IP packet preference is Weighted RED (WRED)

31. Error Detection Ability to detect the presence of errors caused by noise or other impairments during transmission from sender to receiver  Traditional mechanisms: check-summing, PDU sequencing Checksum of a message is an arithmetic sum of message code words of a certain word length (e.g., byte) CRC – Cyclic Redundancy Check – function that takes as input a data stream of any length and produces as output a value (commonly a 32- bit integer) – can be used as a checksum to detect accidental alteration of data during transmission or storage  Multimedia mechanisms: byte error detection at application PDU, time detection

32. Design of Error Correction Codes Automatic repeat-request (ARQ)  Transmitter sends the data and also an error detection code, which the receiver uses to check for errors, and requests retransmission for erroneous data  The receiver sends ACK (acknowledgement of correctly received data) Forward Error Correction (FEC)  Transmitted encodes the data with an error-correcting code (ECC) and sends the coded msg. No ACK exists. CS 414 - Spring 2012

33. Error Control Error Correction  Traditional mechanisms: retransmission using acknowledgement schemes, window-based flow control  Multimedia mechanisms: Go-back-N Retransmission Selective retransmission Partially reliable streams Forward error correction Priority channel coding Slack Automatic Repeat Request CS 414 - Spring 2012

34. Go-back-N Retransmission CS 414 - Spring 2012

35. Jitter Control in Slack Automatic Repeat Request Scheme CS 414 - Spring 2012

36. Conclusion Establishment Phase  Negotiation, Translation  Admission, Reservation Transmission Phase  Traffic Shaping Isochronous Traffic Shaping Shaping Bursty Traffic  Rate Control  Error Control Next: Case Studies of Multimedia Protocols CS 414 - Spring 2012