CS Spring 2014 CS 414 – Multimedia Systems Design Lecture 18 – Multimedia Transport (Part 1) Klara Nahrstedt Spring 2014

CS Spring 2014 Administrative HW1 on – due March 11:59pm Midterm – March 7 in class

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 CS Spring 2014

Summary: Quality of Service (Service Classes and Translation/Negotiation of Parameters) CS Spring 2014 Network MM Application OS/DS/Network MM Application OS/DS/Network Sender YouTube Server Receiver – YouTube Client Translation Logical Negotiation of Network QoS Parameters Physical Transmission of Negotiation Parameters Logical Negotiation of Application QoS Parameters AT&T

Overview - Multimedia Transport Requirements of transport subsystems  User requirements on Multimedia Transport  Translation of user requirements into QoS QoS requirements on multimedia transport QoS and Resource Management  Connection Establishment  Data Transmission over established connection CS Spring 2014

User Requirements on Transport Subsystems High Data Throughput – need to support application data with stream-like behavior and in real time Fast data forwarding – the faster the transport system can move packets the fewer packets have to be buffered Service Guarantees – need appropriate resource management CS Spring 2014

QoS Requirements on Transport Subsystems Audio/video communication needs to be bounded by deadlines End-to-end jitter must be bounded End-to-end guarantees are required Synchronization mechanisms for different data streams are required Variable bit rate traffic support is required Services and protocols should make sure that no starvation occurs CS Spring 2014

Connection Establishment QoS parameters:  End-to-end delay, jitter, throughput, packet loss rate Establishment Protocol to establish Multimedia Call: 1. Application/user defines QoS parameters (e.g., video stream parameters) 2. QoS parameters are distributed and negotiated among participating parties 3. QoS parameters are translated between different layers 4. QoS parameters are mapped to resource requirements 5. Required resources are admitted, reserved and allocated along the path between sender and receiver(s) CS Spring 2014

Negotiation and Translation For negotiation of QoS we may use  Peer-to-peer negotiation and triangular negotiation (if service provider allows for negotiation) Translation between network and application QoS CS Spring 2014

Negotiation Protocol (P2P Receiver-Initiated Negotiation – Example1) CS Spring 2014 Sender (Server) Receiver (Client) time 0 0 Setup Socket Communication Send User/Receiver requested QoS (video rate 20fps) Wait Requested Video rate (e.g.,20fps) Wait Setup Socket Communication - Receive Requested rate -Check with Recorded rate -If requested > recorded Then decrease rate, else O.K. -Translate QoS param. -Perform Resource Admission/Reservation If admission O.K, else Decrease rate, redo Admission/reservation - Send resulting rate Resulting video rate (e.g.,10 fps) - Receive resulting rate -Translate QoS param. -Perform admission, If admission O.K,, then Reserve resources, else Decrease resulting rate - Send agreed/final rate Wait Final video rate (5 fps) -Receive final rate - Adjust reservation -Start streaming Streaming Data at final rate Wait

Negotiation Protocol (P2P Receiver-Initiated Negotiation – Example2) CS Spring 2014 Sender (Server) Receiver (Client) time 0 0 Setup Socket Communication -Get QoS (video rate) from user - Translate QoS - Perform admission, if admission O.K., then reserve local resources, else decrease requested rate, redo admission/reservation Wait Requested Video rate (e.g.,20fps) Wait Setup Socket Communication - Receive Requested rate -Check with Recorded rate -If requested > recorded Then decrease rate, else O.K. -Translate QoS param. -Perform Resource Admission/Reservation If admission O.K, else Decrease rate, redo Admission/reservation -Send resulting rate -Start streaming Resulting video rate (e.g.,10 fps) - Receive resulting rate -Translate QoS param. -Adjust reservation if needed - Start receiving steam Streaming Data at resulting rate

Negotiation Protocol (P2P Sender-Initiated Negotiation - Example) CS Spring 2014 Sender (Server) Receiver (Client) time 0 0 Setup Socket Comm, get movie name -Get recorded rate as the requested rate from the recorded video file -Perform admission, if admission O.K, reserve resources, else decrease rate - Send requested QoS (video rate 20fps) Wait Requested Video rate (e.g.,25ps) Setup Socket Communication (also send server requested video file/movie name) - Receive requested rate -Translate QoS param. -Perform admission, If admission O.K,, then Reserve resources, else Decrease rate - Send agreed/final rate Wait Final video rate (20 fps) -Receive final rate - Adjust reservation -Start streaming Streaming Data at final rate Wait

