Subject: [Diffserv] Re: Comments on draft-bonaventure-diffserv-rashaper-02.txt solicited

From: "Nabil Seddigh" <[email-masked]>
Date: Thu, 01 Jun 2000 07:59:42 -0400

> 
> From:  Kathleen Nichols <[email-masked]>
> To:    [email-masked]
> Date:  Tue, 30 May 2000 20:48:15 -0700
> 
> diffservers,
> 
> Although draft-bonaventure-diffserv-rashaper-02.txt is not
> an official WG document, it concerns a diffserv WG topic,
> a traffic conditioner. The authors are interested in having
> this draft become an experimental RFC and thoughtful comments
> from diffservers would be helpful.
> 
>         thanks,
>                 Kathie and Brian
>                 diffserv WG co-chairs

I had read the draft previously and had a quick look
again. Since recent work has shown that TCP benefits
from ACK/data pacing, spacing and shaping,
this draft is a welcomed initiative in the context
of Diffserv. Few thoughts:

1. The draft actually discusses 4 different shapers.
   It may assist the reader if the abstract & Introduction
   specifically listed the shapers and provided either
   an overview or the salient distinguishing features
   of each shaper as well as highlighted the different
   config parameters for each shaper. 

2. It seemed to me that the srRAS and trRAS could 
    work with any specified meter (eg TSWTCM) and
   do not have to be restricted to interoperating
   with the srTCM and trTCM. Is there any reason
   why the restriction is imposed?

3. The draft uses the term "downstream" in a number
   of places. Sometimes it is unclear if "downstream"
   refers to another router or another block within
   the same router. Some clarification in the 
   document would be helpful.

4. Section 2.2 indicates that the CIR_th and MIR_th
   usually depend on the values of the CBS & PBS.
   Does this imply the exact same value or some
   function of those values? Some clarification would
   assist. Same comment for trRAS.

5. I haven't looked at the simulation results in 
   enough detail but am concerned with certain 
   conclusions. The results show (Tables A5 & A7)
   that for CBS values above 10Kbytes, there
   is no throughput benefit from shaping. The 
   implication is that the RAS is only useful when
   the CBS of the meter is set to 10Kbytes or less.
   Few points:
   
    a) Is this a reasonable conclusion? 

    b) If the conclusion is true then it may
       limit the applicability of the RAS?
       The simulations (if I read correctly)
       included 100 flows per customer. With such
       number of flows per aggregate, I'm not
       sure it is reasonable to assume CBS'
       will be configured below 10Kbytes. You may
       recall that the mailing list had extensive 
       discussion on appropriate meter bucket sizes 
       in 98/99 and my recollection is that the
       meter bucket sizes were recommended to
       be related to BW-Delay product. It is a
       known fact that with small bucket sizes,
       token-bucket based meters will not perform
       properly.

Best,
----
Nabil Seddigh
[email-masked]

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Stefaan De Cnodder <[email-masked]>
Date: Mon, 05 Jun 2000 17:56:17 +0200

Nabil,

The Rate Adaptive Shaper can also be combined with other markers than
the srTCM and the trTCM but this does not mean that it can be combined
with any (future, not yet existing) marker.  The RAS can be combined
with the TSWTCM but combining the green RAS described in section 3 with
the TSWTCM is problematic because the packet is released immediately if
it is conforming to green but with the TSWTCM a packet could be
conforming to green with a certain probability.

Whether the RAS is usefull with the TSWTCM depends on the value of the
AVG_INTERVAL parameter of the Rate Estimator algorithm.  I guess that
the RAS with a TSWTCM with a small AVG_INTERVAL is usefull (comparable
with a small bucket size with the srTCM/trTCM).  However, I have not
done simulations with the TSWTCM.

An other point were the simulations and in particular the CBS.  I am
aware that the recommend CBS for TCP is the bandwidth delay product, but
with a shaper, you do not have the problem of the dimensioning of the
CBS: a CBS of a few packets suffices.  Without shaper, you have to
dimenstion the CBS.  A rule is to use the bandwidth delay (the delay is
usually unknown) product which usually gives high values and maybe not
all ISPs accepts  high values for the CBS.  Also you say: "With such
number of flows per aggregate, I'm not sure it is reasonable to assume
CBS' will be configured below 10Kbytes." so the value for the CBS also
depends on the number of flows (and this is variable).  This means that
a correct dimensioning of the CBS becomes difficult if you do not use a
shaper.

small remark about the simulations: the number of TCP flows per customer
was 10, which means that there is a total of 100 TCP flows.

Thanks for the comments,

Stefaan