[Kamailio-Users] ratelimit enhancements

[marius zbihlei]

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
>