One document matched: draft-bradner-qos-problem-00.txt

Network Working Group                                         Internet 2
Internet-Draft                                            September 1997


         Internet Protocol Quality of Service Problem Statement


                  <draft-bradner-qos-problem-00.txt>

Status of this Memo
   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also  distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract
   This document outlines the requirements for a Quality of Service
   (QoS) function for the Internet Protocol, and is the product of an ad
   hoc Internet 2 working group meeting held August 25-27, 1997 hosted
   by Cisco Systems, Inc. This document is offered to the IP community
   for its consideration and comments.

   This document is organized as follows: Section 1 proposes a simple
   classification scheme to describe QoS models. Subsequent sections
   discuss requirements for Measurement, Administrative Policy,
   Provisioning Issues, Network Environment and Implementation Issues.

1.0 QoS Model Classification
   A QoS model can be conceptualized as a point in the following three-
   space: (Scope, Control Model, Transmission Parameters) Each of the
   these dimensions will be considered below.

   I.  Scope
      The scope defines the boundaries of the QoS  service. For example,
      an end-to-end scope is accessible to applications on end systems.
      An example of end-to-end scope is an RSVP reservation between
      hosts to deliver a pre-specified level of QoS. An intermediate



I2                                                              [Page 1]

Internet-Draft            QoS Problem Statement           September 1997


      scope service, on the other hand, does not necessarily allow end
      systems access to the service interface. An example of
      intermediate scope is an RSVP tunnel between two routers.

   II.  Control Model
      A QoS Control Model describes the granularity, duration, and locus
      of control of QoS requests.  For example, QoS requests may be made
      from either endpoints or intermediate locations (proxy control).
      In addition, the effects of such requests may vary in both
      granularity and duration.  The granularity of a request may extend
      from a single flow between hosts to a site level aggregation,
      while the duration may extend from less than the lifetime of a
      single flow to several months.

   III.  Transmission Parameters
      Transmission parameters can be expressed either quantitatively or
      qualitatively.  They describe the definable and configurable
      metrics of a QoS Model.  Typical parameters are packet loss rate,
      bandwidth, delay average and variation, and MTU.

      The specification of transmission parameters must support
      consistent interpretation and interoperability.

2.0  Measurement
   Any network-provided differentiated service must be measurable from
   the point of view of the user on an end system as well as by the
   operators of any transit networks.  The service requester needs to be
   able to find out using a combination of load-generating tests and
   user-readable network management variables if the service quality
   that has been requested and granted is actually being delivered.
   Notification of QoS failures to both end users and network operators
   is encouraged.

   The network operators need to be able to monitor their networks to be
   sure that they are delivering the requested service and to be able to
   bill for QoS usage.  In the cases where the requested service is not
   being delivered, interoperable mechanisms and tools are needed so
   that fault isolation can be performed. The use of such tools may
   require that the network operators make available particular access
   to their network components so that they can be probed.

   Implementation of these tools may require the development of new SNMP
   MIBs that enable access to underlying QoS mechanisms on the
   intermediate routers and end systems.  Note that end system effects
   such as poor interrupt response on desktop computers must be
   considered when trying to understand the performance of the network
   itself.




I2                                                              [Page 2]

Internet-Draft            QoS Problem Statement           September 1997


3.0  Administrative Policy
   In order for QoS to be an effective tool, a rationing mechanism must
   be in place to allow network management to control the use of
   enhanced QoS capabilities.  This mechanism must be enforced in the
   routing systems but should rely on a locally defined admission
   control mechanism that can take into account user authentication,
   priviledge, ability to pay, etc. Initially, these mechanisms could be
   manual or semi-automatic and could vary widely in granularity.

   A critical element of any widely-deployed differentiated QoS support
   is a scalable and interoperable administrative policy mechanism. The
   granting or possible revocation of QoS requests is dependent on a
   number of policy issues including authentication, authorization,
   prioritization, preemption, and accounting.

   QoS policy must be extensible eventually from a local network and the
   campus network through the Gigapop to backbone networks and other
   ISPs.  A distributed set of QoS policy servers would be one means of
   supporting this level of functionality. Implementation mechanisms
   such as drop policy must be coordinated across administrative domains
   for consistent behavior.

   QoS mechanisms must be robust in the face of theft-of-service
   attempts and various other attacks.

4.0  Provisioning considerations
   A network operator must design and provision sufficient network
   capacity for the quality of service that is offered or that quality
   will not be delivered.   We anticipate that provisioning a network
   offering differential quality of service will be more difficult than
   a best effort network.

   Feedback mechanisms must exist within an administrative domain to
   advise the network operator of situations when aggregate QoS
   commitments approach or exceed network capacity.  For example drop
   rate must be able to be monitored, and if drops as a percentage of
   load offered exceeds some threshold rate, then human intelligence
   must be applied to determine why and what to do about it.

5.0  Network environment
   A networking offering differential QoS must be designed so that
   misbehaving applications do not adversely affect established QoS
   commitments.  In addition, it is desirable to have mechanisms to
   limit the impact of such applications on best effort service.

   We recognize that there are many multicast applications and the QoS
   function should support them.  For example, in many multicast
   environments, there could be a heterogeneity of receivers with



I2                                                              [Page 3]

Internet-Draft            QoS Problem Statement           September 1997


   different QoS requirements.

6.0  Implementation Notes
   The implementation mechanisms for services of this type must be not
   be constrained by Layer-2 substrates that are or will be deployed
   across campus networks, Gigapops, and other provider backbones. On
   the other hand, mechanisms should be able to exploit any QoS features
   present in any substrates.

7.0  Security Considerations
   There are many security issues concerning the use of any QoS service
   on a real network.  At the very least any preference of one user's
   traffic over another's' opens the door for a denial of service
   situation if the QoS controls are not secure.  The full extent of the
   security concerns remains to be determined. (also see section 3.0)

8.0  Participants
   Fred Baker <fred@cisco.com>
   Scott Bradner <sob@harvard.edu>
   Chris Buja <cbuja@cisco.com>
   Steve Corbato <corbato@cac.washington.edu>
   Laura Cunningham <lcunning@mci.net>
   Bruce Davie <bdavie@cisco.com>
   Ken Hays <hays@scri.fsu.edu>
   Ron Hutchins <ron@gatech.edu>
   Paul Hyder <hyder@ucar.edu>
   Jim Leighton <jfl@es.net>
   David Meyer <meyer@antc.uoregon.edu>
   Vishy Narayan <vnarayan@mail.arc.nasa.gov>
   Becca Nitzan <nitzan@es.net>
   Ben Teitelbaum <ben@internet2.edu>
   Steven Wallace <ssw@indiana.edu>
   Steve Wolff <swolff@cisco.com>
   Paul J. Zawada  <zawada@ncsa.uiuc.edu>

9.0  Author's Address
   editor
   Scott Bradner
   Harvard University
   1350 Mass Ave.
   Cambridge MA 02138

   +1 617 495 3864
   sob@harvard.edu







I2                                                              [Page 4]