[sr-dev] [Kamailio-Users] ratelimit enhancements
Daniel-Constantin Mierla
miconda at gmail.com
Fri Jan 22 21:47:50 CET 2010
Hello,
On 1/22/10 3:31 PM, Ovidiu Sas wrote:
> The way that the original module was written did not allow dynamic
> numbers of queues and pipes.
> I am using the ratelimit module to control incoming/outgoing traffic
> on specific trunks by invoking rate limitation based on pipes (by
> forcing a specific pipe).
> Choosing a specific pipe is up to the kamailio config designer (any
> type of operations ca be applied to the pvar before choosing a
> specific pipe, so IMHO it is pretty flexible as is right now - one can
> apply any regex operations to a pvar).
> Pipes and queues can be dynamically modified via mi commands.
> The major limitation of the module is the hard coded number of queues
> and pipes and the fact that dynamic changes to pipes and queues are
> not saved on restart.
>
> Loading the queues and pipes from a db will require a redesign of how
> the pipes and queues are stored internally.
>
yes, it is a hash table. A benefit of dynamic/dynamic names is you can
simply use ip address as pipe name. Also strings tend to look more
meaningful when coming back to a config after some time :-) .
IIRC, one issue with the old design is using single lock for all pipes.
The advantage was using static indexing, therefore faster access (still
under one lock). The new one has a lock per slot, so there can be quite
some parallelism of updates/checks, therefore overall could be same
results, tending to be faster with old for low number of pipes and not
so heavy traffic, better with lot of pipes and lot of traffic.
On the other hand, I find useful what Marius proposed as new features.
Cheers,
Daniel
>
> Regards,
> Ovidiu Sas
>
> On Fri, Jan 22, 2010 at 6:52 AM, marius zbihlei<marius.zbihlei at 1and1.ro> wrote:
>
>> Daniel-Constantin Mierla wrote:
>>
>>> Hi Marius,
>>>
>>>
>> Hello,
>>
>> I am in no way a heavy user of ratelimit, only done a couple of tests using
>> the TAILDROP algorithm. My primary interest was in extending the cfg
>> framework from ser to k modules. I have dug around the documentation and
>> the code so I can say I am familiar with some of the insights.
>>
>>> since you did some updates to this module, I am opening for debate some
>>> needed enhancements I did during 3.0 testing phase and want to get opinions
>>> how to get in the code repo.
>>>
>>>
>> I want to clear some documentation issues first. The ratelimit docs says
>> the queue/pipe use the ipfw nomenclature.
>>
>> <quote>
>> Packets belonging to the same flow are then passed to either of two
>> different objects, which implement
>> the traffic regulation:
>>
>> _pipe_ A pipe emulates a link with given bandwidth, propagation
>> delay, queue size and packet loss
>> rate. Packets are queued in front of the pipe as they come
>> out from the classifier, and
>> then transferred to the pipe according to the pipe's
>> parameters.
>>
>> _queue_ A queue is an abstraction used to implement the WF2Q+
>> (Worst-case Fair Weighted Fair Queue-ing) Queueing)
>> ing) policy, which is an efficient variant of the WFQ policy.
>> The queue associates a _weight_ and a reference pipe to each
>> flow, and then all backlogged
>> (i.e., with packets queued) flows linked to the same pipe
>> share the pipe's bandwidth pro-portionally proportionally
>> portionally to their weights. Note that weights are not
>> priorities; a flow with a lower
>> weight is still guaranteed to get its fraction of the
>> bandwidth even if a flow with a
>> higher weight is permanently backlogged.
>>
>> In practice, _pipes_ can be used to set hard limits to the bandwidth that
>> a flow can use, whereas _queues_
>> can be used to determine how different flow share the available bandwidth.
>>
>> The _pipe_ and _queue_ configuration commands are the following:
>> </quote>
>>
>>> Practically is a new module I named for now ratelimit2 and my last idea is
>>> to get it named pipelimit in the trunk.
>>>
>>> The reason for a new module are some major changes. The module uses the
>>> same algorithm but its core is overhaul.
>>> - definitions of pipes are loaded from database
>>> - there can be unlimited number of pipes
>>> - pipes are identified by string names
>>> - should be possible to reload pipes at runtime (iirc, not yet in)
>>> - new pipes can be added at runtime
>>> - functions accept variables to identify the pipe
>>>
>>>
>> I might add the following nice to have features(provided by implementing and
>> extending queues):
>>
>> - Matching of packets to a specific queue should be done by via regexp, not
>> only method (ratelimit.c find_queue() method). If you remove queues, then
>> matching to a specific pipe...
>> - Add support for weighted queue eg. Specify the same pipe for invite and
>> register but allow a 25%-75% priorities. I yet don't know if we can have
>> several queues assigned per pipe. As a comment, ATM I guess queues are only
>> used to match request to pipes(Say REGISTER and SUBSCRIBE requests go to
>> pipe 1, INVITEs to pipe 2)
>> - Also it would be nice to modify rates(bandwidth in ipfw terminology) at
>> runtime. AFAIK one can only modify algorithm parameters, not the rate. I am
>> looking into it.
>>
>>
>>> Since I never used queues from this module and haven't spent time to
>>> understand the concept behind, this functionality is completely missing.
>>>
>>> The old module might be good to keep in place, probably many people are
>>> using it in this form. So, proposals? What is the way to go on? Common code
>>> (algorithms) can be made lib at some point.
>>>
>>>
>> Hm, I would suggest keeping compatibility between the new module and the old
>> and mark the old as obsolete. The alg section is just a few hundred lines,
>> and the queue functionality isn't yet that advanced(no weights and such),
>> and could be easily duplicated and extended into the new.
>>
>> Any ideas?!
>>
>> Cheers,
>>
>> Marius
>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>
>> _______________________________________________
>> Kamailio (OpenSER) - Users mailing list
>> Users at lists.kamailio.org
>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>
>>
> _______________________________________________
> Kamailio (OpenSER) - Users mailing list
> Users at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>
>
--
Daniel-Constantin Mierla
* http://www.asipto.com/
More information about the sr-dev
mailing list