HELP! * GREY=local Full HTML for

LOCAL foilset Overall Summary of MultiMedia Networks and Rationale for Integrated Services

Given by Marek Podgorny at Tutorial in Poland on April 1996. Foils prepared 3 May 1996
Abstract * Foil Index for this file

See also color IMAGE
Review of the networked multimedia presentations
Requirements for the networking infrastructure supporting multimedia applications
  • Application categorization
  • Relevant network performance parameters
Network technologies supporting multimedia delivery
  • Multicast
  • Switching technologies
  • Quality of service guarantees (integrated services)
  • ATM networks and multimedia

Table of Contents for full HTML of Overall Summary of MultiMedia Networks and Rationale for Integrated Services

1 Network Architectures for Multimedia Delivery
2 Abstract of Network Architectures for Multimedia Delivery
3 Networked multimedia applications
4 Networked multimedia applications (Continued)
5 Multimedia Application Industry -- I
6 Multimedia Application Industry (Continued)
7 Categories of Net MM Apps -- I
8 Categories of Net MM Apps - II
9 Multimedia Kiosks -- I
10 Multimedia Kiosks - II
11 Multimedia Network Requirements - I - Overview
12 Multimedia Network Requirements - II - Bandwidth
13 Multimedia Network Requirements - III - Bandwidth (Continued)
14 Multimedia Network Requirements - IV - Bandwidth Scenarios
15 Multimedia Network Requirements - V - Bandwidth Scenarios (Continued)
16 Multimedia Network Requirements - VI - Quality of Service
17 Multimedia Network Requirements - VII- Quality of Service (Continued)
18 Multimedia Network Requirements - VIII -- Latency
19 Multimedia Network Requirements - IX - Latency (Continued)
20 Multimedia Network Requirements - X - Jitter
21 Multimedia Network Requirements - X I - Jitter (Continued)
22 Multimedia Network Requirements - XII - Multipoint Packet Delivery
23 Multimedia Network Requirements - XIII - Multipoint Packet Delivery (Continued) -- Multicast
24 Multimedia QoS Support -- Introduction
25 Multimedia QoS Support -- General Mechanisms
26 QoS -- ATM and Integrated Services Network
27 ATM versus Integrated Services Network
28 Integrated Services for the Internet
29 Integrated Services: Additional Rationale -- Bandwidth Allocation - I
30 Integrated Services: Additional Rationale -- Bandwidth Allocation II
31 Integrated services: Architecture Elements - I
32 Integrated services: Architecture Elements - II
33 Integrated Services Model - I
34 Integrated Services Model - II -- Basic assumptions of the model
35 Integrated Services Model - III -- Basic assumptions of the model (Continued)
36 Integrated Services Model - IV -- Basic assumptions of the model (Continued)
37 Integrated Services Model: Unnecessary? - I
38 Integrated Services Model: Unnecessary? - II
39 Integrated Services Model: Unnecessary? - III
40 Integrated Services Model: Unnecessary? - IV
41 Integrated Services Model: Reservations - I
42 Integrated Services Model: Reservations - II
43 Reference Implementation Framework Overview I
44 Reference Implementation Framework - Overview II
45 Reference Implementation Framework -- flow
46 Reference Implementation Framework -- Router Function
47 Reference Implementation Framework -- Packet Scheduler I
48 Reference Implementation Framework -- Packet Scheduler II
49 Reference Implementation Framework -- Classifier I
50 Reference Implementation Framework -- Classifier II
51 Reference Implementation Framework -- Admission Control I
52 Reference Implementation Framework -- Admission Control II
53 Integrated Services Router -- Diagram
54 Integrated Services Router -- Forwarding Path
55 Integrated Services Router -- Background Routines
56 IS : Host Model and Routing Changes - I
57 IS : Host Model and Routing Changes -- II
58 Integrated Service Model: Core Services - I
59 Integrated Service Model: Core Services - II
60 Integrated Service Model: Core Services - III
61 Integrated Service Model: Core Services - IV
62 Integrated Service Model: Core Services- QoS - I
63 Integrated Service Model: Core Services- QoS - II
64 Integrated Service Model: Core Services Playback Real-Time Apps - I
65 Integrated Service Model: Core ServicesPlayback Real-Time Apps - II
66 Integrated Service Model: Core ServicesPlayback Real-Time Apps - III
67 Integrated Service Model: Core Services Playback Real-Time Apps - IV
68 Integrated Service Model: Core Services Playback Real-Time Apps - V -- intolerant
69 Integrated Service Model: Core Services Real-Time Apps - Tolerant - I
70 Integrated Service Model: Core Services Real-Time Apps - Tolerant/Predictive Service - II
71 Integrated Service Model: Core Services Real-Time Apps - Guaranteed v. Predictive Services
72 Integrated Service Model: Core Services - Adaptive Real-Time Apps - I
73 Integrated Service Model: Core Services - Adaptive Real-Time Apps - II
74 Integrated Service Model: Core Services - Elastic Applications - I
75 Integrated Service Model: Core Services - Elastic Applications - II
76 Integrated Service Model: Core Services -- Analysis of Taxonomy - I
77 Integrated Service Model: Core Services -- Analysis of Taxonomy - II
78 Integrated Service Model: Core Services -- Resource Sharing - I
79 Integrated Service Model: Core Services -- Resource Sharing - II
80 Integrated Service Model: Core Services -- Resource Sharing - III
81 Integrated Service Model: Core Services -- Resource Sharing - IV
82 Integrated Services: Outstanding Issues

