idnits 2.17.1 draft-bradner-qos-problem-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope service, on the other hand, does not necessarily allow end' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...ay also distr...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1997) is 9691 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Internet 2 2 Internet-Draft September 1997 4 Internet Protocol Quality of Service Problem Statement 6 8 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference 17 material or to cite them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 21 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 22 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 23 ftp.isi.edu (US West Coast). 25 Abstract 26 This document outlines the requirements for a Quality of Service 27 (QoS) function for the Internet Protocol, and is the product of an ad 28 hoc Internet 2 working group meeting held August 25-27, 1997 hosted 29 by Cisco Systems, Inc. This document is offered to the IP community 30 for its consideration and comments. 32 This document is organized as follows: Section 1 proposes a simple 33 classification scheme to describe QoS models. Subsequent sections 34 discuss requirements for Measurement, Administrative Policy, 35 Provisioning Issues, Network Environment and Implementation Issues. 37 1.0 QoS Model Classification 38 A QoS model can be conceptualized as a point in the following three- 39 space: (Scope, Control Model, Transmission Parameters) Each of the 40 these dimensions will be considered below. 42 I. Scope 43 The scope defines the boundaries of the QoS service. For example, 44 an end-to-end scope is accessible to applications on end systems. 45 An example of end-to-end scope is an RSVP reservation between 46 hosts to deliver a pre-specified level of QoS. An intermediate 47 scope service, on the other hand, does not necessarily allow end 48 systems access to the service interface. An example of 49 intermediate scope is an RSVP tunnel between two routers. 51 II. Control Model 52 A QoS Control Model describes the granularity, duration, and locus 53 of control of QoS requests. For example, QoS requests may be made 54 from either endpoints or intermediate locations (proxy control). 55 In addition, the effects of such requests may vary in both 56 granularity and duration. The granularity of a request may extend 57 from a single flow between hosts to a site level aggregation, 58 while the duration may extend from less than the lifetime of a 59 single flow to several months. 61 III. Transmission Parameters 62 Transmission parameters can be expressed either quantitatively or 63 qualitatively. They describe the definable and configurable 64 metrics of a QoS Model. Typical parameters are packet loss rate, 65 bandwidth, delay average and variation, and MTU. 67 The specification of transmission parameters must support 68 consistent interpretation and interoperability. 70 2.0 Measurement 71 Any network-provided differentiated service must be measurable from 72 the point of view of the user on an end system as well as by the 73 operators of any transit networks. The service requester needs to be 74 able to find out using a combination of load-generating tests and 75 user-readable network management variables if the service quality 76 that has been requested and granted is actually being delivered. 77 Notification of QoS failures to both end users and network operators 78 is encouraged. 80 The network operators need to be able to monitor their networks to be 81 sure that they are delivering the requested service and to be able to 82 bill for QoS usage. In the cases where the requested service is not 83 being delivered, interoperable mechanisms and tools are needed so 84 that fault isolation can be performed. The use of such tools may 85 require that the network operators make available particular access 86 to their network components so that they can be probed. 88 Implementation of these tools may require the development of new SNMP 89 MIBs that enable access to underlying QoS mechanisms on the 90 intermediate routers and end systems. Note that end system effects 91 such as poor interrupt response on desktop computers must be 92 considered when trying to understand the performance of the network 93 itself. 95 3.0 Administrative Policy 96 In order for QoS to be an effective tool, a rationing mechanism must 97 be in place to allow network management to control the use of 98 enhanced QoS capabilities. This mechanism must be enforced in the 99 routing systems but should rely on a locally defined admission 100 control mechanism that can take into account user authentication, 101 priviledge, ability to pay, etc. Initially, these mechanisms could be 102 manual or semi-automatic and could vary widely in granularity. 104 A critical element of any widely-deployed differentiated QoS support 105 is a scalable and interoperable administrative policy mechanism. The 106 granting or possible revocation of QoS requests is dependent on a 107 number of policy issues including authentication, authorization, 108 prioritization, preemption, and accounting. 110 QoS policy must be extensible eventually from a local network and the 111 campus network through the Gigapop to backbone networks and other 112 ISPs. A distributed set of QoS policy servers would be one means of 113 supporting this level of functionality. Implementation mechanisms 114 such as drop policy must be coordinated across administrative domains 115 for consistent behavior. 117 QoS mechanisms must be robust in the face of theft-of-service 118 attempts and various other attacks. 120 4.0 Provisioning considerations 121 A network operator must design and provision sufficient network 122 capacity for the quality of service that is offered or that quality 123 will not be delivered. We anticipate that provisioning a network 124 offering differential quality of service will be more difficult than 125 a best effort network. 127 Feedback mechanisms must exist within an administrative domain to 128 advise the network operator of situations when aggregate QoS 129 commitments approach or exceed network capacity. For example drop 130 rate must be able to be monitored, and if drops as a percentage of 131 load offered exceeds some threshold rate, then human intelligence 132 must be applied to determine why and what to do about it. 134 5.0 Network environment 135 A networking offering differential QoS must be designed so that 136 misbehaving applications do not adversely affect established QoS 137 commitments. In addition, it is desirable to have mechanisms to 138 limit the impact of such applications on best effort service. 140 We recognize that there are many multicast applications and the QoS 141 function should support them. For example, in many multicast 142 environments, there could be a heterogeneity of receivers with 143 different QoS requirements. 145 6.0 Implementation Notes 146 The implementation mechanisms for services of this type must be not 147 be constrained by Layer-2 substrates that are or will be deployed 148 across campus networks, Gigapops, and other provider backbones. On 149 the other hand, mechanisms should be able to exploit any QoS features 150 present in any substrates. 152 7.0 Security Considerations 153 There are many security issues concerning the use of any QoS service 154 on a real network. At the very least any preference of one user's 155 traffic over another's' opens the door for a denial of service 156 situation if the QoS controls are not secure. The full extent of the 157 security concerns remains to be determined. (also see section 3.0) 159 8.0 Participants 160 Fred Baker 161 Scott Bradner 162 Chris Buja 163 Steve Corbato 164 Laura Cunningham 165 Bruce Davie 166 Ken Hays 167 Ron Hutchins 168 Paul Hyder 169 Jim Leighton 170 David Meyer 171 Vishy Narayan 172 Becca Nitzan 173 Ben Teitelbaum 174 Steven Wallace 175 Steve Wolff 176 Paul J. Zawada 178 9.0 Author's Address 179 editor 180 Scott Bradner 181 Harvard University 182 1350 Mass Ave. 183 Cambridge MA 02138 185 +1 617 495 3864 186 sob@harvard.edu