Multimedia Networking

7.6.1 Scenario 1: A 1 Mbps Audio Application and an FTP

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

Scenario 1: A Mbps Audio Application and an FTP Transfer

A 1 Mbps audio application shares the 1.5 Mbps link between R1 and R2 with an FTP application that is transferring a file from H2 to H4. In the best-effort Internet, the sudio and FTP packets are mixed in the output queue at R1 and transmitted in a first-in-first-out (FIFO) order.  In this scenario, a burst of packets from the FTP sources could potentially fill up the queue, causing IP audio packets to be excessively delayed or lost due to buffer overflow at R1.

kurose_320719_c07f18.gif

U:nder a strict priority scheduling discipline, an audio packet in the R1 output buffer would always be transmitted before any FTP packet in the R1 output buffer.  The link from R1 to R2 would look like a dedicated link of 1.5 Mbps to the audio traffic, with FTP traffice using the R1-to-R2 link only when no audio traffic is queued.
 
In order for R1 to distinguish between the audio and FTP packets in its queue, each packet must be marked as belonging to one fo these two classes of traffic.
 
Principle 1: Packet marking allows a router to distinguish among packets belonging to differnet classes of traffic.