A Survey of QoS Architectures

1
A Survey of QoS Architectures
Summary presentation by Geir Berset
2
Contents of the article

• Introduction
• A proposal of a generalized QoS architecture
• Examination of some state-of-the art QoS
  Architectures
• Comparison
• Discussion
• Conclusion

3
Introduction

• Meeting QoS guarantees an end-to-end issue!
• All level admission testing and resource
  reservation
• Co-ordination of disk and thread scheduling
  (end-system)
• Packet scheduling and flow control
• Monitoring and maintainance of QoS (all levels)
• It is clear that failing to sustain the desired
  QoS in ANY of these different aspects, will
  degrade the overall QoS of the application.
• These elements must work together
• Much effort has been put in research in
  individual architectural layers.

End-to-end QoS Scenario
4

• Less progress in addressing it as an overall
  end-to-end QoS architecture (the main focus of
  this article) Today, the end-to-end issue is
  probably the one getting the most attention.
• Until recently (in 1996) there has little work on
  QoS-support in distributed systems platforms.
  What work there is, has been in the separate
  areas of the Open Distributed Processing (ODP).
• The current state of QoS provision in
  architectural frameworks can be summarized as
  follows
• Incompleteness current (inter)network
  interfaces are not QoS configurable (like Berkley
  sockets)
• Lack of mechanisms to support QoS guarantees
  need research in monitoring and maintaining
  contracts
• Lack of an overall framework
• The result of realizing the above limitations, is
  a number of proposed architectural approaches to
  QoS provision (QoS Architectures)
• define a set of quality of service configurable
  interfaces that formalize quality of service in
  the end-system and network
• provide a framework for QoS control and management

5
2. Generalized QoS Framework

• The set of elements used in building QoS into
  distributed multimedia systems
• QoS Principles
• QoS Specification
• QoS Mechanisms
• QoS Provision Mechanisms
• QoS Control Mechanisms
• QoS Management Mechanisms

6
QoS Principles

• integration principle
• QoS must be configurable, predictable and
  maintainable over all architectural layers to
  meet end-to-end QoS.
• separation principle
• media transfer, control and management are
  functionally distinct architectural activities
• transparency principle
• applications should be shielded from the
  underlying QoS specification and QoS management
• multiple timescales principle
• division of functionality between architectural
  models, and pertains to the modeling of control
  and management mechanisms
• performance principle
• e.g high performance in communication protocols,
  use of hardware assists for efficient protocol
  processing

7
QoS Specification

• Concerned with capturing application level QoS
  requirements and management policies.
• QoS specification should be declarative rather
  than specific about system oriented issues
  should be able to express what it wants, not how
  to acheive it.
• flow syncronization specification degree of
  synchronization between multiple related flows
• flow performance specification bandwidth, delay,
  jitter, and loss rates
• level of service degree of commitment
  (best-effort, deterministic, predictive)
• QoS management policy degree of adaptation -
  how much can we alter the QoS specification,
  while still satisfying the applications demands
• cost of service the price the user is willing to
  incur for the level of service.

8
QoS Mechanisms

• Mechanisms can be static or dynamic.
• Static resource management deals with flow
  establishment and end-to-end QoS re-negotiation
  phases (QoS Provisions)
• Dynamic resource management deals with the
  media-transfer phase (QoS Control and Management)

9
QoS Mechanisms II- QoS provision mechanisms

• QoS Mapping performes the function of automatic
  translation between representations of QoS at
  different system levels.
• admission testing responsible for comparing the
  resource requirement arising from the requested
  QoS against the available resources in the system
• resource reservation protocols arranges
  allocation of suitable resources according to the
  requested QoS specification

10
QoS Mechanisms III- QoS Control Mechanisms

• Operates real-time.
• Actions based on requested levels of QoS
  established during the QoS provision phase.
• flow shaping
• regulate the flow of data
• flow scheduling
• manages the forwarding of flows in the end-system
  and network
• flow policing
• detecting misbehaving flows, observes whether the
  QoS contracted by a user is being adhered to
• flow control
• open loop flow control the sender is allowed to
  inject data at the agreed level
• closed loop flow control the sender must adjust
  according to feedback from the receiver
• flow synchronization lip sync

11
QoS Mechanisms IV- QoS Management Mechanisms

