Multimedia Networking

7.6.3 Scenario 3: A Misbehaving Audio Application and an FTP Transfer

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 3: A Misbehaving Audio Application and an FTP Transfer

Suppose now that smoehow the router knows it should give priority to packets from the 1 Mbps audio application.  Since the outgoing link speed is 1.5 Mbps, even though the FTP packets receive lower priority, they will still, on average, receive 0.5 Mbps of transmission service. But what happens if the audio application starts sending packets at a rate of 1.5 Mbps or higher the FTP packets will strave, they will not receive any service on the R1-to-R2 link.  Similar problems would occur if multiple applications all with the same priority, were sharing a link's bandwidth; one noncompliant flow could degrade and ruin teh performance of the other flow.
 
Principle 2: It is desirable to provide a degree of isolation among traffic flows, so that one flow is not adversely affected by another misbehaving flow.

kurose_320719_c07f20.gif

An alternative approach for providing isolation among flows is for the link-level packet-scheduling mechanism to explicitly allocate a fixed amount of link bandwidth to each application flow.  The audio flow could be allocated 1 Mbps at R1, and the FTP flow could be allocated 0.5 Mbps.
 
With strict enforcement of the link-level allocation of bandwidth, a flow can use only the amount of bandwidth that has been allocated; it cannot u;tilize bandwidth that is not currently being used by the other applications.

kurose_320719_c07f21.gif

Principle 3: While providing isolation among flows, it is desirable to use resources as efficiently as possible.