This table of Contents Abstract

HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 1 Network Architectures for Multimedia Delivery

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Networked Multimedia Applications and their Impact on the Network Services
March 1996
Marek Podgorny
NPAC
Syracuse University
111 College Place
Syracuse
New York 13244-4100
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 2 Abstract of Network Architectures for Multimedia Delivery

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Review of the networked multimedia presentations
Requirements for the networking infrastructure supporting multimedia applications
  • Application categorization
  • Relevant network performance parameters
Network technologies supporting multimedia delivery
  • Multicast
  • Switching technologies
  • Quality of service guarantees (integrated services)
  • ATM networks and multimedia
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 3 Networked multimedia applications

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Electronic documents with attached voice and video annotations
  • (multimedia electronic mail, workgroup applications).
Desktop conferencing:
  • two or more participants connected through the (inter)network,
  • using audio/video, whiteboard, shared applications...
Distance-learning courses offered as live broadcasts
  • or as video-on-demand, supported by
  • On-line textual material, on-line assignments, shared project areas etc.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 4 Networked multimedia applications (Continued)

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Television broadcasts over local-area networks (LANs).
Interactive kiosks with multimedia product information and demonstrations.
Multimedia databases that store traditional text as well as images, audio, and video clips.
  • Fully searchable digital libraries with instant delivery.
3D navigation in real and abstract landscapes.
Simulation on demand with direct graphical output and interactive input.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 5 Multimedia Application Industry -- I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Hierarchical structure of the MM industry:
  • Multimedia content providers: news industry, television industry, entertainment industry, multimedia CD-ROMs manufacturers.
    • All these companies seek ways to deliver their products over the net.
  • Multimedia application developers: distance learning, desktop videoconferencing, workgroup collaboration, multimedia kiosks, entertainment, imaging, video on demand.
    • All these applications need network support.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 6 Multimedia Application Industry (Continued)

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Multimedia platform builders: Of the computers sold in 1995, 80% was multimedia capable!
Multimedia capable network infrastructure providers:
  • Networking of multimedia is expected to initially occur in businesses over the private networking infrastructure (IntraNets).
  • In 1996, a large demand is expected for multimedia applications across public networks such as the Internet for home, education, business, and entertainment.
Our conclusion: Nearly all multimedia industry gears up to switch to networked applications.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 7 Categories of Net MM Apps -- I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
As shown on next foil, for delivery over an internetwork, multimedia applications can be grouped into categories according to
  • Their sensitivity to delay and the number of simultaneously connected network nodes.
Applications that use stored data streams are not delay-sensitive.
Applications that involve real-time interactivity are sensitive to network delay.
Point-to-point applications involve communication between a single pair of network nodes.
Multipoint applications typically involve a broadcast to many network nodes.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 8 Categories of Net MM Apps - II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * Critical Information in IMAGE
Full HTML Index
Pictorial Representation of Time Sensitivity in Applications
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 9 Multimedia Kiosks -- I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Multimedia kiosk is an important business application!
  • The financial industry wants to use multimedia kiosks at banks to provide detailed information about financial services.
  • The retail industry wants to use kiosks in stores to help customers locate merchandise and find out additional information about merchandise.
Stand-alone kiosk are expensive to maintain. Networking is an operational necessity.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 10 Multimedia Kiosks - II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
The entertainment industry wants to use kiosks as
  • points of sale and to provide
  • advertising for scheduled entertainment events such as the theatre, concerts, plays, etc.
The entertainment industry is also interested in multimedia kiosks that allow multi-person video games to occur over networks.
Highway authorities plan kiosks with tourist information
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 11 Multimedia Network Requirements - I - Overview

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
To provide a decent multimedia delivery infrastructure the network must provide three operational characteristics at an acceptable level:
  • Bandwidth
  • Consistent quality of service
  • Efficient multipoint packet routing and delivery
Two latter requirements are specific to multimedia network traffic. In the past, MM traffic was very limited.
  • With MM revolution just around the corner, the network providers and corporate IS departments face the task of general system reengineering.
Fortunately, the technological solutions are available.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 12 Multimedia Network Requirements - II - Bandwidth

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Bandwidth requirements
  • BW requirements differ widely from application to application.
  • Type of applications and the requested quality are main differentiating factors.
  • Typical examples are shown on following foil
Typical workstation on a corporate LAN has today available BW of 50 - 100 Kbps
This bandwidth is only sufficient for simple MM applications
Solution: switched broadcast networks - will be discussed later.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 13 Multimedia Network Requirements - III - Bandwidth (Continued)

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * Critical Information in IMAGE
Full HTML Index
Some Examples of Needed Network Bandwidth
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 14 Multimedia Network Requirements - IV - Bandwidth Scenarios

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Typical scenarios for deficient bandwidth:
  • I: Desktop machines running MM applications
    • In this environment the most effective way of alleviating the bandwidth problem is network segmentation.
    • However, if there is significant server-related traffic, segmentation is ineffective and a higher BW carrier is needed
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 15 Multimedia Network Requirements - V - Bandwidth Scenarios (Continued)

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Typical scenarios for deficient bandwidth--Contd:
II: Campus backbone
  • For the campus backbone the only solution is a high-speed carrier. Current leading technology is FDDI but its position is being challenged by ATM. Taking this path is a very risky decision, though!
