idnits 2.17.1 draft-huston-pprec-discov-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-26) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 283: '...e not allowed" message, it MUST reduce...' RFC 2119 keyword, line 291: '...a host MUST attempt to avoid eliciting...' RFC 2119 keyword, line 297: '... PPrec Discovery MUST detect decreases...' RFC 2119 keyword, line 298: '...possible. Hosts MAY detect increases ...' RFC 2119 keyword, line 302: '...the current estimate) MUST NOT be done...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 346 has weird spacing: '...trative behav...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A host MUST not increase its estimate of the PPrec in response to the contents of a "precedence not allowed" message. A message purporting to announce an increase in the PPrec might be a stale packet that has been floating around in the Internet, a false packet injected as part of a denial-of-service attack, or the result of having multiple paths to the destination. -- 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 1996) is 9994 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: 10 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft Path Precedence Discovery December 1996 3 Path Precedence Discovery 5 Wed Dec 11 14:12:57 1996 7 Geoff Huston 8 Telstra 9 gih@telstra.net 11 Marshall T. Rose 12 Dover Beach Consulting, Inc. 13 mrose@dbc.mtview.ca.us 15 17 Status of this Memo 19 This document is an Internet Draft. Internet Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its Areas, and 21 its Working Groups. Note that other groups may also distribute working 22 documents as Internet Drafts. 24 Internet Drafts are valid for a maximum of six months and may be 25 updated, replaced, or obsoleted by other documents at any time. It is 26 inappropriate to use Internet Drafts as reference material or to cite 27 them other than as a "work in progress". 29 Abstract 31 This memo describes a technique for dynamically discovering the maximum 32 precedence (MPrec) of an arbitrary internet path. It specifies a small 33 change to the way that routers generate one type of ICMP messages. For 34 a path that passes through a router which does not implement this 35 change, this technique may not necessarily discover the correct Path 36 MPrec. In this case, an application which desires to make use of a 37 non-zero precedence should degrade gracefully. 39 draft Path Precedence Discovery December 1996 41 1. (A Lengthy) Introduction 43 Today's Internet is composed of many Internet Access Providers (IAPs), 44 connected in a disorganized graph. By and large, each IAP provisions 45 its own network independently of its neighbor IAPs. This leads to an 46 Internet mesh of widely-varying characteristics. 48 When an Internet consumer (henceforth "consumer") negotiates with an IAP 49 to provision service, the consumer enters into an agreement which 50 specifies a expected quality-of-service (eQoS) enjoyed by packets which 51 travel between the consumer's point of attachment with the IAP 52 (henceforth "consumer attachment") and anywhere throughout the IAP's 53 network. eQoS includes, but is not limited, to characteristics such as 54 throughput, latency, loss, availability and so on. Accordingly, if two 55 consumers subscribe to the same IAP, then they may determine eQoS for 56 the packets they exchange based on the "intersection" of their service 57 agreement parameters with that IAP. The eQoS is, of course, determined 58 in an out-of-band fashion. For example, two consumers may choose to 59 agree to subscribe to the same IAP for an identical level of service. 61 However, if two consumers subscribe to different IAPs, then it becomes 62 more difficult to determine the eQoS for the packets they exchange. 63 Simply put, there is no mechanism for communicating the eQoS exhibited 64 by the two IAP networks when they exchange traffic. Further, if the two 65 IAP networks do not share an interconnection point, but rather rely on 66 the services of one or more transit networks, then there is no a priori 67 predictability to the eQoS for the packets exchanged by the two 68 consumers. 70 A fully-general solution to this problem is far beyond the scope of this 71 memo. However, any problem can be solved...if the problem can be made 72 small enough! 74 In this context, observe that what is lacking in today's Internet is a 75 simple mechanism whereby IAPs may provision service which differentiates 76 traffic based on precedence (that is, packets with a higher precedence 77 value receive preferential treatment). Although RFC 791, the "Internet 78 Protocol" document, provides for a three-bit precedence field, the 79 _operational_ Internet lacks an mechanism whereby IAPs can treat traffic 80 preferentially. The reason, of course, is that there is no mechanism 81 available which allow a consumer to expect that asking for a higher 82 precedence results in preferential behavior. As a consequence, there is 83 no incentive for IAPs to provide preferential behavior on a cost- 84 differential basis. 86 draft Path Precedence Discovery December 1996 88 To solve this much smaller problem, IAPs must take two actions..lp 89 First, the IAP's routers must be configured to preferentially handle 90 packets based on their precedence. There are three aspects to this: 92 - precedence-ordered queue service (c.f., Section 5.3.3.1 of RFC 93 1812, the "Requirements for IP Version 4 Routers" document), which 94 (among other things) causes a router to order the forwarding 95 process and output interface queues based on highest precedence; 97 - precedence-based congestion control (c.f., Section 5.3.6 of RFC 98 1812), which causes a router to drop packets based on lowest 99 precedence; and, 101 - link layer priority features (c.f., Section 5.3.3.2 of RFC 1812), 102 which causes a router to select service levels of the lower layers 103 to provide preferential treatment. 105 Second, each router on the IAP's side of the consumer/IAP attachment 106 must discard packets higher than the maximum precedence (MPrec) for that 107 consumer site, and return an ICMP destination unreachable message with a 108 code indicating the consumer's MPrec. Naturally, one would expect that 109 the MPrec for the consumer site would be a new variable added into the 110 service agreement between the IAP and the consumer. The default MPrec, 111 of course, is zero, which is the common practice in today's Internet. 113 If the consumer opts to negotiate for a non-zero MPrec, then it must 114 have an expectation that the packets it sends with non-zero precedence 115 will be honored along the path from its IAP attachment to the 116 destination. Further, the consumer probably also wants an assurance 117 that the return traffic can also enjoy the same level of precedence. 118 This memo describes the protocol used in order probe an internet path 119 with respect to the precedence it supports. 121 However, before specifying the protocol, it is necessary to discuss some 122 aspects of provisioning a precedence-based facility in an IAP. 124 draft Path Precedence Discovery December 1996 126 2. RSVP Considered Harmful? 128 In a word, no. Having said that, we must be careful to describe why the 129 solution described in this memo is appropriate for today's Internet 130 environment, and why the RSVP-solution space is premature for today's 131 market. 133 An Internet network can be considered as a collection of switches and 134 interconnecting bandwidth. When provisioning a network to support a 135 single grade of service, the IAP must deploy adequate switches and 136 bandwidth to accomodate the offered load with an "acceptably low level" 137 of transit loss. 139 Although one could view an "acceptably low level" as no loss, the TCP 140 flow control algorithm uses packet loss as one threshold signal when 141 searching for a dynamic level of peak transmission throughput. As such, 142 it is perhaps more appropriate to define the acceptable level as one 143 which avoids periods of degenerative congestion-induced protocol 144 collapse. 146 When the network is placed under load stress the IAP has two options: 148 - augment the bandwidth and basic switching resources to a level 149 commensurate to the increase in load; or, 151 - increase the complexity of the switching algorithm being used. 153 In the latter case, the increased complexity of switching takes the form 154 of algorithms which perform precedence-ordered queue service. By 155 applying these algorithms, network performance is selectively 156 downgraded, allowing a category of network traffic greater access to 157 network resources. 159 2.1. Investment Economics 161 Ultimately, the choice between these options is based on investment 162 economics. 164 If the IAP purchases additional bandwidth outright, the IAP is making a 165 capital investment with a relatively long investment life. Instead, if 166 the IAP leases additional bandwidth, then given adequate supply, the IAP 167 is encountering a recurrent cost, scaling at a rate commensurate with 168 the growth in traffic volume. Both of these activities can be 169 undertaken with reasonable financial certainty given basic soundness in 170 draft Path Precedence Discovery December 1996 172 the provider's business structure. 174 Alternatively, if the IAP increases the level of switching complexity, 175 the IAP is encountering a capital cost with a relatively short 176 investment life cycle. Further, as the same switching algorithm must be 177 applied across higher traffic levels within a constant timeframe, this 178 capital cost increases as a function of transmission speed. 180 To reduce the impact of the scaling of the capital cost of switching 181 complexity, network state models, such as RSVP, were developed to 182 scaling the switching complexity in the face of increasing traffic 183 levels. 185 2.2. The Cost of Switching and Bandwidth 187 Since increasing the complexity of switching does not increase the 188 absolute level of traffic carried by the network, the IAP must apply 189 differential charges to high precedence traffic, in order to generate a 190 financial return on the investment in more complex switching systems. 191 In contrast, increasing bandwidth allows greater traffic volumes, which 192 result into an increased revenue stream, which offsets the cost of the 193 additional bandwidth. 195 As such, the costs of additional switching complexity and bandwidth must 196 be measured against the difference in revenue streams. 198 In general, switching complexity is less expensive than bandwidth only 199 when bandwidth is _very_ expensive, e.g., in international traffic 200 circuits, and in the context of an under-developed communications 201 infrastructure. Although significant, these environments are not 202 dominant parts of the Internet infrastructure. As a result, the end- 203 to-end environment is heterogenous, wherein: 205 - some providers will continue to offer a single grade of service, 206 using augmentation of bandwidth and single service level switching 207 complexity to service their traffic load; whilst 209 - other providers will adopt service class structures as a means of 210 management of the congestion impact of imposed traffic. 212 draft Path Precedence Discovery December 1996 214 2.3. QoS and Critical Mass 216 From the consumer's perspective, service quality results from end-to-end 217 behavior. Contracting for a particular eQoS is irrelevant unless that 218 service is supported across the path taken by the traffic. Indeed, 219 without a level of transitive bilateral, or multilateral, agreements on 220 policy for precedence there is no economic motivation for an Internet 221 Transit Provider (ITP) to honor a precedence request. 223 This leads to a situation where the investment in switching complexity 224 as a unilateral decision by one IAP yields no visible enhancement in 225 end-to-end QoS, even when both end subscribers have subscribed to an 226 enhanced service. For precedence to function in a useful fashion across 227 a multi-provider Internet there is a requirement for a critical number 228 of IAPs and ITPs to adhere to a common structure for honoring precedence 229 requests. 231 We claim, in an heterogenous environment, that it is not uniformly 232 economically attractive for network providers to multilaterally 233 subscribe to the implementation of a definition of an end-to-end network 234 state, e.g., RSVP, to support defined QoS measures. Instead, we claim 235 that it is viable for network providers to: 237 - elect to honor a common semantic structure which allows consumers 238 to make precedence requests; and, 240 - to give the consumer the capability to probe for precedence 241 capability for the path taken by its traffic. 243 This approach allows a graduated imposition of QoS across the Internet, 244 and allows the consumer the option to precedence request in those 245 situations where no appreciable benefit is derived. 247 draft Path Precedence Discovery December 1996 249 3. The Path Precedence (PPrec) Discovery Protocol 251 In brief: 253 - A consumer's host sends a packet with the desired precedence. 255 - If any of the routers along the packet's path are configured to 256 administratively disallow sending packets with that precedence, the 257 router discards the packet and returns an ICMP Destination 258 Unreachable message with a (new) code meaning "precedence not 259 allowed". 261 - Upon receipt of such a "precedence not allowed" message, the host 262 takes reacts based on the requirements of its application. For 263 example, an application might view a particular precedence as a 264 mandatory requirement, and opt not to communicate at that time. 265 Alternatively, it may direct the host to send packets with a lesser 266 precedence. 268 - The PPrec discovery process ends when the host's estimate of the 269 PPrec is low enough that its packets can be delivered without being 270 discarded for administrative reasons. 272 - Changes in the routing topology may reduce the PPrec, resulting in 273 packets being discarded and "precedence not allowed" messages being 274 returned. A host should react accordingly. Similarly, changes in 275 the routing topology may (silently) increase the PPrec. To probe 276 for this, a host may infrequently generate packets with a higher 277 precedence, providing such actions are not destructive to the host 278 application (i.e., receiving a subsequent "precedence not allowed" 279 message will not, by itself, abort a TCP connection). 281 3.1. Host specification 283 When a host receives a "precedence not allowed" message, it MUST reduce 284 its estimate of the MPrec for the relevant path, based on the value of 285 the Next-Hop Maximum Precedence field in the message (c.f., Section 286 3.2). No further specification is placed upon the hosts behavior, as 287 different applications may have different requirements, and since 288 different implementation architectures may favor different strategies. 290 It is required that after receiving a "precedence not allowed" message, 291 a host MUST attempt to avoid eliciting more such messages in the near 292 future, by reducing the precedence of the packets that it is sending 293 draft Path Precedence Discovery December 1996 295 along the path. 297 Hosts using PPrec Discovery MUST detect decreases in MPrec as fast as 298 possible. Hosts MAY detect increases in PPrec, but because doing so 299 requires sending packets larger than the current estimated PPrec, and 300 because the likelihood is that the PPrec will not have increased, this 301 MUST be done at infrequent intervals. An attempt to detect an increase 302 (by sending a packet larger than the current estimate) MUST NOT be done 303 less than 5 minutes after a "precedence not allowed" message has been 304 received for the given destination, or less than 1 minute after a 305 previous, successful attempted increase. It is RECOMMENDED that these 306 timers be set at twice their minimum values (10 minutes and 2 minutes, 307 respectively). 309 A host MUST not increase its estimate of the PPrec in response to the 310 contents of a "precedence not allowed" message. A message purporting to 311 announce an increase in the PPrec might be a stale packet that has been 312 floating around in the Internet, a false packet injected as part of a 313 denial-of-service attack, or the result of having multiple paths to the 314 destination. 316 3.2. Router specification 318 When a router is administratively configured to discard a packet because 319 it exceeds the precedence allowed for the packet's source, the router 320 MUST return an ICMP Destination Unreable message to the source of the 321 packet, with the code indicating "precedence not allowed" [[value TBD]]. 322 The router MUST include the maximum precedence allowed to the packet's 323 source in the Next-hop Maximum Precedence (NH-MPrec) field: 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type = 3 | Code = TBD | Checksum | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | unused = 0 | NH-MPrec | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Internet Header + 64 bits of Original Datagram Data | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 The value carried in the 8-bit Next-Hop MPrec field is: 336 Bits 0-2: Maximum precedence allowed over the next-hop for the 337 packet's source. 338 Bit 3-7: Reserved for Future Use. 340 draft Path Precedence Discovery December 1996 342 3.3. Determining if the Discovery Algorithm is Available 344 RFC 1812 makes no mention of administrative controls of precedence-based 345 routing, other than to say that that there must be a way to disable such 346 mechanisms. As such, there is no "standard" administrative behavior 347 for today's routers when they encounter packets with a non-zero 348 precedence field. 350 It is RECOMMENDED that routers be administratively configured to always 351 generate a "precedence not allowed" message when receiving a packet with 352 a precedence value of 7 (all-ones). This allows a sophisticated host to 353 send to probe for the existence of the PPrec Discovery algorithm by 354 sending packets to the destination with this all-ones value. (Of 355 course, this doesn't guarantee that algorithm is available at all 356 routers along the path, but it does provide a good initial estimate.) 358 4. Implementation Issues 360 The issues in handing PPrec Discovery are similar to those associated 361 with PMTU Discovery. Accordingly, the reader is directed to Section 6 362 of RFC 1191. 364 5. Security considerations 366 This PPrec Discovery mechanism makes possible a denial-of-service 367 attack, in which a third-party sends a false "precedence not allowed" 368 message indicates a Next-hop MPrec much smaller than reality. This may 369 cause an application which requires a higher PPrec to cease its efforts 370 to communicate. 372 A third-party party could also cause problems if it could stop a host 373 from receiving legitimate "precedence not allowed" messages, but in this 374 case there are simpler denial-of-service attacks available. 376 6. Acknowledgements 378 This proposal is inspired by RFC 1191, the "Path MTU Discovery" for IPv4 379 document. All good ideas contained herein have been borrowed freely 380 from other sources, whilst all bad ideas contained herein are wholly 381 new. 383 draft Path Precedence Discovery December 1996 385 7. Authors' Address 387 Geoff Huston 388 Telstra 389 5/490 Northbourne Ave 390 Dickson ACT 2609 391 UA 393 Tel: +1 61 208 1908 394 Fax: +1 61 248 6165 395 E-Mail: gih@telstra.net 397 Marshall T. Rose 398 Dover Beach Consulting, Inc. 399 11975 El Camino Real 400 Suite 200 401 San Diego, CA 92130 402 US 404 Tel: +1 619 793 2700 405 Fax: +1 619 793 2950 406 E-Mail: mrose@dbc.mtview.ca.us 408 draft Path Precedence Discovery December 1996 410 Table of Contents 412 1 (A Lengthy) Introduction ........................................ 2 413 2 RSVP Considered Harmful? ....................................... 4 414 2.1 Investment Economics .......................................... 4 415 2.2 The Cost of Switching and Bandwidth ........................... 5 416 2.3 QoS and Critical Mass ......................................... 6 417 3 The Path Precedence (PPrec) Discovery Protocol .................. 7 418 3.1 Host specification ............................................ 7 419 3.2 Router specification .......................................... 8 420 3.3 Determining if the Discovery Algorithm is Available ........... 9 421 4 Implementation Issues ........................................... 9 422 5 Security considerations ......................................... 9 423 6 Acknowledgements ................................................ 9 424 7 Authors' Address ................................................ 10