[SR-Users] The Algorithm “13” - latency optimized dispatching

[Julien Chavanton]

I did some load tests today and added a comment on the pull request.

My status is that this is production ready.
But it is not yet merged in master, if you want to use it you will have to
use master or cherry-pick a few commits because there was some refactoring
done to facilitate the integration and the review.

Happy Friday the 13th.

On Fri, Nov 13, 2020, 14:54 Joel Serrano <joel at textplus.com> wrote:

> Thanks Juha!! I have a perfect use case for this algorithm.
>
> Is it tryable ?
>
> Joel.
>
> On Fri, Nov 13, 2020 at 5:57 AM David Villasmil <
> david.villasmil.work at gmail.com> wrote:
>
>> Nice!
>>
>> On Thu, 12 Nov 2020 at 22:01, Julien Chavanton <jchavanton at gmail.com>
>> wrote:
>>
>>> About The Algorithm “13” - latency optimized dispatching,
>>>
>>> Is now reviewed once and tested, it will most likely be ready to merge
>>> soon.
>>>
>>> I want to share my thoughts on it one more time as it is not too late to
>>> get more feedback before we merge.
>>>
>>> I think it is the best algorithm in most use cases, here is why :
>>>
>>> It is providing round-robin and fail-over with automatic
>>> de-prioritization of slow/unresponsive gateways.
>>>
>>> You probably asked yourself the following questions in the past :
>>> "How do I set the thresholds to put a gateway out of service ?"
>>>
>>> *ds_probing_threshold*, *ds_inactive_threshold* and timers ...
>>>
>>> - If your thresholds are too strict, you may end up running out of
>>> gateway.
>>> - If your thresholds are too tolerant, you may end up adding excessive
>>> delays to call establishment and using degraded gateways.
>>>
>>> The automatic de-prioritization can help to address this concern more
>>> efficiently by providing more flexibility.
>>>
>>> - it can react faster than lets say 2 consecutive timeouts.
>>> - it will not disable gateways but simply de-prioritize / reorder them
>>> if needed.
>>>
>>> The only main drawback I can imagine is when you always need to evenly
>>> distribute calls using round-robin.
>>> It may be needed sometimes but in this case it means you are willing
>>> accept to send calls to a degraded gateway or trough degraded network paths.
>>>
>>> Even if you may select to preset a mixture of round-robin sets, thanks
>>> to *ds_select_routes* however it will stay static, needs to be
>>> configured precisely, and will not react to degradation automatically.
>>>
>>> I hope this will help use to protect QoS and lower latency of calls
>>> routed by Kamailio.
>>>
>>> Feel free to let me know what you think
>>> Julien
>>>
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> --
>> Regards,
>>
>> David Villasmil
>> email: david.villasmil.work at gmail.com
>> phone: +34669448337
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> 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-users/attachments/20201113/c47db60c/attachment.htm>