• Qos management is frequently required to ensure
  that the contracted QoS is sustained.
• Similar to QoS control, but operates on a slower
  time-scale.
• QoS monitoring
• track the ongoing QoS levels acheived by the
  lower levels
• QoS maintenance
• tracks the monitored QoS against expected QoS
• exerts tuning and adjusting operations to sustain
  the delivered QoS
• QoS degradation
• QoS maintainance fails, alerts user
• QoS availability
• intervals over which one or more QoS parameters
  can be monitored and the application informed
• QoS scalability
• comprises QoS filtering and QoS adaptation
  mechanisms

12
3. QoS Architectures
13
Heidelberg QoS Model

• Comprehensive QoS model which provides guarantees
  in the end-systems and network
• Includes continous media transport system
  (HeiTS/TP), which provides QoS mapping and media
  scaling
• Key to providing end-to-end guarantees is HeiRAT
  (resource administration technique)
• QoS Negotiation
• QoS Calculation
• admission control
• QoS enforcement
• resource sheduling
• Designed to handle heterogenous QoS demands, and
  QoS Adaptivity

14
Extended Integrated Reference Model (XRM)

• Modeling framework for control and management of
  multimedia telecommunications network.
  (multimedia and broadband)
• argues that the foundations for operability of
  multimedia computing and networking devices are
  equivalent both classes of devices can be
  modeled as producers, consumers and processors of
  media.
• General concepts for characterizing the capacity
  of network and end-system devices (disks,
  switches, etc.) have been developed.
• Network resources are allocated based on four
  cell-level traffic classes. A traffic class is
  characterized by its statistical properties and
  QoS requirements.
• In order to satisfy the requirement for the
  cell-level, scheduling, and buffer management
  algorithms dynamically allocate communication
  bandwidth and buffer space appropriately.

15
OMEGA

• Result of research on the relationship between
  application QoS requirements and the ability of
  local and global resource management to satisfy
  these demands.
• OMEGA assumes a network subsystem which provides
  QoS functionality, and an operating system which
  can provide run-time QoS guarantees.
• The essence of OMEGA is resource reservation and
  management of end-to-end resources.
• At call setup-time, guarantees are made between
  several logical levels
• between application and network
• between network and OS, etc.

16
int-serv architecture

• Int-serv is traditionally restricted to the
  network layer
• Int-serv is a comprehensive architecture and a
  QoS framework used to specify the functionality
  of internetwork system elements
• Elements constitute of routers, subnetworks and
  end-point operating systems.
• Each element is QoS-aware, and has its behaviour
  defined as a set of services which it may or may
  not offer.
• The following services are offered (in addition
  to best-effort)
• controlled delay
• predicated delay
• guaranteed delay
• Int-serv is comprised of four components
• packet scheduler
• a classifier
• admission controller
• reservation setup protocol (e.g. RSVP)
• New work on implementing the end-system in the
  int-serv architecture
• Int serv is restricted to the network, but
  applicable in the end-system to. The Quality of
  Service Manager (QM) (see figure) is a part of
  the end-system int-serv architecture.

17
int-serv architecture

• Int-serv is traditionally restricted to the
  network layer
• Int-serv is a comprehensive architecture and a
  QoS framework used to specify the functionality
  of QoS-aware internetwork system elements
• Elements constitute of routers, subnetworks and
  end-point operating systems.
• New work on implementing the end-system in the
  int-serv architecture
• The Quality of Service Manager (QM) (see figure)
  is a part of the end-system int-serv
  architecture.
• Isolates the application from underlying details

18
Int-serv architecture II
19
Quality of Service Architecture (QoS-A)

• A layered architecture of services and mechanisms
  for quality of service management and control of
  continous media flows in multiservice networks.
• Implements the following key notions
• flows , a media stream
• service contracts , QoS agreements between user
  and provider
• flow management , monitoring and maintenance of
  the servce contracts
• Realization of the flow concept demands active
  QoS management and tight integration between
  device management, end-system thread scheduling,
  communications protocols and networks.

20
QoS-A II

• Composed of layers and planes
• Layers
• upper layer provide multimedia communications and
  QoS specification in an Object-based environment
• Lower layers deal with syncronization, jitter,
  and other lower layer QoS mechanisms.
• Planes
• protocol plane, separate protocol for control and
  media components of flows