III: Wide area network
  • Very expensive (recurring cost!). Eventual solution: bandwidth on demand (ATM, but also inverse multiplexing of more traditional channels).
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 16 Multimedia Network Requirements - VI - Quality of Service

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Three major components in Quality of Service requirements:
  • Guaranteed bandwidth (note this is different from available bandwidth)
  • End-to-end latency
  • Jitter (i.e. deviation from the average packet arrival time)
None of these factors was a design parameter of today's packet networks.
Different applications running concurrently over the networks may have different service requirements: this imples need for an integrated service network able to handle data and stream applications.
QoS support is sometimes referred to as integrated services.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 17 Multimedia Network Requirements - VII- Quality of Service (Continued)

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Guaranteed bandwidth requirement: how good are packet-switched networks for different types of applications?
  • Constant bit rate applications
    • Difficult on packet networks. With deficient BW they break, surplus BW not useful. Large buffers on client side about the only remedy if QoS absent.
  • Variable bit rate applications
    • Via statistical sharing VBR applications are more efficient on packet networks than on circuit switched networks.
    • QoS requirements only help with sophisticated application-level network resource scheduling.
  • Available bit rate applications
    • Packet networks are ideal transport for ABR apps. ABR apps adapt to the momentarily available bandwidth.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 18 Multimedia Network Requirements - VIII -- Latency

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
For MM applications network latency requirements are in general less stringent than for compute intensive applications.
  • Compute Intensive often requires short round trip times
  • The latency is measured on the time scale of human perception.
  • Latency is of little relevance for one-way transmissions (up to a certain limit...) but is a potential nuisance for teleconferencing and for shared applications.
  • For these applications the latency should be kept below 0.5 sec.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 19 Multimedia Network Requirements - IX - Latency (Continued)

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Latency issue is almost entirely under control (or lack thereof) of the networking gear vendors.
  • Almost every operation on a packet contributes to the total latency.
  • Technologies such as cut-through (instead of store and forward) forwarding attempt to decrease the latency.
More heterogenous networks usually induce higher latency due to packets encapsulation/header changes or segmentation and reassembly.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 20 Multimedia Network Requirements - X - Jitter

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Jitter - audio quality killer
  • Due to statistical factors, packets do not arrive in evenly spaced intervals. Instead, arrival time displays Guassian variation.
  • Jitter is a problem for both audio and video streams.
  • For audio, jitter may cause "hiccup" which is extremely annoying and adversely affects comprehension.
For video, packets that arrive too late require complex logic in the decoder.
Dropping the late packets may cause header loss and decoder confusion.
Processing the late packets compounds the synchronization problems.
Remedy: network buffers, Bandwidth reservation, packet priority handling, etc.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 21 Multimedia Network Requirements - X I - Jitter (Continued)

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * Critical Information in IMAGE
Full HTML Index
Typical Jitter Distribution
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 22 Multimedia Network Requirements - XII - Multipoint Packet Delivery

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
One-to-many and many-to-many applications are extremely expensive in terms of both network bandwidth and processing power on both workstations and on the routers. Typically, unicast and broadcast mechanisms are used:
  • Unicast: the sending computer can send out a different copy of the data for each recipient.
    • Very wasteful of bandwidth, terrible scaling properties.
  • Broadcast: the sending computer can send out a broadcast packet. The networking devices need to forward these packets to all portions of the network in order to ensure that they reach their intended recipients.
    • Also very wasteful of bandwidth.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 23 Multimedia Network Requirements - XIII - Multipoint Packet Delivery (Continued) -- Multicast

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Multicast: the sending computer can send out a multicast packet that is addressed to all the intended recipients. The network will replicate the packet when necessary.
  • It is a very efficient process.
  • In order for multicast to work, the networking devices need to know which computers need to receive multicast traffic, and they need to be able to dynamically build efficient paths to all destinations.
  • Collective communication algorithms on parallel computers use this approach (if they are any good!)
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 24 Multimedia QoS Support -- Introduction

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Global solution of the multimedia QoS problem requires broad consensus of the network gear vendors on how to implement necessary protocols and measures.
All networking devices carrying the multimedia traffic must support the same set of mechanisms.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 25 Multimedia QoS Support -- General Mechanisms

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Among the mechanisms discussed for QoS Support, the most elementary are:
Priority queuing: today's packet networks are truly democratic and egalitarian -
  • FIFO is about the only packet forwarding strategy.
  • Priority queuing could alleviate jitter problems.
