summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2963.txt
blob: e09a9248e4ce82b9b3069822ae6532694d96e2bc (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L