idnits 2.17.1 draft-feng-dp-services-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-04-25) 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 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 a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (December 1998) is 9263 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) == Unused Reference: 'Ferguson' is defined on line 249, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ATM94' -- Possible downref: Non-RFC (?) normative reference: ref. 'ATM96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Clark95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Clark97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Feng97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Feng97a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ferguson' -- Possible downref: Non-RFC (?) normative reference: ref. 'Diffserv' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kilkki' -- Possible downref: Non-RFC (?) normative reference: ref. 'Nichols' -- Possible downref: Non-RFC (?) normative reference: ref. 'Weiss' Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Wu-chang Feng 2 INTERNET-DRAFT University of Michigan 3 draft-feng-dp-services-00.txt June 1998 4 Expires December 1998 6 Drop Preference Services 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 Abstract 30 Drop preference has been proposed as a possible means for providing 31 differentiated services in the Internet. Used as a parameter in a 32 PHB group, drop preference can provide weighted bandwidth sharing 33 amongst flows and flow aggregates of a PHB group. This memo 34 documents a number of services which can be implemented using either 35 a single drop preference PHB setting or multiple drop preference 36 settings. 38 1. Introduction: 40 Drop preference (DP) has been proposed in both connection-oriented 41 [ATM94,ATM96] and connectionless networks [Diffserv] as a means to 42 provide service differentiation between indivitual flows and flow 43 aggregates. The idea behind drop preference is to mark packets with 44 different drop priorities and to selectively drop lower priority 45 packets when network resources are congested. In all of its 46 proposed forms, drop preference is used to provide some form of 47 weighted bandwidth sharing between flows in the network. Depending 48 on how packets are marked, a variety of services can be implemented 49 with this functionality. This memo documents a number of proposed 50 services which can be implemented using either a single or multiple 51 drop preference settings/parameters within a PHB group. Services 52 implementable using the expedited forwarding (EF) PHB [Nichols] are 53 beyond the scope of this document. 55 2. Differential Services Architecture 57 Drop preference marking, in its current diffserv context, is done at 58 the network edges using traffic conditioners (markers) which set the 59 appropriate PHB fields. In the differential services framework, 60 drop preference can used as a parameter within a PHB group in order 61 to provide service differentiation between flows of a particular PHB 62 group. Within the network, the PHB setting specifies a local 63 forwarding treatment or mechanism for transmitting the packet. 64 While the proposed mechanisms and algorithms for providing drop 65 preference functionality differ, most of them share the same basic 66 characteristics [Clark95,Clark97,Feng97,Feng97a,Kilkki]. In 67 particular, the mechanisms rely on queueing decisions at the 68 bottleneck link in times of congestion. When such situations occur 69 and queues build up, packets with lower priorities are dropped 70 preferentially in an attempt to reduce the offered load at the 71 bottleneck. In most cases, it is assumed that the packets of 72 individual flows, regardless of their DP setting, are not re-ordered 73 by the router. The use of drop preference gives the network a 74 simple, low-overhead, fine-grained means to control bandwidth usage. 75 By controlling the amount of priority marking done, the network can 76 effectively control the bandwidth usage over time for individual 77 flows and flow aggregates. 79 3. Two-level Drop Preference Services 81 There have been several proposed services which use a two-level drop 82 preference setting as a building block in their implementations. 84 3.1 Assured and Controlled-load Services 86 In both assured and controlled-load service, the marker/policer 87 determines the drop preference setting based on a fixed profile. In 88 assured service [Clark95,Clark97] the profile is based on the 89 expected capacity of a flow/aggregate in times of congestion. The 90 profile itself uses a fairly long sliding window to measure 91 bandwidth usage. Based on this profile, packets within their 92 expected capacity profile are marked as "In" (conformant) and given 93 a higher priority. When congestion occurs and queues build up, low 94 priority packets are dropped first while high priority packets are 95 still allowed in the queue. In controlled-load service 96 [Wroclawski], and in particular its diffserv implementation 97 [Feng97], the profile is based on a token bucket specification of 98 the flow or flow aggregate. Packets which are within the traffic 99 envelope, as specified by the token bucket, are sent with higher 100 priority while excess traffic is sent along with normal traffic with 101 lower priority. In both cases, because of the burstiness of the 102 traffic being policed and the dynamics of TCP congestion control, a 103 large profile must be used in order to maintain predictable quality 104 of service. 106 The marking behavior of assured and controlled-load service affords 107 flows a constant amount of marking regardless of their sending rate 108 at all times. That is, when a flow/aggregate sends an arbitrary 109 amount over its profile, the marker still marks packets at the rate 110 indicated in the profile. This marking differentiates the two 111 services from SIMA and CBR as described below. 113 3.2 Two-level SIMA (Simple Integrated Media Access) 115 The original SIMA service [Kilkki], as described in Section 4, uses 116 multiple drop preference levels to provide service differentiation 117 between flows in times of congestion. In SIMA, sources contract a 118 sending rate with the network referred to as a nominal bit rate 119 (NBR). This rate serves as a profile from which drop preference 120 marking is done. Depending on the actual rate the source sends, the 121 network marks each packet of a flow with a particular drop 122 preference setting which is calculated as a function of the profile 123 and the actual sending rate. When the source sends at rates below 124 its profile, its packets are marked with increasingly higher 125 priority. In contrast, when the source sends at rates above its 126 profile, its packets are marked with increasingly lower priority. 127 The effect of this type of SIMA marking is to ensure that flows 128 within their contracted rate receive a low amount of loss when 129 congestion occurs. Flows which increasingly send above their 130 contracted rate see increasingly higher packet loss rates in times 131 of congestion as the SIMA marker changes lowers their priorities. 132 While SIMA relies on using multiple drop priorities, it is possible 133 to build a SIMA-like service using a two-level drop preference 134 scheme. Instead of marking all of a flow's packets with a 135 particular drop priority, a variable fraction of a flow's packets 136 can be marked with either high or low priority. Flows sending below 137 the profile have most of their packets marked with high priority. 138 As flows send increasingly above their profile, the amount of high 139 priority marking given steadily decreases to zero. 141 The marking behavior of this implementation of SIMA is different 142 than both assured service and controlled-load service in that the 143 amount of marking steadily decreases as the flow/aggregate exceeds 144 its profile. As described above, the marking remains constant in 145 assured and controlled-load service regardless of the amount of data 146 the sources are sending above the profile. 148 3.3 CBR 150 Drop preference can also be used to implement a constant bit rate 151 service [Feng97a]. As in assured service, the marker/policer 152 observes the bandwidth usage of a connection using a sliding window 153 and uses the contracted bit rate as a profile for determining its 154 marking behavior. The marker implementing CBR service attempts to 155 mark a minimal amount of packets in order for the flow/aggregate to 156 meet its contracted profile. Thus, for a given profile, the CBR 157 marker marks packets at a rate which is less than or equal to that 158 of the assured and controlled-load services. The marker does this 159 by observing the sending rate of the flow/aggregate over the sliding 160 window. As long as the flow/aggregate is sending above its profile, 161 the marker slowly reduces its marking. As long as the 162 flow/aggregate is sending below its profile, the marker slowly 163 increases its marking. Over a period of time, such adaptive marking 164 delivers the flow/aggregate a constant amount bandwidth. By 165 minimizing the amount of priority packets in the network, the CBR 166 marker can help improve the performance of priority-based queueing 167 algorithms in the network. 169 The marking behavior of CBR is different than the above services in 170 that marking is reduced to zero when the flow/aggregate exceeds its 171 profile. This is in contrast to the assured and controlled-load 172 services which maintain a constant rate of marking regardless of the 173 flow/aggregate's actual sending rate and in contrast to SIMA which 174 slowly reduces the marking as the flow/aggregate increases its rate. 176 4. Multi-level Drop Preference Services 178 Several services which use more than two drop preference levels have 179 been proposed to provide weighted bandwidth sharing amongst flows 180 and flow aggregates. 182 4.1 SIMA 184 As described earlier, the original SIMA service uses multiple drop 185 priorities to provide service differentiation between flows. In 186 this service, marking is done strictly based on the sending rate of 187 the flow/aggregate and its negotiated rate (NBR). The SIMA marker 188 marks all of the packets of a particular flow/aggregate with the 189 same priority according to how much it is sending with regard to its 190 profile. As the source(s) increasingly sends above its profile, the 191 marker steadily decreases the drop priority. 193 4.2 Proportional Sharing 195 Cooperative Dropping [Weiss] is a framework for flexibly providing a 196 number of bandwidth services (including proportional sharing) using 197 multiple drop priorities. In this scheme, the packets of a 198 flow/aggregate are striped across the multiple priority levels. At 199 each intermediate router, preferential dropping is done depending on 200 the priority level of the packets and the current level of 201 congestion. Given an incoming multi-priority traffic stream, the 202 congested router adaptively selects a drop priority threshold in 203 which all packets below the threshold are dropped. Depending on how 204 the packets of a flow/aggregate are striped across the multiple 205 priorities, proportional sharing and a variety of other services can 206 potentially be implemented. For example, using the preferential 207 dropping mechanism in conjunction with a marker which stripes a 208 flow/aggregate's packets evenly across all priorities, sharing in 209 direct proportion to the flow/aggregate's sending rate can be 210 achieved. Note that the granularity and accuracy of the bandwidth 211 sharing is dependent on the number of priority levels used. Using 212 more priority levels results in a finer degree of bandwidth sharing. 214 The marking behavior of proportional sharing, given a profile per 215 priority level, remains fixed. Additional marking policies in the 216 cooperative dropping framework can be deployed, however, in order to 217 implement a larger range of services. 219 5. References 221 [ATM94] ATM User-Network Interface (UNI) Signalling 222 Specification Version 3.1 (af-uni-0010.002), 223 September 1994. 225 [ATM96] ATM Traffic Management Specification Version 4.0 226 (af-tm-0056.000), April 1996. 228 [Clark95] D. Clark, "Adding Service Discrimination to the 229 Internet", 230 http://ana-www.lcs.mit.edu/anaweb/ps-papers/TPRC2-0.ps, 231 September 1995. 233 [Clark97] D. Clark and J. Wroclawski, "An Approach to Service 234 Allocation in the Internet", Internet Draft 235 , July 1997. 237 [Feng97] W. Feng, D. Kandlur, D. Saha, and K. Shin, 238 "Understanding TCP Dynamics in an Integrated Services 239 Internet", Proc. of NOSSDAV '97, 240 http://www.eecs.umich.edu/~wuchang/ered/ , 241 July 1997. 243 [Feng97a] W. Feng, D. Kandlur, D. Saha, and K. Shin, "Adaptive 244 Packet Marking for Providing Differentiated Services 245 in the Internet", UM CSE-TR-347-97, 246 http://www.eecs.umich.edu/~wuchang/pmg/ , 247 September 1997. 249 [Ferguson] P. Ferguson, "Simple Differential Services: IP TOS and 250 Precedence, Delay Indication, and Drop Preference, 251 Internet Draft , 252 November 1997. 254 [Diffserv] Differentiated Services Framework Draft, May 1998. 256 [Kilkki] K. Kilkki, "Simple Integrated Media Access (SIMA)", 257 Internet Draft 258 , June 1997. 260 [Nichols] K. Nichols and S. Blake, "Definition of the 261 Differentiated Services Field (DS Byte) in the IPv4 262 and IPv6 Headers", Internet Draft 263 , May 1998. 265 [Weiss] W. Weiss, "Providing Differentiated Services through 266 Cooperative Dropping and Delay Indication", Internet 267 Draft , March 1998. 269 [Wroclawski] J. Wroclawski, "Specification of the Controlled-Load 270 Network Element Service." RFC 2211, September 1997. 272 Author's Address 274 Wu-chang Feng 275 University of Michigan 276 Dept. of EECS 277 Real-time Computing Laboratory 278 1301 Beal Ave./2228 EECS Building 279 Ann Arbor, MI 48109-2122 280 Phone: +1-734-763-5363 281 Fax: +1-734-763-4617 282 E-mail: wuchang@eecs.umich.edu