Custom queuing: this is a bandwidth reservation mechanism.
  • It is less drastic than priority queuing as it schedules MM packets based on the specified jitter upper bound, not on the absolute priority.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 26 QoS -- ATM and Integrated Services Network

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Two possible solutions:
ATM networking technology - QoS is a build-in feature for this type of transport. This is probably a solution for tomorrow's GII backbone. Will it work in near future?
  • 100% ATM network will never happen.
  • ATM far more expensive than broadcast networks; new fiber/UTP cable plant needed,
  • Serious management and maintenance problems unsolved.
  • ATM QoS does not provide global QoS support.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 27 ATM versus Integrated Services Network

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
ATM Technology -- problems!
  • ATM standards still in flux, implementations more so, LANE not universally available. Consequently, QoS mostly works on the paper.
  • There is no API to the ATM QoS mechanisms. Hence, applications do not have any way to request such services.
Solution -- Integrated services over the packet switched networks
  • A new architecture on top of the current IP layer as opposed to ATM low level approach
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 28 Integrated Services for the Internet

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
In the following, we will discuss the emerging architecture implementing so called integrated services running on top of the existing Internet infrastructure.
The integrated services infrastructure complements two other enabling technologies:
  • Client multimedia hardware: many modern workstations now come equipped with built-in multimedia hardware, including audio codecs and video frame-grabbers, and the necessary video gear is now inexpensive.
  • IP multicasting: while not yet commonly available, it makes its way into Internet infrastructure. Integrated services architecture assumes multicast as a sine qua non component of future multimedia Internet
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 29 Integrated Services: Additional Rationale -- Bandwidth Allocation - I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Real-time QoS is not the only issue for a next generation of traffic management in the Internet: network operators are requesting the ability to control the sharing of bandwidth on a particular link among different traffic classes.
  • They want to be able to divide traffic into a few administrative classes and assign to each a minimum percentage of the link bandwidth under conditions of overload, while allowing "unused" bandwidth to be available at other times.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 30 Integrated Services: Additional Rationale -- Bandwidth Allocation II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
These network administration classes may represent different user groups or different protocol families, for example.
  • Such a management facility is commonly called controlled link-sharing.
Therefore, in the following, the term integrated services (IS) for an Internet service model includes best-effort service, real-time service, and controlled link sharing.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 31 Integrated services: Architecture Elements - I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
The fundamental service model of the Internet, as embodied in the best-effort delivery service of IP, has been unchanged since the beginning of the Internet research project.
Integrated services postulate a major change.
  • From an academic viewpoint, changing the service model of the Internet is a major undertaking;
  • However, its impact is mitigated by the fact that we wish only to extend the original architecture.
The new components and mechanisms to be added will supplement but not replace the basic IP service.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 32 Integrated services: Architecture Elements - II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
The proposed architectural extension is comprised of two elements:
  • An extended service model, called the IS model,
  • A reference implementation framework, which provides a set of vocabulary and a generic program organization to realize the IS model.
It is important to separate the service model, which defines the externally visible behavior, from the discussion of the implementation, which will evolve during the life of the service model.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 33 Integrated Services Model - I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
The IS model includes two sorts of service targeted towards real-time traffic: guaranteed and predictive service.
  • It integrates these services with controlled link-sharing,
  • and it is designed to work well with multicast as well as unicast.
We now discuss several basic assumptions of the model:
Resources (e.g., bandwidth) must be explicitly managed in order to meet application requirements.
  • This implies that "resource reservation" and "admission control" are key building blocks of the service.
  • An alternative approach is to attempt to support real-time traffic without any explicit changes to the Internet service model.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 34 Integrated Services Model - II -- Basic assumptions of the model

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
It is desirable to use the Internet as a common infrastructure to support both non-real-time and real-time communication.
  • One could alternatively build an entirely new, parallel infrastructure for real-time services, leaving the Internet unchanged.
  • With this approach one would lose the significant advantages of statistical sharing between real-time and non-real-time traffic, and it would be much more complex to build and administer than a common infrastructure.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 35 Integrated Services Model - III -- Basic assumptions of the model (Continued)

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
There is a unified protocol stack, employing a single Internet-layer protocol for both real-time and non-real-time service.
  • The IS model proposes to use the existing Internet-layer protocol for real-time data.
  • Another approach would be to add a new real-time protocol in the Internet layer.
  • Unified stack approach provides economy of mechanism, and it allows one to fold in controlled link-sharing easily.
  • It also handles the problem of partial coverage, i.e., allowing interoperation between IS-capable Internet systems and systems that have not been extended, without the complexity of tunneling.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 36 Integrated Services Model - IV -- Basic assumptions of the model (Continued)

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
There should be a single service model for the Internet.
  • If there were different service models in different parts of the Internet, it is very difficult to see how any end- to-end service quality statements could be made.
  • Single service model does not necessarily imply a single implementation for packet scheduling or admission control. It is possible to implement different mechanisms that will also satisfy the service model.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 37 Integrated Services Model: Unnecessary? - I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Arguments have been raised against an integrated service model based on the assumptions we outlined.
In particular, the following arguments have been presented against the necessity of a complex reservation model:
  • "Bandwidth will be infinite."
    • This will be impossible in the short term and unlikely in the medium term.
    • While raw bandwidth may seem inexpensive, bandwidth provided as a network service is not likely to become so cheap that wasting it will be the most cost-effective design principle.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 38 Integrated Services Model: Unnecessary? - II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
