idnits 2.17.1 draft-ietf-diffserv-rfc2598bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 466 has weird spacing: '...size if appro...' -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2001) is 8411 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2474' on line 491 == Unused Reference: '1' is defined on line 502, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 505, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 512, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2598 (ref. '1') (Obsoleted by RFC 3246) ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 2983 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bruce Davie, Editor 3 Internet Draft Anna Charny 4 Expiration Date: October 2001 Fred Baker 5 Cisco Systems, Inc. 6 Jon Bennet 7 Riverdelta Networks 9 Kent Benson Jean-Yves Le Boudec 10 Tellabs EPFL 12 Angela Chiu William Courtney 13 AT&T Labs TRW 15 Shahram Davari Victor Firoiu 16 PMC-Sierra Nortel Networks 18 Charles Kalmanek K.K. Ramakrishnam 19 AT&T Research TeraOptic Networks 21 Dimitrios Stiliadis 22 Lucent Technologies 24 April 2001 26 An Expedited Forwarding PHB 28 draft-ietf-diffserv-rfc2598bis-01.txt 30 Status of this Memo 32 This document is an Internet-Draft and is in full conformance with 33 all provisions of Section 10 of RFC2026. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt. 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 This document is a product of the Diffserv working group of the 58 Internet Engineering Task Force. Please address comments to the 59 group's mailing list at diffserv@ietf.org, with a copy to the 60 authors. 62 Copyright Notice 64 Copyright (C) The Internet Society (2001). All Rights Reserved. 66 Abstract 68 The PHB (per-hop behavior) is a basic building block in the 69 Differentiated Services architecture. This document defines a PHB 70 called Expedited Forwarding (EF). EF is intended to provide a 71 building block for low delay, low jitter and low loss services by 72 ensuring that the EF aggregate is served at a certain configured 73 rate. 75 Contents 77 1 Introduction ........................................... 3 78 2 Definition of EF PHB ................................... 4 79 2.1 Intuitive Description of EF ............................ 4 80 2.2 Formal Definition of the EF PHB ........................ 5 81 2.3 Figures of merit ....................................... 8 82 2.4 Delay and jitter ....................................... 9 83 2.5 Loss ................................................... 10 84 2.6 Microflow misordering .................................. 10 85 2.7 Recommended codepoint for this PHB ..................... 10 86 2.8 Mutability ............................................. 11 87 2.9 Tunneling .............................................. 11 88 2.10 Interaction with other PHBs ............................ 11 89 3 Security Considerations ................................ 11 90 4 IANA Considerations .................................... 12 91 5 Acknowledgments ........................................ 12 92 6 References ............................................. 12 93 7 Full Copyright ......................................... 16 95 Specification of Requirements 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [3]. 101 1. Introduction 103 Network nodes that implement the differentiated services enhancements 104 to IP use a codepoint in the IP header to select a per-hop behavior 105 (PHB) as the specific forwarding treatment for that packet [RFC2474, 106 RFC2475]. This memo describes a particular PHB called expedited 107 forwarding (EF). 109 The intent of the EF PHB is to provide a building block for low loss, 110 low delay, and low jitter services. The details of exactly how to 111 build such services are outside the scope of this specification. 113 The dominant causes of delay in packet networks are fixed propagation 114 delays (e.g. those arising from speed-of-light delays) on wide area 115 links and queuing delays in switches and routers. Since propagation 116 delays are a fixed property of the topology, delay and jitter are 117 minimized when queueing delays are minimized. In this context, jitter 118 is defined as the variation between maximum and minimum delay. The 119 intent of the EF PHB is to provide a PHB in which suitably marked 120 packets usually encounter short or empty queues. Furthermore, if 121 queues remain short relative to the buffer space available, packet 122 loss is also kept to a minimum. 124 To ensure that queues encountered by EF packets are usually short, it 125 is necessary to ensure that the service rate of EF packets on a given 126 output interface exceeds their arrival rate at that interface over 127 long and short time intervals, independent of the load of other 128 (non-EF) traffic. This specification defines a PHB in which EF 129 packets are guaranteed to receive service at or above a configured 130 rate and provides a means to quantify the accuracy with which this 131 service rate is delivered over any time interval. It also provides a 132 means to quantify the maximum delay and jitter that a packet may 133 experience under bounded operating conditions. 135 Note that the EF PHB only defines the behavior of a single node. The 136 specification of behavior of a collection of nodes is outside the 137 scope of this document. A Per-Domain Behavior (PDB) specification [7] 138 may provide such information. 140 When a DS-compliant node claims to implement the EF PHB, the 141 implementation MUST conform to the specification given in this 142 document. However, the EF PHB is not a mandatory part of the 143 Differentiated Services architecture - a node is NOT REQUIRED to 144 implement the EF PHB in order to be considered DS-compliant. 146 2. Definition of EF PHB 148 2.1. Intuitive Description of EF 150 Intuitively, the definition of EF is simple: the rate at which EF 151 traffic is served at a given output interface should be at least the 152 configured rate R, over a suitably defined interval, independent of 153 the offered load of non-EF traffic to that interface. Two 154 difficulties arise when we try to formalize this intuition: 156 - it is difficult to define the appropriate timescale at which to 157 measure R. By measuring at short timescales we may introduce 158 sampling errors; at long timescales we may allow excessive jitter. 160 - EF traffic clearly cannot be served at rate R if there are no EF 161 packets waiting to be served, but it may be impossible to 162 determine externally whether EF packets are actually waiting to be 163 served by the output scheduler. For example, if an EF packet has 164 entered the router and not exited, it may be awaiting service, or 165 it may simply have encountered some processing or transmission 166 delay within the router. 168 The formal definition below takes account of these issues. It assumes 169 that EF packets should ideally be served at rate R or faster, and 170 bounds the deviation of the actual departure time of each packet from 171 the "ideal" departure time of that packet. We define the departure 172 time of a packet as the time when the last bit of that packet leaves 173 the node. The "ideal" departure time of each EF packet is computed 174 iteratively. 176 In the case when an EF packet arrives to a device when all the 177 previous EF packets have already departed, the computation of the 178 ideal departure time is simple. Service of the packet should 179 (ideally) start as soon as it arrives, so the ideal departure time is 180 simply the arrival time plus the ideal time to transmit the packet at 181 rate R. For a packet of length L_j, that transmission time at the 182 configured rate R is L_j/R. (Of course, a real packet will typically 183 get transmitted at line rate once its transmission actually starts, 184 but we are calculating the ideal target behavior here; the ideal 185 service takes place at rate R.) 187 In the case when an EF packet arrives to a device that still contains 188 EF packets awaiting service, the computation of the ideal departure 189 time is more complicated. There are two cases to be considered. If 190 the previous (j-1-th) departure occurred after its own ideal 191 departure time, then the scheduler is running "late". In this case, 192 the ideal time to start service of the new packet is the ideal 193 departure time of the previous (j-1-th) packet, or the arrival time 194 of the new packet, whichever is later, because we can't expect a 195 packet to begin service before it arrives. If the previous (j-1-th) 196 departure occurred before its own ideal departure time, then the 197 scheduler is running "early". In this case, service of the new packet 198 should begin at the actual departure time of the previous packet. 200 Once we know the time at which service of the jth packet should 201 (ideally) begin, then the ideal departure time of the jth packet is 202 L_j/R seconds later. Thus we are able to express the ideal departure 203 time of the jth packet in terms of the arrival time of the jth 204 packet, the actual departure time of the j-1-th packet, and the ideal 205 departure time of the j-1-th packet. Equations eq_1 and eq_2 in 206 Section 2.2 capture this relationship. 208 Whereas the original EF definition did not provide any means to 209 guarantee the delay of an individual EF packet, this property may be 210 desired. For this reason, the equations in Section 2.2 consist of two 211 parts: an "aggregate behavior" set and a "packet-identity-aware" set 212 of equations. The aggregate behavior equations (eq_1 and eq_2) simply 213 describe the properties of the service delivered to the EF aggregate 214 by the device. The "packet-identity-aware" equations (eq_3 and eq_4) 215 enable the bound on delay of an individual packet to be calculated 216 given a knowledge of the operating conditions of the device. The 217 significance of these two sets of equations is discussed further in 218 Section 2.2. Note that these two sets of equations provide two ways 219 of characterizing the behavior of a single device, not two different 220 modes of behavior. 222 2.2. Formal Definition of the EF PHB 224 A node that supports EF on an interface I at some configured rate R 225 MUST satisfy the following equations: 227 d_j <= f_j + E_a for all j > 0 (eq_1) 229 where f_j is defined iteratively by 231 f_0 = 0, d_0 = 0 233 f_j = max(a_j, min(d_j-1, f_j-1)) + l_j/R, for all j > 0 (eq_2) 235 In this definition: 237 - d_j is the time that the last bit of the j-th EF packet to 238 depart actually leaves the node from the interface I. 240 - f_j is the target departure time for the j-th EF packet to 241 depart from I, the "ideal" time at or before which the last bit of 242 that packet should leave the node. 244 - a_j is the time that the last bit of the j-th EF packet destined 245 to the output I actually arrives at the node. 247 - l_j is the size (bits) of the j-th EF packet to depart from I. 248 l_j is measured on the IP datagram (IP header plus payload) and 249 does not include any lower layer (e.g. MAC layer) overhead. 251 - R is the EF configured rate at output I (in bits/second). 253 - E_a is the error term for the treatment of the EF aggregate. 254 Note that E_a represents the worst case deviation between actual 255 departure time of an EF packet and ideal departure time of the 256 same packet, i.e. E_a provides an upper bound on (d_j - f_j) for 257 all j. 259 - d_0 and f_0 do not refer to a real packet departure but are used 260 purely for the purposes of the recursion. The time origin should 261 be chosen such that no EF packets are in the system at time 0. 263 - for the definitions of a_j and d_j, the "last bit" of the packet 264 includes the layer 2 trailer if present, because a packet cannot 265 generally be considered available for forwarding until such a 266 trailer has been received. 268 An EF-compliant node MUST be able to be characterized by the range of 269 possible R values that it can support on each of its interfaces while 270 conforming to these equations, and the value of E_a that can be met 271 on each interface. R may be line rate or less. E_a MAY be specified 272 as a worst-case value for all possible R values or MAY be expressed 273 as a function of R. 275 Note also that, since a node may have multiple inputs and complex 276 internal scheduling, the jth EF packet to arrive at the node destined 277 for a certain interface may not be the jth EF packet to depart from 278 that interface. It is in this sense that eq_1 and eq_2 are unaware of 279 packet identity. 281 In addition, a node that supports EF on an interface I at some 282 configured rate R MUST satisfy the following equations: 284 D_j <= F_j + E_p for all j > 0 (eq_3) 286 where F_j is defined iteratively by 288 F_0 = 0, D_0 = 0 290 F_j = max(A_j, min(D_j-1, F_j-1)) + L_j/R, for all j > 0 (eq_4) 292 In this definition: 294 - D_j is actual the departure time of the individual EF packet 295 that arrived at the node destined for interface I at time A_j, 296 i.e., given a packet which was the j-th EF packet destined for I 297 to arrive at the node via any input, D_j is the time at which the 298 last bit of that individual packet actually leaves the node from 299 the interface I. 301 - F_j is the target departure time for the individual EF packet 302 that arrived at the node destined for interface I at time A_j. 304 - A_j is the time that the last bit of the j-th EF packet destined 305 to the output I to arrive actually arrives at the node. 307 - L_j is the size (bits) of the j-th EF packet to arrive at the 308 node that is destined to output I. L_j is measured on the IP 309 datagram (IP header plus payload) and does not include any lower 310 layer (e.g. MAC layer) overhead. 312 - R is the EF configured rate at output I (in bits/second). 314 - E_p is the error term for the treatment of individual EF 315 packets. Note that E_p represents the worst case deviation between 316 actual departure time of an EF packet and ideal departure time of 317 the same packet, i.e. E_p provides an upper bound on (D_j - F_j) 318 for all j. 320 - D_0 and F_0 do not refer to a real packet departure but are used 321 purely for the purposes of the recursion. The time origin should 322 be chosen such that no EF packets are in the system at time 0. 324 - for the definitions of A_j and D_j, the "last bit" of the packet 325 includes the layer 2 trailer if present, because a packet cannot 326 generally be considered available for forwarding until such a 327 trailer has been received. 329 It is the fact that D_j and F_j refer to departure times for the jth 330 packet to arrive that makes eq_3 and eq_4 aware of packet identity. 331 This is the critical distinction between the last two equations and 332 the first two. 334 An EF-compliant node SHOULD be able to be characterized by the range 335 of possible R values that it can support on each of its interfaces 336 while conforming to these equations, and the value of E_p that can be 337 met on each interface. E_p MAY be specified as a worst-case value for 338 all possible R values or MAY be expressed as a function of R. An E_p 339 value of "undefined" MAY be specified. For discussion of situations 340 in which E_p may be undefined see the Appendix and [6]. 342 For the purposes of testing conformance to these equations, it may be 343 necessary to deal with packet arrivals on different interfaces that 344 are closely spaced in time. If two or more EF packets destined for 345 the same output interface arrive (on different inputs) at almost the 346 same time and the difference between their arrival times can't be 347 measured, then it is acceptable to use a random tie-breaking method 348 to decide which packet arrived "first". 350 2.3. Figures of merit 352 E_a and E_p may be thought of as "figures of merit" for a device. A 353 smaller value of E_a means that the device serves the EF aggregate 354 more smoothly at rate R over relatively short timescales, whereas a 355 larger value of E_a implies a more bursty scheduler which serves the 356 EF aggregate at rate R only when measured over longer intervals. A 357 device with a larger E_a can "fall behind" the ideal service rate R 358 by a greater amount than a device with a smaller E_a. 360 A lower value of E_p implies a tighter bound on the delay experienced 361 by an individual packet. Factors that might lead to a higher E_p 362 might include a large number of input interfaces (since an EF packet 363 might arrive just behind a large number of EF packets that arrived on 364 other interfaces), or might be due to internal scheduler details 365 (e.g. per-flow scheduling within the EF aggregate). 367 We observe that factors that increase E_a such as those noted above 368 will also increase E_p, and that E_p is thus typically greater than 369 or equal to E_a. In summary, E_a is a measure of deviation from 370 ideal service of the EF aggregate at rate R, while E_p measures both 371 non-ideal service and non-FIFO treatment of packets within the 372 aggregate. 374 For more discussion of these issues see the Appendix and [6]. 376 2.4. Delay and jitter 378 Given a known value of E_p and a knowledge of the bounds on the EF 379 traffic offered to a given output interface, summed over all input 380 interfaces, it is possible to bound the delay and jitter that will be 381 experienced by EF traffic leaving the node via that interface. The 382 delay bound is 384 D = B/R + E_p (eq_5) 386 where 388 - R is the configured EF service rate on the output interface 390 - the total offered load of EF traffic destined to the output 391 interface, summed over all input interfaces, is bounded by a token 392 bucket of rate r <= R and depth B 394 Since the minimum delay through the device is clearly at least zero, 395 D also provides a bound on jitter. To provided a tighter bound on 396 jitter, the value of E_p for a device MAY be specified as two 397 separate components such that 399 E_p = E_fixed + E_variable 401 where E_fixed represents the minimum delay that can be experienced by 402 an EF packet through the node. 404 2.5. Loss 406 The EF PHB is intended to be a building block for low loss services. 407 However, under sufficiently high load of EF traffic (including 408 unexpectedly large bursts from many inputs at once), any device with 409 finite buffers may need to discard packets. Thus, it must be possible 410 to establish whether a device conforms to the EF definition even when 411 some packets are lost. This is done by performing an "off-line" test 412 of conformance to equations 1 through 4. After observing a sequence 413 of packets entering and leaving the node, the packets which did not 414 leave are assumed lost and are notionally removed from the input 415 stream. The remaining packets now constitute the arrival stream (the 416 a_j's) and the packets which left the node constitute the departure 417 stream (the d_j's). Conformance to the equations can thus be verified 418 by considering only those packets that successfully passed through 419 the node. 421 In addition, to assist in meeting the low loss objective of EF, a 422 node MAY be characterized by the operating region in which loss of EF 423 due to congestion will not occur. This MAY be specified, using a 424 token bucket of rate r <= R and burstsize B, as the sum of traffic 425 across all inputs to a given output interface that can be tolerated 426 without loss. 428 In the event that loss does occur, the specification of which packets 429 are lost is beyond the scope of this document. However it is a 430 requirement that those packets not lost MUST conform to the equations 431 of Section 2.2. 433 2.6. Microflow misordering 435 Packets belonging to a single microflow within the EF aggregate 436 passing through a device SHOULD NOT experience re-ordering in normal 437 operation of the device. 439 2.7. Recommended codepoint for this PHB 441 Codepoint 101110 is RECOMMENDED for the EF PHB. 443 2.8. Mutability 445 Packets marked for EF PHB MAY be remarked at a DS domain boundary 446 only to other codepoints that satisfy the EF PHB. Packets marked for 447 EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS 448 domain. 450 2.9. Tunneling 452 When EF packets are tunneled, the tunneling packets SHOULD be marked 453 as EF. A full discussion of tunneling issues is presented in [5]. 455 2.10. Interaction with other PHBs 457 Other PHBs and PHB groups may be deployed in the same DS node or 458 domain with the EF PHB. The equations of Section 2.2 MUST hold for a 459 node independent of the amount of non-EF traffic offered to it. 461 If the EF PHB is implemented by a mechanism that allows unlimited 462 preemption of other traffic (e.g., a priority queue), the 463 implementation MUST include some means to limit the damage EF traffic 464 could inflict on other traffic (e.g., a token bucket rate limiter). 465 Traffic that exceeds this limit MUST be discarded. This maximum EF 466 rate, and burst size if appropriate, MUST be settable by a network 467 administrator (using whatever mechanism the node supports for non- 468 volatile configuration). 470 3. Security Considerations 472 To protect itself against denial of service attacks, the edge of a DS 473 domain SHOULD strictly police all EF marked packets to a rate 474 negotiated with the adjacent upstream domain. Packets in excess of 475 the negotiated rate SHOULD be dropped. If two adjacent domains have 476 not negotiated an EF rate, the downstream domain SHOULD use 0 as the 477 rate (i.e., drop all EF marked packets). 479 In addition, traffic conditioning at the ingress to a DS-domain MUST 480 ensure that only packets having DSCPs that correspond to an EF PHB 481 when they enter the DS-domain are marked with a DSCP that corresponds 482 to EF inside the DS-domain. Such behavior is as required by RFC 483 2475. It protects against denial-of-service and theft-of-service 484 attacks which exploit DSCPs that are not identified in any TCS 485 provisioned at an ingress interface, but which map to EF inside the 486 DS-domain. 488 4. IANA Considerations 490 This document allocates one codepoint, 101110, in Pool 1 of the code 491 space defined by [RFC2474]. 493 5. Acknowledgments 495 This document draws heavily on the original EF PHB definition of 496 Jacobson, Nichols and Poduri. It was also greatly influenced by the 497 work of the EFRESOLVE team of Armitage, Casati, Crowcroft, Halpern, 498 Kumar, and Schnizlein. 500 6. References 502 [1] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding 503 PHB", RFC 2598, June 1999 505 [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement 506 Levels", RFC 2119, BCP 14, March 1997 508 [3] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the 509 Differentiated Services Field (DS Field) in the IPv4 and IPv6 510 Headers", RFC 2474, December 1998. 512 [4] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An 513 Architecture for Differentiated Services", RFC 2475, December 1998. 515 [5] D. Black, "Differentiated Services and Tunnels", RFC 2983, 516 October 2000. 518 [6] A. Charny et al., "Supplemental Information for the New 519 Definition of the EF PHB", Work in Progress, February 2001. 521 [7] K. Nichols and B. Carpenter, "Definition of Differentiated 522 Services Per Domain Behaviors and Rules for their Specification", 523 Work in Progress, January 2001. 525 Appendix: Implementation Examples 527 This appendix is not part of the normative specification of EF. 528 However, it is included here as a possible source of useful 529 information for implementors. 531 A variety of factors in the implementation of a node supporting EF 532 will influence the values of E_a and E_p. These factors are discussed 533 in more detail in [6], and include both output schedulers and the 534 internal design of a device. 536 A priority queue is widely considered as the canonical example of an 537 implementation of EF. A "perfect" output buffered device (i.e. one 538 which delivers packets immediately to the appropriate output queue) 539 with a priority queue for EF traffic will provide both a low E_a and 540 a low E_p. We note that the main factor influencing E_a will be the 541 inability to pre-empt an MTU-sized non-EF packet that has just begun 542 transmission at the time when an EF packet arrives at the output 543 interface, plus any additional delay that might be caused by non- 544 pre-emptable queues between the priority queue and the physical 545 interface. E_p will be influenced primarily by the number of 546 interfaces. 548 Another example of an implementation of EF is a weighted round robin 549 scheduler. Such an implementation will typically not be able to 550 support values of R as high as the link speeds, because the maximum 551 rate at which EF traffic can be served in the presence of competing 552 traffic will be affected by the number of other queues and the 553 weights given to them. Furthermore, such an implementation is likely 554 to have a value of E_a that is higher than a priority queue 555 implementation, all else being equal, as a result of the time spent 556 serving non-EF queues by the round robin scheduler. 558 Finally, it is possible to implement hierarchical scheduling 559 algorithms, such that some non-FIFO scheduling algorithm is run on 560 sub-flows within the EF aggregate, while the EF aggregate as a whole 561 could be served at high priority or with a large weight by the top- 562 level scheduler. Such an algorithm might perform per-input scheduling 563 or per-microflow scheduling within the EF aggregate, for example. 564 Because such algorithms lead to non-FIFO service within the EF 565 aggregate, the value of E_p for such algorithms may be higher than 566 for other implementations. For some schedulers of this type it may be 567 difficult to provide a meaningful bound on E_p that would hold for 568 any pattern of traffic arrival, and thus a value of "undefined" may 569 be most appropriate. 571 It should be noted that it is quite acceptable for a Diffserv domain 572 to provide multiple instances of EF. Each instance should be 573 characterizable by the equations in Section 2.2 of this 574 specification. The effect of having multiple instances of EF on the 575 E_a and E_p values of each instance will depend considerably on how 576 the multiple instances are implemented. For example, in a multi-level 577 priority scheduler, an instance of EF that is not at the highest 578 priority may experience relatively long periods when it receives no 579 service while higher priority instances of EF are served. This would 580 result in relatively large values of E_a and E_p. By contrast, in a 581 WFQ-like scheduler, each instance of EF would be represented by a 582 queue served at some configured rate and the values of E_a and E_p 583 could be similar to those for a single EF instance. 585 Authors' Addresses 587 Bruce Davie 588 Cisco Systems, Inc. 589 300 Apollo Drive 590 Chelmsford, MA, 01824 592 E-mail: bsd@cisco.com 594 Anna Charny 595 Cisco Systems 596 300 Apollo Drive 597 Chelmsford, MA 01824 599 E-mail: acharny@cisco.com 601 Fred Baker 602 Cisco Systems 603 170 West Tasman Dr. 604 San Jose, CA 95134 606 E-mail: fred@cisco.com 608 Jon Bennett 609 RiverDelta Networks 610 3 Highwood Drive East 611 Tewksbury, MA 01876 613 E-mail: jcrb@riverdelta.com 614 Kent Benson 615 Tellabs Research Center 616 3740 Edison Lake Parkway #101 617 Mishawaka, IN 46545 619 E-mail: Kent.Benson@tellabs.com 621 Jean-Yves Le Boudec 622 ICA-EPFL, INN 623 Ecublens, CH-1015 624 Lausanne-EPFL, Switzerland 626 E-mail: leboudec@epfl.ch 628 Angela Chiu 629 AT&T Labs 630 100 Schulz Dr. Rm 4-204 631 Red Bank, NJ 07701 633 E-mail: alchiu@att.com 635 Bill Courtney 636 TRW 637 Bldg. 201/3702 638 One Space Park 639 Redondo Beach, CA 90278 641 E-mail: bill.courtney@trw.com 643 Shahram Davari 644 PMC-Sierra Inc 645 411 Legget Drive 646 Ottawa, ON K2K 3C9, Canada 648 E-mail: shahram_davari@pmc-sierra.com 649 Victor Firoiu 650 Nortel Networks 651 600 Tech Park 652 Billerica, MA 01821 654 E-mail: vfirou@nortelnetworks.com 656 Charles Kalmanek 657 AT&T Labs-Research 658 180 Park Avenue, Room A113, 659 Florham Park NJ 661 E-mail: crk@research.att.com. 663 K.K. Ramakrishnan 664 TeraOptic Networks, Inc. 665 686 W. Maude Ave 666 Sunnyvale, CA 94086 668 E-mail: kk@teraoptic.com 670 Dimitrios Stiliadis 671 Lucent Technologies 672 1380 Rodick Road 673 Markham, Ontario, L3R-4G5, Canada 675 E-mail: stiliadi@bell-labs.com 677 7. Full Copyright 679 Copyright (C) The Internet Society 2001. All Rights Reserved. 681 This document and translations of it may be copied and furnished to 682 others, and derivative works that comment on or otherwise explain it 683 or assist in its implementation may be prepared, copied, published 684 and distributed, in whole or in part, without restriction of any 685 kind, provided that the above copyright notice and this paragraph are 686 included on all such copies and derivative works. However, this 687 document itself may not be modified in any way, such as by removing 688 the copyright notice or references to the Internet Society or other 689 Internet organizations, except as needed for the purpose of 690 developing Internet standards in which case the procedures for 691 copyrights defined in the Internet Standards process must be 692 followed, or as required to translate it into languages other than 693 English. 695 The limited permissions granted above are perpetual and will not be 696 revoked by the Internet Society or its successors or assigns. 698 This document and the information contained herein is provided on an 699 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 700 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 701 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 702 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 703 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.