Multimedia Networking

7.6.4 Scenario 4: Two 1 Mbps Audio Applications over an Overload 1.5 Mbps Link

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 4: Two 1 Mbps Audio Applications over an Overloaded 1.5 Mbps Link

Two 1 Mbps audio connections transmit their packets over the 1.5 Mbps link.  The combined data rate of the two flows exceeds the link capacity.  Even with classification and marking (Principle 1), isolation of lows (Principle 2), and sharing of unused bandwidth (Principle 3), of which there is none, this is clearly a losing proposition.  There is simply not enough bandwidht to accommodate the application's needs.  If the two applications equally share teh bandwidth, each would receive only 0.75 Mbps.
 
For a flow that needs a minimum QoS in order to be considered usable, the network should either allow or block the flow.

kurose_320719_c07f22.gif

Implicit with the need to provide a guaranteed QoS to a flow is the need for the flow to delcare its QoS requirements.  This process of having a flow declare its QoS requirement, and then having the network either accept the flow or block the flow is referred to as the call admission process.  The need for call admission is the fourth underlying principle in the provision of QoS guarantees:
 
Principle 4: If sufficient resources will not always be available, a call admission process is needed in which flows declare their QoS requirements and are then either admitted to the network or blocked from the network.