"Bandwidth will be infinite." (Continued)
  • Even if low-cost bandwidth does eventually become commonly available, it is unlikely that it will be available "everywhere" in the Internet.
  • Hence, unless the network management provides for the possibility of dealing with congested links, then real-time services will simply be precluded in those cases.
  • In military applications, assume need for "Theater Extensions" with low bandwidth in major areas of activity linked to high bandwidth Global Information Infrastructure
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 39 Integrated Services Model: Unnecessary? - III

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Arguments against integrated services (continued):
"Simple priority is sufficient."
  • While it is true that simply giving higher priority to real-time traffic would lead to adequate real-time service at some times and under some conditions, priority is an implementation mechanism, not a service model.
  • If we define the service by means of a specific mechanism, we may not get the exact features we want.
  • In the case of simple priority the issue is that as soon as there are too many real-time streams competing for the higher priority, every stream is degraded.
  • Restricting the service to this single failure mode is unacceptable.
  • In some cases, users will demand that some streams succeed while some new requests receive a "busy signal".
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 40 Integrated Services Model: Unnecessary? - IV

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
People argue that: "Applications can adapt." However ...
  • The development of adaptive real-time applications does not eliminate the need to put an upper bound on packet delivery time.
  • Human requirements for interaction and intelligibility limit the possible range of adaptation to network delays.
  • It can be shown in real experiments that, while an application can adapt to network delays of many seconds, the users find that interaction is impossible in these cases.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 41 Integrated Services Model: Reservations - I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
There is an inescapable requirement for routers to be able to reserve resources, in order to provide special QoS for specific user packet streams, or "flows".
  • This in turn requires flow-specific state in the routers, which represents a fundamental change to the Internet model: the Internet architecture has been founded on the concept that all flow-related state should be in the end systems.
  • Designing the TCP/IP protocol suite on this concept of end system flow control led to a robustness that is one of the keys to its success.
  • Adding flow state to the routers threatens Internet robustness!
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 42 Integrated Services Model: Reservations - II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Therefore, the flow state added to the routers for resource reservation in the integrated services model is designed to be "soft", i.e., it is maintained by periodic "refresh".
Since reservation implies that some users are getting privileged service, resource reservation needs enforcement of policy and administrative controls.
This in turn calls for authentication of both users and packets.
  • Incidentally, these issues are not unique to "IS": commercialization and commercial security are leading to the same requirements.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 43 Reference Implementation Framework Overview I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
The implementation framework includes four components:
  • The packet scheduler,
  • The admission control routine,
  • The classifier,
  • And the reservation setup protocol.
The first three items will be discussed in the following foils.
The reservation protocol will be discussed is a separate presentation.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 44 Reference Implementation Framework - Overview II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
It is important to understand that the implementation framework discussed below is essentially an example of how the IS model can be realized.
The framework is not a part of any proposed standard!
This notwithstanding, the framework reveals the actual working model of the future Internet....
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 45 Reference Implementation Framework -- flow

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
The "flow" is a distinguishable stream of related datagrams that results from a single user activity and requires the same QoS.
  • A flow might consist of one transport connection or one video stream between a given host pair.
  • A flow is the finest granularity of packet stream distinguishable by the IS.
  • A flow is assumed to be simplex, i.e., to have a single source but N destinations. Thus, an N-way teleconference will generally require N flows, one originating at each site.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 46 Reference Implementation Framework -- Router Function

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
For integrated services, a router must implement an appropriate QoS for each flow, in accordance with the service model.
  • The router function that creates different qualities of service is called "traffic control".
  • Traffic control in turn is implemented by three components:
    • The packet scheduler,
    • The classifier,
    • And admission control.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 47 Reference Implementation Framework -- Packet Scheduler I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
The packet scheduler manages the forwarding of different packet streams using a set of queues and perhaps other mechanisms like timers.
The packet scheduler must be implemented at the point where packets are queued; this is the output driver level of a typical operating system, and corresponds to the link layer protocol.
The details of the scheduling algorithm may be specific to the particular output medium.
  • For example, the output driver will need to invoke the appropriate link-layer controls when interfacing to a network technology that has an internal bandwidth allocation mechanism.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 48 Reference Implementation Framework -- Packet Scheduler II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
There is another component that could be considered part of the packet scheduler or as a separate piece: the estimator.
  • This algorithm is used to measure properties of the outgoing traffic stream
  • To develop statistics that control packet scheduling and admission control.
  • This presentation will consider the estimator to be a part of the packet scheduler.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 49 Reference Implementation Framework -- Classifier I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
For the purpose of traffic control (and accounting), each incoming packet must be mapped into some class; all packets in the same class get the same treatment from the packet scheduler.
This mapping is performed by the classifier. Choice of a class may be based upon the contents of the existing packet header(s) and/or some additional classification number added to each packet.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 50 Reference Implementation Framework -- Classifier II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
A class might correspond to a broad category of flows, e.g., all video flows or all flows attributable to a particular organization.
  • A class might also hold only a single flow.
A class is an abstraction that may be local to a particular router; the same packet may be classified differently by different routers along the path.
  • For example, backbone routers may choose to map many flows into a few aggregated classes, while routers nearer the periphery, where there is much less aggregation, may use a separate class for each flow.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 51 Reference Implementation Framework -- Admission Control I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Admission control implements the decision algorithm that a router or host uses to determine whether a new flow can be granted the requested QoS without impacting earlier guarantees.
