idnits 2.17.1 draft-ietf-intserv-commit-rate-svc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an 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 abstract seems to contain references ([2], [6,7], [3], [4], [5], [8], [8,9], [9], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 246: '... elements MUST return an error for r...' RFC 2119 keyword, line 247: '...Network elements MUST return an error ...' RFC 2119 keyword, line 254: '...Network elements MUST return an error ...' RFC 2119 keyword, line 255: '...range. Network elements MUST return an...' RFC 2119 keyword, line 346: '... packets SHOULD be ''marked'' as bei...' 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) == Unused Reference: '10' is defined on line 654, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 659, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 663, but no explicit reference was found in the text -- 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' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 14 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 F. Baker/ R. Guerin/ D. Kandlur 3 draft-ietf-intserv-commit-rate-svc-00.txt CISCO/IBM/IBM 4 June, 1996 5 Expires: 9/15/96 7 Specification of Committed Rate Quality of 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 23 Shadow 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 document is a product of the Integrated Services working group 28 of 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 document describes the network element behavior required to 35 deliver a Committed Rate service in the Internet. The Committed Rate 36 service provides applications with a firm commitment from the 37 network, that at a minimum the transmission rate they requested is 38 available to them at each network element on their path. The 39 commitment of a given transmission rate by a network element is not 40 associated with a specific delay guarantee, but requires that network 41 elements perform admission control to avoid over-allocation of 42 resources. 44 Introduction 46 This document defines the requirements for network elements that 47 support a Committed Rate service. This memo is one of a series of 48 documents that specify the network element behavior required to 49 support various qualities of service in IP internetworks. Services 50 described in these documents are useful both in the global Internet 51 and private IP networks. 53 This document is based on the service specification template given in 54 [1]. Please refer to that document for definitions and additional 55 information about the specification of qualities of service within 56 the IP protocol family. 58 End-to-End Behavior 60 The end-to-end behavior provided to an application by a series of 61 network elements that conform to the service described in this 62 document is a committed transmission rate that, when used by a 63 policed flow, ensures that its packets are transmitted with no or 64 minimal queueing losses through the network (assuming no failure of 65 network components or changes in routing during the life of the 66 flow). In addition, while this service does not provide any specific 67 delay guarantees, the provision of a committed transmission rate at 68 each network element should ensure that packets do not experience 69 delays at a network element that are significantly in excess of what 70 they would experienced from a dedicated transmission facility 71 operating at the committed rate. 73 To ensure that this service is provided, clients requesting Committed 74 Rate service provide the network elements with both the transmission 75 rate they want to have guaranteed and information on their traffic 76 characteristics. Traffic characteristics are specified in the TSpec 77 of the flow, which is defined in the section on Invocation 78 Information below. In return, the network elements perform admission 79 control to allocate enough resources (bandwidth and buffer) to ensure 80 that over some reasonable time interval, a flow with packets waiting 81 to be transmitted sees a transmission rate at least equal to its 82 requested transmission rate and only experiences packet losses very 83 rarely. 85 Motivation 87 The Committed Rate service is intended to offer applications a 88 service that provides them with the guarantee that the network will 89 commit a certain amount of bandwidth to them in an attempt to emulate 90 a dedicated circuit of at least that amount of bandwidth. This 91 service is intended for applications that require a given amount of 92 bandwidth in order to operate properly. This bandwidth can be 93 related to an intrinsic rate at which the applications generates 94 data, e.g., the average transmission rate of a video codec, or chosen 95 so as to allow the transmission of a certain amount of data within a 96 reasonable time, e.g., a function of the size of the data object to 97 be transmitted and how fast it needs to be received. 99 The rate guarantees provided by the Committed Rate service are in a 100 sense similar to those provided by the Guaranteed Service [2]. 101 However, a key difference is that they are not coupled to the same 102 rigorous delay guarantees provided by the Guaranteed Service. This 103 decoupling simplifies the invocation of the service and its support 104 at intermediate network elements as the service is only a function of 105 local resources at each node and, therefore, independent of the end- 106 to-end characteristics of the path itself. In addition, the 107 relaxation of the delay guarantees to be provided, can allow a higher 108 utilization of network resources, e.g., bandwidth. However, note 109 that this greater simplicity and higher efficiency come at a cost, 110 namely 112 - The lack of hard delay guarantees. This is because the 113 commitment of a transmission rate at a network element can be 114 provided through a range of mechanisms, that correspond to 115 different delay behaviors (see the section on Network Element Data 116 Handling Requirements for additional details). Specifically, 117 depending on the characteristics of the implementation used to 118 support the Committed Rate service at network elements, the worst 119 case delay experienced by packets receiving this service could be 120 much higher than under Guaranteed service, i.e., the delay bounds 121 are relaxed. 123 - The lack of a priori estimates of the end-to-end delay to be 124 expected. This is because rate guarantees are local to each 125 network element, and hence do not provide any end-to-end delay 126 characterization for the path on which the flow is routed. 128 - Weaker loss guarantees as the lack of characterization of the 129 behavior of individual network elements also means, that accurate 130 sizing of buffer requirements to ensure lossless operation cannot 131 be provided. 133 The Committed Rate service is also different from the Controlled-Load 134 service [3] in that it allows policing at the edge of the network and 135 reshaping at intermediated network elements. Note that the emulation 136 of a dedicated circuit at the requested committed rate, can amount to 137 reshaping the flow of packets to this rate. In addition, contrary to 138 the Controlled-Load service that specifies that the transit delay 139 experienced by most packets should be close to the minimum transit 140 delay, the Committed Rate service only guarantees that the transit 141 delay of any packet should not significantly exceed what it would 142 have experienced over a dedicated circuit at the committed rate. 144 The Committed Rate service can, therefore, be viewed as an 145 intermediate service level in between the Guaranteed Service and the 146 Controlled Load service. It provides weaker service guarantees than 147 the Guaranteed Service, but imposes fewer constraints on network 148 elements. This may facilitate deployment in an heterogeneous 149 environment, where not all network elements may be capable of 150 satisfying the requirements of the Guaranteed Service. Similarly, 151 the provision of a fixed rate service guarantee may be less flexible 152 than the Controlled-Load service for adaptive applications, but may 153 simplify the call admission and scheduling functions at network 154 elements. In particular, the buffer and bandwidth allocation 155 functions may benefit from the stricter traffic (TSpec) 156 specification. 158 Network Element Data Handling Requirements 160 The network element must ensure that the service approximates a 161 dedicated circuit of rate at least equal to the requested rate R. 162 This means that the network element must perform call admission to 163 ensure the availability of sufficient bandwidth to accommodate a 164 flow's request for a transmission rate R. This will typically mean 165 allocating an amount of link bandwidth at least equal to R. However, 166 note that this service specification does not require that a network 167 element provide an application with a transmission rate greater than 168 R even when there is excess bandwidth available, i.e., reshaping of 169 the traffic to the rate R is allowed. More generally, approximating 170 a dedicated rate circuit of rate at least R only implies, that if for 171 a period of time T an application has data packets waiting to be 172 transmitted at a network element, i.e., it is backlogged, the amount 173 of data it is able to send during T should approach RT as T grows 174 large. The smaller the value of T for which this is achieved, the 175 better the approximation of a dedicated circuit at rate R. 177 Specifically, the difference between the service provided at a 178 network element and a dedicated rate circuit is a function of the 179 scheduler used at the service element and also reflects the impact of 180 the packetized nature of transmission units. Many recently proposed 181 schedulers, e.g., Weighted Fair Queueing (WFQ) [4], Virtual Clock 182 [5], Rate Controlled Service Disciplines (RCSD) [6,7], Latency Rate 183 Servers [8], etc., can provide reasonably good approximations for 184 such a service, i.e., typically with a value for T of the order of 185 L/R, where L is the size of the packet to be transmitted. On the 186 other hand, other simpler schedulers such as FIFO, static priorities, 187 frame based schedulers [9], may only provide relatively coarse 188 approximations. While this service specification does not mandate 189 the use of a particular type of scheduler, the nature of its service 190 definition, i.e., the close approximation of a dedicated rate 191 circuit, means that the use of schedulers that perform well in 192 regards to this measure is recommended. 194 In addition, the manner in which a network element approximates a 195 dedicated rate circuit will impact the amount of buffering it needs 196 to provide to ensure minimum losses for a compliant flow. For 197 example, a network element for which the scheduler can delay 198 transmission of packets from a given flow for a time period T, may 199 need to buffer up to b+rT amount of data for that flow, where b 200 corresponds to the token bucket depth advertised in the TSpec of the 201 flow and r is the associated token bucket rate (see next section on 202 Invocation Information for details). It is, therefore, expected that 203 each network element allocates, when accepting a new flow, not only 204 enough bandwidth to accommodate the requested rate, but also 205 sufficient buffer space to provide compliant flows with minimal 206 losses. Note that it is possible for a network element to trade 207 bandwidth for buffer space, i.e., allocate to each flow more 208 bandwidth than it requests, so as to ensure a low enough load to keep 209 buffer requirements low. The necessary amount of buffer space is a 210 quantity to be engineered for each network element. For example, 211 edge network elements may need to allocate b or more to each flow 212 (this depends in part on how much larger R is than r), while core 213 network elements may be able to take advantage of statistical 214 multiplexing to allocate much less. 216 Links are not permitted to fragment packets as part of the Committed 217 Rate service. Packets larger than the MTU of the link must be 218 policed as non-conformant which means that they will be policed 219 according to the rules described in the Policing section below. 221 Packet losses due to non-congestion-related causes, such as bit 222 errors are not accounted for by this service. 224 Invocation Information 226 The Committed Rate service is invoked by specifying the traffic 227 (TSpec) of the flow and the desired Committed Rate (RSpec) to the 228 network element. A service request for an existing flow that has a 229 new TSpec and/or RSpec should be treated as a new invocation, in the 230 sense that admission control must be reapplied to the flow. Flows 231 that reduce their TSpec and/or RSpec (i.e., their new TSpec/RSpec is 232 strictly smaller than the old TSpec/RSpec according to the ordering 233 rules described in the section on Ordering below) should never be 234 denied service. 236 The TSpec takes the form of a token bucket plus a peak rate (p), a 237 minimum policed unit (m), and a maximum packet size (M). 239 The token bucket has a bucket depth, b, and a bucket rate, r, which 240 corresponds to the requested rate that the flow is requesting the 241 network to commit. Both b and r must be positive. Note that it is 242 necessary to habe b>=M. The rate, r, is measured in bytes of IP 243 datagrams per second, and can range from 1 byte per second to as 244 large as 40 terabytes per second (or about what is believed to be the 245 maximum theoretical bandwidth of a single strand of fiber). Network 246 elements MUST return an error for requests containing values outside 247 this range. Network elements MUST return an error for any request 248 containing a value within this range which cannot be supported by the 249 element. In practice, only the first few digits of the r parameter 250 are significant, so the use of floating point representations, 251 accurate to at least 0.1%, is encouraged. 253 The bucket depth, b, is measured in bytes and can range from 1 byte 254 to 250 gigabytes. Network elements MUST return an error for requests 255 containing values outside this range. Network elements MUST return an 256 error for any request containing a value within this range which 257 cannot be supported by the element. In practice, only the first few 258 digits of the r parameter are significant, so the use of floating 259 point representations, accurate to at least 0.1%, is encouraged. 261 The range of values for these parameters is intentionally large to 262 allow for future network and transmission technologies. This range 263 is not intended to imply that a network element must be capable of 264 supporting the entire range of values. 266 The peak rate, p, is measured in bytes of IP datagrams per second and 267 has the same range and suggested representation as the bucket rate. 268 The peak rate is the maximum rate at which the source and any 269 reshaping points (reshaping points are defined below) may inject 270 bursts of traffic into the network. More precisely, it is the 271 requirement that for all time periods the amount of data sent cannot 272 exceed M+pT where M is the maximum packet size and T is the length of 273 the time period. Furthermore, p must be greater than or equal to the 274 token bucket rate, r. A peak rate value of 0 means the peak rate is 275 not being used or is unknown. 277 The minimum policed unit, m, is an integer measured in bytes. All IP 278 datagrams less than size m will be counted, when policed and tested 279 for conformance to the TSpec, as being of size m. The maximum packet 280 size, M, is the biggest packet that will conform to the traffic 281 specification; it is also measured in bytes. A network element must 282 reject a service request, if the requested maximum packet size is 283 larger than the MTU of the link. Both m and M must be positive, and 284 m must be less than or equal to M. 286 The RSpec consists of the desired service rate R. The motivations 287 for separating the specification of the rate R from the the token 288 bucket rate in the TSpec, are to provide greater flexibility in the 289 level of service a receiver can request and in simplifying support 290 for shared reservations. With shared reservations, a receiver can 291 request a certain Committed Rate R from the network, that may not be 292 directly related to the token bucket rates specified in the TSpec of 293 the different flows that are to share the reservation. 295 The preferred representation for the TSpec consists of three floating 296 point numbers in single-precision IEEE floating point format followed 297 by two 32-bit integers in network byte order. The first value is the 298 rate (r), the second value is the bucket size (b), the third is the 299 peak rate (p), the fourth is the minimum policed unit (m), and the 300 fifth is the maximum packet size (M). 302 The preferred representation for the RSpec rate, R, is also in 303 single-precision IEEE floating point format. 305 For all IEEE floating point values, the sign bit must be zero. (All 306 values must be positive). Exponents less than 127 (i.e., 0) are 307 prohibited. Exponents greater than 162 (i.e., positive 35) are 308 discouraged. 310 The Committed Rate service is assigned service_name 6. 312 The Committed Rate traffic specification parameter (TSpec) is 313 assigned parameter_name 1, as indicated in the listing of well-known 314 parameter name assignments given in [1]. 316 Exported Information 318 The Committed Rate service has no required characterization 319 parameters. Individual implementations may export appropriate 320 implementation-specific measurement and monitoring information. 322 Policing and Reshaping 324 Policing and reshaping are two related forms of traffic control, that 325 are meant to limit the amount of traffic that an application can 326 inject into the network. In either cases, the result is that only 327 conformant packets are forwarded. Conformance is determined as a 328 function of the TSpec for the flow. A flow is deemed conformant if 329 the amount of data it sent during any given time period of duration T 330 does not exceed M+min[pT, rT+b-M], where p is the peak rate, r and b 331 are the token bucket parameters, and M is the maximum packet size for 332 that flow. For the purposes of this accounting, links must count 333 packets which are smaller than the minimal policing unit to be of 334 size m. Packets which arrive at an element and cause a violation of 335 the M+min[pT, rT+b-M] bound are considered non-conformant. 336 Additionally, packets bigger than the outgoing link MTU are 337 considered non-conformant. It is expected that such a situation will 338 typically not arise, because flow setup mechanisms are expected to 339 notify the sending application of the appropriate path MTU. 341 Policing and reshaping differ in their treatment of non-conformant 342 packets. Policing performs a strict control on the traffic of a 343 given flow by either discarding non-conformant packets, or possibly 344 sending them as best effort packets. Note that if and when a marking 345 ability becomes available, non-conformant packets sent as best-effort 346 packets SHOULD be ''marked'' as being non-compliant so that they can 347 be treated as best effort packets at all subsequent network elements. 348 In the context of the Committed Rate service, policing should ONLY be 349 performed at the edge of the network, where it is used to ensure 350 conformance of the user traffic with the TSpec it advertised. 352 On the other hand, the strict traffic control implied by policing is 353 NOT appropriate inside the network, since the perturbations caused by 354 the queueing and scheduling delays at network elements will often 355 turn an initially conformant flow into a non-conformant one. 356 Instead, it is recommended that reshaping be used at intermediate 357 network elements inside the network. Reshaping amounts to delaying 358 (buffering) non-conformant packets until they are compliant, rather 359 than discard or send them as best-effort. Reshaping, therefore, 360 restores the traffic characteristics of a flow to conform to the 361 specified token bucket and peak rate parameters used by the reshaper. 362 (To avoid delaying unnecessarily the initial packets of a flow, the 363 token bucket at a reshaper should be initialized full). 365 The benefit of restoring a flow to its original envelope is that it 366 limits the magnitude of the "distortions" that schedulers at network 367 elements can introduce in the initial stream of packets from a flow. 368 As discussed in the section on Network Element Data Handling 369 Requirements, depending on how well a scheduler approximates a 370 dedicated rate circuit, significant bunching up of packets can be 371 introduced. This translates in turn into bigger buffer requirements 372 at downstream network elements. Reshaping the flow ensures that 373 downstream network elements are isolated from the bunching effects 374 introduced by upstream schedulers. However, note that in order to 375 achieve these benefits, the reshapers must provide sufficient buffer 376 space to hold packets until they can be released as compliant with 377 the traffic envelope to which the flow is being reshaped. 379 Contrary to the Guaranteed Service where the information exported by 380 network elements allows the computation of an upper bound on the 381 amount of buffer needed when reshaping traffic, in the context of the 382 Committed Rate service this quantity can only be estimated. The 383 required amount to ensure minimum packet losses to Committed Rate 384 flows is, therefore, a quantity to be engineered for each network 385 element. 387 If a packet arrives at a reshaper and finds the reshaping buffer 388 full, the packet can either be discarded or accommodated by 389 forwarding as best effort a packet of the flow. 391 NOTE: As with policers, it should be possible to configure how 392 reshapers handle packets that arrive to a full reshaping buffer. 393 If such cases are to be handled by forwarding a packet as best 394 effort, reshaping points may wish to forward a packet from the 395 front of the reshaping queue, in order to minimize packet 396 reordering problems at the receiver(s). 398 Ordering and Merging 400 TSpec's are ordered according to the following rule: TSpec A is a 401 substitute ("as good or better than") for TSpec B if 403 (1) both the token bucket depth and rate for TSpec A are greater 404 than or equal to those of TSpec B, 406 (2) the minimum policed unit m is at least as small for TSpec A as 407 it is for TSpec B, 409 (3) the maximum packet size M is at least as large for TSpec A as 410 it is for TSpec B, 412 (4) the peak rate p is at least as large in TSpec A as it is in 413 TSpec B. 415 A merged TSpec may be calculated over a set of TSpec's by taking the 416 largest token bucket rate, largest bucket size, largest peak rate, 417 smallest minimal policed unit, and largest maximum packet size across 418 all members of the set. This use of the word "merging" is similar to 419 that in the RSVP protocol; a merged TSpec is one which is adequate to 420 describe the traffic from any one of a number of flows. 422 RSpec's are merged in a similar manner as the TSpec's, i.e., a set of 423 RSpec's is merged onto a single RSpec by taking the largest rate R of 424 all RSpec's in the set. 426 NOTE: In case of shared reservations, i.e., a single RSpec whose 427 rate, R, is to be shared between a number of flows, it is 428 important to chose the requested rate R so as to ensure stable 429 operation. Selection of the appropriate value is an application 430 level decision, but two general cases may be considered. In the 431 first case, the token bucket rates advertized by the senders 432 sharing the reservation correspond to their average rate while 433 active, e.g., the average rate for a voice signal when the speaker 434 is talking. In such situations, the requested service rate R may 435 be chosen to be significantly less than the sum of the token 436 bucket rates of all the flows sharing the reservation. For 437 example, this would apply to an audio conference call where only 438 one speaker will typically be active at any time. In the second 439 case, the token bucket rates advertized by the senders sharing the 440 reservation correspond to their true long term average rate. In 441 that case it is important that the requested service rate R be 442 chosen larger than the sum of the token bucket rates of all the 443 flows sharing the reservation. 445 Guidelines for Implementors 447 This section reviews two important implementation aspects of a 448 Committed Rate service, that are closely related. 450 (1) The approximation of a dedicated rate circuit, 452 (2) The allocation of sufficient buffering to ensure minimal 453 losses. 455 As mentioned in the section on Network Element Data Handling 456 Requirement, support for the Committed Rate service requires that the 457 network element approximates as well as possible the behavior of a 458 dedicated rate circuit. This means, assuming a requested rate R, 459 that whenever a flow is backlogged (has packets waiting to be 460 transmitted) at a network element, it should ideally be able to 461 transmit the packet at the head of its queue within at most L/R time 462 units, where L is the size in bits of the packet. The ability of a 463 network element to achieve this behavior depends on the type of 464 scheduler it uses. While simple schedulers such as FIFO or priority 465 queues may be used, it is highly recommended that an implementation 466 of Committed Rate rely on a scheduler capable of providing service 467 guarantees to individual connections. As mentioned in the section 468 below on Examples of Use, there are a number of available schedulers 469 that provide such capabilities. 471 In addition to choosing an appropriate scheduling algorithm, an 472 implementation of the Committed Rate service at a network element 473 also requires the use of an admission control algorithm. Admission 474 control is required to ensure that the network element resources, 475 i.e., bandwidth and buffers, are not over-committed. Admission 476 control is to be performed based on the TSpec and RSpec specified by 477 each flow requesting the Committed Rate service. The RSpec 478 identifies the amount of bandwidth that the flow is requesting, and 479 which should, therefore, at a minimum be available on the 480 corresponding outgoing link from the network element. The exact 481 amount of bandwidth to be allocated to the flow by the call admission 482 algorithm depends on both the scheduler and the buffering scheme 483 used. It is, therefore, a quantity to be engineered for each network 484 element. 486 The admission control algorithm is also responsible for ensuring that 487 sufficient buffer space is available to accommodate a new request. 488 This is a function of the TSpec of the flow, in particular the peak 489 rate, p, and the token bucket depth, b, but in general depends on a 490 number of factors: 492 - The token bucket and peak rate parameters and the requested 493 service rate R, i.e., how fast and for how long can the flow be 494 sending at a rate exceeding the transmission rate R that has been 495 allocated to it. 497 - The amount of statistical multiplexing that is expected at the 498 network element, i.e., how likely is it that all flows 499 simultaneously need the maximum possible amount of buffers. 501 - The perturbations introduced by schedulers at upstream network 502 elements since the last reshaping point, i.e., how much bunching 503 of packets is likely to have been introduced. 505 For example, assuming a scheduler that approximates reasonably 506 closely the behavior of a dedicated rate circuit, e.g., a WFQ 507 scheduler, a possible buffer allocation rule for a flow with given 508 TSpec and committed rate R, is to ensure that the network element is 509 able to buffer an amount of data of the order of b(p-R)/(p-r), where 510 b is the token bucket depth, r the token bucket rate, and p the peak 511 rate. Depending on the amount of statistical multiplexing expected 512 at the network element, this does NOT necessarily imply that this 513 amount of buffers has to be dedicated to the flow, i.e., buffer 514 allocation is not necessarily additive in the number of flows even if 515 this represents a simple and somewhat conservative rule. 517 However, note that the amount of buffering needed for flow at a 518 network element also depends, to some extent, on the behavior of 519 upstream (previous) network elements. For example, assuming that the 520 scheduler at the previous network element did not approximate well 521 the behavior of a dedicated rate circuit, e.g., could delay 522 transmission of packets of a flow for a time period of duration T, 523 the next (downstream) network element may then have to buffer the 524 entire amount b+rT, if at the end of the period T this gets 525 transmitted at at a speed much higher than the rate R. Hence, as 526 mentioned before, even though the Committed Rate service 527 specification does not mandate a particular type of scheduler, it 528 encourages the use of schedulers that approximates as closely as 529 possible a dedicated rate circuit, so as to minimize buffering 530 requirements at downstream network elements. 532 Evaluation Criteria 534 The scheduling algorithm and admission control algorithm of the 535 element must ensure that the requested committed rate is provided 536 over some reasonably long time period, and that packets from a 537 compliant flow are rarely lost. 539 The closer a network element approximates the behavior of a dedicated 540 circuit at the requested committed rate, the better it performs in 541 supporting the Committed Rate service. 543 This behavior can be evaluated by continuously sending packet into 544 the network at the maximum possible rate allowed while remaining 545 conformant, and by monitoring the delay experienced when traversing a 546 series of network elements. The lower the average delay and its 547 variations, i.e., difference between the maximum and minimum values, 548 as experienced by the packets, the higher the evaluation ratings for 549 the service. In addition, the smaller the value of the time period 550 needed to transmit the amount of data corresponding to the Committed 551 Rate, the higher the evaluation ratings for the service. 553 This behavior should also be consistently provided to flows accepted 554 by the admission control algorithm, independently of the load levels 555 at network elements. This should be tested by increasing the 556 background best effort traffic on the network elements as well as by 557 increasing, up to the maximum number allowed by the call admission 558 algorithm of each network element, the number of Committed Rate flows 559 being carried. The smaller the worst case values for the delay 560 experienced by Committed Rate service flows across the range of load 561 conditions, the higher the evaluation ratings for the service. 563 Additionally, users may want to evaluate, when applicable, the 564 behavior of the Committed Rate service at a network element, when 565 provided jointly with some other services whose more rigorous service 566 requirements may affect the level of service given to Committed Rate 567 flows. For example, this may apply to network elements that support 568 both the Guaranteed Service and the Committed Rate service. 569 Evaluation of this behavior can be achieved by loading the network 570 element with a "test" Committed Rate flow and the maximum possible 571 amount of Guaranteed Service traffic that the network element(s) can 572 accept. The delays experienced by the Committed Rate flow should 573 then be compared to those experienced in the other configurations 574 described above. As before, the smaller the delay values, the higher 575 the evaluation ratings for the service. 577 Examples of Implementation 579 Several scheduling algorithms and implementations exist that allow a 580 close approximation of a dedicated rate circuit. They include 581 Weighted Fair Queueing (WFQ) [4], Virtual Clock [5], Rate Controlled 582 Service Disciplines [6,7], etc. Additional theoretical results 583 positioning these results in the context of broader classes of 584 algorithms can be found in [8,9]. 586 Examples of Use 588 Consider an application that requires a specific guaranteed 589 throughput in order to operate properly, but is reasonably tolerant 590 in terms of the delay and delay variations it will experience, so 591 that the delay guarantees of the Guaranteed service may not be 592 warranted. For example, this may consist of an application 593 retrieving a large document including graphics and pictures from a 594 web server. This application wants a large enough rate to ensure 595 that the document is retrieved reasonably fast, but does not require 596 tight delay guarantees as the user will typically start browsing the 597 initial material received and can, therefore, tolerate delay 598 variations in receiving the remainder of the data. Another example, 599 is that of a transaction based application that requires the transfer 600 of reasonably large amounts of data in sufficiently timely fashion to 601 ensure an adequate response time. Such an application will be 602 satisfied by the provision of a large enough transmission rate, but 603 again does not need very tight delay guarantees. 605 Security Considerations 607 Security considerations are not discussed in this memo. 609 Acknowledgments 611 The authors would like to gratefully acknowledge the help of the 612 INT-SERV working group and the many contributions to its mailing 613 list. In addition, they would like to acknowledge the Guaranteed 614 Service specifications which served as a base for many of the aspects 615 discussed in this draft. 617 References 619 [1] S. Shenker and J. Wroclawski. "Network Element Service 620 Specification Template," Internet Draft, June 1995, 623 [2] S. Shenker and C. Partridge. "Specification of Guaranteed 624 Quality of Service," Internet Draft, November 1995, 627 [3] J. Wroclawski. "Specification of The Controlled-Load Network 628 Element Service," Internet Draft, November 1995, 631 [4] A. Demers, S. Keshav and S. Shenker, "Analysis and Simulation of 632 a Fair Queueing Algorithm," in Internetworking: Research and 633 Experience, Vol 1, No. 1., pp. 3-26. 635 [5] L. Zhang, "Virtual Clock: A New Traffic Control Algorithm for 636 Packet Switching Networks," in Proc. ACM SIGCOMM'90, pp. 19-29. 638 [6] H. Zhang, and D. Ferrari, "Rate-Controlled Service Disciplines," 639 Journal of High Speed Networks, 3(4):389--412, 1994. 641 [7] L. Georgiadis, R. Guerin, V. Peris, and K. N. Sivaraja, 642 "Efficient Network QoS Provisioning Based on per Node Traffic 643 Shaping," IEEE/ACM Transactions on Networking, 4(4), August 1996. 645 [8] D. Stiliadis and A. Varma, "Latency-Rate Servers: A General Model 646 for Analysis of Traffic Scheduling Algorithms," on Proc. INFOCOM'96, 647 pp. 111-119. 649 [9] P. Goyal, S.S. Lam and H.M. Vin, "Determining End-to-End Delay 650 Bounds in Heterogeneous Networks," in Proc. 5th Intl. Workshop on 651 Network and Operating System Support for Digital Audio and Video, 652 April 1995. 654 [10] B. Braden, L. Zhang, S. Berson, S. Herzog, and J. Wroclawski. 655 "Resource Reservation Protocol (RSVP) - Version 1 Functional 656 Specification," Internet Draft, November 1995, 659 [11] J. Wroclawski. "Standard Data Encoding for Integrated Services 660 Objects," Internet Draft, November 1995, 663 [12] S. Shenker. "Specification of General Characterization 664 Parameters," Internet Draft, November 1995, 667 Authors' Address: 669 Fred Baker 670 Cisco Systems 671 519 Lado Drive 672 Santa Barbara, California 93111 673 fred@cisco.com 674 VOICE +1 408 526-4257 675 FAX +1 805 681-0115 677 Roch Guerin 678 IBM T.J. Watson research Center 679 P.O. Box 704 680 Yorktown Heights, NY 10598 681 guerin@watson.ibm.com 682 VOICE +1 914 784-7038 683 FAX +1 914 784-6318 685 Dilip Kandlur 686 IBM T.J. Watson research Center 687 P.O. Box 704 688 Yorktown Heights, NY 10598 689 kandlur@watson.ibm.com 690 VOICE +1 914 784-7722 691 FAX +1 914 784-6625