No subject

1.1. Overview

   This module implements rate limiting for SIP requests. In
   contrast to the PIKE module this limits the flow based on a
   per SIP request type basis and not per source IP. The MI
   interface can be used to change tunables while running
   openSER. Currently supported requests are INVITE, REGISTER and
   SUBSCRIBE.

   The module does not implement any actions on blocking - it
   just simply reports that there is a high traffic; what to do,
   is the administator decision (via scripting).
     _________________________________________________________

1.2. Use Cases

   Limiting the rate messages are processed on a system directly
   influences the load. The ratelimit module can be used to
   protect a single host or to protect an openSER cluster when
   run on the dispatching box in front.

   A sample configuration snippet might look like this:
...
        if (is_method("INVITE|REGISTER|SUBSCRIBE") {
                if (!rl_check()) {
                        sl_send_reply("503", "Service Unavailable");
                        exit;
                };
        };
...

   Upon every incoming request listed above rl_check is invoked.
   It returns an OK code if the current per request load is below
   the configured threshold. If the load is exceeded the function
   returns an error and an administrator can discard requests
   with a stateless response.
     _________________________________________________________

1.3. Rate Limiting Algorithms

   The ratelimit module supports two different algorithms to be
   used by rl_check to determine whether a message should be
   blocked or not.
     _________________________________________________________

1.3.1. Tail Drop (TD)

   This is a trivial algorithm that imposes some risks when used
   in conjunction with long timer intervals. At the start of each
   interval an internal counter is reset and incremented for each
   incoming message. Once the counter hits the configured limit
   rl_check returns an error.

   The downside of this algorithm is that it can lead to SIP
   client synchronization. During a relatively long interval only
   the first requests (i.e. REGISTERs) would make it through.
   Following messages (i.e. RE-REGISTERs) will all hit the SIP
   proxy at the same time when a common Expire timer expired.
   Other requests will be retransmissed after given time, the
   same on all devices with the same firmware/by the same vendor.
     _________________________________________________________

1.3.2. Random Early Detection (RED)

   Random Early Detection tries to circumvent the synchronization
   problem imposed by the tail drop algorithm by measuring the
   average load and adapting the drop rate dynamically. When
   running with the RED algorithm (enabled by default) SER will
   return errors to the SER routing engine every n'th packet
   trying to evenly spread the measured load of the last timer
   interval onto the current interval. As a negative side effect
   SER might drop messages although the limit might not be
   reached within the interval. Decrease the timer interval if
   you encounter this.
     _________________________________________________________



Regards,
Ovidiu Sas

----------------------------------------------------------------------

>Comment By: Henning Westerholt (henningw)
Date: 2008-01-16 09:34

Message:
Logged In: YES 
user_id=337916
Originator: NO

Hi Bogdan, hi Osas,

i had this on my mind too after a short review.. Combining the both into
one would make sense. But we should go for the new name 'ratelimit', this
is a little bit more userfriendly than pike, in my opinion.

Cheers,

Henning

----------------------------------------------------------------------

Comment By: Ovidiu Sas (osas)
Date: 2008-01-15 21:40

Message:
Logged In: YES 
user_id=1395524
Originator: YES

Hi Bogdan,

I won't commit until you give me the green light :)