Network Working Group O. Bonaventure Request for Comments: 2963 FUNDP Category: Informational S. De Cnodder Alcatel October 2000 A Rate Adaptive Shaper for Differentiated Services Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractThis memo describes several Rate Adaptive Shapers (RAS) that can be used in combination with the single rate Three Color Markers (srTCM) and the two rate Three Color Marker (trTCM) described in RFC2697 and RFC2698, respectively. These RAS improve the performance of TCP when a TCM is used at the ingress of a diffserv network by reducing the burstiness of the traffic. With TCP traffic, this reduction of the burstiness is accompanied by a reduction of the number of marked packets and by an improved TCP goodput. The proposed RAS can be used at the ingress of Diffserv networks providing the Assured Forwarding Per Hop Behavior (AF PHB). They are especially useful when a TCM is used to mark traffic composed of a small number of TCP connections. RFC2475], the incoming data traffic, with the AF PHB in particular, could be subject to marking where the purpose of this marking is to provide a low drop probability to a minimum part of the traffic whereas the excess will have a larger drop probability. Such markers are mainly token bucket based such as the single rate Three Color Marker (srTCM) and two rate Three Color Marker (trTCM) described in [RFC2697] and [RFC2698], respectively. Similar markers were proposed for ATM networks and simulations have shown that their performance with TCP traffic was not always satisfactory and several researchers have shown that these performance problems could be solved in two ways:
1. increasing the burst size, i.e. increasing the Committed Burst Size (CBS) and the Peak Burst Size (PBS) in case of the trTCM, or 2. shaping the traffic such that a part of the burstiness is removed. The first solution has as major disadvantage that the traffic sent to the network can be very bursty and thus engineering the network to provide a low packet loss ratio can become difficult. To efficiently support bursty traffic, additional resources such as buffer space are needed. Conversely, the major disadvantage of shaping is that the traffic encounters additional delay in the shaper's buffer. In this document, we propose two shapers that can reduce the burstiness of the traffic upstream of a TCM. By reducing the burstiness of the traffic, the adaptive shapers increase the percentage of packets marked as green by the TCM and thus the overall goodput of the users attached to such a shaper. Such rate adaptive shapers will probably be useful at the edge of the network (i.e. inside access routers or even network adapters). The simulation results in [Cnodder] show that these shapers are particularly useful when a small number of TCP connections are processed by a TCM. The structure of this document follows the structure proposed in [Nichols]. We first describe two types of rate adaptive shapers in section two. These shapers correspond to respectively the srTCM and the trTCM. In section 3, we describe an extension to the simple shapers that can provide a better performance. We briefly discuss simulation results in the appendix. Bonaventure] to improve the performance of TCP with the Guaranteed Frame Rate [TM41] service category in ATM networks. Another type of rate adaptive shaper suitable for differentiated services was briefly discussed in [Azeem]. A RAS will typically be used as shown in figure 1 where the meter and the marker are the TCMs proposed in [RFC2697] and [RFC2698].
Result +----------+ | | | V +--------+ +-------+ +--------+ Incoming | | | | | | Outgoing Packet ==>| RAS |==>| Meter |==>| Marker |==>Packet Stream | | | | | | Stream +--------+ +-------+ +--------+ Figure 1. Rate adaptive shaper The presentation of the rate adaptive shapers in Figure 1 is somewhat different as described in [RFC2475] where the shaper is placed after the meter. The main objective of the shaper is to produce at its output a traffic that is less bursty than the input traffic, but the shaper avoids to discard packets in contrast with classical token bucket based shapers. The shaper itself consists of a tail-drop FIFO queue which is emptied at a variable rate. The shaping rate, i.e. the rate at which the queue is emptied, is a function of the occupancy of the FIFO queue. If the queue occupancy increases, the shaping rate will also increase in order to prevent loss and too large delays through the shaper. The shaping rate is also a function of the average rate of the incoming traffic. The shaper was designed to be used in conjunction with meters such as the TCMs proposed in [RFC2697] and [RFC2698]. There are two types of rate adaptive shapers. The single rate rate adaptive shaper (srRAS) will typically be used upstream of a srTCM while the two rates rate adaptive shaper (trRAS) will usually be used upstream of a trTCM.
CIR <= MIR <= line rate The two buffer thresholds, CIR_th and MIR_th shall be specified in bytes and SHOULD be configurable. If these thresholds are configured, then the srRAS MUST ensure that the following relation holds: CIR_th <= MIR_th <= buffer size of the shaper The chosen values for CIR_th and MIR_th will usually depend on the values chosen for CBS and PBS in the downstream srTCM. However, this dependency does not need to be standardized. Stoica] can be used (i.e. EARnew = [(1-exp(- T/K))*L/T] + exp(-T/K)*EARold where EARold is the previous value of the Estimated Average Rate, EARnew is the updated value, K a constant, L the size of the arriving packet and T the amount of time since the arrival of the previous packet). Other averaging functions can be used as well. The second factor is the instantaneous occupancy of the FIFO buffer of the shaper. When the buffer occupancy is below CIR_th, the output rate of the shaper is set to the maximum of the estimated average rate (EAR(t)) and the CIR. This ensures that the shaper buffer will be emptied at least at a rate equal to CIR. When the buffer occupancy increases above CIR_th, the output rate of the shaper is computed as the maximum of the EAR(t) and a linear function F of the buffer occupancy for which F(CIR_th)=CIR and F(MIR_th)=MIR. When the buffer occupancy reaches the MIR_th threshold, the output rate of the shaper is set to the maximum information rate. The computation of the shaping rate is illustrated in figure 2. We expect that real implementations will only use an approximate function to compute the shaping rate.
^ Shaping rate | | | MIR | ========= | // | // EAR(t) |----------------// | // | // CIR |============ | | | |------------+---------+-----------------------> CIR_th MIR_th Buffer occupancy Figure 2. Computation of shaping rate for srRAS
section 2 calculate a shaping rate, which is defined as the maximum of the estimated average incoming data rate and some function of the buffer occupancy. Using this shaping rate, the RAS computes the time schedule at which the packet at the head of the queue of the shaper is to be released. The main idea of the green RAS is to couple the shaper with the downstream meter so that the green RAS knows at what time the packet at the head of its queue would be accepted as green by the meter. If this time instant is earlier than the release time computed from the current shaping rate, then the packet can be released at this time instant. Otherwise, the packet at the head of the queue of the green RAS will be released at the time instant calculated from the current shaping rate. section 2.2).
RFC2697] and [RFC2698] are used. In fact, simulations briefly discussed in Appendix A show that the performance of TCP can be improved when a rate adaptive shaper is used upstream of a TCM. We expect such rate adaptive shapers to be particularly useful at the edge of the network, for example inside (small) access routers or even network adapters. Fang]. However, the exact definition of such new adaptive shapers and their performance is outside the scope of this document.
[Azeem] Azeem, F., Rao, A., Lu, X. and S. Kalyanaraman, "TCP- Friendly Traffic Conditioners for Differentiated Services", Work in Progress. [RFC2475] Blake S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [Bonaventure] Bonaventure O., "Integration of ATM under TCP/IP to provide services with a minimum guaranteed bandwidth", Ph. D. thesis, University of Liege, Belgium, September 1998. [Clark] Clark D. and Fang, W., "Explicit Allocation of Best- Effort Packet Delivery Service", IEEE/ACM Trans. on Networking, Vol. 6, No. 4, August 1998. [Cnodder] De Cnodder S., "Rate Adaptive Shapers for Data Traffic in DiffServ Networks", NetWorld+Interop 2000 Engineers Conference, Las Vegas, Nevada, USA, May 10-11, 2000. [Fang] Fang W., Seddigh N. and B. Nandy, "A Time Sliding Window Three Colour Marker (TSWTCM)", RFC 2859, June 2000. [Floyd] Floyd S. and V. Jacobson, "Random Early Detection Gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, August 1993. [RFC2697] Heinanen J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999. [RFC2698] Heinanen J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, September 1999. [RFC2597] Heinanen J., Baker F., Weiss W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [Nichols] Nichols K. and B. Carpenter, "Format for Diffserv Working Group Traffic Conditioner Drafts", Work in Progress.
2.5 msec, 34 Mbps 2.5 msec, 34 Mbps <--------------> <--------------> \+---+ +---+/ -| C1|--------------+ +--------------|C1'|- /+---+ | | +---+\ \+---+ | | +---+/ -| C2|------------+ | | +------------|C2'|- /+---+ | | | | +---+\ \+---+ | | | | +---+/ -| C3|----------+ | | | | +----------|C3'|- /+---+ | | | | | | +---+\ \+---+ | | | | | | +---+/ -| C4|--------+ +-+----------+ +----------+-+ +--------|C4'|- /+---+ | | | | | | +---+\ \+---+ +---| | | |---+ +---+/ -| C5|------------| ER1 |-----| ER2 |------------|C5'|- /+---+ +---| | | |---+ +---+\ \+---+ | | | | | | +---+/ -| C6|--------+ +----------+ +----------+ +--------|C6'|- /+---+ |||| |||| +---+\ \+---+ |||| <-------> |||| +---+/ -| C7|------------+||| 70 Mbps |||+------------|C7'|- /+---+ ||| 10 msec ||| +---+\ \+---+ ||| ||| +---+/ -| C8|-------------+|| ||+-------------|C8'|- /+---+ || || +---+\ \+---+ || || +---+/ -| C9|--------------+| |+--------------|C9'|- /+---+ | | +---+\ \+---+ | | +----+/ -|C10|---------------+ +---------------|C10'|- /+---+ +----+\ Figure A.1. the simulation model. The customer routers are connected with 34 Mbps links to the backbone network which is, in our case, composed of a single bottleneck 70 Mbps link between the edge routers ER1 and ER2. The delay on all the customer-edge 34 Mbps links has been set to 2.5 msec to model a MAN or small WAN environment. These links and the customer routers are not a bottleneck in our environment and no losses occurs inside the edge routers. The customer routers are equipped with a trTCM [Heinanen2] and mark the incoming traffic. The parameters of the trTCM are shown in table A.1.
Table A.1: configurations of the trTCMs Router CIR PIR Line Rate C1 2 Mbps 4 Mbps 34 Mbps C2 4 Mbps 8 Mbps 34 Mbps C3 6 Mbps 12 Mbps 34 Mbps C4 8 Mbps 16 Mbps 34 Mbps C5 10 Mbps 20 Mbps 34 Mbps C6 2 Mbps 4 Mbps 34 Mbps C7 4 Mbps 8 Mbps 34 Mbps C8 6 Mbps 12 Mbps 34 Mbps C9 8 Mbps 16 Mbps 34 Mbps C10 10 Mbps 20 Mbps 34 Mbps All customer routers are equipped with a trTCM where the CIR are 2 Mbps for router C1 and C6, 4 Mbps for C2 and C7, 6 Mbps for C3 and C8, 8 Mbps for C4 and C9 and 10 Mbps for C5 and C10. Routers C6-C10 also contain a trRAS in addition to the trTCM while routers C1-C5 only contain a trTCM. In all simulations, the PIR is always twice as large as the CIR. Also the PBS is the double of the CBS. The CBS will be varied in the different simulation runs. The edge routers, ER1 and ER2, are connected with a 70 Mbps link which is the bottleneck link in our environment. These two routers implement the RIO algorithm [Clark] that we have extended to support three drop priorities instead of two. The thresholds of the parameters are 100 and 200 packets (minimum and maximum threshold, respectively) for the red packets, 200 and 400 packets for the yellow packets and 400 and 800 for the green packets. These thresholds are reasonable since there are 100 TCP connections crossing each edge router. The parameter maxp of RIO for green, yellow and red are respectively set to 0.02, 0.05, and 0.1. The weight to calculate the average queue length which is used by RED or RIO is set to 0.002 [Floyd]. The simulated time is set to 102 seconds where the first two seconds are not used to gather TCP statistics (the so-called warm-up time) such as goodput.
packets is equal to the difference between the total traffic and the green and the yellow traffic. In table A.3, we show the total throughput achieved by the workstations attached to customer routers with a rate adaptive shaper. Table A.2: throughput in Mbps for the unshaped traffic. green yellow total 2Mbps [C1] 1.10 0.93 2.25 4Mbps [C2] 2.57 1.80 4.55 6Mbps [C3] 4.10 2.12 6.39 8Mbps [C4] 5.88 2.32 8.33 10Mbps [C5] 7.57 2.37 10.0 Table A.3: throughput in Mbps for the adaptively shaped traffic. green yellow total 2Mbps [C6] 2.00 1.69 3.71 4Mbps [C7] 3.97 2.34 6.33 6Mbps [C8] 5.93 2.23 8.17 8Mbps [C9] 7.84 2.28 10.1 10Mbps [C10] 9.77 2.14 11.9 This first simulation shows clearly that the workstations attached to an edge router with a rate adaptive shaper have a clear advantage, from a performance point of view, with respect to workstations attached to an edge router with only a trTCM. The performance improvement is the result of the higher proportion of packets marked as green by the edge routers when the rate adaptive shaper is used. To evaluate the impact of the CBS on the TCP goodput, we did additional simulations were we varied the CBS of all customer routers. Table A.4 shows the total goodput for workstations attached to, respectively, routers C1 (trTCM with 2 Mbps CIR, no adaptive shaping), C6 (trRAS with 2 Mbps CIR and adaptive shaping), C3 (trTCM with 6 Mbps CIR, no adaptive shaping), and C8 (trRAS with 6 Mbps CIR and adaptive shaping) for various values of the CBS. From this table, it is clear that the rate adaptive shapers provide a performance benefit when the CBS is small. With a very large CBS, the performance decreases when the shaper is in use. However, a CBS of a few hundred KBytes is probably too large in many environments.
Table A.4: goodput in Mbps (link rate is 70 Mbps) versus CBS in KBytes. CBS 2_Mbps_unsh 2_Mbps_sh 6_Mbps_unsh 6_Mbps_sh 3 1.88 3.49 5.91 7.77 10 2.97 2.91 6.76 7.08 25 3.14 2.78 7.07 6.73 50 3.12 2.67 7.20 6.64 75 3.18 2.56 7.08 6.58 100 3.20 2.64 7.00 6.62 150 3.21 2.54 7.11 6.52 200 3.26 2.57 7.07 6.53 300 3.19 2.53 7.13 6.49 400 3.13 2.48 7.18 6.43
large, the shaped and unshaped traffic performs more or less the same. This is in contrast with the trRAS, where the performance of the shaped traffic was slightly worse in case of a large CBS. Table A.7: goodput in Mbps (link rate is 70 Mbps) versus CBS in KBytes. CBS 2_Mbps_unsh 2_Mbps_sh 6_Mbps_unsh 6_Mbps_sh 3 1.90 3.44 5.62 8.44 10 2.95 3.30 6.70 7.20 25 2.98 3.01 7.03 6.93 50 3.06 2.85 6.81 6.84 75 3.08 2.80 6.87 6.96 100 2.99 2.78 6.85 6.88 150 2.98 2.70 6.80 6.81 200 2.96 2.70 6.82 6.97 300 2.94 2.70 6.83 6.86 400 2.86 2.62 6.83 6.84 Cnodder]
http://www.infonet.fundp.ac.be Stefaan De Cnodder Alcatel Network Strategy Group Fr. Wellesplein 1, B-2018 Antwerpen, Belgium. Phone: 32-3-240-8515 Fax: 32-3-240-9932 EMail: email@example.com
Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.