1 / 27

CS 414 – Multimedia Systems Design Lecture 18 – Multimedia Transport (Part 1)

Explore the design and functioning of multimedia transport systems, covering aspects of QoS, negotiation, connection establishment, and user requirements. Learn about QoS parameters, negotiation protocols, and connection setup in multimedia communication.

hsherry
Download Presentation

CS 414 – Multimedia Systems Design Lecture 18 – Multimedia Transport (Part 1)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS 414 – Multimedia Systems DesignLecture 18 – Multimedia Transport (Part 1) Klara Nahrstedt Spring 2014 CS 414 - Spring 2014

  2. Administrative • HW1 on – due March 3 @ 11:59pm • Midterm – March 7 in class CS 414 - Spring 2014

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

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

  5. 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 414 - Spring 2014

  6. 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 414 - Spring 2014

  7. 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 414 - Spring 2014

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

  9. 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 414 - Spring 2014

  10. Negotiation Protocol (P2P Receiver-Initiated Negotiation – Example1) time 0 time 0 Setup Socket Communication Setup Socket Communication Wait Send User/Receiver requested QoS (video rate 20fps) Requested Video rate (e.g.,20fps) • - 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 Wait 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 Wait Streaming Data at final rate Sender (Server) CS 414 - Spring 2014 Receiver (Client)

  11. Negotiation Protocol (P2P Receiver-Initiated Negotiation – Example2) time 0 time 0 Setup Socket Communication 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 • - 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 Requested Video rate (e.g.,20fps) Wait 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 Sender (Server) CS 414 - Spring 2014 Receiver (Client)

  12. Negotiation Protocol (P2P Sender-Initiated Negotiation - Example) time 0 time 0 Setup Socket Comm, get movie name Setup Socket Communication (also send server requested video file/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) • -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 Wait Streaming Data at final rate Sender (Server) CS 414 - Spring 2014 Receiver (Client)

  13. Example of Translation • Consider application QoS (frame size MA, frame rate RA) and network QoS (throughput BN, packet rate RN) • Assume • MA = (320x240 pixels, 1 pixel = 8 bits), • RA = 10 fps, packet size • MN = 4KBytes • Application Throughput: • BA = MA x RA = (320 x 240 x 8) x 10 = 6,144,000 bps • Packet rate: • = 190 packets per second • Network Throughput: • BN = MN x RN = 6,225,920 bps CS 414 - Spring 2014

  14. Bandwidth Admission Test • Consider • bi – reserved bandwidth for the ‘i’ connection • Bmax– maximal bandwidth at the network interface • Admission test (if all connections declare their bandwidth requirements bi at the same time): • ∑(i=1,…n) bi ≤ Bmax CS 414 - Spring 2014

  15. Bandwidth Admission • Admission Test (if requests come in iterative fashion) : • Consider • bialloc – bandwidth already admitted, allocated and promised to connection ‘i’ • bjreq – bandwidth requested by connection‘j’ • Bavail = Bmax - ∑(i=1,..n) bialloc, where i ≠ j • Admission Test: • bjreq ≤ Bavail CS 414 - Spring 2014

  16. 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 414 - Spring 2014

  17. Packet Scheduling Admission ei– processing of a packet ‘i’ in network node Admission Test: ei ≤ deadline (within a switch) ∑(i=1,…,n) servei/ (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 CS 414 - Spring 2014

  18. Resource Reservation/Allocation • Bandwidth reservation • Pessimistic reservation with maximal bandwidth allocation: Given (MN, RA, and MA) • if then CS 414 - Spring 2014

  19. 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: • MA= 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 = 12800 Kbps CS 414 - Spring 2014

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

  21. 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: • MA = 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 414 - Spring 2014

  22. Sender-Oriented Reservation Protocol CS 414 - Spring 2014

  23. Receiver-Oriented Reservation Protocol CS 414 - Spring 2014

  24. 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 414 - Spring 2014

  25. Additional slides CS 414 - Spring 2014

  26. 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 414 - Spring 2014

  27. Reservation Styles CS 414 - Spring 2014

More Related