diff options
Diffstat (limited to 'doc/rfc/rfc2963.txt')
| -rw-r--r-- | doc/rfc/rfc2963.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc2963.txt b/doc/rfc/rfc2963.txt new file mode 100644 index 0000000..e09a924 --- /dev/null +++ b/doc/rfc/rfc2963.txt @@ -0,0 +1,1067 @@ + + + + + + +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. + +Abstract + + This 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. + +1. Introduction + + In DiffServ networks [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: + + + + +Bonaventure & De Cnodder Informational [Page 1] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + + 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. + +2. Description of the rate adaptive shapers + +2.1. Rate adaptive shaper + + The rate adaptive shaper is based on a similar shaper proposed in + [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]. + + + + + + + + + +Bonaventure & De Cnodder Informational [Page 2] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + + 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. + +2.2. Configuration of the srRAS + + The srRAS is configured by specifying four parameters: the Committed + Information Rate (CIR), the Maximum Information Rate (MIR) and two + buffer thresholds: CIR_th (Committed Information Rate threshold) and + MIR_th (Maximum Information Rate threshold). The CIR shall be + specified in bytes per second and MUST be configurable. The MIR + shall be specified in the same unit as the CIR and SHOULD be + configurable. To achieve a good performance, the CIR of a srRAS will + usually be set to the same value as the CIR of the downstream srTCM. + A typical value for the MIR would be the line rate of the output link + of the shaper. When the CIR and optionally the MIR are configured, + the srRAS MUST ensure that the following relation is verified: + + + + + + +Bonaventure & De Cnodder Informational [Page 3] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + + 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. + +2.3. Behavior of the srRAS + + The output rate of the shaper is based on two factors. The first one + is the (long term) average rate of the incoming traffic. This + average rate can be computed by several means. For example, the + function proposed in [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. + + + + + + + + + + + + + +Bonaventure & De Cnodder Informational [Page 4] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + + ^ + Shaping rate | + | + | + MIR | ========= + | // + | // + EAR(t) |----------------// + | // + | // + CIR |============ + | + | + | + |------------+---------+-----------------------> + CIR_th MIR_th Buffer occupancy + + Figure 2. Computation of shaping rate for srRAS + +2.4. Configuration of the trRAS + + The trRAS is configured by specifying six parameters: the Committed + Information Rate (CIR), the Peak Information Rate (PIR), the Maximum + Information Rate (MIR) and three buffer thresholds: CIR_th, PIR_th + and MIR_th. The CIR shall be specified in bytes per second and MUST + be configurable. To achieve a good performance, the CIR of a trRAS + will usually be set at the same value as the CIR of the downstream + trTCM. The PIR shall be specified in the same unit as the CIR and + MUST be configurable. To achieve a good performance, the PIR of a + trRAS will usually be set at the same value as the PIR of the + downstream trRAS. The MIR SHOULD be configurable and shall be + specified in the same unit as the CIR. A typical value for the MIR + will be the line rate of the output link of the shaper. When the + values for CIR, PIR and optionally MIR are configured, the trRAS MUST + ensure that the following relation is verified: + + CIR <= PIR <= MIR <= line rate + + The three buffer thresholds, CIR_th, PIR_th and MIR_th shall be + specified in bytes and SHOULD be configurable. If these thresholds + are configured, then the trRAS MUST ensure that the following + relation is verified: + + CIR_th <= PIR_th <= MIR_th <= buffer size of the shaper + + The CIR_th, PIR_th and MIR_th will usually depend on the values + chosen for the CBS and the PBS in the downstream trTCM. However, + this dependency does not need to be standardized. + + + +Bonaventure & De Cnodder Informational [Page 5] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + +2.5. Behavior of the trRAS + + The output rate of the trRAS is based on two factors. The first is + the (long term) average rate of the incoming traffic. This average + rate can be computed as for the srRAS. + + 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 will always + send traffic at least at the 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 piecewise linear function F of the + buffer occupancy. This piecewise function can be defined as follows. + The first piece is between zero and CIR_th where F is equal to CIR. + This means that when the buffer occupancy is below a certain + threshold CIR_th, the shaping rate is at least CIR. The second piece + is between CIR_th and PIR_th where F increases linearly from CIR to + PIR. The third part is from PIR_th to MIR_th where F increases + linearly from PIR to the MIR and finally when the buffer occupancy is + above MIR_th, the shaping rate remains constant at the MIR. The + computation of the shaping rate is illustrated in figure 3. We + expect that real implementations will use an approximation of the + function shown in this figure to compute the shaping rate. + + ^ + Shaping rate | + | + MIR | ====== + | /// + | /// + PIR | /// + | // + | // + EAR(t) |----------------// + | // + | // + CIR |============ + | + | + | + |------------+---------+--------+--------------------> + CIR_th PIR_th MIR_th Buffer occupancy + + Figure 3. Computation of shaping rate for trRAS + + + + + + +Bonaventure & De Cnodder Informational [Page 6] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + +3. Description of the green RAS. + +3.1. The green rate adaptive shapers + + The srRAS and the trRAS described in the previous section are not + aware of the status of the meter. This entails that a RAS could + unnecessarily delay a packet although there are sufficient tokens + available to color the packet green. This delay could mean that TCP + takes more time to increase its congestion window and this may lower + the performance with TCP traffic. The green RAS shown in figure 4 + solves this problem by coupling the shaper with the meter. + + Status Result + +----------+ +----------+ + | | | | + V | | V + +--------+ +-------+ +--------+ + Incoming | green | | | | | Outgoing + Packet ==>| RAS |==>| Meter |==>| Marker |==>Packet + Stream | | | | | | Stream + +--------+ +-------+ +--------+ + + Figure 4. green RAS + + The two rate adaptive shapers described in 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. + +3.2. Configuration of the Green single rate Rate Adaptive Shaper + (GsrRAS) + + The G-srRAS must be configured in the same way as the srRAS (see + section 2.2). + + + + + + + + +Bonaventure & De Cnodder Informational [Page 7] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + +3.3. Behavior of the G-srRAS + + First of all, the shaping rate of the G-srRAS is calculated in the + same way as for the srRAS. With the srRAS, this shaping rate + determines a time schedule, T1, at which the packet at the head of + the queue is to be released from the shaper. + + A second time schedule, T2, is calculated as the earliest time + instant at which the packet at the head of the shaper's queue would + be colored as green by the downstream srTCM. Suppose that a packet + of size B bytes is at the head of the shaper and that CIR is the + Committed Information Rate of the srTCM in bytes per second. If we + denote the current time by t and by Tc(t) the amount of green tokens + in the token bucket of the srTCM at time t, then T2 is equal to + max(t, t+(B-Tc(t))/CIR). If B is larger than CBS, the Committed + Burst Size of the srTCM, then T2 is set to infinity. + + When a packet arrives at the head of the queue of the shaper, it will + leave this queue not sooner than min(T1, T2) from the shaper. + +3.4 Configuration of the Green two rates Rate Adaptive Shaper (G-trRAS) + + The G-trRAS must be configured in the same way as the trRAS (see + section 2.4). + +3.5. Behavior of the G-trRAS + + First of all, the shaping rate of the G-trRAS is calculated in the + same way as for the trRAS. With the trRAS, this shaping rate + determines a time schedule, T1, at which the packet at the head of + the queue is to be released from the shaper. + + A second time schedule, T2, is calculated as the earliest time + instant at which the packet at the head of the shaper's queue would + be colored as green by the downstream trTCM. Suppose that a packet + of size B bytes is at the head of the shaper and that CIR is the + Committed Information Rate of the srTCM in bytes per second. If we + denote the current time by t and by Tc(t) (resp. Tp(t)) the amount of + green (resp. yellow) tokens in the token bucket of the trTCM at time + t, then T2 is equal to max(t, t+(B-Tc(t))/CIR,t+(B-Tp(t))/PIR). If B + is larger than CBS, the committed burst size, or PBS, the peak burst + size, of the srTCM, then T2 is set to infinity. + + When a packet arrives at the head of the queue of the shaper, it will + leave this queue not sooner than min(T1, T2) from the shaper. + + + + + + +Bonaventure & De Cnodder Informational [Page 8] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + +4. Assumption + + The shapers discussed in this document assume that the Internet + traffic is dominated by protocols such as TCP that react + appropriately to congestion by decreasing their transmission rate. + + The proposed shapers do not provide a performance gain if the traffic + is composed of protocols that do not react to congestion by + decreasing their transmission rate. + +5. Example services + + The shapers discussed in this document can be used where the TCMs + proposed in [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. + +6. The rate adaptive shaper combined with other markers + + This document explains how the idea of a rate adaptive shaper can be + combined with the srTCM and the trTCM. This resulted in the srRAS + and the G-srRAS for the srTCM and in the trRAS and the G-trRAS for + the trTCM. Similar adaptive shapers could be developed to support + other traffic markers such as the Time Sliding Window Three Color + Marker (TSWTCM) [Fang]. However, the exact definition of such new + adaptive shapers and their performance is outside the scope of this + document. + +7. Security Considerations + + The shapers described in this document have no known security + concerns. + +8. Intellectual Property Rights + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + +9. Acknowledgement + + We would like to thank Emmanuel Desmet for his comments. + + + + + +Bonaventure & De Cnodder Informational [Page 9] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + +10. References + + [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. + + + + + + + + +Bonaventure & De Cnodder Informational [Page 10] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + + [Stoica] Stoica I., Shenker S. and H. Zhang, "Core-stateless + fair queueuing: achieving approximately fair bandwidth + allocations in high speed networks", ACM SIGCOMM98, pp. + 118-130, Sept. 1998 + + [TM41] ATM Forum, Traffic Management Specification, verion + 4.1, 1999 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bonaventure & De Cnodder Informational [Page 11] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + +Appendix + +A. Simulation results + + We briefly discuss simulations showing the benefits of the proposed + shapers in simple network environments. Additional simulation results + may be found in [Cnodder]. + +A.1 description of the model + + To evaluate the rate adaptive shaper through simulations, we use the + simple network model depicted in Figure A.1. In this network, we + consider that a backbone network is used to provide a LAN + Interconnection service to ten pairs of LANs. Each LAN corresponds + to an uncongested switched 10 Mbps LAN with ten workstations attached + to a customer router (C1-C10 in figure A.1). The delay on the LAN + links is set to 1 msec. The MSS size of the workstations is set to + 1460 bytes. The workstations on the left hand side of the figure + send traffic to companion workstations located on the right hand side + of the figure. All traffic from the LAN attached to customer router + C1 is sent to the LAN attached to customer router C1'. There are ten + workstations on each LAN and each workstation implements SACK-TCP + with a maximum window size of 64 KBytes. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bonaventure & De Cnodder Informational [Page 12] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + + 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. + + + + + + + + +Bonaventure & De Cnodder Informational [Page 13] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + + 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. + +A.2 Simulation results for the trRAS + + For our first simulations, we consider that routers C1-C5 only + utilize a trTCM while routers C6-C10 utilize a rate adaptive shaper + in conjunction with a trTCM. All routers use a CBS of 3 KBytes. In + table A.2, we show the total throughput achieved by the workstations + attached to each LAN as well as the total throughput for the green + and the yellow packets as a function of the CIR of the trTCM used on + the customer router attached to this LAN. The throughput of the red + + + +Bonaventure & De Cnodder Informational [Page 14] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + + 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. + + + + + + + + +Bonaventure & De Cnodder Informational [Page 15] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + + 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 + +A.3 Simulation results for the Green trRAS + + We use the same scenario as in A.2 but now we use the Green trRAS + (G-trRAS). + + Table A.5 and Table A.6 show the results of the same scenario as for + Table A.2 and Table A.3 but the shaper is now the G-trRAS. We see + that the shaped traffic performs again much better, also compared to + the previous case (i.e. where the trRAS was used). This is because + the amount of yellow traffic increases with the expense of a slight + decrease in the amount of green traffic. This can be explained by + the fact that the G-trRAS introduces some burstiness. + + Table A.5: throughput in Mbps for the unshaped traffic. + green yellow total + 2Mbps [C1] 1.10 0.95 2.26 + 4Mbps [C2] 2.41 1.66 4.24 + 6Mbps [C3] 3.94 1.97 6.07 + 8Mbps [C4] 5.72 2.13 7.96 + 10Mbps [C5] 7.25 2.29 9.64 + + Table A.6: throughput in Mbps for the adaptively shaped + traffic. + green yellow total + 2Mbps [C6] 1.92 1.75 3.77 + 4Mbps [C7] 3.79 3.24 7.05 + 6Mbps [C8] 5.35 3.62 8.97 + 8Mbps [C9] 6.96 3.48 10.4 + 10Mbps [C10] 8.69 3.06 11.7 + + The impact of the CBS is shown in Table A.7 which is the same + scenario as Table A.4 with the only difference that the shaper is now + the G-trRAS. We see that the shaped traffic performs much better + than the unshaped traffic when the CBS is small. When the CBS is + + + +Bonaventure & De Cnodder Informational [Page 16] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + + 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 + +A.4 Conclusion simulations + + From these simulations, we see that the shaped traffic has much + higher throughput compared to the unshaped traffic when the CBS was + small. When the CBS is large, the shaped traffic performs slightly + less than the unshaped traffic due to the delay in the shaper. The + G-trRAS solves this problem. Additional simulation results may be + found in [Cnodder] + + + + + + + + + + + + + + + + + + + + + + + + +Bonaventure & De Cnodder Informational [Page 17] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + +Authors' Addresses + + Olivier Bonaventure + Infonet research group + Institut d'Informatique (CS Dept) + Facultes Universitaires Notre-Dame de la Paix + Rue Grandgagnage 21, B-5000 Namur, Belgium. + + EMail: Olivier.Bonaventure@info.fundp.ac.be + URL: 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: stefaan.de_cnodder@alcatel.be + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bonaventure & De Cnodder Informational [Page 18] + +RFC 2963 A Rate Adaptive Shaper October 2000 + + +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. + + + + + + + + + + + + + + + + + + + +Bonaventure & De Cnodder Informational [Page 19] + |