Admission control is invoked at each node to make a local accept/reject decision, at the time a host requests a real-time service along some path through the Internet. The admission control algorithm must be consistent with the service model, and it is logically part of traffic control.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 52 Reference Implementation Framework -- Admission Control II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Admission control is sometimes confused with policing or enforcement, which is a packet-by-packet function at the "edge" of the network to ensure that a host does not violate its promised traffic characteristics.
  • Packet level policing is considered to be one of the functions of the packet scheduler.
In addition to ensuring that QoS guarantees are met, admission control will be concerned with enforcing administrative policies on resource reservations.
  • Some policies will demand authentication of those requesting reservations.
Finally, admission control will play an important role in accounting and administrative reporting.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 53 Integrated Services Router -- Diagram

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * Critical Information in IMAGE
Full HTML Index
The router has two broad functional divisions: the forwarding path below the double horizontal line, and the background code above the line.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 54 Integrated Services Router -- Forwarding Path

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
The forwarding path of the router is executed for every packet and usually involves a hardware assist.
The path is divided into three sections: input driver, Internet forwarder, and output driver.
  • The Internet forwarder interprets the internet working protocol header appropriate to the protocol suite.
  • For each packet, an Internet forwarder executes a suite-dependent classifier and then passes the packet and its class to the appropriate output driver.
  • The output driver implements the packet scheduler.
  • It now has two distinct sections: the packet scheduler that is largely independent of the detailed mechanics of the interface, and the actual I/O driver that is only concerned with the nitty gritty details of the hardware.
  • The estimator lives somewhere in between.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 55 Integrated Services Router -- Background Routines

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
The background routines create data structures that control the forwarding path.
  • The routing agent implements a particular routing protocol and builds a routing database.
  • The reservation setup agent implements the protocol used to set up resource reservations.
    • If admission control gives the "OK" for a new request, the appropriate changes are made to the classifier and packet scheduler database to implement the desired QoS.
  • The network management agent must be able to modify the classifier and packet scheduler databases to set up controlled link-sharing and to set admission control policies.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 56 IS : Host Model and Routing Changes - I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
The implementation framework for a host is generally similar to that for a router, with the addition of applications.
  • Rather than being forwarded, host data originates and terminates in an application.
  • An application needing a real-time QoS for a flow must somehow invoke a local reservation setup agent.
  • The best way to interface to applications is not determined yet.
  • For example, there might be an explicit API for network resource setup, or the setup might be invoked implicitly as part of the operating system scheduling function.
  • The IP output routine of a host may need no classifier, since the class assignment for a packet can be specified in the local I/O control structure corresponding to the flow.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 57 IS : Host Model and Routing Changes -- II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
In routers, integrated service will require changes to both the forwarding path and the background functions.
  • The forwarding path, which may depend upon hardware acceleration for performance, will be the more difficult and costly to change.
  • It will be vital to choose a set of traffic control mechanisms that is general and adaptable to a wide variety of policy requirements and future circumstances, and that can be implemented efficiently.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 58 Integrated Service Model: Core Services - I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
A service model is embedded within the network service interface invoked by applications to define the set of services they can request.
  • For compatibility reasons, this service interface must remain relatively stable
    • (or, more properly, extensible; adding new services in the future should be possible but it is expected that it will be hard to change existing services).
  • Because of its enduring impact, the service model should not be designed in reference to any specific network artifact but rather should be based on fundamental service requirements.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 59 Integrated Service Model: Core Services - II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
The core service model addresses those services which relate most directly to the time-of-delivery of packets.
  • Services as routing, security, or stream synchronization are subject of other standardization venues.
Multicast -- Send one packet to bunch of places
RTP -- real Time Protocol
RSVP -- reservation Protocol
will be discussed in later foilsets
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 60 Integrated Service Model: Core Services - III

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
A service model consists of a set of service commitments: in response to a service request the network commits to deliver some service.
  • These service commitments can be categorized by the entity to whom they are made: they can be made to either individual flows or to collective entities (classes of flows).
  • The service commitments made to individual flows are intended to provide reasonable application performance, and thus are driven by the ergonomic requirements of the applications; these service commitments relate to the quality of service delivered to an individual flow.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 61 Integrated Service Model: Core Services - IV

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
The service commitments made to collective entities are driven by resource-sharing, or economic, requirements; these service commitments relate to the aggregate resources made available to the various entities.
  • In the following, we will explore the service requirements of individual flows and describe a corresponding set of services.
  • We then discuss the service requirements and services for resource sharing.
  • Finally, we conclude with some remarks about packet dropping.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 62 Integrated Service Model: Core Services- QoS - I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
For QoS requirements, the core service model is concerned almost exclusively with the time-of-delivery of packets.
Per-packet delay is the central quantity about which the network makes quality of service commitments.
Strictly speaking, the only quantity about which a quantitative service commitments can be made are bounds on the maximum and minimum delays.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 63 Integrated Service Model: Core Services- QoS - II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
The degree to which application performance depends on low delay service varies widely, and one can make several qualitative distinctions between applications based on the degree of their dependence.
  • One class of applications needs the data in each packet by a certain time and, if the data has not arrived by then, the data is essentially worthless - these are real-time applications.
  • Another class of applications will always wait for data to arrive; these are "elastic" applications.
