Patches item #1870857, was opened at 2008-01-13 23:00
Message generated for change (Comment added) made by osas
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1870857&group_id=139143
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver devel
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ovidiu Sas (osas)
Assigned to: Ovidiu Sas (osas)
Summary: new module: ratelimit
Initial Comment:
Please find in the attachment the source code for ratelimit module (ported from
SER).
>From README:
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: Ovidiu Sas (osas)
Date: 2008-01-16 05: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 04: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 04: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 16:40
Message:
Logged In: YES
user_id=1395524
Originator: YES
Hi Bogdan,
I won't commit until you give me the green light :)
>From the 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.
Regards,
Ovidiu Sas
----------------------------------------------------------------------
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-01-15 16:31
Message:
Logged In: YES
user_id=1275325
Originator: NO
Hi Ovidiu,
before going for commit, maybe we should evaluate if make sense to merge
this into the pike module. To be honest, to many modules (with similar
functionality) may be confusing, so maybe we should try to compact a bit,
if possible.
Regards,
Bogdan
----------------------------------------------------------------------
Comment By: Daniel-Constantin Mierla (miconda)
Date: 2008-01-15 16:23
Message:
Logged In: YES
user_id=1246013
Originator: NO
You should have write access to SVN. Please report otherwise.
Once the module is imported, just close this item. The enhancements done
in opensimscore do look interesting, when time allows you, would be nice to
import.
----------------------------------------------------------------------
Comment By: Ovidiu Sas (osas)
Date: 2008-01-14 19:55
Message:
Logged In: YES
user_id=1395524
Originator: YES
New src tarball updated.
File Added: ratelimit.tar.gz
----------------------------------------------------------------------
Comment By: Ovidiu Sas (osas)
Date: 2008-01-14 17:49
Message:
Logged In: YES
user_id=1395524
Originator: YES
Hi Daniel,
Yes, I noticed the missing free in destroy. I will fix them up and when I
have time, I will import the openims extensions.
I would be happy to maintain the module.
-ovi
----------------------------------------------------------------------
Comment By: Daniel-Constantin Mierla (miconda)
Date: 2008-01-14 17:34
Message:
Logged In: YES
user_id=1246013
Originator: NO
I took a quick look at the module, and for a clean shut down, all
variables allocated in share memory in mod init should be freed in mod
destroy. Make sure they are initialized to NULL and you check their value
before freeing, to avoid crashes when there are errors in config and
openser shut downs before the module is initialize.
I assume you want to maintain the module on svn repository.
----------------------------------------------------------------------
Comment By: Ovidiu Sas (osas)
Date: 2008-01-14 08:09
Message:
Logged In: YES
user_id=1395524
Originator: YES
> Does this also includes the extensions from openims?
No. It is the port of the version that is in the SER cvs.
I will backport the openims extensions later.
Regards,
Ovidiu
----------------------------------------------------------------------
Comment By: Klaus Darilion (klaus_darilion)
Date: 2008-01-14 05:37
Message:
Logged In: YES
user_id=1318360
Originator: NO
Does this also includes the extensions from openims?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1870857&group_id=139143
_______________________________________________
Devel mailing list
Devel@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/devel
