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
Nice!
On Thu, 12 Nov 2020 at 22:01, Julien Chavanton jchavanton@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@gmail.com> wrote:
Nice!
On Thu, 12 Nov 2020 at 22:01, Julien Chavanton jchavanton@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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@gmail.com> wrote:
Nice!
On Thu, 12 Nov 2020 at 22:01, Julien Chavanton jchavanton@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
First of all, s/Juha/Julien/g on my previous email (Sorry!)
That said, what branch are you working on? I’m happy to test it.
I have a setup in Panama (multiple kams, working as a cluster in different physical locations), the 2 sites are interconnected with direct fiber connection that fails very often (Panama Internet quality is not the best). We also have asterisk boxes in each location. All kams can reach all asterisks. Every now and then, the interconnectivity degrades (but doesn’t fail) although calls are affected (latency) what we normally do in these cases is force-route to only a specific set of servers from one location until the degradation is over.
I almost sure this version of algorithm 13 will handle that case totally automatic for us.
Really excited about this!
Joel.
On Fri, Nov 13, 2020 at 18:10 Julien Chavanton jchavanton@gmail.com wrote:
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@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@gmail.com> wrote:
Nice!
On Thu, 12 Nov 2020 at 22:01, Julien Chavanton jchavanton@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Sounds good,
https://github.com/kamailio/kamailio/pull/2493
At this point l, I am simply waiting to see if we get another review, more testing is always a plus and if something is not clear in the doc etc. And get the approval.
I am interested about your use case and settings, this will be a good exercise to make sure using this algorithm is clear and simple.
The priority is also the threshold in ms at which a gateway should be de-prioritised for example in the US East and West coast 30ms could be a good choice. To make sure that under normal conditions the you are using a gateway that is closer.
Under problematic conditions, you may want the estimator to react and adjust quickly, you can tune the estimator. This is not crucial but you can decide if it should have more long term memory or not using the latency alpha.
I think I should write a little blog article about it, would be best if it was a wiki because my first drafts are usually terrible and I like to come back and improve it.
Looking forward your feedback
On Sat, Nov 14, 2020, 08:03 Joel Serrano joel@textplus.com wrote:
First of all, s/Juha/Julien/g on my previous email (Sorry!)
That said, what branch are you working on? I’m happy to test it.
I have a setup in Panama (multiple kams, working as a cluster in different physical locations), the 2 sites are interconnected with direct fiber connection that fails very often (Panama Internet quality is not the best). We also have asterisk boxes in each location. All kams can reach all asterisks. Every now and then, the interconnectivity degrades (but doesn’t fail) although calls are affected (latency) what we normally do in these cases is force-route to only a specific set of servers from one location until the degradation is over.
I almost sure this version of algorithm 13 will handle that case totally automatic for us.
Really excited about this!
Joel.
On Fri, Nov 13, 2020 at 18:10 Julien Chavanton jchavanton@gmail.com wrote:
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@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@gmail.com> wrote:
Nice!
On Thu, 12 Nov 2020 at 22:01, Julien Chavanton jchavanton@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
About your fiber optics failing, if they get congested unresponsive and then fails like it is the case most of the time on the Internet due to buffers etc. It should help.
The estimator will do a better job at remembering if one is more stable than the other.
On Sat, Nov 14, 2020, 08:27 Julien Chavanton jchavanton@gmail.com wrote:
Sounds good,
https://github.com/kamailio/kamailio/pull/2493
At this point l, I am simply waiting to see if we get another review, more testing is always a plus and if something is not clear in the doc etc. And get the approval.
I am interested about your use case and settings, this will be a good exercise to make sure using this algorithm is clear and simple.
The priority is also the threshold in ms at which a gateway should be de-prioritised for example in the US East and West coast 30ms could be a good choice. To make sure that under normal conditions the you are using a gateway that is closer.
Under problematic conditions, you may want the estimator to react and adjust quickly, you can tune the estimator. This is not crucial but you can decide if it should have more long term memory or not using the latency alpha.
I think I should write a little blog article about it, would be best if it was a wiki because my first drafts are usually terrible and I like to come back and improve it.
Looking forward your feedback
On Sat, Nov 14, 2020, 08:03 Joel Serrano joel@textplus.com wrote:
First of all, s/Juha/Julien/g on my previous email (Sorry!)
That said, what branch are you working on? I’m happy to test it.
I have a setup in Panama (multiple kams, working as a cluster in different physical locations), the 2 sites are interconnected with direct fiber connection that fails very often (Panama Internet quality is not the best). We also have asterisk boxes in each location. All kams can reach all asterisks. Every now and then, the interconnectivity degrades (but doesn’t fail) although calls are affected (latency) what we normally do in these cases is force-route to only a specific set of servers from one location until the degradation is over.
I almost sure this version of algorithm 13 will handle that case totally automatic for us.
Really excited about this!
Joel.
On Fri, Nov 13, 2020 at 18:10 Julien Chavanton jchavanton@gmail.com wrote:
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@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@gmail.com> wrote:
Nice!
On Thu, 12 Nov 2020 at 22:01, Julien Chavanton jchavanton@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
David Villasmil -
Joel Serrano -
Julien Chavanton