Advanced Multimedia University of Palestine University of Palestine Eng. Wisam Zaqoot Eng. Wisam Zaqoot October 2010 October 2010 Ref: Computer Networking: A Top Down Approach, 4th ed., Kurose & Ross Multimedia Networking Applications

The last few years have witnessed an explosive growth in Multimedia Networking Applications. The last few years have witnessed an explosive growth in Multimedia Networking Applications. Entertainment video Entertainment video IP telephony IP telephony Internet radio Internet radio Multimedia WWW sites Multimedia WWW sites Teleconferencing Teleconferencing Interactive games Interactive games Virtual worlds Virtual worlds Distance learning Distance learning Etc. Etc.

Multimedia Networking Applications MN applications differ significantly from those of traditional data-oriented applications such as web text/image, , FTP and DNS applications. MN applications differ significantly from those of traditional data-oriented applications such as web text/image, , FTP and DNS applications. In contrast to data-oriented applications, MN applications are highly sensitive to end-to-end delay and delay variation (jitter), but can tolerate occasional loss of data. In contrast to data-oriented applications, MN applications are highly sensitive to end-to-end delay and delay variation (jitter), but can tolerate occasional loss of data.

Multimedia Networking Applications MN applications characteristics: MN applications characteristics: typically delay sensitive typically delay sensitive end-to-end delay (from few hundred milliseconds in Internet telephony to few seconds in streaming MM) end-to-end delay (from few hundred milliseconds in Internet telephony to few seconds in streaming MM) delay jitter * delay jitter * loss tolerant: infrequent losses cause minor glitches in audio and video loss tolerant: infrequent losses cause minor glitches in audio and video In contrast to data, which are loss intolerant but delay tolerant. Delays here are annoying but not harmful. The most important thing here is to keep the data integrity. In contrast to data, which are loss intolerant but delay tolerant. Delays here are annoying but not harmful. The most important thing here is to keep the data integrity.

* Jitter is the variability of packet delays within the same packet stream network provides application with level of performance needed for application to function. QoS

Delays and Jitter Challenges Delay constraint: Delay constraint: Data not received before their playout time are considered lost. Jitter: variable delays in the received data. Data transmitted periodically typically will not arrive periodically. This network-induced jitter must not be apparent in the multimedia playout at the receiver.

Delays and Jitter Challenges One technique to decrease the amount of late- arriving data and to accommodate jitter is to delay the beginning of playout, essentially pushing the playout deadlines further into the future. (pieces of arriving data are placed in a playout buffer. After some delay, playout begins and data are removed from the buffer). The playout buffer not only decreases late- arrival loss, but also masks the jitter*. * Imagine ten packets of data in the playout buffer, it is irrelevant whether those ten packets arrived smoothly over time (with no jitter) or arrived with wildly different delays (high jitter).

Classes of MM applications: 1) Streaming stored multimedia 2) Streaming live multimedia 3) Real-time interactive multimedia 4) Stored multimedia file (a file downloaded in its entirety and then played out, we will ignore this class)

Classes of MM applications: In all MM classes, multimedia data has both content (bytes that make up an audio sample or a video frame) and timing attributes. For example, the timing attribute might be the video frame temporal location during a particular interval of time within the video.

Classes of MM applications: Data must be received from the server in time for its playout at the client. Data not received before their playout time are considered lost. Stored applications have the flexibility to transmit data as fast as the network path will allow, since all of the multimedia is stored and always available for transmission. Live applications do not have this flexibility. Interactive human-to-human communication (for example, a teleconference or an audio call) requires low end-to-end latencies, typically less than 400 msec in order for such interaction communication to feel “natural” for the participants.

1) Streaming Stored Multimedia Stored streaming: media stored at source media stored at source transmitted to client transmitted to client streaming: client playout begins before all data has arrived timing constraint for still-to-be transmitted data: in time for playout timing constraint for still-to-be transmitted data: in time for playout The most famous applications here are offered by Microsoft and Real Networks. The most famous applications here are offered by Microsoft and Real Networks.

1) Streaming Stored Multimedia 1. video recorded 2. video sent Cumulative data streaming: at this time, client playing out early part of video, while server still sending later part of video network delay time 3. video received, played out at client

1) Streaming Stored Multimedia: Interactivity: VCR-like functionality: client can pause, rewind, FF, push slider bar VCR-like functionality: client can pause, rewind, FF, push slider bar 10 sec initial delay OK 10 sec initial delay OK 1-2 sec until command effect OK 1-2 sec until command effect OK Timing constraint for still-to-be transmitted data: in time for playout Timing constraint for still-to-be transmitted data: in time for playout

2) Streaming Live Multimedia Examples: Internet radio talk show Internet radio talk show AlJazeera TV channel live streaming AlJazeera TV channel live streaming Streaming (as with streaming stored multimedia) playback buffer playback buffer playback can lag tens of seconds after transmission playback can lag tens of seconds after transmission still have timing constraint still have timing constraintInteractivity: fast forward impossible fast forward impossible rewind, pause could be possible! rewind, pause could be possible!

3) Real-Time Interactive Multimedia Applications: IP telephony, video conference, virtual class rooms, distributed interactive worlds, etc. Applications: IP telephony, video conference, virtual class rooms, distributed interactive worlds, etc. end-end delay requirements: end-end delay requirements: audio: < 150 msec good, < 400 msec OK audio: < 150 msec good, < 400 msec OK includes application-level (packetization) and network delays includes application-level (packetization) and network delays higher delays noticeable, impair interactivity higher delays noticeable, impair interactivity What Real-Time Interactive MM applications you know? What Real-Time Interactive MM applications you know?

Multimedia Over Today’s Internet TCP/UDP/IP: “best-effort service” no guarantees on delay, loss no guarantees on delay, loss Today’s Internet multimedia applications use application-level techniques to mitigate (as best possible) effects of delay, loss But you said multimedia apps require QoS and level of performance to be effective! ? ? ?? ? ? ? ? ? ? ?

How should the Internet evolve to better support multimedia? Integrated services philosophy: fundamental changes in Internet so that apps can reserve end-to-end bandwidth fundamental changes in Internet so that apps can reserve end-to-end bandwidth requires new, complex software in hosts & routers requires new, complex software in hosts & routersLaissez-faire no major changes no major changes more bandwidth when needed more bandwidth when needed content distribution, application-layer multicast content distribution, application-layer multicast application layer application layer Differentiated services philosophy: fewer changes to Internet infrastructure, yet provide 1st and 2nd class service What’s your opinion?

Forward error correction (FEC) There are a number of reliable data transfer protocols that retransmit lost or damaged packets. An alternative approach toward achieving reliability is to use forward error correction (FEC) techniques. With FEC, enough redundant information is added to the original data so that even if some of the transmitted data (original data plus redundant data) is lost, the receiver can still recover the original data. The simple two-dimensional parity technique for detection and correction of single bit errors is a simple example of FEC. FEC techniques can be particularly valuable when an application cannot wait for a round-trip time to recover lost data via a timeout- and-transmit mechanism.