idnits 2.17.1 draft-ietf-intserv-ctrl-load-svc-03.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-19) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 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. ** 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 253: '... elements MUST return an error for r...' RFC 2119 keyword, line 254: '...Network elements MUST return an error ...' RFC 2119 keyword, line 261: '...igabytes. Network elements MUST return...' RFC 2119 keyword, line 263: '... elements MUST return an error for a...' RFC 2119 keyword, line 292: '...Network elements MUST reject a service...' (5 more instances...) 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: 'RFCGP' on line 320 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Integrated Services WG 2 INTERNET-DRAFT J. Wroclawski 3 draft-ietf-intserv-ctrl-load-svc-03.txt MIT LCS 4 August, 1996 5 Expires: 2/97 7 Specification of the Controlled-Load Network Element Service 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 months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress". 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 This draft is a product of the Integrated Services Working Group of 28 the Internet Engineering Task Force. Comments are solicited and 29 should be addressed to the working group's mailing list at int- 30 serv@isi.edu and/or the author(s). 32 Abstract 34 This memo specifies the network element behavior required to 35 deliver Controlled-Load service in the Internet. Controlled-load 36 service provides the client data flow with a quality of service 37 closely approximating the QoS that same flow would receive from an 38 unloaded network element, but uses capacity (admission) control to 39 assure that this service is received even when the network element 40 is overloaded. 42 1. Introduction 44 This document defines the requirements for network elements that 45 support the Controlled-Load service. This memo is one of a series of 46 documents that specify the network element behavior required to 47 support various qualities of service in IP internetworks. Services 48 described in these documents are useful both in the global Internet 49 and private IP networks. 51 This document is based on the service specification template given in 52 [1]. Please refer to that document for definitions and additional 53 information about the specification of qualities of service within 54 the IP protocol family. 56 2. End-to-End Behavior 58 The end-to-end behavior provided to an application by a series of 59 network elements providing controlled-load service tightly 60 approximates the behavior visible to applications receiving best- 61 effort service *under unloaded conditions* from the same series of 62 network elements. Assuming the network is functioning correctly, 63 these applications may assume that: 65 - A very high percentage of transmitted packets will be 66 successfully delivered by the network to the receiving end-nodes. 67 (The percentage of packets not successfully delivered must closely 68 approximate the basic packet error rate of the transmission 69 medium). 71 - The transit delay experienced by a very high percentage of the 72 delivered packets will not greatly exceed the minimum transmit 73 delay experienced by any successfully delivered packet. (This 74 minimum transit delay includes speed-of-light delay plus the fixed 75 processing time in routers and other communications devices along 76 the path.) 78 To ensure that these conditions are met, clients requesting 79 controlled-load service provide the intermediate network elements 80 with a estimation of the data traffic they will generate; the TSpec. 81 In return, the service ensures that network element resources 82 adequate to process traffic falling within this descriptive envelope 83 will be available to the client. Should the client's traffic 84 generation properties fall outside of the region described by the 85 TSpec parameters, the QoS provided to the client may exhibit 86 characteristics indicative of overload, including large numbers of 87 delayed or dropped packets. The service definition does not require 88 that the precise characteristics of this overload behavior match 89 those which would be received by a best-effort data flow traversing 90 the same path under overloaded conditions. 92 NOTE: In this memo, the term "unloaded" is used in the sense of 93 "not heavily loaded or congested" rather than in the sense of "no 94 other network traffic whatsoever". 96 3. Motivation 98 The controlled load service is intended to support a broad class of 99 applications which have been developed for use in today's Internet, 100 but are highly sensitive to overloaded conditions. Important members 101 of this class are the "adaptive real-time applications" currently 102 offered by a number of vendors and researchers. These applications 103 have been shown to work well on unloaded nets, but to degrade quickly 104 under overloaded conditions. A service which mimics unloaded nets 105 serves these applications well. 107 The controlled-load service is intentionally minimal, in that there 108 are no optional functions or capabilities in the specification. The 109 service offers only a single function, and system and application 110 designers can assume that all implementations will be identical in 111 this respect. 113 Internally, the controlled-load service is suited to a wide range of 114 implementation techniques, including evolving scheduling and 115 admission control algorithms that allow implementations to be highly 116 efficient in the use of network resources. It is equally amenable to 117 extremely simple implementation in circumstances where maximum 118 utilization of network resources is not the only concern. 120 4. Network Element Data Handling Requirements 122 Each network element accepting a request for controlled-load service 123 must ensure that adequate bandwidth and packet processing resources 124 are available to handle the requested level of traffic, as given by 125 the requestor's TSpec. This must be accomplished through active 126 admission control. All resources important to the operation of the 127 network element must be considered when admitting a request. Common 128 examples of such resources include link bandwidth, router or switch 129 port buffer space, and computational capacity of the packet 130 forwarding engine. 132 The controlled-load service does not accept or make use of specific 133 target values for control parameters such as delay or loss. Instead, 134 acceptance of a request for controlled-load service is defined to 135 imply a commitment by the network element to provide the requestor 136 with service closely equivalent to that provided to uncontrolled 137 (best-effort) traffic under lightly loaded conditions. 139 The definition of "closely equivalent to unloaded best-effort 140 service" is necessarily imprecise. It is easiest to define this 141 quality of service by describing the events which are expected to 142 *not* occur with any frequency. A flow receiving controlled-load 143 service at a network element may expect to experience: 145 - Little or no average packet queueing delay over all timescales 146 significantly larger than the "burst time". The burst time is 147 defined as the time required for the flow's maximum size data burst 148 to be transmitted at the flow's requested transmission rate, where 149 the burst size and rate are given by the flow's TSpec, as described 150 below. 152 - Little or no congestion loss over all timescales significantly 153 larger than the "burst time" defined above. In this context, 154 congestion loss includes packet losses due to shortage of any 155 required processing resource, such as buffer space or link 156 bandwidth. Although occasional congestion losses may occur, any 157 substantial sustained loss represents a failure of the admission 158 control algorithm. 160 The basic effect of this language is to establish an expectation on 161 the *duration* of a disruption in delivery service. Events of shorter 162 duration are viewed as statistical effects which may occur in normal 163 operation. Events of longer duration are indicative of failure to 164 allocate adequate capacity to the controlled-load flow. 166 A network element may employ statistical approaches to decide whether 167 adequate capacity is available to accept a service request. For 168 example, a network element processing a number of flows with long- 169 term characteristics predicted through measurement of past behavior 170 may be able to overallocate its resources to some extent without 171 reducing the level of service delivered to the flows. 173 A network element may employ any appropriate scheduling means to 174 ensure that admitted flows receive appropriate service. 176 NOTE: The flexibility implied by the above paragraph exists within 177 definite limits. Readers should observe that the specification's 178 requirement that the delay and loss behavior described above 179 imposes concrete requirements on implementations. 181 Perhaps the most important requirement is that the implementation 182 has to make bandwidth greater than the Tspec token rate available 183 to the flow in certain situations. The requirement for the 184 availability of extra bandwidth may be derived from the fluid 185 model of traffic scheduling (e.g. [7]). If a flow receives exactly 186 its promised token rate at all times, queueing caused by an over- 187 rate burst arriving at the network element may never clear, 188 causing the traffic queueing delay to permanantly increase. This 189 will happen if the flow continues to generate traffic at exactly 190 the token rate after emitting the burst. 192 To control the long-term effects of traffic bursts, a Controlled 193 Load implementation has several options. At minimum, a mechanism 194 must be present to "borrow" bandwidth needed to clear bursts from 195 the network. There are a number of ways to implement such a 196 mechanism, ranging from explicit borrowing schemes within the 197 traffic scheduler to implicit schemes based on statistical 198 multiplexing and measurement-based admission control. The 199 specification does not prefer any method over any other, but does 200 require that some such mechanism must exist. 202 Similarly, the requirement for low congestion loss for in-Tspec 203 traffic implies that buffer management must have some flexibility. 204 Because the controlled-load service does not reshape traffic to 205 its token-bucket parameters at every node, traffic flowing through 206 the network will be distorted as it traverses queueing points. 207 This distortion is particularly likely to occur during traffic 208 bursts, precisely when buffering is most heavily used. In these 209 circumstances, rigidly restricting the buffering capacity to a 210 size equal to the flow's TSpec burst size may lead to congestion 211 loss. An implementaton should be prepared to make additional 212 buffering available to bursting flows. Again, this may be 213 accomplished in a number of ways. One obvious choice is 214 statistical multiplexing of a shared buffer pool. 216 Links are not permitted to fragment packets which receive the 217 controlled-load service. Packets larger than the MTU of the link must 218 be treated as nonconformant to the TSpec. This implies that they will 219 be forwarded according to the rules described in the Policing section 220 below. 222 Implementations of controlled-load service are not required to 223 provide any control of short-term packet delay jitter beyond that 224 described above. However, the use of packet scheduling algorithms 225 that provide additional jitter control is not prohibited by this 226 specification. 228 Packet losses due to non-congestion-related causes, such as link 229 errors, are not bounded by this service. 231 5. Invocation Information 233 The controlled-load service is invoked by specifying the data flow's 234 desired traffic parameters (TSpec) to the network element. Requests 235 placed for a new flow will be accepted if the network element has the 236 capacity to forward the flow's packets as described above. Requests 237 to change the TSpec for an existing flow should be treated as a new 238 invocation, in the sense that admission control must be reapplied to 239 the flow. Requests that reduce the TSpec for an existing flow (in the 240 sense that the new TSpec is strictly smaller than the old TSpec 241 according to the ordering rules given below) should never be denied 242 service. 244 The Controlled-Load service uses the TOKEN_BUCKET_TSPEC defined in 245 Reference [5] to describe a data flow's traffic parameters. This 246 TSpec takes the form of a token bucket specification plus a peak rate 247 (p), a minimum policed unit (m) and a maximum packet size (M). 249 The token bucket specification includes a bucket rate r and a bucket 250 depth, b. Both r and b must be positive. The rate, r, is measured 251 in bytes of IP datagrams per second. Values of this parameter may 252 range from 1 byte per second to 40 terabytes per second. Network 253 elements MUST return an error for requests containing values outside 254 this range. Network elements MUST return an error for any request 255 containing a value within this range which cannot be supported by the 256 element. In practice, only the first few digits of the r parameter 257 are significant, so the use of floating point representations, 258 accurate to at least 0.1% is encouraged. 260 The bucket depth, b, is measured in bytes. Values of this parameter 261 may range from 1 byte to 250 gigabytes. Network elements MUST return 262 an error for requests containing values outside this range. Network 263 elements MUST return an error for any request containing a value 264 within this range which cannot be supported by the element. In 265 practice, only the first few digits of the b parameter are 266 significant, so the use of floating point representations, accurate 267 to at least 0.1% is encouraged. 269 The range of values allowed for these parameters is intentionally 270 large to allow for future network technologies. Any given network 271 element is not expected to support the full range of values. 273 The peak rate, p, is measured in bytes of IP datagrams per second and 274 has the same range and suggested representation as the bucket rate. 275 The peak rate parameter exists in this version of the specification 276 primarily for TSpec compatability with other QoS control services and 277 the shared TOKEN_BUCKET_TSPEC parameter. While some admission control 278 and buffer allocation algorithms may find the peak rate value useful, 279 the field may always be ignored by a Controlled-Load service 280 conforming to this version of the specification. That is, the service 281 module at a network element may always assume that the peak data rate 282 arriving at that element is the line rate of the incoming interface, 283 and the service's evaluation criteria do not require a network 284 element to consider the peak rate value. More explicit use of the 285 peak-rate parameter by a Controlled-Load service module may be added 286 to the specification in the future. 288 The minimum policed unit, m, is an integer measured in bytes. All IP 289 datagrams less than size m will be counted against the token bucket 290 as being of size m. The maximum packet size, M, is the biggest packet 291 that will conform to the traffic specification; it is also measured 292 in bytes. Network elements MUST reject a service request if the 293 requested maximum packet size is larger than the MTU of the link. 294 Both m and M must be positive, and m must be less then or equal to M. 296 The preferred concrete representation for the TSpec is three floating 297 point numbers in single-precision IEEE floating point format followed 298 by two 32-bit integers in network byte order. The first value is the 299 rate (r), the second value is the bucket size (b), the third is the 300 peak rate (p), the fourth is the minimum policed unit (m), and the 301 fifth is the maximum packet size (M). For the parameters (r) and (b), 302 only bit-patterns which represent valid non-negative floating point 303 numbers are allowed. Negative numbers (including "negative zero), 304 infinities, and NAN's are not allowed. For the parameter (p) only 305 bit-patterns which represent valid non-negative floating point 306 numbers or positive infinity are allowed. Positive infinity is 307 represented with an exponent of all ones (255) and a sign bit and 308 mantissa of all zeroes. Negative numbers (including "negative zero"), 309 negative infinity, and NAN's are not allowed. 311 NOTE: An implementation which utilizes general-purpose hardware or 312 software IEEE floating-point support may wish to verify that 313 arriving parameters meet this requirement before using the 314 parameters in floating-point computations, in order to avoid 315 unexpected exceptions or traps. 317 The controlled-load service is assigned service_name 5. 319 The TOKEN_BUCKET_TSPEC parameter used by the Controlled-Load service 320 is general parameter number 127, as indicated in [RFCGP]. 322 6. Exported Information 324 The controlled-load service has no required characterization 325 parameters. Individual implementations may export appropriate 326 implementation-specific measurement and monitoring information. 328 7. Policing 330 The controlled-load service is provided to a flow on the basis that 331 the flow's traffic conforms to a TSpec given at flow setup time. This 332 section defines the meaning of conformance to the controlled-load 333 TSpec, describes the circumstances under which a controlled-load 334 flow's traffic might *not* conform to the TSpec, and specifies the 335 network element's action in those circumstances. 337 Controlled-load service modules provide QoS control for traffic 338 conforming to the TSpec given at setup time. The TSpec's token 339 bucket parameters require that traffic must obey the rule that over 340 all time periods, the amount of data sent does not exceed rT+b, where 341 r and b are the token bucket parameters and T is the length of the 342 time period. For the purposes of this accounting, links must count 343 packets that are smaller than the minimal policing unit m to be of 344 size m. Packets that arrive at an element and cause a violation of 345 the the rT+b bound are considered nonconformant. 347 Additionally, packets bigger than the outgoing link MTU are 348 considered nonconformant. It is expected that this situation will 349 not arise with any frequency, because flow setup mechanisms are 350 expected to notify the sending application of the appropriate path 351 MTU. 353 In the presence of nonconformant packets arriving for one or more 354 controlled-load flows, each network element must ensure locally that 355 the following requirements are met: 357 1) The network element MUST continue to provide the contracted 358 quality of service to those controlled-load flows not experiencing 359 excess traffic. 361 2) The network element SHOULD prevent excess controlled-load 362 traffic from unfairly impacting the handling of arriving best- 363 effort traffic. This requirement is discussed further in Section 9 364 of this document (Guidelines for Implementors). 366 3) Consistent with points 1 and 2, the network element MUST attempt 367 to forward the excess traffic on a best-effort basis if sufficient 368 resources are available. 370 Network elements must not assume that that arrival of nonconformant 371 traffic for a specific controlled-load flow will be unusual, or 372 indicative of error. In certain circumstances (particularly, routers 373 acting as the "split points" of a multicast distribution tree 374 supporting a shared reservation) large numbers of packets will fail 375 the conformance test *as a matter of normal operation*. 377 Network elements must not assume that data sources or upstream 378 elements have taken action to "police" controlled-load flows by 379 limiting their traffic to conform to the flow's TSpec. Each network 380 element providing controlled-load service MUST independently ensure 381 that the requirements given above are met in the presence of 382 nonconformant arriving traffic for one or more controlled-load flows. 384 Network elements may use any appropriate implementation mechanism to 385 meet the requirements given above. Examples of such mechanisms 386 include token-bucket policing filters and per-flow scheduling 387 algorithms. However, it is insufficient to simply place all 388 controlled-load flows into the same shared resource pool, without 389 first ensuring that non-conformant flows are prevented from starving 390 conformant flows of the necessary processing resources. 392 Further discussion of this issue may be found in Section 11 of this 393 note. 395 Beyond requirements 2 and 3 above, the controlled-load service does 396 not define the QoS behavior delivered to flows with non-conformant 397 arriving traffic. Specifically, it is permissible either to degrade 398 the service delivered to all of the flow's packets equally, or to 399 sort the flow's packets into a conformant set and a nonconformant set 400 and deliver different levels of service to the two sets. This point 401 is discussed further in Section 9 of this note. 403 When resources are available, network elements at points within the 404 interior of the network SHOULD be prepared to accommodate packet 405 bursts somewhat larger than the actual TSpec. This requirement 406 derives from the traffic distortion effect described in Section 4. As 407 described there, it may be met either through explicit means or 408 statistical multiplexing of shared buffering resources. 410 When handling such traffic, it is permissible to allow some delaying 411 of a packet if that delay would allow it to pass the policing 412 function. (In other words, to reshape the traffic). However, the 413 overall requirement for limiting the duration of any such traffic 414 distortion must be considered. The challenge is to define a viable 415 reshaping function. 417 Intuitively, a plausible approach is to allow a delay of (roughly) up 418 to the maximum queueing delay experienced by completely conforming 419 packets before declaring that a packet has failed to pass the 420 policing function. The merit of this approach, and the precise 421 wording of the specification that describes it, require further 422 study. 424 8. Ordering and Merging 426 The controlled-load service TSpec is ordered according to the 427 following rule: TSpec A is a substitute for ("as good or better than" 428 or "greater than or equal to") TSpec B if and only if: 430 (1) the token bucket rate r for TSpec A is greater than or equal to 431 that of TSpec B, 433 (2) the token bucket depth b for TSpec A is greater than or equal 434 to that of TSpec B, 436 (3) the peak rate p for TSpec A is greater than or equal to that of 437 TSpec B, 439 (4) the minimum policed unit m for TSpec A is less than or equal to 440 that of TSpec B, 442 (5) the maximum packet size M of TSpec A is greater than or equal 443 to that of TSpec B. 445 Note that not all TSpecs can be ordered with respect to each other. 446 If two TSpecs differ but not all five of the points above are true, 447 then the TSpecs are unordered. 449 A merged TSpec may be calculated over a set of TSpecs by taking: 451 (1) the largest token bucket rate r; 453 (2) the largest token bucket size b; 455 (3) the largest peak rate p; 457 (4) the smallest minimal policed unit m; 459 (5) the largest maximum packet size M; 461 across all members of the set. This use of the word "merging" is 462 similar to that in the RSVP protocol; a merged TSpec is one that is 463 adequate to describe the traffic from any one of a number of flows. 465 The sum of n controlled-load service TSpecs is used when computing 466 the TSpec for a shared reservation of n flows. It is computed by 467 taking: 469 - The sum across all TSpecs of the token bucket rate parameter r. 471 - The sum across all TSpecs of the token bucket size parameter b. 473 - The sum across all TSpecs of the peak rate parameter p. 475 - The minimum across all TSpecs of the minimum policed unit 476 parameter m. 478 - The maximum across all TSpecs of the maximum packet size 479 parameter M. 481 The minimum of two TSpecs differs according to whether the TSpecs can 482 be ordered according to the "greater than or equal to" rule above. 483 If one TSpec is less than the other TSpec, the smaller TSpec is the 484 minimum. For unordered TSpecs, a different rule is used. The 485 minimum of two unordered TSpecs is determined by comparing the 486 respective values in the two TSpecs and choosing: 488 (1) the smaller token bucket rate r; 490 (2) the *larger* token bucket size b; 492 (3) the smaller peak rate p; 494 (4) the *smaller* minimum policed unit m; 496 (5) the smaller maximum packet size M; 498 9. Guidelines for Implementors 500 REQUIREMENTS PLACED ON ADMISSION CONTROL ALGORITHM: The intention of 501 this service specification is that network elements deliver a level 502 of service closely approximating best-effort service under unloaded 503 conditions. As with best-effort service under these conditions, it is 504 not required that every single packet must be successfully delivered 505 with zero queueing delay. Network elements providing controlled-load 506 service are permitted to oversubscribe the available resources to 507 some extent, in the sense that the bandwidth and buffer requirements 508 indicated by summing the TSpec token buckets of all controlled-load 509 flows may exceed the maximum capabilities of the network element. 510 However, this oversubscription may only be done in cases where the 511 element is quite sure that actual utilization is less than the sum of 512 the token buckets would suggest, so that the implementor's 513 performance goals will be met. This information may come from 514 measurement of the aggregate traffic flow, specific knowledge of 515 application traffic statistics, or other means. The most conservative 516 approach, rejection of new flows whenever the addition of their 517 traffic would cause the strict sum of the token buckets to exceed the 518 capacity of the network element (including consideration of resources 519 needed to maintain the delay and loss characteristics specified by 520 the service) may be appropriate in other circumstances. 522 Specific issues related to this subject are discussed in the 523 "Evaluation Criteria" and "Examples of Implementation" sections 524 below. 526 INTERACTION WITH BEST-EFFORT TRAFFIC: Implementors of this service 527 should clearly understand that in certain circumstances (routers 528 acting as the "split points" of a multicast distribution tree 529 supporting a shared reservation) large numbers of a flow's packets 530 may fail the TSpec conformance test *as a matter of normal 531 operation*. According to the requirements of Section 7, these 532 packets should be forwarded on a best-effort basis if resources 533 permit. 535 If the network element's best-effort queueing algorithm does not 536 distinguish between these packets and elastic best-effort traffic 537 such as TCP flows, THE EXCESS CONTROLLED-LOAD PACKETS WILL "BACK OFF" 538 THE ELASTIC TRAFFIC AND DOMINATE THE BEST-EFFORT BANDWIDTH USAGE. The 539 integrated services framework does not currently address this issue. 540 However, several possible solutions to the problem are known [RED, 541 xFQ]. Network elements supporting the controlled load service should 542 implement some mechanism in their best-effort queueing path to 543 discriminate between classes of best-effort traffic and provide 544 elastic traffic with protection from inelastic best-effort flows. 546 Two basic approaches are available to meet this requirement. The 547 network element can maintain separate resource allocations for 548 different classes of best-effort traffic, so that no one class will 549 excessively dominate the loaded best-effort mix. Alternatively, an 550 element can process excess controlled-load traffic at somewhat lower 551 priority than elastic best-effort traffic, so as to completely avoid 552 the back-off effect discussed above. 554 If most or all controlled-load traffic arises from non-rate-adaptive 555 real-time applications, the use of priority mechanisms might be 556 desirable. If most controlled-load traffic arises from rate-adaptive 557 realtime or elastic applications attempting to establish a bounded 558 minimum level of service, the use of separate resource classes might 559 be preferable. However, this is not a firm guideline. In practice, 560 the network element designer's choice of mechanism will depend 561 heavily on both the goals of the design and the implementation 562 techniques appropriate for the designer's platform. This version of 563 the service specification does not specify one or the other behavior, 564 but leaves the choice to the implementor. 566 FORWARDING BEHAVIOR IN PRESENCE OF NONCONFORMANT TRAFFIC: As 567 indicated in Section 7, the controlled-load service does not define 568 the QoS behavior delivered to flows with non-conformant arriving 569 traffic. It is permissible either to degrade the service delivered 570 to all of the flow's packets equally, or to sort the flow's packets 571 into a conformant set and a nonconformant set and deliver different 572 levels of service to the two sets. 574 In the first case, expected queueing delay and packet loss 575 probability will rise for all packets in the flow, but packet 576 delivery reordering will, in general, remain at low levels. This 577 behavior is preferable for those applications or transport protocols 578 which are sensitive to excessive packet reordering. A possible 579 example is an unmodified TCP connection, which would see reordering 580 as lost packets, triggering duplicate acks and hence excessive 581 retransmissions. 583 In the second case, some subset of the flow's packets will be 584 delivered with low loss and delay, while some other subset will be 585 delivered with higher loss and potentially higher delay. The delayed 586 packets will appear to the receiver to have been reordered in the 587 network, while the non-delayed packets will, on average, arrive in a 588 more timely fashion than if all packets were treated equally. This 589 might be preferable for applications which are highly time-sensitive, 590 such as interactive conferencing tools. 592 10. Evaluation Criteria 594 The basic requirement placed on an implementation of controlled-load 595 service is that, under all conditions, it provide accepted data flows 596 with service closely similar to the service that same flow would 597 receive using best-effort service under unloaded conditions. 599 This suggests a simple two-step evaluation strategy. Step one is to 600 compare the service given best-effort traffic and controlled-load 601 traffic under underloaded conditions. 603 - Measure the packet loss rate and delay characteristics of a test 604 flow using best-effort service and with no load on the network 605 element. 607 - Compare those measurements with measurements of the same flow 608 receiving controlled-load service with no load on the network 609 element. 611 Closer measurements indicate higher evaluation ratings. A 612 substantial difference in the delay characteristics, such as the 613 smoothing which would be seen in an implementation which scheduled 614 the controlled-load flow using a fixed, constant-bitrate algorithm, 615 should result in a somewhat lower rating. 617 Step two is to observe the change in service received by a 618 controlled-load flow as the load increases. 620 - Increase the background traffic load on the network element, 621 while continuing to measuring the loss and delay characteristics of 622 the controlled-load flow. Characteristics which remain essentially 623 constant as the element is driven into overload indicate a high 624 evaluation rating. Minor changes in the delay distribution indicate 625 a somewhat lower rating. Significant increases in delay or loss 626 indicate a poor evaluation rating. 628 This simple model is not adequate to fully evaluate the performance 629 of controlled-load service. Three additional variables affect the 630 evaluation. The first is the short-term burstiness of the traffic 631 stream used to perform the tests outlined above. The second is the 632 degree of long-term change in the controlled-load traffic within the 633 bounds of its TSpec. (Changes in this characteristic will have great 634 effect on the effectiveness of certain admission control algorithms.) 635 The third is the ratio of controlled-load traffic to other traffic at 636 the network element (either best effort or other controlled 637 services). 639 The third variable should be specifically evaluated using the 640 following procedure. 642 With no controlled-load flows in place, overload the network 643 element with best-effort traffic (as indicated by substantial 644 packet loss and queueing delay). 646 Execute requests for controlled-load service giving TSpecs with 647 increasingly large rate and burst parameters. If the request is 648 accepted, verify that traffic matching the TSpec is in fact handled 649 with characteristics closely approximating the unloaded 650 measurements taken above. 652 Repeat these experiments to determine the range of traffic 653 parameter (rate, burst size) values successfully handled by the 654 network element. The useful range of each parameter must be 655 determined for several settings of the other parameter, to map out 656 a two-dimensional "region" of successfully handled TSpecs. When 657 compared with network elements providing similar capabilities, this 658 region indicates the relative ability of the elements to provide 659 controlled-load service under high load. A larger region indicates 660 a higher evaluation rating. 662 11. Examples of Implementation 664 One possible implementation of controlled-load service is to provide 665 a queueing mechanism with two priority levels; a high priority one 666 for controlled-load and a lower priority one for best effort service. 667 An admission control algorithm is used to limit the amount of traffic 668 placed into the high-priority queue. This algorithm may be based 669 either on the specified characteristics of the high-priority flows 670 (using information provided by the TSpecs), or on the measured 671 characteristics of the existing high-priority flows and the TSpec of 672 the new request. 674 Another possible implementation of controlled-load service is based 675 on the existing capabilities of network elements which support 676 "traffic classes" based on mechanisms such as weighted fair queueing 677 or class-based queueing [6]. In this case, it is sufficient to map 678 data flows accepted for controlled-load service into an existing 679 traffic class with adequate capacity to avoid overload. This 680 requirement is enforced by an admission control algorithm which 681 considers the characteristics of the traffic class, the 682 characteristics of the traffic already admitted to the class, and the 683 TSpec of the new flow requesting service. Again, the admission 684 control algorithm may be based either on the TSpec-specified or the 685 measured characteristics of the existing traffic. 687 A specific case of the above approach is to employ a scheduler which 688 implements weighted fair queueing or similar load-management scheme, 689 allocating a separate scheduling queue with correctly chosen weight 690 to each individual controlled-load flow. In this circumstance, the 691 traffic scheduler also plays the role of the policing function, by 692 ensuring that nonconformant traffic arriving for one controlled-load 693 flow does not affect either other controlled-load flows or the best- 694 effort traffic. This elimination of mechanism is balanced by the 695 drawback that the approach does not benefit from any performance or 696 resource usage gain arising from statistical aggregation of several 697 flows into a single queueing class. 699 Admission control algorithms based on specified characteristics are 700 likely be appropriate when the number of flows in the high-priority 701 class is small, or the traffic characteristics of the flows appear 702 highly variable. In these situations the measured behavior of the 703 aggregate controlled-load traffic stream may not serve as an 704 effective predictor of future traffic, leading a measurement-based 705 admission control algorithm to produce incorrect results. Conversely, 706 in situations where the past behavior of the aggregate controlled- 707 load traffic *is* a good predictor of future behavior, a measurement- 708 based admission control algorithm may allow more traffic to be 709 admitted to the controlled-load service class with no degradation in 710 performance. An implementation may choose to switch between these two 711 approaches depending on the nature of the traffic stream at a given 712 time. 714 A variety of techniques may be used to provide the desired isolation 715 between excess (nonconformant) controlled-load traffic and other 716 best-effort traffic. Use of a low priority queue for nonconformant 717 controlled-load traffic is simple, but other approaches may provide 718 superior service or fit better into existing architectures. Variants 719 of fair queueing or weighted fair queueing may be used to allocate a 720 percentage of the available resources to different best-effort 721 traffic classes. One approach would be to allocate each controlled- 722 load flow a a 1/N "fair share" percentage of the available best- 723 effort bandwidth for its excess traffic. An alternate approach would 724 be to provide a single WFQ resource class for all excess controlled- 725 load traffic. Finally, alternate mechanisms such as RED [xxx] may be 726 used to provide the same overall function. 728 12. Examples of Use 730 The controlled-load service may be used by any application which can 731 make use of best-effort service, but is best suited to those 732 applications which can usefully characterize their traffic 733 requirements. Applications based on the transport of "continuous 734 media" data, such as digitized audio or video, are an important 735 example of this class. 737 The controlled-load service is not isochronous and does not provide 738 any explicit information about transmission delay. For this reason, 739 applications with end-to-end timing requirements, including the 740 continuous-media class mentioned above, provide an application- 741 specific timing recovery mechanism, similar or identical to the 742 mechanisms required when these applications use best-effort service. 743 A protocol useful to applications requiring this capability is the 744 IETF Real-Time Transport Protocol [2]. 746 Load-sensitive applications may choose to request controlled-load 747 service whenever they are run. Alternatively, these applications may 748 monitor their own performance and request controlled-load service 749 from the network only when best-effort service is not providing 750 acceptable performance. The first strategy provides higher assurance 751 that the level of quality delivered to the user will not change over 752 the lifetime of an application session. The second strategy provides 753 greated flexibility and offers cost savings in environments where 754 levels of service above best-effort incur a charge. 756 13. Security Considerations 758 Security considerations are not discussed in this memo. 760 Appendix 1: Use of the Controlled-Load service with RSVP 762 The use of Controlled-Load service in conjunction with the RSVP 763 resource reservation setup protocol is specified in reference [4]. 764 This document gives the format of RSVP FLOWSPEC, SENDER_TSPEC, and 765 ADSPEC objects needed to support applications desiring Controlled- 766 Load service and gives information about how RSVP processes those 767 objects. The RSVP protocol itself is specified in Reference [3]. 769 References 771 [1] S. Shenker and J. Wroclawski. "Network Element QoS Control 772 Service Specification Template". Internet Draft, July 1996, 775 [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. "RTP: 776 A Transport Protocol for Real-Time Applications", Internet Draft, 777 March 1995, 779 [3] B. Braden, et. al. "Resource Reservation Protocol (RSVP) - 780 Version 1 Functional Specification", Internet Draft, July 1996, 781 783 [4] J. Wroclawski. "The use of RSVP with IETF Integrated Services", 784 Internet Draft, July 1996, 786 [5] S. Shenker and J. Wroclawski. "General Characterization 787 Parameters for Integrated Service Network Elements", Internet Draft, 788 July 1996, 790 [6] S. Floyd, and V. Jacobson. "Link-sharing and Resource Management 791 Models for Packet Networks," IEEE/ACM Transactions on Networking, 792 Vol. 3 No. 4, pp. 365-386, August 1995. 794 [7] A. K. J. Parekh. "A Generalized Processor Sharing Approach to 795 Flow Control in Integrated Service Networks". MIT Laboratory for 796 Information and Decision Systems, Report LIDS-TH-2089, February 1992 798 Authors' Address: 800 John Wroclawski 801 MIT Laboratory for Computer Science 802 545 Technology Sq. 803 Cambridge, MA 02139 804 jtw@lcs.mit.edu 805 617-253-7885 806 617-253-2673 (FAX)