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: Klaus Darilion (klaus_darilion)
Date: 2008-01-16 13:37

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

IMO having 2 modules fine - and add a note to the README of both modules
which tells the user that the other module exists too (and describing the
difference: IP level vs. SIP level)

klaus

PS: sourceforge does not remember my login anymore (since ~1-2 month).
Anyone else having similar problems?

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

Comment By: Ovidiu Sas (osas)
Date: 2008-01-16 11:57

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

Hi Henning,

Thank you for the copyright updates.


Regards,
Ovidiu

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

Comment By: Ovidiu Sas (osas)
Date: 2008-01-16 11:53

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

Hello all,

Here is a quick overview:
 - pike is dealing with traffic on a per IP basis and it doesn't care
about requests type.  It doesn't deal with the load on the server (it can't
control the load of the server).  It is good to control DoS attacks.
 - ratelimit is dealing with traffic on a per request basis and it doesn't
care about IPs.  It tries to control the load on the server but it can't
help for DoS attacks.  Also, it can be used as a traffic shaper.

In my view, the two modules complements each other and they have different
roles.  We can integrate both into one single module (this is not a
problem).  When we take such decision, we need to take in consideration
also the user perspective and the easy of configuration.  For example, pike
module has it's own timer and ratelimit has it's own timer.  This two
timers cannot be merged, as they server different purposes.  Having a lot
of configuration options for a single module may be confusing.

Just my 2c before taking a decision about integrating them ot not.


Regards,
Ovidiu Sas

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

Comment By: Henning Westerholt (henningw)
Date: 2008-01-16 10:46

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

Hi Ovidiu,

i think the actual licence header is a little bit confusing.

You state that this file is part of 'SER', that is not true anymore. You
said also that its possible to obtain a licence !(GPL v2 or later) for this
code from iptel.org. This is also not true anymore, unless you've assign
iptel.org the copyright of your port. 

I would suggest to keep the copyright of Hendrik (of course) and add a
senctence that this module was ported from SER. After that use the standard
copyright header with 'GPL2 or later - OpenSER' that is used for all other
code.

Regards,

Henning

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

Comment By: Henning Westerholt (henningw)
Date: 2008-01-16 10: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 22:40

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

Hi Bogdan,

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