idnits 2.17.1 draft-ietf-intserv-ctrl-load-svc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 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. ** There are 15 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 209: '... elements MUST return an error for r...' RFC 2119 keyword, line 210: '...Network elements MUST return an error ...' RFC 2119 keyword, line 217: '...igabytes. Network elements MUST return...' RFC 2119 keyword, line 219: '... elements MUST return an error for a...' RFC 2119 keyword, line 233: '...Network elements MUST reject a service...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 191 has weird spacing: '...ed-load servi...' == Line 387 has weird spacing: '...largest maxim...' -- 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: 'M' on line 788 -- 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' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 9 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-01.txt MIT LCS 4 November, 1995 5 Expires: 6/96 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 (the 74 "speed-of-light delay"). 76 To ensure that these conditions are met, clients requesting 77 controlled-load service provide the intermediate network elements 78 with a estimation of the data traffic they will generate; the TSpec. 79 In return, the service ensures that network element resources 80 adequate to process traffic falling within this descriptive envelope 81 will be available to the client. Should the client's traffic 82 generation properties fall outside of the region described by the 83 TSpec parameters, the QoS provided to the client may exhibit 84 characteristics indicative of overload, including large numbers of 85 delayed or dropped packets. The service definition does not require 86 that the precise characteristics of this overload behavior match 87 those which would be received by a best-effort data flow traversing 88 the same path under overloaded conditions. 90 NOTE: In this memo, the term "unloaded" is used in the sense of 91 "not heavily loaded or congested" rather than in the sense of "no 92 other network traffic whatsoever". 94 3. Motivation 96 The controlled load service is intended to support a broad class of 97 applications which have been developed for use in today's Internet, 98 but are highly sensitive to overloaded conditions. Important members 99 of this class are the "adaptive real-time applications" currently 100 offered by a number of vendors and researchers. These applications 101 have been shown to work well on unloaded nets, but to degrade quickly 102 under overloaded conditions. A service which mimics unloaded nets 103 serves these applications well. 105 The controlled-load service is intentionally minimal, in that there 106 are no optional functions or capabilities in the specification. The 107 service offers only a single function, and system and application 108 designers can assume that all implementations will be identical in 109 this respect. 111 Internally, the controlled-load service is suited to a wide range of 112 implementation techniques, including evolving scheduling and 113 admission control algorithms that allow implementations to be highly 114 efficient in the use of network resources. It is equally amenable to 115 extremely simple implementation in circumstances where maximum 116 utilization of network resources is not the only concern. 118 4. Network Element Data Handling Requirements 120 Each network element accepting a request for controlled-load service 121 must ensure that adequate bandwidth and packet processing resources 122 are available to handle the requested level of traffic, as given by 123 the requestor's TSpec. This must be accomplished through active 124 admission control. All resources important to the operation of the 125 network element must be considered when admitting a request. Common 126 examples of such resources include link bandwidth, router or switch 127 port buffer space, and computational capacity of the packet 128 forwarding engine. 130 The controlled-load service does not accept or make use of specific 131 target values for control parameters such as delay or loss. Instead, 132 acceptance of a request for controlled-load service is defined to 133 imply a commitment by the network element to provide the requestor 134 with service closely equivalent to that provided to uncontrolled 135 (best-effort) traffic under lightly loaded conditions. 137 The definition of "closely equivalent to unloaded best-effort 138 service" is necessarily imprecise. It is easiest to define this 139 quality of service by describing the events which are expected to 140 *not* occur with any frequency. A flow receiving controlled-load 141 service at a network element may expect to experience: 143 - Little or no average packet queueing delay over all timescales 144 significantly larger than the "burst time". The burst time is 145 defined as the time required for the flow's maximum size data burst 146 to be transmitted at the flow's requested transmission rate, where 147 the burst size and rate are given by the flow's TSpec, as described 148 below. 150 - Little or no congestion loss over all timescales significantly 151 larger than the "burst time" defined above. In this context, 152 congestion loss includes packet losses due to shortage of any 153 required processing resource, such as buffer space or link 154 bandwidth. Although occasional congestion losses may occur, any 155 substantial sustained loss represents a failure of the admission 156 control algorithm. 158 The basic effect of this language is to establish an expectation on 159 the *duration* of a disruption in delivery service. Events of shorter 160 duration are viewed as statistical effects which may occur in normal 161 operation. Events of longer duration are indicative of failure to 162 allocate adequate capacity to the controlled-load flow. 164 A network element may employ statistical approaches to decide whether 165 adequate capacity is available to accept a service request. For 166 example, a network element processing a number of flows with long- 167 term characteristics predicted through measurement of past behavior 168 may be able to overallocate its resources to some extent without 169 reducing the level of service delivered to the flows. 171 A network element may employ any appropriate scheduling means to 172 ensure that admitted flows receive appropriate service. 174 Links are not permitted to fragment packets which receive the 175 controlled-load service. Packets larger than the MTU of the link must 176 be treated as nonconformant to the TSpec. This implies that they will 177 be forwarded according to the rules described in the Policing section 178 below. 180 Implementations of controlled-load service are not required to 181 provide any control of short-term packet delay jitter beyond that 182 described above. However, the use of packet scheduling algorithms 183 that provide additional jitter control is not prohibited by this 184 specification. 186 Packet losses due to non-congestion-related causes, such as link 187 errors, are not bounded by this service. 189 5. Invocation Information 191 The controlled-load service is invoked by specifying the data flow's 192 desired traffic parameters (TSpec) to the network element. Requests 193 placed for a new flow will be accepted if the network element has the 194 capacity to forward the flow's packets as described above. Requests 195 to change the TSpec for an existing flow should be treated as a new 196 invocation, in the sense that admission control must be reapplied to 197 the flow. Requests that reduce the TSpec for an existing flow (in the 198 sense that the new TSpec is strictly smaller than the old TSpec 199 according to the ordering rules given below) should never be denied 200 service. 202 The TSpec takes the form of a token bucket specification plus a 203 minimum policed unit (m) and a maximum packet size (M). 205 The token bucket specification includes a bucket rate r and a bucket 206 depth, b. Both r and b must be positive. The rate, r, is measured 207 in bytes of IP datagrams per second. Values of this parameter may 208 range from 1 byte per second to 40 terabytes per second. Network 209 elements MUST return an error for requests containing values outside 210 this range. Network elements MUST return an error for any request 211 containing a value within this range which cannot be supported by the 212 element. In practice, only the first few digits of the r parameter 213 are significant, so the use of floating point representations, 214 accurate to at least 0.1% is encouraged. 216 The bucket depth, b, is measured in bytes. Values of this parameter 217 may range from 1 byte to 250 gigabytes. Network elements MUST return 218 an error for requests containing values outside this range. Network 219 elements MUST return an error for any request containing a value 220 within this range which cannot be supported by the element. In 221 practice, only the first few digits of the b parameter are 222 significant, so the use of floating point representations, accurate 223 to at least 0.1% is encouraged. 225 The range of values allowed for these parameters is intentionally 226 large to allow for future network technologies. Any given network 227 element is not expected to support the full range of values. 229 The minimum policed unit, m, is an integer measured in bytes. All IP 230 datagrams less than size m will be counted against the token bucket 231 as being of size m. The maximum packet size, M, is the biggest packet 232 that will conform to the traffic specification; it is also measured 233 in bytes. Network elements MUST reject a service request if the 234 requested maximum packet size is larger than the MTU of the link. 235 Both m and M must be positive, and m must be less then or equal to M. 237 The preferred concrete representation for the TSpec is two floating 238 point numbers in single-precision IEEE floating point format followed 239 by two 32-bit integers in network byte order. The first value is the 240 rate (r), the second value is the bucket size (b), the third is the 241 minimum policed unit (m), and the fourth is the maximum packet size 242 (M). 244 The controlled-load service is assigned service_name 5. 246 The controlled-load traffic specification parameter (TSpec) is 247 assigned parameter_name 1, as indicated in the listing of well-known 248 parameter name assignments given in [1]. 250 6. Exported Information 252 The controlled-load service has no required characterization 253 parameters. Individual implementations may export appropriate 254 implementation-specific measurement and monitoring information. 256 7. Policing 258 The controlled-load service is provided to a flow on the basis that 259 the flow's traffic conforms to a TSpec given at flow setup time. This 260 section defines the meaning of conformance to the controlled-load 261 TSpec, describes the circumstances under which a controlled-load 262 flow's traffic might *not* conform to the TSpec, and specifies the 263 network element's action in those circumstances. 265 Controlled-load service modules provide QoS control for traffic 266 conforming to the TSpec given at setup time. The TSpec's token 267 bucket parameters require that traffic must obey the rule that over 268 all time periods, the amount of data sent does not exceed rT+b, where 269 r and b are the token bucket parameters and T is the length of the 270 time period. For the purposes of this accounting, links must count 271 packets that are smaller than the minimal policing unit m to be of 272 size m. Packets that arrive at an element and cause a violation of 273 the the rT+b bound are considered nonconformant. 275 Additionally, packets bigger than the outgoing link MTU are 276 considered nonconformant. It is expected that this situation will 277 not arise with any frequency, because flow setup mechanisms are 278 expected to notify the sending application of the appropriate path 279 MTU. 281 In the presence of nonconformant packets arriving for one or more 282 controlled-load flows, each network element must ensure locally that 283 the following requirements are met: 285 1) The network element MUST continue to provide the contracted 286 quality of service to those controlled-load flows not experiencing 287 excess traffic. 289 2) The network element SHOULD prevent excess controlled-load 290 traffic from unfairly impacting the handling of arriving best- 291 effort traffic. This requirement is discussed further in Section 9 292 of this document (Guidelines for Implementors). 294 3) Consistent with points 1 and 2, the network element MUST attempt 295 to forward the excess traffic on a best-effort basis if sufficient 296 resources are available. 298 Network elements must not assume that that arrival of nonconformant 299 traffic for a specific controlled-load flow will be unusual, or 300 indicative of error. In certain circumstances (particularly, routers 301 acting as the "split points" of a multicast distribution tree 302 supporting a shared reservation) large numbers of packets will fail 303 the conformance test *as a matter of normal operation*. 305 Network elements must not assume that data sources or upstream 306 elements have taken action to "police" controlled-load flows by 307 limiting their traffic to conform to the flow's TSpec. Each network 308 element providing controlled-load service MUST independently ensure 309 that the requirements given above are met in the presence of 310 nonconformant arriving traffic for one or more controlled-load flows. 312 Network elements may use any appropriate implementation mechanism to 313 meet the requirements given above. Examples of such mechanisms 314 include token-bucket policing filters and per-flow scheduling 315 algorithms. Further discussion of this issue may be found in Section 316 11 of this note. 318 Beyond requirements 2 and 3 above, the controlled-load service does 319 not define the QoS behavior delivered to flows with non-conformant 320 arriving traffic. Specifically, it is permissible either to degrade 321 the service delivered to all of the flow's packets equally, or to 322 sort the flow's packets into a conformant set and a nonconformant set 323 and deliver different levels of service to the two sets. This point 324 is discussed further in Section 9 of this note. 326 If resources are available, it is desirable for network elements at 327 points within the interior of the network (but *not* at edge traffic 328 entry points) to enforce slightly "relaxed" traffic parameters to 329 accommodate packet bursts somewhat larger than the actual TSpec. 331 Other actions, such as reshaping the traffic stream (delaying packets 332 until they are compliant), are not allowed. 334 [The following notes provide further discussion of the requirements 335 specified above. They are not necessarily intended for inclusion in 336 the final document.] 338 NOTE: RESHAPING. The prohibition on delaying packets is one of 339 many possible design choices. It may be better to permit some 340 delaying of a packet if that delay would allow it to pass the 341 policing function. (In other words, to reshape the traffic). The 342 challenge is to define a viable reshaping function. 344 Intuitively, a plausible approach is to allow a delay of (roughly) 345 up to the maximum queueing delay experienced by completely 346 conforming packets before declaring that a packet has failed to 347 pass the policing function. The merit of this approach, and the 348 precise wording of the specification that describes it, require 349 further study. 351 NOTE: EDGE POLICING. The text above specifies that the policing 352 function attempt to forward non-conformant packets on a best- 353 effort basis at all points. A possible alternative is to allow or 354 require dropping of nonconformant packets at the edges of the 355 network: 357 The effect of this change is significant. Under the non-dropping 358 model, it is possible for a source to vastly over-send its TSpec, 359 with the excess packets being delivered if conditions permit. The 360 service offered in this case has been described as "best-effort- 361 with-floor"; essentially a best-effort delivery service with 362 enough resources reserved for a certain minimum traffic level. 364 Under the dropping model, the service loses its "best-effort- 365 with-floor" characteristics, and becomes essentially a fixed- 366 traffic-level service. In return, it offers significantly more 367 protection against overload of the network resources and 368 degradation of other flows' QoS. 370 8. Ordering and Merging 372 The controlled-load service TSpec is ordered according to the 373 following rule: TSpec A is a substitute for ("as good or better 374 than") TSpec B if and only if 376 (1) both the token bucket depth and rate for TSpec A are greater 377 than or equal to those of TSpec B, 379 (2) the minimum policed unit m is at least as small for TSpec A as 380 it is for TSpec B, and 382 (3) the maximum packet size M is at least as large for TSpec A as 383 it is for TSpec B. 385 A merged TSpec may be calculated over a set of TSpecs by taking the 386 largest token bucket rate, largest bucket size, smallest minimal 387 policed unit, and largest maximum packet size across all members of 388 the set. This use of the word "merging" is similar to that in the 389 RSVP protocol; a merged TSpec is one that is adequate to describe the 390 traffic from any one of a number of flows. 392 The sum of n controlled-load service TSpecs is used when computing 393 the TSpec for a shared reservation of n flows. It is computed by 394 taking: 396 - The minimum across all TSpecs of the minimum policed unit 397 parameter m. 399 - The maximum across all TSpecs of the maximum packet size 400 parameter M. 402 - The sum across all TSpecs of the token bucket rate parameter r. 404 - The sum across all TSpecs of the token bucket size parameter b. 406 The perfect minimum of two TSpecs is defined as a TSpec which would 407 view as compliant any traffic flow that complied with both of the 408 original TSpecs, but would reject any flow that was non-compliant 409 with at least one of the original TSpecs. This perfect minimum can be 410 computed only when the two original TSpecs are ordered, in the sense 411 described above. 413 A definition for computing the minimum of two unordered TSpecs is: 415 - The minimum of the minimum policed units m. 417 - The maximum of the maximum packet sizes M. 419 - The minimum of the token bucket rates r. 421 - The maximum of the token bucket sizes b. 423 NOTE: The proper definition the minimum TSpec function is a topic 424 of current discussion. The definition above is provisional and 425 subject to change. 427 9. Guidelines for Implementors 429 REQUIREMENTS PLACED ON ADMISSION CONTROL ALGORITHM: The intention of 430 this service specification is that network elements deliver a level 431 of service closely approximating best-effort service under unloaded 432 conditions. As with best-effort service under these conditions, it is 433 not required that every single packet must be successfully delivered 434 with zero queueing delay. Network elements providing controlled-load 435 service are permitted to oversubscribe the available resources to 436 some extent, in the sense that the bandwidth and buffer requirements 437 indicated by summing the TSpec token buckets of all controlled-load 438 flows may exceed the maximum capabilities of the network element. 439 However, this oversubscription may only be done in cases where the 440 element is quite sure that actual utilization is far less than the 441 sum of the token buckets would suggest. The most conservative 442 approach, rejection of new flows whenever the addition of their 443 traffic would cause the sums of the token buckets to exceed the 444 capacity of the network element, may be appropriate in other 445 circumstances. 447 Specific issues related to this subject are discussed in the 448 "Evaluation Criteria" and "Examples of Implementation" sections 449 below. 451 INTERACTION WITH BEST-EFFORT TRAFFIC: Implementors of this service 452 should clearly understand that in certain circumstances (routers 453 acting as the "split points" of a multicast distribution tree 454 supporting a shared reservation) large numbers of a flow's packets 455 may fail the TSpec conformance test *as a matter of normal 456 operation*. According to the requirements of Section 7, these 457 packets should be forwarded on a best-effort basis if resources 458 permit. 460 If the network element's best-effort queueing algorithm does not 461 distinguish between these packets and elastic best-effort traffic 462 such as TCP flows, THE EXCESS CONTROLLED-LOAD PACKETS WILL "BACK OFF" 463 THE ELASTIC TRAFFIC AND DOMINATE THE BEST-EFFORT BANDWIDTH USAGE. The 464 integrated services framework does not currently address this issue. 465 However, several possible solutions to the problem are known [RED, 466 xFQ]. Network elements supporting the controlled load service should 467 implement some mechanism in their best-effort queueing path to 468 discriminate between classes of best-effort traffic and provide 469 elastic traffic with protection from inelastic best-effort flows. 471 Two basic approaches are available to meet this requirement. The 472 network element can maintain separate resource allocations for 473 different classes of best-effort traffic, so that no one class will 474 excessively dominate the loaded best-effort mix. Alternatively, an 475 element can process excess controlled-load traffic at somewhat lower 476 priority than elastic best-effort traffic, so as to completely avoid 477 the back-off effect discussed above. 479 If most or all controlled-load traffic arises from non-rate-adaptive 480 real-time applications, the use of priority mechanisms might be 481 desirable. If most controlled-load traffic arises from rate-adaptive 482 realtime or elastic applications attempting to establish a bounded 483 minimum level of service, the use of separate resource classes might 484 be preferable. However, this is not a firm guideline. In practice, 485 the network element designer's choice of mechanism will depend 486 heavily on both the goals of the design and the implementation 487 techniques appropriate for the designer's platform. This version of 488 the service specification does not specify one or the other behavior, 489 but leaves the choice to the implementor. 491 FORWARDING BEHAVIOR IN PRESENCE OF NONCONFORMANT TRAFFIC: As 492 indicated in Section 7, the controlled-load service does not define 493 the QoS behavior delivered to flows with non-conformant arriving 494 traffic. It is permissible either to degrade the service delivered 495 to all of the flow's packets equally, or to sort the flow's packets 496 into a conformant set and a nonconformant set and deliver different 497 levels of service to the two sets. 499 In the first case, expected queueing delay and packet loss 500 probability will rise for all packets in the flow, but packet 501 delivery reordering will, in general, remain at low levels. This 502 behavior is preferable for those applications or transport protocols 503 which are sensitive to excessive packet reordering. A possible 504 example is an unmodified TCP connection, which would see reordering 505 as lost packets, triggering duplicate acks and hence excessive 506 retransmissions. 508 In the second case, some subset of the flow's packets will be 509 delivered with low loss and delay, while some other subset will be 510 delivered with higher loss and potentially higher delay. The delayed 511 packets will appear to the receiver to have been reordered in the 512 network, while the non-delayed packets will, on average, arrive in a 513 more timely fashion than if all packets were treated equally. This 514 might be preferable for applications which are highly time-sensitive, 515 such as interactive conferencing tools. 517 10. Evaluation Criteria 519 The basic requirement placed on an implementation of controlled-load 520 service is that, under all conditions, it provide accepted data flows 521 with service closely similar to the service that same flow would 522 receive using best-effort service under unloaded conditions. 524 This suggests a simple two-step evaluation strategy. Step one is to 525 compare the service given best-effort traffic and controlled-load 526 traffic under underloaded conditions. 528 - Measure the packet loss rate and delay characteristics of a test 529 flow using best-effort service and with no load on the network 530 element. 532 - Compare those measurements with measurements of the same flow 533 receiving controlled-load service with no load on the network 534 element. 536 Closer measurements indicate higher evaluation ratings. A 537 substantial difference in the delay characteristics, such as the 538 smoothing which would be seen in an implementation which scheduled 539 the controlled-load flow using a fixed, constant-bitrate algorithm, 540 should result in a somewhat lower rating. 542 Step two is to observe the change in service received by a 543 controlled-load flow as the load increases. 545 - Increase the background traffic load on the network element, 546 while continuing to measuring the loss and delay characteristics of 547 the controlled-load flow. Characteristics which remain essentially 548 constant as the element is driven into overload indicate a high 549 evaluation rating. Minor changes in the delay distribution indicate 550 a somewhat lower rating. Significant increases in delay or loss 551 indicate a poor evaluation rating. 553 This simple model is not adequate to fully evaluate the performance 554 of controlled-load service. Three additional variables affect the 555 evaluation. The first is the short-term burstiness of the traffic 556 stream used to perform the tests outlined above. The second is the 557 degree of long-term change in the controlled-load traffic within the 558 bounds of its TSpec. (Changes in this characteristic will have great 559 effect on the effectiveness of certain admission control algorithms.) 560 The third is the ratio of controlled-load traffic to other traffic at 561 the network element (either best effort or other controlled 562 services). 564 The third variable should be specifically evaluated using the 565 following procedure. 567 With no controlled-load flows in place, overload the network 568 element with best-effort traffic (as indicated by substantial 569 packet loss and queueing delay). 571 Execute requests for controlled-load service giving TSpecs with 572 increasingly large rate and burst parameters. If the request is 573 accepted, verify that traffic matching the TSpec is in fact handled 574 with characteristics closely approximating the unloaded 575 measurements taken above. 577 Repeat these experiments to determine the range of traffic 578 parameter (rate, burst size) values successfully handled by the 579 network element. The useful range of each parameter must be 580 determined for several settings of the other parameter, to map out 581 a two-dimensional "region" of successfully handled TSpecs. When 582 compared with network elements providing similar capabilities, this 583 region indicates the relative ability of the elements to provide 584 controlled-load service under high load. A larger region indicates 585 a higher evaluation rating. 587 11. Examples of Implementation 589 One possible implementation of controlled-load service is to provide 590 a queueing mechanism with two priority levels; a high priority one 591 for controlled-load and a lower priority one for best effort service. 592 An admission control algorithm is used to limit the amount of traffic 593 placed into the high-priority queue. This algorithm may be based 594 either on the specified characteristics of the high-priority flows 595 (using information provided by the TSpecs), or on the measured 596 characteristics of the existing high-priority flows and the TSpec of 597 the new request. 599 Another possible implementation of controlled-load service is based 600 on the existing capabilities of network elements which support 601 "traffic classes" based on mechanisms such as weighted fair queueing 602 or class-based queueing [6]. In this case, it is sufficient to map 603 data flows accepted for controlled-load service into an existing 604 traffic class with adequate capacity to avoid overload. This 605 requirement is enforced by an admission control algorithm which 606 considers the characteristics of the traffic class, the 607 characteristics of the traffic already admitted to the class, and the 608 TSpec of the new flow requesting service. Again, the admission 609 control algorithm may be based either on the TSpec-specified or the 610 measured characteristics of the existing traffic. 612 A specific case of the above approach is to employ a scheduler which 613 implements weighted fair queueing or similar load-management scheme, 614 allocating a separate scheduling queue with correctly chosen weight 615 to each individual controlled-load flow. In this circumstance, the 616 traffic scheduler also plays the role of the policing function, by 617 ensuring that nonconformant traffic arriving for one controlled-load 618 flow does not affect either other controlled-load flows or the best- 619 effort traffic. This elimination of mechanism is balanced by the 620 drawback that the approach does not benefit from any performance or 621 resource usage gain arising from statistical aggregation of several 622 flows into a single queueing class. 624 Admission control algorithms based on specified characteristics are 625 likely be appropriate when the number of flows in the high-priority 626 class is small, or the traffic characteristics of the flows appear 627 highly variable. In these situations the measured behavior of the 628 aggregate controlled-load traffic stream may not serve as an 629 effective predictor of future traffic, leading a measurement-based 630 admission control algorithm to produce incorrect results. Conversely, 631 in situations where the past behavior of the aggregate controlled- 632 load traffic *is* a good predictor of future behavior, a 633 measurement-based admission control algorithm may allow more traffic 634 to be admitted to the controlled-load service class with no 635 degradation in performance. An implementation may choose to switch 636 between these two approaches depending on the nature of the traffic 637 stream at a given time. 639 A variety of techniques may be used to provide the desired isolation 640 between excess (nonconformant) controlled-load traffic and other 641 best-effort traffic. Use of a low priority queue for nonconformant 642 controlled-load traffic is simple, but other approaches may provide 643 superior service or fit better into existing architectures. Variants 644 of fair queueing or weighted fair queueing may be used to allocate a 645 percentage of the available resources to different best-effort 646 traffic classes. One approach would be to allocate each controlled- 647 load flow a a 1/N "fair share" percentage of the available best- 648 effort bandwidth for its excess traffic. An alternate approach would 649 be to provide a single WFQ resource class for all excess controlled- 650 load traffic. Finally, alternate mechanisms such as RED [xxx] may be 651 used to provide the same overall function. 653 12. Examples of Use 655 The controlled-load service may be used by any application which can 656 make use of best-effort service, but is best suited to those 657 applications which can usefully characterize their traffic 658 requirements. Applications based on the transport of "continuous 659 media" data, such as digitized audio or video, are an important 660 example of this class. 662 The controlled-load service is not isochronous and does not provide 663 any explicit information about transmission delay. For this reason, 664 applications with end-to-end timing requirements, including the 665 continuous-media class mentioned above, provide an application- 666 specific timing recovery mechanism, similar or identical to the 667 mechanisms required when these applications use best-effort service. 668 A protocol useful to applications requiring this capability is the 669 IETF Real-Time Transport Protocol [2]. 671 Load-sensitive applications may choose to request controlled-load 672 service whenever they are run. Alternatively, these applications may 673 monitor their own performance and request controlled-load service 674 from the network only when best-effort service is not providing 675 acceptable performance. The first strategy provides higher assurance 676 that the level of quality delivered to the user will not change over 677 the lifetime of an application session. The second strategy provides 678 greated flexibility and offers cost savings in environments where 679 levels of service above best-effort incur a charge. 681 13. Security Considerations 683 Security considerations are not discussed in this memo. 685 Appendix 1: RSVP Messages used with Controlled-Load Service 687 This appendix describes the RSVP [3] protocol objects used to request 688 controlled load service from a series of network elements. The 689 formatting of these objects follows the integrated service data 690 object formatting rules specified in [4]. 692 RSVP FLOWSPEC 694 The RSVP FLOWSPEC object used to request controlled-load service 695 carries a controlled-load traffic specification (TSpec) specifying 696 the traffic parameters of the flow for which controlled-load service 697 is being requested. This TSpec originates at the receiver making the 698 RSVP reservation request. 700 The format of the controlled-load FLOWSPEC object is shown below. 701 Each of the TSpec fields is represented using the preferred concrete 702 representation specified in the 'Invocation Information' section of 703 this memo. 705 31 24 23 16 15 8 7 0 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | 0 (a) | Unused | 5 (b) | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | 5 (c) | 4 (d) | 1 (e) | 0 (f) | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Token Bucket Size [b] (32-bit IEEE floating point number) | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Minimum Policed Unit [m] (32-bit integer) | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Maximum Packet Size [M] (32-bit integer) | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 (a) - Version number (0) 721 (b) - Overall length (5 words not including header) 722 (c) - Service header, service number 5 (controlled-load) 723 (d) - Length of per-service data, 4 words not including header 724 (e) - Parameter ID, parameter 1 (TSpec) 725 (f) - Parameter 1 flags (none set) 727 RSVP SENDER_TSPEC 729 The RSVP SENDER_TSPEC object describes the traffic being generated by 730 a sender. The exact format of the SENDER_TSPEC object depends on 731 whether the sender wishes to allow only the use of controlled-load 732 service (and/or best-effort service) reservations, or wishes to allow 733 the receiver to select the traffic control service desired. 735 For senders wishing to allow only controlled-load service 736 reservations, the format of the RSVP SENDER_TSPEC object is given 737 below. The service-specific header indicates service_name 5, the 738 controlled_load service. The remainder of the data is a 739 controlled_load service TSpec, represented using the preferred 740 concrete representation specified in the 'Invocation Information' 741 section of this memo. 743 31 24 23 16 15 8 7 0 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | 0 (a) | Unused | 5 (b) | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | 5 (c) | 4 (d) | 1 (e) | 0 (f) | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Token Bucket Size [b] (32-bit IEEE floating point number) | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Minimum Policed Unit [m] (32-bit integer) | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Maximum Packet Size [M] (32-bit integer) | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 (a) - Version number (0) 759 (b) - Overall length (5 words not including header) 760 (c) - Service header, service number 5 (controlled-load) 761 (d) - Length of per-service data, 4 words not including header 762 (e) - Parameter ID, parameter 1 (TSpec) 763 (f) - Parameter 1 flags (none set) 765 For senders wishing to allow the receiver to select the reservation 766 service desired, the TSpec contained in the SENDER_TSPEC object 767 should be a generic TSPEC, indicated by a service_specific header 768 specifying service 1. At present, the format of the generic TSpec has 769 not been formally defined. However, FOR EXPERIMENTAL USE ONLY it is 770 permissible to use the following SENDER_TSPEC object to support 771 multi-service receivers. 773 NOTE: This format may change in the next version of this draft 774 31 24 23 16 15 8 7 0 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | 0 (a) | Unused | 5 (b) | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | 1 (c) | 4 (d) | 1 (e) | 0 (f) | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Token Bucket Size [b] (32-bit IEEE floating point number) | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Peak Data Rate [p] (32-bit IEEE floating point number) | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Minimum Policed Unit [m] (32-bit integer) | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Maximum Packet Size [M] (32-bit integer) | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 (a) - Version number (0) 792 (b) - Overall length (5 words not including header) 793 (c) - Service header, service number 1 (generic information) 794 (d) - Length of per-service data, 4 words not including header 795 (e) - Parameter ID, parameter 1 (TSpec) 796 (f) - Parameter 1 flags (none set) 798 RSVP ADSPEC 800 The RSVP ADSPEC object carries characterization parameters and 801 composition variables used in the process of end-to-end service 802 characterization. The controlled-load service does not export any 803 characterization parameters and does not provide any service-specific 804 end-to-end characterizations. Therefore no information is placed into 805 the RSVP ADSPEC message by a controlled-load service module. 807 RSVP ADSPEC messages generated and received by network elements 808 supporting the controlled-load service may contain other information; 809 particularly the general characterization parameters defined in [5]. 810 Any such information will follow the format given in [4], with an 811 identifying service header indicating a service *other* than 812 controlled-load (Service ID Number other than 5). 814 OTHER RSVP OBJECTS 816 No other RSVP objects carry data with formats specific to the 817 controlled-load service. 819 References 821 [1] S. Shenker and J. Wroclawski. "Network Element Service 822 Specification Template", Internet Draft, June 1995, 825 [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. "RTP: 826 A Transport Protocol for Real-Time Applications", Internet Draft, 827 March 1995, 829 [3] B. Braden, L. Zhang, S. Berson, S. Herzog, and J. Wroclawski. 830 "Resource Reservation Protocol (RSVP) - Version 1 Functional 831 Specification", Internet Draft, November 1995, 834 [4] J. Wroclawski. "Standard Data Encoding for Integrated Services 835 Objects", Internet Draft, November 1995, 838 [5] S. Shenker. "Specification of General Characterization 839 Parameters", Internet Draft, November 1995, 842 [6] S. Floyd, and V. Jacobson. "Link-sharing and Resource Management 843 Models for Packet Networks," IEEE/ACM Transactions on Networking, 844 Vol. 3 No. 4, pp. 365-386, August 1995. 846 Authors' Address: 848 John Wroclawski 849 MIT Laboratory for Computer Science 850 545 Technology Sq. 851 Cambridge, MA 02139 852 jtw@lcs.mit.edu 853 617-253-7885 854 617-253-2673 (FAX)