Example of Translation Consider application QoS (frame size M A, frame rate R A ) and network QoS (throughput B N, packet rate R N ) Assume  M A = (320x240 pixels, 1 pixel = 8 bits),  R A = 10 fps, packet size  M N = 4KBytes Application Throughput:  B A = M A x R A = (320 x 240 x 8) x 10 = 6,144,000 bps Packet rate:  = 190 packets per second Network Throughput:  B N = M N x R N = 6,225,920 bps CS Spring 2014

Bandwidth Admission Test Consider  b i – reserved bandwidth for the ‘i’ connection  B max – maximal bandwidth at the network interface Admission test (if all connections declare their bandwidth requirements b i at the same time):  ∑ (i=1,…n) b i ≤ B max CS Spring 2014

Bandwidth Admission Admission Test (if requests come in iterative fashion) : Consider  b i alloc – bandwidth already admitted, allocated and promised to connection ‘i’  b j req – bandwidth requested by connection ‘j’  B avail = B max - ∑ (i=1,..n) b i alloc, where i ≠ j Admission Test:  b j req ≤ B avail CS Spring 2014

Packet/Frame Scheduling Admission At switches/routers/end systems we have queues Need packet scheduling decision to be made when admitting new streams of packets Need packet schedulability tests  Note that in networking only NON- PREEMPTIVE scheduling exists!!! CS Spring 2014

Packet Scheduling Admission CS Spring 2014 e i – processing of a packet ‘i’ in network node Admission Test: e i ≤ deadline (within a switch) ∑ (i=1,…,n) serve i / (1/r) ≤ 1 serve – packet service time at the processors – constant time due to hardware implementation q_in and q_out are queuing times q = N/λ (Little Theorem) r – service rate of the switch

Resource Reservation/Allocation Bandwidth reservation  Pessimistic reservation with maximal bandwidth allocation: Given (M N, R A, and M A ) if then CS Spring 2014

Pessimistic Resource Reservation (Example) Example: Consider sequence of MPEG video frames of size 80KB, 60 KB, 20KB, 20 KB, 60KB, 20 KB, 20 KB (Group of Pictures I, P, B, B, P, B, B ), Pessimistic frame size calculation:  M A = max(80, 60, 20, 20, 60, 20, 20) = 80KB Given video frame rate RA = 20 fps If Given MN = 10 KB (network packet size, e.g., packet size for the transport layer like TCP/UDP), then need to consider bandwidth/ throughput reservation for  BN = 10KB x (8 network packets per application frame) x 20 application frames per second= 1600 KB/second = Kbps CS Spring 2014

Optimistic Resource Reservation/Allocation Optimistic reservation considers average bandwidth allocation Given MA, RA, MN, where Then CS Spring 2014

Optimistic Resource Reservation (Example) Example: Consider sequence of MPEG video frames of size 80KB, 60 KB, 20KB, 20 KB, 60KB, 20 KB, 20 KB (Group of Pictures I, P, B, B, P, B, B, ), Optimistic frame size calculation:  M A = 280/7 = 40 KB Given video frame rate RA = 20 fps If Given MN = 10 KB (network packet size, e.g., packet size for the transport layer like TCP/UDP), then need to consider bandwidth/ throughput reservation for  BN = 10KB x (4 network packets per application frame) x 20 application frames per second= 800 KB/second = 6400 Kbps CS Spring 2014

Sender-Oriented Reservation Protocol CS Spring 2014

Receiver-Oriented Reservation Protocol CS Spring 2014

Conclusion Multimedia System/networking designer must be clear about the requirements coming from the applications and users Multimedia system/networking designer must be also clear about the constraints, what underlying protocols, services and networks can and cannot do and promise what’s possible to guarantee and deliver CS Spring 2014

ADDITIONAL SLIDES CS Spring 2014

Reservation Styles IETF (Internet Engineering Task Force) standard defines three types of reservation styles  Wildcard Allows receiver to create a single reservation along each link shared among all senders for the given session  Fixed filter Allows each receiver to create a single reservation from a particular sender whose packets it wants to receive  Dynamic filter Allows each receiver to create N reservations to carry flows from up to N different senders. This style allows the receiver to do channel switching (similar to TV channel switching) CS Spring 2014

Reservation Styles CS Spring 2014