The taxonomy of applications into real time and elastic is neither exact nor complete. It is only used to guide the development of the core service model.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 64 Integrated Service Model: Core Services Playback Real-Time Apps - I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
An important class of such real-time applications: "playback" applications.
  • In a playback application, the source takes some signal, packetizes it, and then transmits the packets over the network.
  • The network inevitably introduces some variation in the delay of the delivered packets.
  • The receiver depacketizes the data and then attempts to faithfully play back the signal. This is done by buffering the incoming data and then replaying the signal at some fixed offset delay from the original departure time;
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 65 Integrated Service Model: Core ServicesPlayback Real-Time Apps - II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
The term "playback point" refers to the point in time which is offset from the original departure time by this fixed delay.
Data arriving after the playback point is essentially useless.
In order to choose a reasonable value for the offset delay, an application needs some "a priori" characterization of the maximum delay its packets will experience.
This "a priori" characterization could either be provided by the network in a quantitative service commitment to a delay bound, or through the observation of the delays experienced by the previously arrived packets.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 66 Integrated Service Model: Core ServicesPlayback Real-Time Apps - III

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
The performance of a playback application is measured along two dimensions: latency and fidelity.
  • Some playback applications, in particular those that involve interaction between the two ends of a connection such as a phone call, are rather sensitive to the latency;
  • Transmitting a movie or lecture is not.
  • Similarly, applications exhibit a wide range of sensitivity to loss of fidelity.
    • Intolerant applications require an absolutely faithful playback,
    • Tolerant applications can tolerate some loss of fidelity.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 67 Integrated Service Model: Core Services Playback Real-Time Apps - IV

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Vast majority of audio and video applications will be tolerant.
One can however envision applications, such as circuit emulation, that are intolerant.
Web based Computing is likely to be intolerant if synchronizing many nodes on a single application as delays at one point, will delay all nodes
It is important to note that late packets always decrease fidelity, even if the applications has clever "adaptive" ways of dealing with them
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 68 Integrated Service Model: Core Services Playback Real-Time Apps - V -- intolerant

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Hence, intolerant applications must use a fixed offset delay.
  • For a given distribution of packet delays, this fixed offset delay must be larger than the absolute maximum delay, to avoid the possibility of late packets.
  • Such an application can only set its offset delay appropriately if it is given a perfectly reliable upper bound on the maximum delay of each packet.
A service characterized by a perfectly reliable upper bound on delay is called "guaranteed service".
This is the appropriate service model for intolerant playback applications.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 69 Integrated Service Model: Core Services Real-Time Apps - Tolerant - I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
In contrast, tolerant applications do not need to set their offset delay greater than the absolute maximum delay.
  • They can also attempt to reduce their latency by varying their offset delays in response to the actual packet delays experienced in the recent past ("adaptivity").
For tolerant applications, the "right: service model is "predictive service" which supplies a fairly reliable, but not perfectly reliable, delay bound.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 70 Integrated Service Model: Core Services Real-Time Apps - Tolerant/Predictive Service - II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
For "predictive service" the bound is not based on worst case assumptions on the behavior of other flows.
Instead, this bound might be computed with properly conservative predictions about the behavior of other flows.
If the network turns out to be wrong and the bound is violated, the application's performance will perhaps suffer, but the users are willing to tolerate such interruptions in service in return for the presumed lower cost of the service.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 71 Integrated Service Model: Core Services Real-Time Apps - Guaranteed v. Predictive Services

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Why two different services?
  • The key consideration here is efficiency:
  • When one relaxes the service requirements from perfectly to fairly reliable bounds, this increases the level of network utilization that can be sustained, and thus the price of the predictive service will presumably be lower than that of guaranteed service.
  • The predictive service class is motivated by the conjecture that the performance penalty will be small for tolerant applications but the overall efficiency gain will be quite large.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 72 Integrated Service Model: Core Services - Adaptive Real-Time Apps - I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Let us discuss accommodation of the "true" adaptive applications in the service model
  • A fundamental point of the overall IS architecture is that traffic characterization and admission control are necessary for these real-time delay bound services.
  • So far one assumed that an application's data generation process is an intrinsic property unaffected by the network.
  • However, there are likely to be many audio and video applications which can adjust their coding scheme and thus can alter the resulting data generation process depending on the network service available.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 73 Integrated Service Model: Core Services - Adaptive Real-Time Apps - II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
This alteration of the coding scheme will present a trade-off between fidelity (of the coding scheme itself, not of the playback process) and the bandwidth requirements of the flow.
Such "rate-adaptive" playback applications have the advantage that they can adjust to the current network conditions not just by resetting their playback point but also by adjusting the traffic pattern itself.
For rate-adaptive applications, the traffic characterizations used in the service commitment are not immutable.
One can thus augment the service model by allowing the network to notify (either implicitly through packet drops or explicitly through control packets) rate-adaptive applications to change their traffic characterization.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 74 Integrated Service Model: Core Services - Elastic Applications - I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Elastic applications will always wait for data to arrive.
  • Elastic application typically uses the arriving data immediately and will always choose to wait for the incoming data rather than proceed without it. These applications do not require any a priori characterization of the service in order for the application to function.
  • For a given distribution of packet delays, the perceived performance of elastic applications will depend more on the average delay than on the tail of the delay distribution.
