Multimedia Networking

7.3.1 The Limitations of a Best-Effort Service

Home
Introduction
7.1 Multimedia Networking Applications
7.1.1 Examples of Multimedia Applications
7.1.2 Hurdles for Multimedia in Today's Internet
7.1.3 How Should the Internet Evolve to Support Multimedia Better?
7.1.4 Audio and Video Compression
7.2 Streamimg Stored Audio and Video
7.2.1 Accessing Audio and Video Through a Web Server
7.2.2 Sending Multimedia from a Streaming Server to a Helper Application
7.2.3 Real-Time Streaming Protocol (RTSP)
7.3 Making the Best of the Best-Effort Service: An Internet Phone Example
7.3.1 The Limitations of a Best-Effort Service
7.3.2 Removing Jitter at the Receiver for Audio
7.3.3 Recovering from Packet Loss
7.4 Protocols for Real-Time Interactive Applications
7.4.1 RTP
7.4.2 RTP Control Protocol (RTCP)
7.4.3 SIP
7.4.4 H.323
7.5 Distributing Multimedia: Content Distribution Networks
7.6 Beyond Best Effort
7.6.1 Scenario 1: A 1 Mbps Audio Application and an FTP
7.6.2 Scenario 2: A 1 Mbps Audio Application and a High-Priority FTP Transfer
7.6.3 Scenario 3: A Misbehaving Audio Application and an FTP Transfer
7.6.4 Scenario 4: Two 1 Mbps Audio Applications over an Overload 1.5 Mbps Link
7.7 Scheduling and Policing Mechanisms
7.7.1 Scheduling Mechanisms
7.7.2 Policing: The Leaky Bucket
7.8 Intergrated Services and Differentiated Services
7.8.1 Intserv
7.8.2 Diffserv
7.9 RSVP
7.9.1 The Essence of RSVP
7.9.2 A Few Simple Examples
The Limitations of a Best-Effort Service

Best-effort service can lead to packet loss, excessive end-to-end delay, and packet jitter.
 
Packet Loss
Consider one of the UDP segments generated by our Internet phone applicatio.  The UDP segment is encapsulated in an IP datagram.  As the datagram wanders through the network, it passes through buffers in the routers in order to access outbound links.  It is possible that one or more of the buffers in the route from sender to receiver is full and cannot admit the IP datagram.  The IP datagram is discarded, never to arrive at the receiving application.
 
Loss could be eliminated by sending packets the packets oer TCP rather than over UDP.  Recall that TCP retransmits packets that do not arrive at the destination.  Retransmission mechanisms are often considered unacceptable for interacitve real-time audio applications such as Internet phone, because they increase end-to-end delay.
 
End-to-End Delay
End-to-end delay is the accumulation of transmission, porcessing, and queuing delays in routers; propagation delays in the links; and end-system processing delays.
 
Packet Jitter
A crucial component of end-to-end delay is the random queuing delays in the routers.  Boecause of these varying delays within the network, the time from when a packet is generated at the source until it is received at the receiver can fluctuate from packet to packet.  This phenomenon is called jitter.
 
Jitter can often be removed by using sequence numbers, timestamps, and a playout delay.