[LARTC] Attacing a RED to a CBQ

[LARTC] Attacing a RED to a CBQ

[Jan Coppens]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

Hi all,

I've create a cbq qdisc on an 100Mbit link and I attached a cbq class to it with a rate of 15Mbit (borrow). Now I would like to attach a RED qdisc to that class, but I'm a little confused by the REDs parameters. What should I choose for the bandwidth (100Mbit or 15Mbit) and what are some good values for min, max, limit and burst in my case?

All help is appreciated
thanks,

Jan

[-- Attachment #2: Type: text/html, Size: 941 bytes --]

[LARTC] Attacing a RED to a CBQ

[Leonardo Balliache]

Hi Jan:

Perhaps this could help you.

Best regards,

Leonardo Balliache

Pd: haven't never implemented one of this monsters.

NAME
        red - Random Early Detection

SYNOPSIS
        tc  qdisc  ...  red  limit bytes min bytes max bytes
        avpkt bytes burst packets [ ecn ] [ bandwidth rate ]
        probability chance

DESCRIPTION
        Random  Early  Detection is a classless qdisc which limits
        its queue size smartly. Regular queues simply drop packets
        from  the  tail  when  they are full, which may not be the
        optimal behaviour. RED also performs tail drop,  but  does
        so in a more gradual way.

        Once  the  queue  hits  a  certain average length, packets
        enqueued have a configurable chance of being marked (which
        may  mean dropped). This chance increases linearly up to a
        point called the max average queue  length,  although  the
        queue might get bigger.

        This  has  a  host of benefits over simple taildrop, while
        not being processor  intensive.  It  prevents  synchronous
        retransmits  after a burst in traffic, which cause further
        retransmits, etc.

        The goal is the have a small queue size, which is good for
        interactivity while not disturbing TCP/IP traffic with too
        many sudden drops after a burst of traffic.

        Depending on wether  ECN  is  configured,  marking  either
        means dropping or purely marking a packet as overlimit.

ALGORITHM
        The average queue size is used for determining the marking
        probability.  This  is  calculated  using  an  Exponential
        Weighted  Moving Average, which can be more or less sensi-
        tive to bursts.

        When the average queue size is below min bytes, no  packet
        will  ever be marked. When it exceeds min, the probability
        of doing so climbs linearly up to probability,  until  the
        average  queue size hits max bytes. Because probability is
        normally not set to 100%, the queue size might conceivably
        rise  above  max bytes, so the limit parameter is provided
        to set a hard maximum for the size of the queue.

PARAMETERS
        min    Average queue size at which marking becomes a  pos-
               sibility.

        max    At this average queue size, the marking probability
               is maximal. Should be at least twice min to prevent
               synchronous retransmits, higher for low min.

        probability
               Maximum  probability  for  marking,  specified as a
               floating point number from 0.0  to  1.0.  Suggested
               values are 0.01 or 0.02 (1 or 2%, respectively).

        limit  Hard  limit on the real (not average) queue size in
               bytes. Further packets are dropped. Should  be  set
               higher  than max+burst. It is advised to set this a
               few times higher than max.

        burst  Used for determining how  fast  the  average  queue
               size  is  influenced by the real queue size. Larger
               values make the calculation more sluggish, allowing
               longer  bursts  of  traffic  before marking starts.
               Real life experiments support the following  guide-
               line: (min+min+max)/(3*avpkt).

        avpkt  Specified  in  bytes.  Used with burst to determine
               the time constant for average queue  size  calcula-
               tions. 1000 is a good value.

        bandwidth
               This rate is used for calculating the average queue
               size after some idle time. Should  be  set  to  the
               bandwidth of your interface. Does not mean that RED
               will shape for you! Optional.

        ecn    As mentioned  before,  RED  can  either  'mark'  or
               'drop'. Explicit Congestion Notification allows RED
               to notify remote hosts that their rate exceeds  the
               amount  of  bandwidth  available.  Non-ECN  capable
               hosts can only be notified by  dropping  a  packet.
               If this parameter is specified, packets which indi-
               cate that their hosts honor ECN will only be marked
               and  not  dropped, unless the queue size hits limit
               bytes. Needs a tc binary with RED support  compiled
               in. Recommended.

SOURCES
        o      Floyd, S., and Jacobson, V., Random Early Detection
               gateways      for       Congestion       Avoidance.
               http://www.aciri.org/floyd/papers/red/red.html
        o      Some   changes   to  the  algorithm  by  Alexey  N.
               Kuznetsov.
SEE ALSO
        tc-cbq(8), tc-htb(8), tc-red(8), tc-tbf(8), tc-pfifo(8),
        tc-bfifo(8), tc-pfifo_fast(8), tc-filters(8)



_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/