Categories of elastic applications:
interactive burst (Telnet, X, NFS),
interactive bulk transfer (FTP), and
asynchronous bulk transfer (electronic mail, FAX).
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 75 Integrated Service Model: Core Services - Elastic Applications - II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
The delay requirements of elastic applications vary from rather demanding for interactive burst applications to rather lax for asynchronous bulk transfer, with interactive bulk transfer being intermediate between them.
An appropriate service model for elastic applications is to provide "as-soon-as-possible", or ASAP (=best effort) service.
One should offer several classes of best-effort service to reflect the relative delay sensitivities of different elastic applications.
This service model allows interactive burst applications to have lower delays than interactive bulk applications, which in turn would have lower delays than asynchronous bulk applications.
Applications using this service are not subject to admission control.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 76 Integrated Service Model: Core Services -- Analysis of Taxonomy - I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Although the applications taxonomy was rather crude, the core service model should be judged on its ability to adequately meet the needs of the entire spectrum of applications.
  • Not all real-time applications are playback applications;
  • for example, one might imagine a visualization application which merely displayed the image encoded in each packet whenever it arrived.
  • However, non- playback applications can still use either the guaranteed or predictive real-time service model, although these services are not specifically tailored to their needs.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 77 Integrated Service Model: Core Services -- Analysis of Taxonomy - II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Similarly, playback applications cannot be neatly classified as either tolerant or intolerant, but rather fall along a continuum.
Offering both guaranteed and predictive service allows applications to make their own trade-off between fidelity, latency, and cost.
Despite these obvious deficiencies in the taxonomy, there are reasons to believe that it describes the service requirements of current and future applications well enough so that the Integrated Service model core services can adequately meet essentially all application needs.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 78 Integrated Service Model: Core Services -- Resource Sharing - I

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
The quantity of primary interest in resource-sharing is aggregate bandwidth on individual links.
"link- sharing" component of the service model addresses the question of how to share the aggregate bandwidth of a link among various collective entities according to some set of specified shares.
Multi-entity link-sharing
  • A link may be purchased and used jointly by several organizations, government agencies or the like.
  • They may wish to insure that under overload the link is shared in a controlled way, perhaps in proportion to the capital investment of each entity.
  • At the same time, they might wish that when the link is underloaded, any one of the entities could utilize all the idle bandwidth.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 79 Integrated Service Model: Core Services -- Resource Sharing - II

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Multi-protocol link-sharing
  • In a multi-protocol Internet, it may be desired to prevent one protocol family (DECnet, IP, IPX, OSI, SNA, etc.) from overloading the link and excluding the other families.
  • Note that different families may have different methods of detecting and responding to congestion, and some methods may be more "aggressive" than others.
  • This could lead to a situation in which one protocol backs off more rapidly than another under congestion, and ends up getting no bandwidth.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 80 Integrated Service Model: Core Services -- Resource Sharing - III

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Multi-service sharing
  • Within a protocol family such as IP, an administrator might wish to limit the fraction of bandwidth allocated to various service classes.
  • For example, an administrator might wish to limit the amount of real-time traffic to some fraction of the link, to avoid preempting elastic traffic such as FTP.
In general terms
  • The link-sharing service model is to share the aggregate bandwidth according to some specified shares.
  • A hierarchy of shares is possible.
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 81 Integrated Service Model: Core Services -- Resource Sharing - IV

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
Definition of a service supporting efficient link-sharing is difficult.
There is a number of research models, including the idealized fluid model of instantaneous link-sharing with proportional sharing of excess where at every instant the available bandwidth is shared between the active entities in proportion to the assigned shares of the resource.
This fluid model exhibits the desired policy behavior but is an unrealistic idealization.
The actual service model should be to approximate, as closely as possible, the bandwidth shares produced by the ideal fluid model.
Actual implementation may be difficult!
HELP! * GREY=local HTML version of LOCAL Foils prepared 3 May 1996

Foil 82 Integrated Services: Outstanding Issues

From Overall Summary of MultiMedia Networks and Rationale for Integrated Services Tutorial in Poland -- April 1996. * See also color IMAGE
Full HTML Index
There is a number of issues that have not been discussed but are quite important:
  • impact of packet dropping on the proposed core services
  • Usage feedback (to prevent abuse of network resources)
  • Reservation model (will be covered)
  • Detailed traffic control mechanisms for
    • packet scheduling, controlled packet dropping, packet classification, admission control
  • Combination of the traffic control mechanisms to ensure
    • guaranteed delay bounds, link sharing, predictive real time service
  • Implementation of the soft state for the routers
For these, access to the original literature is recommended
Northeast Parallel Architectures Center, Syracuse University, npac@npac.syr.edu

If you have any comments about this server, send e-mail to webmaster@npac.syr.edu.

Page produced by wwwfoil on Wed Feb 19 1997