idnits 2.17.1 draft-bonaventure-diffserv-rashaper-04.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 40 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC2697], [RFC2698]), 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 141: '...s per second and MUST be configurable....' RFC 2119 keyword, line 142: '...t as the CIR and SHOULD be configurabl...' RFC 2119 keyword, line 147: '... MUST ensure that the following rela...' RFC 2119 keyword, line 152: '... bytes and SHOULD be configurable. I...' RFC 2119 keyword, line 153: '... then the srRAS MUST ensure that the ...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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) == Missing Reference: 'RFC2697' is mentioned on line 384, but not defined == Missing Reference: 'RFC2698' is mentioned on line 384, but not defined == Missing Reference: 'RFC2475' is mentioned on line 116, but not defined == Missing Reference: 'Cnodder' is mentioned on line 707, but not defined == Missing Reference: 'Nichols' is mentioned on line 85, but not defined == Missing Reference: 'Stoica' is mentioned on line 166, but not defined == Missing Reference: 'Heinanen2' is mentioned on line 533, but not defined == Missing Reference: 'C1' is mentioned on line 662, but not defined == Missing Reference: 'C2' is mentioned on line 663, but not defined == Missing Reference: 'C3' is mentioned on line 664, but not defined == Missing Reference: 'C4' is mentioned on line 665, but not defined == Missing Reference: 'C5' is mentioned on line 666, but not defined == Missing Reference: 'C6' is mentioned on line 671, but not defined == Missing Reference: 'C7' is mentioned on line 672, but not defined == Missing Reference: 'C8' is mentioned on line 673, but not defined == Missing Reference: 'C9' is mentioned on line 674, but not defined == Missing Reference: 'C10' is mentioned on line 675, but not defined -- Possible downref: Normative reference to a draft: ref. 'Azeem' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bonaventure' -- Possible downref: Non-RFC (?) normative reference: ref. 'Clark' -- Unexpected draft version: The latest known version of draft-fang-diffserv-tc-tswtcm is -00, but you're referring to -01. ** Downref: Normative reference to an Experimental draft: draft-fang-diffserv-tc-tswtcm (ref. 'Fang') -- Possible downref: Non-RFC (?) normative reference: ref. 'Floyd' -- Possible downref: Non-RFC (?) normative reference: ref. 'TM41' Summary: 10 errors (**), 0 flaws (~~), 20 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Olivier Bonaventure 3 INTERNET DRAFT FUNDP 4 draft-bonaventure-diffserv-rashaper-04.txt Stefaan De Cnodder 5 Alcatel 6 July, 2000 7 Expires January, 2001 9 A rate adaptive shaper for differentiated services 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 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 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Copyright Notice 29 Copyright (C) The Internet Society (2000). All Rights Reserved. 31 Abstract 33 This memo describes several Rate Adaptive Shapers (RAS) that can be 34 used in combination with the single rate Three Color Markers (srTCM) 35 and the two rate Three Color Marker (trTCM) described in [RFC2697] 36 and [RFC2698], respectively. These RAS improve the performance of TCP 37 when a TCM is used at the ingress of a diffserv network by reducing 38 the burstiness of the traffic. With TCP traffic, this reduction of 39 the burstiness is accompanied by a reduction of the number of marked 40 packets and by an improved TCP goodput. The proposed RAS can be used 41 at the ingress of Diffserv networks providing the Assured Forwarding 42 Per Hop Behavior (AF PHB). They are especially useful when a TCM is 43 used to mark traffic composed of a small number of TCP connections. 45 1. Introduction 47 In DiffServ networks [RFC2475], the incoming data traffic, with the 48 AF PHB in particular, could be subject to marking where the purpose 49 of this marking is to provide a low drop probability to a minimum 50 part of the traffic whereas the excess will have a larger drop 51 probability. Such markers are mainly token bucket based such as the 52 single rate Three Color Marker (srTCM) and two rate Three Color 53 Marker (trTCM) described in [RFC2697] and [RFC2698], respectively. 55 Similar markers were proposed for ATM networks and simulations have 56 shown that their performance with TCP traffic was not always 57 satisfactory and several researchers have shown that these 58 performance problems could be solved in two ways: 60 1. increasing the burst size, i.e. increasing the Committed Burst 61 Size (CBS) and the Peak Burst Size (PBS) in case of the trTCM, or 63 2. shaping the traffic such that a part of the burstiness is removed. 65 The first solution has as major disadvantage that the traffic sent to 66 the network can be very bursty and thus engineering the network to 67 provide a low packet loss ratio can become difficult. To efficiently 68 support bursty traffic, additional resources such as buffer space are 69 needed. Conversely, the major disadvantage of shaping is that the 70 traffic encounters additional delay in the shaper's buffer. 72 In this document, we propose two shapers that can reduce the 73 burstiness of the traffic upstream of a TCM. By reducing the 74 burstiness of the traffic, the adaptive shapers increase the 75 percentage of packets marked as green by the TCM and thus the overall 76 goodput of the users attached to such a shaper. 78 Such rate adaptive shapers will probably be useful at the edge of the 79 network (i.e. inside access routers or even network adapters). The 80 simulation results in [Cnodder] show that these shapers are 81 particularly useful when a small number of TCP connections are 82 processed by a TCM. 84 The structure of this document follows the structure proposed in 85 [Nichols]. We first describe two types of rate adaptive shapers in 86 section two. These shapers correspond to respectively the srTCM and 87 the trTCM. In section 3, we describe an extension to the simple 88 shapers that can provide a better performance. We briefly discuss 89 simulation results in the appendix. 91 2. Description of the rate adaptive shapers 93 2.1. Rate adaptive shaper 95 The rate adaptive shaper is based on a similar shaper proposed in 96 [Bonaventure] to improve the performance of TCP with the Guaranteed 97 Frame Rate [TM41] service category in ATM networks. Another type of 98 rate adaptive shaper suitable for differentiated services was briefly 99 discussed in [Azeem]. A RAS will typically be used as shown in 100 figure 1 where the meter and the marker are the TCMs proposed in 101 [RFC2697] and [RFC2698]. 103 Result 104 +----------+ 105 | | 106 | V 107 +--------+ +-------+ +--------+ 108 Incoming | | | | | | Outgoing 109 Packet ==>| RAS |==>| Meter |==>| Marker |==>Packet 110 Stream | | | | | | Stream 111 +--------+ +-------+ +--------+ 113 Figure 1. Rate adaptive shaper 115 The presentation of the rate adaptive shapers in Figure 1 is somewhat 116 different as described in [RFC2475] where the shaper is placed after 117 the meter. The main objective of the shaper is to produce at its 118 output a traffic that is less bursty than the input traffic, but the 119 shaper avoids to discard packets in contrast with classical token 120 bucket based shapers. The shaper itself consists of a tail-drop FIFO 121 queue which is emptied at a variable rate. The shaping rate, i.e. 122 the rate at which the queue is emptied, is a function of the 123 occupancy of the FIFO queue. If the queue occupancy increases, the 124 shaping rate will also increase in order to prevent loss and too 125 large delays through the shaper. The shaping rate is also a function 126 of the average rate of the incoming traffic. The shaper was designed 127 to be used in conjunction with meters such as the TCMs proposed in 128 [RFC2697] and [RFC2698]. 130 There are two types of rate adaptive shapers. The single rate rate 131 adaptive shaper (srRAS) will typically be used upstream of a srTCM 132 while the two rates rate adaptive shaper (trRAS) will usually be used 133 upstream of a trTCM. 135 2.2. Configuration of the srRAS 137 The srRAS is configured by specifying four parameters : the Committed 138 Information Rate (CIR), the Maximum Information Rate (MIR) and two 139 buffer thresholds : CIR_th (Committed Information Rate threshold) and 140 MIR_th (Maximum Information Rate threshold). The CIR shall be 141 specified in bytes per second and MUST be configurable. The MIR shall 142 be specified in the same unit as the CIR and SHOULD be configurable. 143 To achieve a good performance, the CIR of a srRAS will usually be set 144 to the same value as the CIR of the downstream srTCM. A typical 145 value for the MIR would be the line rate of the output link of the 146 shaper. When the CIR and optionally the MIR are configured, the srRAS 147 MUST ensure that the following relation is verified: 149 CIR <= MIR <= line rate 151 The two buffer thresholds, CIR_th and MIR_th shall be specified in 152 bytes and SHOULD be configurable. If these thresholds are configured, 153 then the srRAS MUST ensure that the following relation holds: 155 CIR_th <= MIR_th <= buffer size of the shaper 157 The chosen values for CIR_th and MIR_th will usually depend on the 158 values chosen for CBS and PBS in the downstream srTCM. However, this 159 dependency does not need to be standardized. 161 2.3. Behavior of the srRAS 163 The output rate of the shaper is based on two factors. The first one 164 is the (long term) average rate of the incoming traffic. This average 165 rate can be computed by several means. For example, the function 166 proposed in [Stoica] can be used (i.e. EARnew = [(1-exp(-T/K))*L/T] + 167 exp(-T/K)*EARold where EARold is the previous value of the Estimated 168 Average Rate, EARnew is the updated value, K a constant, L the size 169 of the arriving packet and T the amount of time since the arrival of 170 the previous packet). Other averaging functions can be used as well. 172 The second factor is the instantaneous occupancy of the FIFO buffer 173 of the shaper. When the buffer occupancy is below CIR_th, the output 174 rate of the shaper is set to the maximum of the estimated average 175 rate (EAR(t)) and the CIR. This ensures that the shaper buffer will 176 be emptied at least at a rate equal to CIR. When the buffer occupancy 177 increases above CIR_th, the output rate of the shaper is computed as 178 the maximum of the EAR(t) and a linear function F of the buffer 179 occupancy for which F(CIR_th)=CIR and F(MIR_th)=MIR. When the buffer 180 occupancy reaches the MIR_th threshold, the output rate of the shaper 181 is set to the maximum information rate. The computation of the 182 shaping rate is illustrated in figure 2. We expect that real 183 implementations will only use an approximate function to compute the 184 shaping rate. 186 ^ 187 Shaping rate | 188 | 189 | 190 MIR | ========= 191 | // 192 | // 193 EAR(t) |----------------// 194 | // 195 | // 196 CIR |============ 197 | 198 | 199 | 200 |------------+---------+-----------------------> 201 CIR_th MIR_th Buffer occupancy 203 Figure 2. Computation of shaping rate for srRAS 205 2.4. Configuration of the trRAS 207 The trRAS is configured by specifying six parameters : the Committed 208 Information Rate (CIR), the Peak Information Rate (PIR), the Maximum 209 Information Rate (MIR) and three buffer thresholds : CIR_th, PIR_th 210 and MIR_th. The CIR shall be specified in bytes per second and MUST 211 be configurable. To achieve a good performance, the CIR of a trRAS 212 will usually be set at the same value as the CIR of the downstream 213 trTCM. The PIR shall be specified in the same unit as the CIR and 214 MUST be configurable. To achieve a good performance, the PIR of a 215 trRAS will usually be set at the same value as the PIR of the 216 downstream trRAS. The MIR SHOULD be configurable and shall be 217 specified in the same unit as the CIR. A typical value for the MIR 218 will be the line rate of the output link of the shaper. When the 219 values for CIR, PIR and optionally MIR are configured, the trRAS MUST 220 ensure that the following relation is verified : 222 CIR <= PIR <= MIR <= line rate 224 The three buffer thresholds, CIR_th, PIR_th and MIR_th shall be 225 specified in bytes and SHOULD be configurable. If these thresholds 226 are configured, then the trRAS MUST ensure that the following 227 relation is verified: 229 CIR_th <= PIR_th <= MIR_th <= buffer size of the shaper 231 The CIR_th, PIR_th and MIR_th will usually depend on the values 232 chosen for the CBS and the PBS in the downstream trTCM. However, this 233 dependency does not need to be standardized. 235 2.5. Behavior of the trRAS 237 The output rate of the trRAS is based on two factors. The first is 238 the (long term) average rate of the incoming traffic. This average 239 rate can be computed as for the srRAS. 241 The second factor is the instantaneous occupancy of the FIFO buffer 242 of the shaper. When the buffer occupancy is below CIR_th, the output 243 rate of the shaper is set to the maximum of the estimated average 244 rate (EAR(t)) and the CIR. This ensures that the shaper will always 245 send traffic at least at the CIR. When the buffer occupancy increases 246 above CIR_th, the output rate of the shaper is computed as the 247 maximum of the EAR(t) and a piecewise linear function F of the buffer 248 occupancy. This piecewise function can be defined as follows. The 249 first piece is between zero and CIR_th where F is equal to CIR. This 250 means that when the buffer occupancy is below a certain threshold 251 CIR_th, the shaping rate is at least CIR. The second piece is 252 between CIR_th and PIR_th where F increases linearly from CIR to PIR. 253 The third part is from PIR_th to MIR_th where F increases linearly 254 from PIR to the MIR and finally when the buffer occupancy is above 255 MIR_th, the shaping rate remains constant at the MIR. The 256 computation of the shaping rate is illustrated in figure 3. We expect 257 that real implementations will use an approximation of the function 258 shown in this figure to compute the shaping rate. 260 ^ 261 Shaping rate | 262 | 263 MIR | ====== 264 | /// 265 | /// 266 PIR | /// 267 | // 268 | // 269 EAR(t) |----------------// 270 | // 271 | // 272 CIR |============ 273 | 274 | 275 | 276 |------------+---------+--------+------------------------> 277 CIR_th PIR_th MIR_th Buffer occupancy 279 Figure 3. Computation of shaping rate for trRAS 281 3. Description of the green RAS. 283 3.1. The green rate adaptive shapers 285 The srRAS and the trRAS described in the previous section are not 286 aware of the status of the meter. This entails that a RAS could 287 unnecessarily delay a packet although there are sufficient tokens 288 available to color the packet green. This delay could mean that TCP 289 takes more time to increase its congestion window and this may lower 290 the performance with TCP traffic. The green RAS shown in figure 4 291 solves this problem by coupling the shaper with the meter. 293 Status Result 294 +----------+ +----------+ 295 | | | | 296 V | | V 297 +--------+ +-------+ +--------+ 298 Incoming | green | | | | | Outgoing 299 Packet ==>| RAS |==>| Meter |==>| Marker |==>Packet 300 Stream | | | | | | Stream 301 +--------+ +-------+ +--------+ 303 Figure 4. green RAS 305 The two rate adaptive shapers described in section 2 calculate a 306 shaping rate, which is defined as the maximum of the estimated 307 average incoming data rate and some function of the buffer occupancy. 308 Using this shaping rate, the RAS computes the time schedule at which 309 the packet at the head of the queue of the shaper is to be released. 310 The main idea of the green RAS is to couple the shaper with the 311 downstream meter so that the green RAS knows at what time the packet 312 at the head of its queue would be accepted as green by the meter. If 313 this time instant is earlier than the release time computed from the 314 current shaping rate, then the packet can be released at this time 315 instant. Otherwise, the packet at the head of the queue of the green 316 RAS will be released at the time instant calculated from the current 317 shaping rate. 319 3.2. Configuration of the Green single rate Rate Adaptive Shaper (G- 320 srRAS) 322 The G-srRAS must be configured in the same way as the srRAS (see 323 section 2.2). 325 3.3. Behavior of the G-srRAS 327 First of all, the shaping rate of the G-srRAS is calculated in the 328 same way as for the srRAS. With the srRAS, this shaping rate 329 determines a time schedule, T1, at which the packet at the head of 330 the queue is to be released from the shaper. 332 A second time schedule, T2, is calculated as the earliest time 333 instant at which the packet at the head of the shaper's queue would 334 be colored as green by the downstream srTCM. Suppose that a packet of 335 size B bytes is at the head of the shaper and that CIR is the 336 Committed Information Rate of the srTCM in bytes per second. If we 337 denote the current time by t and by Tc(t) the amount of green tokens 338 in the token bucket of the srTCM at time t, then T2 is equal to 339 max(t, t+(B-Tc(t))/CIR). If B is larger than CBS, the Committed 340 Burst Size of the srTCM, then T2 is set to infinity. 342 When a packet arrives at the head of the queue of the shaper, it will 343 leave this queue not sooner than min(T1, T2) from the shaper. 345 3.4 Configuration of the Green two rates Rate Adaptive Shaper (G-trRAS) 347 The G-trRAS must be configured in the same way as the trRAS (see 348 section 2.4). 350 3.5. Behavior of the G-trRAS 352 First of all, the shaping rate of the G-trRAS is calculated in the 353 same way as for the trRAS. With the trRAS, this shaping rate 354 determines a time schedule, T1, at which the packet at the head of 355 the queue is to be released from the shaper. 357 A second time schedule, T2, is calculated as the earliest time 358 instant at which the packet at the head of the shaper's queue would 359 be colored as green by the downstream trTCM. Suppose that a packet of 360 size B bytes is at the head of the shaper and that CIR is the 361 Committed Information Rate of the srTCM in bytes per second. If we 362 denote the current time by t and by Tc(t) (resp. Tp(t)) the amount of 363 green (resp. yellow) tokens in the token bucket of the trTCM at time 364 t, then T2 is equal to max(t, t+(B-Tc(t))/CIR,t+(B-Tp(t))/PIR). If B 365 is larger than CBS, the committed burst size, or PBS, the peak burst 366 size, of the srTCM, then T2 is set to infinity. 368 When a packet arrives at the head of the queue of the shaper, it will 369 leave this queue not sooner than min(T1, T2) from the shaper. 371 4. Assumption 373 The shapers discussed in this document assume that the Internet 374 traffic is dominated by protocols such as TCP that react 375 appropriately to congestion by decreasing their transmission rate. 377 The proposed shapers do not provide a performance gain if the traffic 378 is composed of protocols that do not react to congestion by 379 decreasing their transmission rate. 381 5. Example services 383 The shapers discussed in this document can be used where the TCMs 384 proposed in [RFC2697] and [RFC2698] are used. In fact, simulations 385 briefly discussed in Appendix A show that the performance of TCP can 386 be improved when a rate adaptive shaper is used upstream of a TCM. We 387 expect such rate adaptive shapers to be particuarly useful at the 388 edge of the network, for example inside (small) access routers or 389 even network adapters. 391 6. The rate adaptive shaper combined with other markers 393 This document explains how the idea of a rate adaptive shaper can be 394 combined with the srTCM and the trTCM. This resulted in the srRAS 395 and the G-srRAS for the srTCM and in the trRAS and the G-trRAS for 396 the trTCM. Similar adaptive shapers could be developped to support 397 other traffic markers such as the Time Sliding Window Three Color 398 Marker (TSWTCM) [Fang]. However, the exact definition of such new 399 adaptive shapers and their performance is outside the scope of this 400 document. 402 7. Security Issues 404 The shapers described in this document have no known security 405 concerns. 407 8. Intellectual Property Rights 409 The IETF has been notified of intellectual property rights claimed in 410 regard to some or all of the specification contained in this 411 document. For more information consult the online list of claimed 412 rights. 414 9. Acknowledgement 416 We would like to thank Emmanuel Desmet for his comments. 418 10. References 420 [Azeem] F. Azeem, A. Rao,X. Lu and S. Kalyanaraman, "TCP-Friendly 421 Traffic Conditioners for Differentiated Services", draft-azeem- 422 tcpfriendly-diffserv-00.txt, March 1999, Work in progress. 424 [RFC2475]S. Blake, et al., "An Architecture for Differentiated Ser- 425 vices", RFC 2475, December 1998. 427 [Bonaventure] 428 O. Bonaventure, "Integration of ATM under TCP/IP to provide ser- 429 vices with a guaranteed minimum bandwidth", Ph. D. thesis, 430 University of Liege, September 1998. 432 [Clark] D. D. Clark, and W. Fang, "Explicit Allocation of Best-Effort 433 Packet Delivery Service", IEEE/ACM Trans. on Networking, Vol. 6, 434 No. 4, August 1998. 436 [Cnodder]S. De Cnodder, "Rate Adaptive Shapers for Data Traffic in 437 DiffServ Networks", NetWorld+Interop 2000 Engineers Conference, 438 Las Vegas, Nevada, USA, May 10-11, 2000. 440 [Fang] W. Fang, N. Seddigh, and B. Nandy, "A Time Sliding Window Three 441 Colour Marker (TSWTCM)", Internet draft draft-fang-diffserv-tc- 442 tswtcm-01.txt 444 [Floyd] S. Floyd, and V. Jacobson, "Random Early Detection Gateways for 445 Congestion Avoidance", IEEE/ACM Transactions on Networking, 446 August 1993. 448 [RFC2697]J. Heinanen, and R. Guerin, "A Single Rate Three Color Marker", 449 RFC 2697, September 1999. 451 [RFC2698]J. Heinanen, and R. Guerin, "A Two Rate Three Color Marker", 452 RFC 2698, September 1999. 454 [RFC2597]J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, "Assured 455 Forwarding PHB Group", RFC 2597, June 1999. 457 [Nichols]K. Nichols and B. Carpenter, "Format for Diffserv Working Group 458 Traffic Conditioner Drafts", Internet draft draft-ietf- 459 diffserv-traffcon-format-00.txt, February 1999, work in progress 461 [Stoica]I. Stoica and S. Shenker and H. Zhang, "Core-stateless fair 462 queueuing : achieving approxiamtely fair bandwidth allocations 463 in high speed networks", ACM SIGCOMM98, pp. 118-130, Sept. 1998 465 [TM41] ATM Forum, Traffic Management Specification, verion 4.1, 1999 467 Appendix 469 A. Simulation results 471 We briefly discuss simulations showing the benefits of the 472 proposed shapers in simple network environments. Additional 473 simulation results may be found in [Cnodder]. 475 A.1 description of the model 477 To evaluate the rate adaptive shaper through simulations, we use 478 the simple network model depicted in Figure A.1. In this net- 479 work, we consider that a backbone network is used to provide a 480 LAN Interconnection service to ten pairs of LANs. Each LAN 481 corresponds to an uncongested switched 10 Mbps LAN with ten 482 workstations attached to a customer router (C1-C10 in figure 483 A.1). The delay on the LAN links is set to 1 msec. The MSS size 484 of the workstations is set to 1460 bytes. The workstations on 485 the left hand side of the figure send traffic to companion 486 workstations located on the right hand side of the figure. All 487 traffic from the LAN attached to customer router C1 is sent to 488 the LAN attached to customer router C1'. There are ten worksta- 489 tions on each LAN and each workstation implements SACK-TCP with 490 a maximum window size of 64 KBytes. 492 2.5 msec, 34 Mbps 2.5 msec, 34 Mbps 493 <--------------> <--------------> 494 \+---+ +---+/ 495 -| C1|--------------+ +--------------|C1'|- 496 /+---+ | | +---+\ 497 \+---+ | | +---+/ 498 -| C2|------------+ | | +------------|C2'|- 499 /+---+ | | | | +---+\ 500 \+---+ | | | | +---+/ 501 -| C3|----------+ | | | | +----------|C3'|- 502 /+---+ | | | | | | +---+\ 503 \+---+ | | | | | | +---+/ 504 -| C4|--------+ +-+----------+ +----------+-+ +--------|C4'|- 505 /+---+ | | | | | | +---+\ 506 \+---+ +---| | | |---+ +---+/ 507 -| C5|------------| ER1 |-----| ER2 |------------|C5'|- 508 /+---+ +---| | | |---+ +---+\ 509 \+---+ | | | | | | +---+/ 510 -| C6|--------+ +----------+ +----------+ +--------|C6'|- 511 /+---+ |||| |||| +---+\ 512 \+---+ |||| <-------> |||| +---+/ 513 -| C7|------------+||| 70 Mbps |||+------------|C7'|- 514 /+---+ ||| 10 msec ||| +---+\ 515 \+---+ ||| ||| +---+/ 516 -| C8|-------------+|| ||+-------------|C8'|- 517 /+---+ || || +---+\ 518 \+---+ || || +---+/ 519 -| C9|--------------+| |+--------------|C9'|- 520 /+---+ | | +---+\ 521 \+---+ | | +----+/ 522 -|C10|---------------+ +---------------|C10'|- 523 /+---+ +----+\ 524 Figure A.1. the simulation model. 526 The customer routers are connected with 34 Mbps links to the 527 backbone network which is, in our case, composed of a single 528 bottleneck 70 Mbps link between the edge routers ER1 and ER2. 529 The delay on all the customer-edge 34 Mbps links has been set to 530 2.5 msec to model a MAN or small WAN environment. These links 531 and the customer routers are not a bottleneck in our environment 532 and no losses occurs inside the edge routers. The customer 533 routers are equipped with a trTCM [Heinanen2] and mark the 534 incoming traffic. The parameters of the trTCM are shown in table 535 A.1. 537 Table A.1: configurations of the trTCMs 539 Router CIR PIR Line Rate 540 C1 2 Mbps 4 Mbps 34 Mbps 541 C2 4 Mbps 8 Mbps 34 Mbps 542 C3 6 Mbps 12 Mbps 34 Mbps 543 C4 8 Mbps 16 Mbps 34 Mbps 544 C5 10 Mbps 20 Mbps 34 Mbps 545 C6 2 Mbps 4 Mbps 34 Mbps 546 C7 4 Mbps 8 Mbps 34 Mbps 547 C8 6 Mbps 12 Mbps 34 Mbps 548 C9 8 Mbps 16 Mbps 34 Mbps 549 C10 10 Mbps 20 Mbps 34 Mbps 551 All customer routers are equipped with a trTCM where the CIR are 552 2 Mbps for router C1 and C6, 4 Mbps for C2 and C7, 6 Mbps for C3 553 and C8, 8 Mbps for C4 and C9 and 10 Mbps for C5 and C10. Routers 554 C6-C10 also contain a trRAS in addition to the trTCM while 555 routers C1-C5 only contain a trTCM. In all simulations, the PIR 556 is always twice as large as the CIR. Also the PBS is the double 557 of the CBS. The CBS will be varied in the different simulation 558 runs. 560 The edge routers, ER1 and ER2, are connected with a 70 Mbps link 561 which is the bottleneck link in our environment. These two 562 routers implement the RIO algorithm [Clark] that we have 563 extended to support three drop priorities instead of two. The 564 thresholds of the parameters are 100 and 200 packets (minimum 565 and maximum threshold, respectively) for the red packets, 200 566 and 400 packets for the yellow packets and 400 and 800 for the 567 green packets. These thresholds are reasonable since there are 568 100 TCP connections crossing each edge router. The parameter 569 maxp of RIO for green, yellow and red are respectively set to 570 0.02, 0.05, and 0.1. The weight to calculate the average queue 571 length which is used by RED or RIO is set to 0.002 [Floyd]. 573 The simulated time is set to 102 seconds where the first two 574 seconds are not used to gather TCP statistics (the so-called 575 warm-up time) such as goodput. 577 A.2 Simulation results for the trRAS 579 For our first simulations, we consider that routers C1-C5 only 580 utilize a trTCM while routers C6-C10 utilize a rate adaptive 581 shaper in conjunction with a trTCM. All routers use a CBS of 3 582 KBytes. In table A.2, we show the total throughput achieved by 583 the workstations attached to each LAN as well as the total 584 throughput for the green and the yellow packets as a function of 585 the CIR of the trTCM used on the customer router attached to 586 this LAN. The throughput of the red packets is equal to the 587 difference between the total traffic and the green and the yel- 588 low traffic. In table A.3, we show the total throughput achieved 589 by the workstations attached to customer routers with a rate 590 adaptive shaper. 592 Table A.2: throughput in Mbps for the unshaped traffic. 593 green yellow total 594 2Mbps [C1] 1.10 0.93 2.25 595 4Mbps [C2] 2.57 1.80 4.55 596 6Mbps [C3] 4.10 2.12 6.39 597 8Mbps [C4] 5.88 2.32 8.33 598 10Mbps [C5] 7.57 2.37 10.0 600 Table A.3: throughput in Mbps for the adaptively shaped 601 traffic. 602 green yellow total 603 2Mbps [C6] 2.00 1.69 3.71 604 4Mbps [C7] 3.97 2.34 6.33 605 6Mbps [C8] 5.93 2.23 8.17 606 8Mbps [C9] 7.84 2.28 10.1 607 10Mbps [C10] 9.77 2.14 11.9 609 This first simulation shows clearly that the workstations 610 attached to an edge router with a rate adaptive shaper have a 611 clear advantage, from a performance point of view, with respect 612 to workstations attached to an edge router with only a trTCM. 613 The performance improvement is the result of the higher propor- 614 tion of packets marked as green by the edge routers when the 615 rate adaptive shaper is used. 617 To evaluate the impact of the CBS on the TCP goodput, we did 618 additional simulations were we varied the CBS of all customer 619 routers. 621 Table A.4 shows the total goodput for workstations attached to , 622 respectively, routers C1 (trTCM with 2 Mbps CIR, no adaptive 623 shaping), C6 (trRAS with 2 Mbps CIR and adaptive shaping), C3 624 (trTCM with 6 Mbps CIR, no adaptive shaping), and C8 (trRAS with 625 6 Mbps CIR and adaptive shaping) for various values of the CBS. 626 From this table, it is clear that the rate adaptive shapers pro- 627 vide a performance benefit when the CBS is small. With a very 628 large CBS, the performance decreases when the shaper is in use. 629 However, a CBS of a few hundred KBytes is probably too large in 630 many environments. 632 Table A.4: goodput in Mbps (link rate is 70 Mbps) versus CBS 633 in KBytes. 634 CBS 2_Mbps_unsh 2_Mbps_sh 6_Mbps_unsh 6_Mbps_sh 635 3 1.88 3.49 5.91 7.77 636 10 2.97 2.91 6.76 7.08 637 25 3.14 2.78 7.07 6.73 638 50 3.12 2.67 7.20 6.64 639 75 3.18 2.56 7.08 6.58 640 100 3.20 2.64 7.00 6.62 641 150 3.21 2.54 7.11 6.52 642 200 3.26 2.57 7.07 6.53 643 300 3.19 2.53 7.13 6.49 644 400 3.13 2.48 7.18 6.43 646 A.3 Simulation results for the Green trRAS 648 We use the same scenario as in A.2 but now we use the Green 649 trRAS (G-trRAS). 651 Table A.5 and Table A.6 show the results of the same scenario as 652 for Table A.2 and Table A.3 but the shaper is now the G-trRAS. 653 We see that the shaped traffic performs again much better, also 654 compared to the previous case (i.e. where the trRAS was used). 655 This is because the amount of yellow traffic increases with the 656 expense of a slight decrease in the amount of green traffic. 657 This can be explained by the fact that the G-trRAS introduces 658 some burstiness. 660 Table A.5: throughput in Mbps for the unshaped traffic. 661 green yellow total 662 2Mbps [C1] 1.10 0.95 2.26 663 4Mbps [C2] 2.41 1.66 4.24 664 6Mbps [C3] 3.94 1.97 6.07 665 8Mbps [C4] 5.72 2.13 7.96 666 10Mbps [C5] 7.25 2.29 9.64 668 Table A.6: throughput in Mbps for the adaptively shaped 669 traffic. 670 green yellow total 671 2Mbps [C6] 1.92 1.75 3.77 672 4Mbps [C7] 3.79 3.24 7.05 673 6Mbps [C8] 5.35 3.62 8.97 674 8Mbps [C9] 6.96 3.48 10.4 675 10Mbps [C10] 8.69 3.06 11.7 677 The impact of the CBS is shown in Table A.7 which is the same 678 scenario as Table A.4 with the only difference that the shaper 679 is now the G-trRAS. We see that the shaped traffic performs 680 much better than the unshaped traffic when the CBS is small. 681 When the CBS is large, the shaped and unshaped traffic performs 682 more or less the same. This is in contrast with the trRAS, 683 where the performance of the shaped traffic was slightly worse 684 in case of a large CBS. 686 Table A.7: goodput in Mbps (link rate is 70 Mbps) versus CBS 687 in KBytes. 688 CBS 2_Mbps_unsh 2_Mbps_sh 6_Mbps_unsh 6_Mbps_sh 689 3 1.90 3.44 5.62 8.44 690 10 2.95 3.30 6.70 7.20 691 25 2.98 3.01 7.03 6.93 692 50 3.06 2.85 6.81 6.84 693 75 3.08 2.80 6.87 6.96 694 100 2.99 2.78 6.85 6.88 695 150 2.98 2.70 6.80 6.81 696 200 2.96 2.70 6.82 6.97 697 300 2.94 2.70 6.83 6.86 698 400 2.86 2.62 6.83 6.84 700 A.4 Conclusion simulations 702 From these simulations, we see that the shaped traffic has much 703 higher throughput compared to the unshaped traffic when the CBS 704 was small. When the CBS is large, the shaped traffic performs 705 slightly less than the unshaped traffic due to the delay in the 706 shaper. The G-trRAS solves this problem. Additionnal simula- 707 tion results may be found in [Cnodder] 709 Authors Addresses 711 Olivier Bonaventure 712 Institut d'Informatique (CS Dept) 713 Facultes Universitaires Notre-Dame de la Paix 714 Rue Grandgagnage 21, B-5000 Namur, Belgium. 715 E-mail: Olivier.Bonaventure@info.fundp.ac.be 716 URL : http://www.info.fundp.ac.be/~obo 718 Stefaan De Cnodder 719 Alcatel Network Strategy Group 720 Fr. Wellesplein 1, B-2018 Antwerpen, Belgium. 721 Phone : 32-3-240-8515 722 Fax : 32-3-240-9932 723 E-mail: stefaan.de_cnodder@alcatel.be 725 Full Copyright Statement 727 Copyright (C) The Internet Society (1999). All Rights Reserved. 729 This document and translations of it may be copied and furnished to 730 others, and derivative works that comment on or otherwise explain it 731 or assist in its implementation may be prepared, copied, published 732 and distributed, in whole or in part, without restriction of any 733 kind, provided that the above copyright notice and this paragraph are 734 included on all such copies and derivative works. However, this 735 document itself may not be modified in any way, such as by removing 736 the copyright notice or references to the Internet Society or other 737 Internet organizations, except as needed for the purpose of 738 developing Internet standards in which case the procedures for 739 copyrights defined in the Internet Standards process must be 740 followed, or as required to translate it into languages other than 741 English. 743 The limited permissions granted above are perpetual and will not be 744 revoked by the Internet Society or its successors or assigns. 746 This document and the information contained herein is provided on an 747 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 748 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 749 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 750 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 751 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.