[sr-dev] [SR-Users] congestion control priority for priority based dispatching

[Julien Chavanton]

Thank you both for the attention and the feedbacks

Point clarified, it should be a new algorithms, something like :

   “13” - location optimized routing mode, the lowest latency gets higher
priority (serial forking ordered by priority,  ds_ping_latency_stats is
required).

The main drawback it that there is not load balancing, I would like to
address this now, by making it configurable, an option to activate location
optimized with load balancing routing mode.

I would like to find a clear and simple way to do this, that should be easy
to document and understand.

For example in a scenario like that, it would be best that gateways with
similar latency would get traffic load balanced to them, the priority could
be overloaded to represent the threshold :




I found this simple formula : *ADJUSTED_PRIORITY = PRIORITY -
(ROUNDDOWN(ESTIMATED_LATENCY/PRIORITY))*
Priority is also the threshold for latency priority adjustment, not sure if
overloading it is creating confusion, in this example gateway 1, 4 and 6
would receive 33%/33%/33%, the other gateways would be only there for
failover


GATEWAY PRIORITY ESTIMATED_LATENCY ADJUSTED_PRIORITY
1 30 21 30
2 30 91 27
3 30 61 28
4 30 19 30
5 30 32 29
6 30 0 30
7 30 201 24






















On Thu, May 28, 2020 at 9:08 AM Daniel-Constantin Mierla <miconda at gmail.com>
wrote:

> Hello,
>
> maybe a dedicated module is going to be too complex or better said,
> duplicate a lot of code for management of the destinations,
> load/reload/keepalive, ... (although I won't have anything against such
> approach, if considered better by developer).
>
> However, if done in dispatcher, I think that a new algorithm id should be
> used, leaving 8 as it is. Also, there should be a new field added in the
> internal structure to keep this "dynamic" priority -- it can be initialized
> to the "priority" value.
>
> In some cases I use different algorithms for the same group of
> destinations, so it would be good to be able to use algorithm 8 with
> priority from database and the new algorithm at the same time.
>
> Cheers,
> Daniel
> On 27.05.20 21:46, Henning Westerholt wrote:
>
> Hi Julien,
>
>
>
> sounds interesting, a “location optimized routing mode”. What about making
> it as a dedicated mode, to not overloading the mode “8”?
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* sr-dev <sr-dev-bounces at lists.kamailio.org>
> <sr-dev-bounces at lists.kamailio.org> *On Behalf Of *Julien Chavanton
> *Sent:* Thursday, May 14, 2020 7:26 PM
> *To:* Kamailio (SER) - Development Mailing List
> <sr-dev at lists.kamailio.org> <sr-dev at lists.kamailio.org>; Kamailio (SER) -
> Users Mailing List <sr-users at lists.kamailio.org>
> <sr-users at lists.kamailio.org>
> *Subject:* [sr-dev] congestion control priority for priority based
> dispatching
>
>
>
> Hi Folks,
>
>
> Just found another simple use case of the dispatcher latency stats.
>
> Just shraing this idea of a feature I want to contribute.
>
>
> When using dispatcher algorithm 8:
>
>    “8” - select destination sorted by priority attribute value (serial
> forking ordered by priority).
>
> If the gateway as the attribute, the priority becomes the estimated
> latency.
>
>    cc-priority
>
>
>
> - The dispatcher would automatically prioritize the closest one.
>
> - If a gateway is becoming unresponsive it will automatically become de
> prioritize.
>
>
> Consider this real life scenario where you have gateways in East and West
> Coast
>
> Example
>
>
> URI: sip:28.71.19.140
>
>
> FLAGS: AP
> PRIORITY: 10
> ATTRS: {
>         BODY: cc_priority=1
> }
> LATENCY: {
>         AVG: 84.001000
>         STD: 0.062000
>         EST: 84.001000 (high == low priority)
>         MAX: 93
>         TIMEOUT: 0
> URI: sip:28.71.16.140
> FLAGS: AP
> PRIORITY: 10
>
> ATTRS: {
>         BODY: cc_priority=1
> }
>
> LATENCY: {
>         AVG: 29.110000
>         STD: 2.383000
>         EST: 31.999000 (low == high priority)
>         MAX: 1499
>         TIMEOUT: 1
>
>
>
>
>
> Another major improvement to all of this would be to gather stats on
> INVITE <> 100 to have a very accurate latency estimation even if the
> gateway does not support SIP OPTIONS pings
>
>
>
>
>
> _______________________________________________
> Kamailio (SER) - Development Mailing Listsr-dev at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20200528/711f5f3c/attachment-0001.html>