Multimedia Networking

7.8.2 Diffserv

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

Diffserv

The ability to request and reserve per-flow resources makes it possible for the Intserv framework to provide QoS guarantees to individual flows.  As work on Intserv proceeded, howerver, researchers involved began to appreciate some of the difficulties associated with the Intserv model and per-flow reservation of resources.
 
  • Scalability-Per-flow resources reservation implies the need for a router to process resource reservations and to maintain per-flow atate of each flow passing through the router.
  • Flexible service models-The Intserv framwork lprovides for a small number of pre-specified service classes.
 
These considerations led to the so-called Diffserv activity within the Internet Engineering Task Force. The Diffserv architecture aims to provide scalable and flexible service differentiation--that is, the ability to handle different "classes"  of traffic in differen ways within the Internet.  The need for scalability arises from the fact that hundreds of thousands of simultaneous source-destination traffic flows may be present at a backbone router of the Internet.
 
Differentiated Services: A Simple Scenario
To set the framwork for defining the architectural components of the differentiated service model.
The Diffserv sachitecture consists of two sets of functional elements:
  • Edge functions: packet classification and traffic conditioning.  At the incoming edge of the network arriving pacekts are marked.
  • Core function: forwarding.  When a DS-marked packet arrives at a Diffserv-capable router, the packet is forwarded onto its next hop according to the so-called per-hop behavior associated with that packet's class.

kurose_320719_c07f33.gif

Per-Hop Behaviors
The second key component of the Diffserv architecture involves the per-hop behavior (PHB) performed by Diffserv-capable routers.  PHB is rather cryptically, but acrefully, defined as "a description of the externally observable forwarding behavoir of a Diffserv node applied to a particular Diffserv behavior aggregate".  Digging a llittle deeper int this definition, we can see several important considerations embedded within it:
  • A PHB can result in different classes of traffic receiving different performance.
  • While a PHB defines differences in perfomance among classes, it does not mandate anu particular mechanism for achieving these behaviors.
  • Differences in performance must be observable and hance measurable.
  • The expedited forwarding PHB specifies that the departure rate of a class of traffic from a router must equal or exceed a configured rate.
  • The assured forwarding PHB is more complex.
 
 

kurose_320719_c07f34.gif

Intserv and Diffserv Retrospective
For the past 20 years there have been numerous unsuccessful attempts to introduce QoS into packet-switched networks.  The various attempts have failed so far more because of economic and legacy reasons than because of technical reasons.  These attempts include end-to-end ATM networks, and TCP/IP networks deploying Intserv or Diffserv.