Integrated Services Model

    The core service model of [RFC1633, Section 3,] considers only quantitative service commitments concerning the bounds on minimum and maximum per-packet transmission delays within a flow.

Applications can be divided into two categories according to the way their performance depends on the transmission delay behaviour.

Real-Time Applications.

For this class of applications the transmitted data is of any value only if it arrives within a certain time.
Often, real-time applications belong to the class of playback applications , which consist of a source that transforms a signal into data packets and transmits these over the network. At the receiver's site, the packets arrive potentially disordered and with variable delays. The receiver then tries to reconstruct the source data from the packets and attempts to play back the signal as faithfully as possible with some fixed offset delay from the departure time.
An application must find a suitable a priori estimate of this offset delay. It can either be provided by a network service commitment containing a delay bound or by observation of the previously received traffic.

The performance of a playback application is determined by the presentation latency and fidelity, both of which are affected by the delay behaviour of the network.
First, the latency of an application depends on the offset delay predictions about future packet delays. Secondly, the fidelity of the playback can be distorted by individual packet delays exceeding the predictions.

The sensitivity to loss of fidelity leads to two application classes, each requiring a particular service class:

• Intolerant Applications.  Intolerant systems require absolutely faithful playback fidelity and can be found for example with circuit emulation.

  Intolerant applications must choose a fixed offset delay, which is larger than the maximum expected packet delay. Consequently, a reliable upper bound on the maximum packet delay is required.

  A service that enforces such a reliable bound is called a  guaranteed service, and embodies the appropriate service model for intolerant playback applications.

• Tolerant Applications.  Tolerant systems work satisfactorily even with a certain loss of fidelity. Most video and sound applications are tolerant or even rate-adaptive in their encoding scheme.

  The service model proposed in [RFC1633] for tolerant applications is called  predictive service. Its delay bound is fairly but not perfectly reliable; the delay bound could be a prediction based not on worst-case but on statistical assumptions about the behaviour of other data flows in the system. The idea behind predictive service is that a potential, small, tolerable loss of application performance will facilitate a considerable gain in overall network efficiency.

  Newer IS drafts do not mention predictive service. Instead, a similar service, called  controlled-load service, was developed. Controlled-load service tries to approximate the behaviour of best-effort service under unloaded network conditions at any time. Client applications may assume that a very high percentage of the transmitted packets will be successfully delivered by the network, and that the transit delay experienced by a very high percentage of the delivered packets will not greatly exceed the minimum transit delay experienced by any successfully delivered packet.
  Admission control is necessary to ensure that the clients obtain this service quality even if the network is overloaded.

Naturally, in most cases it will be difficult to rigidly distinguish between tolerant and intolerant applications, as their characteristics are continually changing. Delay-bounded services require a characterisation of the expected traffic and admission control mechanisms in order to be able to guarantee or predict the service quality (see Section for details).

Elastic Applications.

  Elastic applications will always wait for data to arrive rather than proceed without it. Although the performance of these applications will be marred by a large (average) delay, they require no a priori characterisation of the delay in order to function properly.
Subcategories of elastic applications with different delay expectations are interactive burst (Telnet, X, NFS), interactive bulk transfer (FTP), and asynchronous bulk transfer (electronic mail, FAX).
   A network should offer a  best-effort service for use with elastic applications, also known as as-soon-as-possible or ASAP service. Best-effort service is not subject to admission control.

Other topics addressed by the Integrated Services model include:

• Resource Sharing. Whereas QoS commitments lay down how the network allocates its resources,  link sharing addresses how the total bandwidth of a link is shared among various client entities.
  Possible forms of link sharing are:
  • Multi-entity link sharing
  • Multi-protocol link sharing
  • Multi-service link sharing

• Packet Dropping. The Integrated Service model proposes the introduction of a  preemptible packet service, which treats packets marked preemptible as less important than those not marked. If the system is in danger of violating its commitments in cases of network overload, it can drop packets that are marked preemptible and thereby reduce the delay of the non-preempted packets.
  As an example, when transmitting MPEG video frames, B-frames, which belong to the least important frame type, could be marked as preemptible while it would not be advisable to discard any I-frames, which are of highest importance.

• Usage Feedback. Controlled--link-sharing service, which can be used to impose limits on resource consumption, is one way to prevent abuse of network resources. Another possibility is to make users responsible for their usage, which is known as network  accounting.

• Reservation Model. The reservation model describes how an application negotiates a certain QoS level with the network system.
  A flowspec is passed to the appropriate resource manager, which can refuse the request, accept it, or grant a lower QoS level if the network cannot promise to fulfill the original request to its full extent.
  All affected system components, especially the routers along the path of a flow, must be informed about the actually granted level to set up corresponding local reservations. For this purpose, the use of a reservation setup protocol such as RSVP is recommended.