idnits 2.17.1 draft-ferguson-delay-drop-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-16) 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. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 are 10 instances of too long lines in the document, the longest one being 4 characters in excess of 72. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Figure 1' on line 126 -- Looks like a reference, but probably isn't: 'Figure 2' on line 154 ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '3') ** Obsolete normative reference: RFC 1349 (ref. '6') (Obsoleted by RFC 2474) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Paul Ferguson 2 November 7, 1997 cisco Systems, Inc. 3 Expires in six months 5 Simple Differential Services: 6 IP TOS and Precedence, Delay Indication, and Drop Preference 7 draft-ferguson-delay-drop-00.txt 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a 20 "working draft" or "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 Recent opinions and sentiments expressed in the Internet 31 Service Provider (ISP) community, as well as the Internet 32 community at-large, have voiced concern over the applicability 33 and scaleability of RSVP and the Integrated Service model in 34 the global Internet infrastructure. Convincing arguments have 35 been made for a differential services model which offers packet 36 delivery services better than traditional best effort, yet not 37 as resource intensive as RSVP. As a result, an effort within the 38 Intergrated Services working group has been examining methods to 39 provide simpler, less resource intensive methods of offering 40 differentiated services. This draft provides a practical method 41 to use bit values expressed in the IP Type or Service (TOS) 42 and IP precedence fields for delay indication and packet drop 43 preference, respectively. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 48 2. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Architectural Significance . . . . . . . . . . . . . . . . 4 50 3.1 Delay Indication . . . . . . . . . . . . . . . . . . . 5 51 3.2 Queuing Packets with Delay Indication . . . . . . . . 5 52 3.3 Drop Preference . . . . . . . . . . . . . . . . . . . 7 53 3.4 Preferential Drop Mechanism at Intermediate Nodes . . 7 54 3.5 Passive and Active admission . . . . . . . . . . . . . 8 55 4. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 5. Security Considerations. . . . . . . . . . . . . . . . . . 9 57 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 9 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . 9 59 8. Author's Address . . . . . . . . . . . . . . . . . . . . . 10 61 1. Introduction 63 Differentiated Quality of Service (QoS) has become a watchword 64 in the Internet community, at the expense of differentiated 65 definitions of the concept. While many had hoped that RSVP would 66 prove to be the mechanism to provide this functionailty, a large 67 contingent of Internet Service Providers (ISP's) have expressed 68 concern over the amount of computational, memory, and other 69 system resources which might be consumed by managing thousands, 70 or perhaps hundreds of thousands, of flows. 72 As a result, a small collective group within the IETF Integrated 73 Services working group has been examining several methods to define 74 less resource intensive mechanisms to provide differentiated 75 services -- somewhere between the traditional best effort model 76 and the guaranteed [1] and controlled-load [2] service models 77 defined in the Integrated Services architecture [3]. 79 This draft focuses on two fundamental issues -- a simplistic 80 method to signify a "delay indicator" in packets, as well as 81 a "drop preference" to indicate the relative priority of a 82 particular packet as it is transited through the network. 84 2. Background 86 One of the first questions that becomes immediately apparent in this 87 scheme is, "What are we trying to accomplish?" As mentioned previously, 88 there is a need for a QoS traffic scheme which provides reasonable 89 levels of differentiation, but yet which does not impose the path and 90 resource reservation state maintenance required by RSVP [4]. 92 The first order of business is to examine methods which provide a 93 simpler, less resource intensive method of differentiating traffic, 94 but at the same time requires no fundamental change in deployed 95 protocols, implementation, and only a modification in the 96 interpreted semantics of bit values in the IP TOS and precedence 97 fields, when used inconjunction with a differentiated services 98 implementation. 100 Without adding a new signaling protocol (which has, in and of itself, 101 been a topic of much dissension), the most logical place to consider for 102 placing indicators for differentiation is in the IP header. If we examine 103 the IP header, we find the 8 bit TOS field could indeed be used to convey 104 differential service information [Figure 1] [5]. This is due to the fact 105 that none of the bits within this particular field have been widely used 106 for anything to date. 108 0 1 2 3 109 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 |Version| IHL |Type of Service| Total Length | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Identification |Flags| Fragment Offset | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Time to Live | Protocol | Header Checksum | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | Source Address | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Destination Address | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Options | Padding | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 Example IPv4 Datagram Header [5] 126 [Figure 1] 128 0 1 2 3 4 5 6 7 129 +-----+-----+-----+-----+-----+-----+-----+-----+ 130 | | | | 131 | PRECEDENCE | TOS | MBZ | 132 | | | | 133 +-----+-----+-----+-----+-----+-----+-----+-----+ 135 Type of Service Byte [6] 137 [Figure 2] 139 As it exists today, RFC701 [5] suggests using the following 140 semantics of bit values which might be contained in the 141 precedence field, as depicted in [Figure 2]: 143 111 - Network Control 144 110 - Internetwork Control 145 101 - CRITIC/ECP 146 100 - Flash Override 147 011 - Flash 148 010 - Immediate 149 001 - Priority 150 000 - Routine 152 Additionally, RFC1349 [6] is the most current reference which 153 describes the semantics of the bit values which might be contained 154 in the 4 bit TOS field, also depicted in [Figure 2]: 156 1000 -- minimize delay 157 0100 -- maximize throughput 158 0010 -- maximize reliability 159 0001 -- minimize monetary cost 160 0000 -- normal service 162 This proposal modifies the intrinsic semantics of the values 163 of both of these fields when used in a differential services 164 implementation. It should be noted that as both of these bit value 165 semantics are currently defined in RFC791 and RFC1349, neither is 166 widely used for traffic differentiation in practice. 168 3. Architectural Significance 170 The objective in this approach is to provide a simplistic method 171 in which to indicate the intrinsic value of each packet presented 172 to the network for transit. Consider the following topology: 174 | 175 h1---->+ 176 | 177 h2---->+-->r--->R---->R--->R-----> [towards destination] 178 | 180 Consider h1 and h2 as the "hosts" which desire some sort of 181 "better-then-best-effort" service -- h1 may send traffic 182 which is somewhat delay sensitive (for example, real-time 183 loss-tolerant video), and h2 may send traffic which is not 184 delay sensitive (for example, batch ftp traffic), but is 185 considered to be of higher intrinsic value than traditional 186 best effort traffic (e.g. e-mail). 188 Each of the tools mentioned in this draft have very sepcific 189 architectural significance, or in other words, the effectiveness 190 each tool is dependent on where & how it is used at various 191 locations in the network topology. 193 3.1 Delay Indication 195 It should be again be mentioned that this approach does not provide 196 a priori knowledge of end-to-end network delay or maximal queuing 197 delay, as done with the Integrated Services guaranteed service 198 model. What it does attempt to provide, however, is a mechanism 199 to identify packets which belong to traffic flows for which predictable 200 queuing behavior is desired. 202 The following semantics (Delay Indication) is proposed for differential 203 services implementations in addition to existing RFC1349 TOS semantics: 205 Bit Existing Delay 206 Value Semantics Indication 208 1000 -- minimize delay Highest delay sensitivity 209 0100 -- maximize throughput . 210 0010 -- maximize reliability . 211 0001 -- minimize monetary cost Lowest delay sensitivity 212 0000 -- normal service No delay sensitivity 214 The values 0100 (maximize throughput) and 0010 (maximize 215 reliability) can be used as incremental delay indication values 216 to represent any arbitrary delay sensitivity which falls between 217 the "highest" and "lowest" delay sensitivity value indicators. 219 3.2 Queuing Packets with Delay Indication 221 There are perhaps several methods which could be used to 222 map packets with the delay indication (expressed in Section 223 3.1) to specific queues as a mechanism to provide predicatble 224 transmission behavior. This relies on the queuing discipline 225 used, as well as the queue servicing characteristics. The most 226 interesting, and perhaps most effective, method of doing this 227 is to map packets to different CBQ (Class Based Queuing) [7] 228 queues. 230 There are at least two choices with reagrds to where CBQ could 231 be deployed in this architectural model. A CBQ-like mechanism 232 should be implemented on the first-hop ingress router (r), but 233 can also be implemented on each intermediate router in the 234 transit path (R). However, it is unlikely that the latter 235 model is realistic in the global Internet, due to the fact that 236 intermediate routers in the transit path between the source 237 and destination may reside in various different administrative 238 domains. Also, it is unclear that a preferential queuing discipline 239 is actually needed at subsequent intermediate nodes. 241 Simple Delay Indication to CBQ mapping example: 243 delay +-----------------------------+ 244 sensitivity | CBQ queue depth | 245 | | 246 | | 247 | +-------------------+ | 248 0010-+ | +->| |-+ | 249 | | | +-------------------+ | | towards 250 | | | | | destinations 251 +-------+ +----------------+ +--------> 252 0100----------->| |----------------> 253 +-------+ +----------------+ +-------> 254 | | | | | 255 | | | +--------+ | | 256 1000-+ | +->| |-------------+ | 257 | +--------+ | 258 | | 259 +-----------------------------+ 261 Router 263 Incoming 264 packets with CBQ queue 265 delay depths proportional 266 indication to relative transmit 267 priority 269 The CBQ queue servicing algorithm may be implementation specific, 270 but it is important to note that the desired functionality is for 271 packets with a 'higher' delay sensitivity indication to be 272 transmited prior to those with 'lower' delay sensitivity inication. 274 It is also important to note that this is simply an example of 275 how the delay indication bits could be used, not a mandatory 276 implementation. We believe it is prudent to allow implementors 277 to determine how these mechanics will be deployed -- it is only 278 important to agree on the bit value semantics. 280 3.3 Drop Preference 282 There is at least one known implementation of preferntial 283 packet drop which uses the values expressed in the IP 284 precedence field, as described in [5], and this draft 285 does not modify the semantics of the existing IP precedence 286 values defined below [5]. Instead, a suggested interpretation 287 of these values is provided below which modifies the existing 288 semantics when used inconjunction with a differential services 289 implementation: 291 Bit Existing Drop Preference 292 Value Semantics Semantics 294 111 - Network Control Lowest 295 110 - Internetwork Control . 296 101 - CRITIC/ECP . 297 100 - Flash Override . 298 011 - Flash . 299 010 - Immediate . 300 001 - Priority . 301 000 - Routine Highest 303 The values which fall between 110 (Internetwork Control) 304 and 001 (Priority) can be used to represent any arbitrary 305 incremental drop preference between "lowest" and "highest" 306 drop preference values, 111 and 000 respectively. This is 307 could be considered a matter of local policy. 309 3.4 Preferential Drop Mechanism at Intermediate Nodes 311 It is important to note that if congestion is not experienced 312 at an intermediate transit node, then no action (e.g. packet 313 discard) is taken -- packets are forwarded in the order in which 314 they are received. 316 The concept of preferential drop, or packet discard, only becomes 317 an issue should congestion be imminent. The most effective method 318 of mitigating congestion is to use Random Early Detection (RED) 319 [8], such that congestion and global synchronization [9] (and 320 ultimately congestion collapse) is avoided to the maximum extent 321 possible. 323 However, basic RED functionality can be considered to be 324 somewhat "fair", in that packets are pseudo- randomly selected 325 for discard as the queue depth(s) reaches an arbitrary, 326 administratively-defined threshold. What is needed is a more 327 "unfair", or preferential, method of selecting packets for 328 discard when the queue depth(s) exceed the threshold. 330 A modified RED behavior is discussed in [10], whereas the relative 331 priority of packets (as discussed in Section 3.2) is considered in 332 the packet discard decision process. 334 This "unfair" and "enhanced" RED should be implemented on each node 335 (R) in the traffic transit path. 337 Again, it is also important to note that this is simply an example 338 of how the drop preference bits could be used, not a mandatory 339 implementation. We believe it is prudent to allow implementors 340 to determine how these mechanics will be deployed -- it is only 341 important to agree on the bit value semantics. 343 3.5 Passive and Active admission 345 There are two possible scenarios for how packets are marked as 346 they enter the network. The hosts (for example h1 and h2) could 347 set the TOS (delay indication) and precedence values (drop 348 preference) in their IP packets as they see fit, and the first-hop 349 ingress router (r) could simply accept traffic "as is" without 350 examining or policing it, and simply forward it on it's way 351 unimpeded. This is passive admission. 353 The alternative approach is for the first-hop ingress router (r) 354 to actively profile, monitor, and police traffic which is presented 355 to it for transit. The method of performing this active admission 356 control can be implementation-specific, but there is at least one 357 method that we understand, and which works well. This is the use of 358 a token-bucket implemented on (r), or perhaps mutiple token-buckets, 359 which uses thresholds to mark packets based upon their compliance 360 or non-compliance (or both) to a bit rate threshold. A similar 361 method for marking packets in this fashion is discussed in [11]. 362 The ingress router is also an ideal point in the topology to mark 363 packet indication insofar as host address or application (TCP or 364 UDP port). 366 4. Summary 368 The mechanisms discussed in this proposal are simple and effective 369 methods to provide reasonably predictable service differentiation 370 for traffic presented to the network. It should be noted, however, 371 that the effectiveness of the deployment of these tools relies 372 somewhat on the engineering of the network architecture, in that if 373 the network is drastically under-provisioned and severely congested, 374 these tools become noticeably less effective. This is the intrinsic 375 difference between service quality and quality of service (QoS), in 376 that if the network is poorly provisioned or excessively unstable 377 (poor service quality), the effectiveness of any tool that attempts 378 to provide service differentiation (QoS) is effectively diminished. 380 Having said that, however, traffic entering the network will indeed 381 be provided preferential queuing and transmission if the delay 382 indication bits are set accordingly, and traffic will be discarded 383 at intermediate nodes in accordance with the drop preference indication 384 set in the packets themselves. 386 These use of delay indication and drop preference are not 387 necessarily mutually exclusive -- they can be used independently 388 or in conjunction with one another. However, use of the delay 389 indication bits requires the use of preferential queueing and 390 transmission at the network ingress router, and likewise, use 391 of the drop preference bits requires that a preferential drop 392 mechanism be used on each intermediate node in the transit path, 393 in order for these mechanisms to be effective. 395 5. Security Considerations 397 Inherently, it may be necessary to provide some sort of policy 398 mechanism at the network ingress node to ensure that only 399 "authorized" entities or applications can obtain preferential 400 use of network resources. This is a local policy matter, and 401 the implementation of such policy mechanisms are not discussed 402 in this memo. 404 6. Acknowledgments 406 Special thanks to Juha Heinanen (Telia) for his assistance 407 in reviewing this memo. 409 7. References 411 [1] RFC2212, "Specification of Guaranteed Quality of Service," 412 S. Shenker, C. Partridge, R. Guerin, September 1997. 414 [2] RFC2211, "Specification of the Controlled-Load Network Element 415 Service," J. Wroclawski, September 1997. 417 [3] RFC1633, "Integrated Services in the Internet Architecture: An 418 Overview," R. Braden, D. Clark, S. Shenker, June 1994. 420 [4] RFC2205, "Resource ReSerVation Protocol (RSVP) Version 1 421 Functional Specification," R. Braden, L. Zhang, S. Berson, 422 S. Herzog, S. Jamin, September 1997. 424 [5] RFC791, "INTERNET PROTOCOL, DARPA INTERNET PROGRAM PROTOCOL 425 SPECIFICATION," September 1981. 427 [6] RFC1349, "Type of Service in the Internet Protocol Suite," 428 P. Almquist. July 1992. 430 [7] "Link-sharing and Resource Management Models for Packet 431 Networks," Floyd, S., and Jacobson, V., IEEE/ACM Transactions 432 on Networking, Vol. 3 No. 4, pp. 365-386, August 1995. 433 http://ftp.ee.lbl.gov/floyd/cbq.html 435 [8] "Random Early Detection Gateways for Congestion Avoidance," 436 S. Floyd, V. Jacobson, IEEE/ACM Transactions on Networking, 437 v.1, n.4, August 1993. 438 http://www-nrg.ee.lbl.gov/floyd/red.html 440 [9] "Oscillating Behavior of Network Traffic: A Case Study 441 Simulation," L. Zhang, D. Clark, Internetwork: Research and 442 Experience, Volume 1, Number 2, John Wiley & Sons, 1990, pages 443 101-112. 445 [10] "Understanding TCP Dynamics in an Integrated Services 446 Internet," W. Feng, D. Kandlur, D. Saha, K. Shin, NOSSDAV 447 '97, May 1997. 448 http://www.eecs.umich.edu/~wuchang/work/nossdav97.ps.Z 450 [11] "Adaptive Packet Marking for Providing Differentiated 451 Services in the Internet," W. Feng, D. Kandlur, D. Saha, 452 K. Shin, U. Michigan CSE-TR-347-97, October 1997. 453 http://www.eecs.umich.edu/~wuchang/work/pmg.ps.Z 455 8. Author's address 457 Paul Ferguson 458 cisco Systems, Inc. 459 400 Herndon Parkway 460 Herndon, VA USA 20170 461 Email: ferguson@cisco.com