Network Working Group Internet 2 Internet-Draft September 1997 Internet Protocol Quality of Service Problem Statement 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 Scott Bradner Chris Buja Steve Corbato Laura Cunningham Bruce Davie Ken Hays Ron Hutchins Paul Hyder Jim Leighton David Meyer Vishy Narayan Becca Nitzan Ben Teitelbaum Steven Wallace Steve Wolff Paul J. Zawada 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]