Multimedia Applications

Real time applications, such as

• Internet telephony
• Internet radio/video
• live
• video conferencing
• distance learning
• concert broadcasts
• stored
• video on demand

How do these applications differ from traditional ones like file transfer, telnet, email?

• High bandwidth requirement
• Sensitive to delay
• Can tolerate occasional loss of data

Need a different quality of service

IP provides "best effort" service, but no guarantees

• does not differentiate between levels of service
• "packet jitter" - variability in delay
• the Web uses TCP, which results in more delay than IP.

How to respond?

• Add more bandwidth to existing Internet
• Make fundamental changes to allow a user to reserve end-to-end bandwidth in advance -- need new protocols
• Introduce different service levels with different pricing policies

Some techniques in use today:

1.  Data compression

CD-quality audio uses sampling rate of 44,100 per second --> 1.411 Mbps

Video:  For a 1024x768 pixel display, 24 bits per pixel, 25 frames per second, need 472 Mbps

This can be reduced by

• slower sampling rate.  For voice, around 10Kbps, for music (MP3) around 128Kbps
• exploit redundancy
• spatial - one color for a block of pixels
• temporal - encode changes from one image to the next

MPEG-2 video (DVD) - 3-6 Mbps
MPEG-1 video (CD) - 1.2 Mbps

2.  Let the user's media player talk to a separate streaming server using UDP instead of TCP.

3.  Removing jitter

• Use sequence numbers and timestamps to mark packets.
• Delay playout at the receiver, by buffering incoming packets, play them at the correct time
• smooth out variation in packet delay
• if a packet is too late, discard it
• A high playout delay reduces lost packets but may be noticeable to user (especially with telephony)

4.  Error recovery schemes

What to do about a lost packet?

• receiver-based
• repeat previous packet
• interpolation (averaging)
• sender-based
• FEC - forward error correction
• Lower-quality redundant information is piggy-backed onto other packets
• Increases bandwidth requirement
• Interleaving
• Shuffle the data in packets, so if one is lost, it is a little bit of several time intervals, not one big time interval
• This increases delay, so it is more appropriate for streaming stored media than interactive real-time

Question:  How can IP's best-effort service be improved?

1.  Allow packets to be marked with different classes of service.

• Routers can handle them differently, give them different priorities.
• Based on user request, fee structure

2.  Isolate traffic flows

• So one misbehaving application does not adversely affect others
• routers must be able to "police" traffic flows

3.  Make it possible to reject flows which cannot be handled

• In order to guarantee a level of service to a flow, flows must declare their service needs.

RSVP is a protocol used for reserving bandwidth

RTP  Real Time Transport Protocol

• Actually runs at application level
• RTP packets are sent through UDP sockets
• Multiplex up to 16 different data streams in a sequence of packets
• Packets contain sequence number, timestamp so they can be played back correctly at the receiver.

We'll consider four examples of digital audio:

Static audio files

• Download a music file using HTTP, store it on disk
• When complete, start playing it in a media player
• Doesn't require anything more than a normal browser

Streaming audio

• Download a file, but start playing it before download is complete
• Problem:  Jitter caused by variance in packet arrival times
• To eliminate jitter, buffer data (say 10-15 seconds worth) before starting playback.  Jitter can be eliminated as long as the player has each packet by the time it is needed.
• Use interleaving to handle dropped packets.  (One packet contains all the data values for even times, the next for odd times.  If a packet is lost, the effect will be reduced resolution in the playback, rather than completely missing time interval.)
• Use RTP to identify correct position and timing of each incoming packet, in the presence of dropped or out-of-order packets.

Live streaming audio

• Internet radio
• Use buffering to avoid jitter
• However, server cannot send data faster than real time
• Multicasting (which would be nice) is normally not used -- not supported widely enough
• Uses TCP rather than RTP over UDP.

Voice over IP

• Real time constraints are tighter because conversations are two-way
• Receiver can't buffer 15 seconds ahead to avoid jitter
• Sender can't batch data into large packets

Must be able to handle call setup and termination
Must be able to connect to, accept connections from normal telephones in the Public Switched Telephone Network

Application layer summary

The variety of applications and their widespread use is a testament to the power of the Internet architecture and its lower level protocols

• Scalable beyond what could have been anticipated by the original designers
• Variety of usage goes way beyond the intent of the original design
• Open standards