• QoS maintainance plane, consists of several layer
  specific QoS managers
• flow management, QoS mapping, QoS Scaling

21
OSI QoS Framework

• The QoS associated with objects and their
  interactions is described through the definition
  of a set of QoS characteristics. The key OSI QoS
  framework concepts include
• QoS requirements -
• QoS characteristics
• QoS categories
• QoS management functions
• The OSI Framework is made up of two management
  entities (layer specific and system-wide
  entities)
• Both these two management entities try to meet
  the QoS requirements by monitoring, maintaining
  and controlling end-to-end QoS.

22
OSI QoS Framework II
The system policy control function interacts with
each layer-specific policy control function to
provide an overall selection of QoS functions and
facilities.
23
Tenet Architecture

• The Tenet Group has developed a family of
  protocols which run over an experimental wide
  area ATM network.
• Real Time Channel Administration Protocol (RCAP)
• Real Time Internet Protocol (RTIP)
• Continous Media Transport Protocol (CMTP)
• The Tenet group makes a distinction between
  deterministic and statistical guarantees for
  hard real-time and continous media flows
  respectively.
• deterministic guarantees a hard bound on the
  performance of all cells within a session
• statistical guarantees promise that no more than
  x of packets would experience a delay greater
  than specified, or no more than x of cells is
  missed in a session

24
TINA QoS Framework

• Describes a framework for specifying QoS aspects
  of distributed telecommunications within the
  context of the Computing Architecture
• Addresses the computational and engineering
  viewpoints of distributed telecommunications
  applications.
• Governed by the separation between
  telecommunications applications and the
  Distrubuted Processing Environment (DPE)
• By stating QoS requirements declaratively,
  applications are relieved of the burden of coping
  with complex resource management mechanisms
  needed for ensuring QoS guarantees.

25
MASI End-to-end Model

• Offers a generic QoS framework to specify and
  implement the required QoS requirements of
  distributed multimedia applications operating
  over ATM-based networks.
• Research motivated by
• The need to map QoS requirements from the
  ODP-layer to specific resource modules in a clean
  and efficient manner
• the need to resolve mutimedia synchronization
  needs of multiple related ODP streams

26
End System QoS Framework

• Four components of this framework
• QoS specification (with a small number of
  parameters)
• QoS mapping (calculate resource
  requirements)
• QoS enforcement (real time processing guarantees
  for multimedia transfer)
• protocol implementation
• (attributes
  derived from high-level QoS mapping)

27
4. Comparison

• The following figure gives a simple qualitative
  comparison, using the elements of the generalized
  QoS framework as a basis for the comparison in
  the following table.

28
(No Transcript)
29
5. Discussion

• All QoS architectures surveyed in section 3
  consider QoS specification to be fundamental in
  capturing application-level QoS requirements.
• Allthough there is a broad consensus on the need
  for a flow spec which captures quantitative
  performance requirements, there exists two
  schools of thought on how it should be
• some solutions are based on a flow spec that is
  made up of one or two QoS parameters that
  identify a traffic class and an average bandwidth
• others adopt a multi-valued flow spec
• The former of these two solutions can be somewhat
  limiting, while in the latter one, there might be
  a more complex setup

30
Soft- or hard-state connections

• Almost all work advocate hard-state connections
  in their solution, this couples path
  establishment and resource reservation.
• Work in the IETF on the Integrated Services
  argues the opposite, that network level
  guarantees can be built using a soft state
  approach (best-effort)
• no connection establishment
• decouples path establishment and resource
  reservation
• reduces setup-time
• Perhaps too early to determine which is more
  suitable for future multimedia applications.

31
Commonalities in network and end-system

• Similarities exist, e.g. admission control,
  resource management, scheduling mechanisms.
• To which extent mechanisms in the one, should be
  applied in the other, remains an open issue.
• management goals may differ
• differ in nature and complexity (a router is more
  specialized than an end-system)

32
6. Conclusion

• This paper has argued that one should adopt an
  end-to-end approach to meet application level QoS
  requirements
• This is motivated by 5 principles
• Integration, separation, transparency, multiple
  timescales and performance.
• Work on QoS Architectures remains in its early
  stages
• Gives a qualitative understanding of the key
  principles, services and mechanisms needed to
  build end-to-end QoS into distributed systems