Telcobridges - Session Border Controllers
Would you like to react to this message? Create an account in a few clicks or log in to continue.

Traffic shaping

2 posters

Go down

Traffic shaping Empty Traffic shaping

Post by ppierscionek Sun Sep 08, 2019 5:48 am

ProSBC has a support for rate limiting with optional burst buffer.
While this is nice for protecting against overloads it causes a lot of drops with service unavailable in Contact Center scenarios.

Imagine a scenario where a Contact Center "predictive" dialer, however poorly implemented, initiates 100 calls per each 5 second window.
20 CAPS on average but all 100 calls are made within the first second and the next 4 are idle.

20 CAPS Ratelimit with no burst would drop 80% of requests. So burst is required here but imagine a carrier that has a 20 CAPS limit and no burst.
SBC forwards the traffic to the carrier and we either drop 80% on the SBC or the carrier drops 80% and is angry at us.

We solve this issue with Kamailio 5.3 by using leaky bucket (same algo as in ProSBC) but we artificially delay each request by the current depth of the bucket and drop only the requests where bucket + burst is over limit.
This evens out the traffic nicely and there are no more dropped calls.
Some are delayed by up to 5 seconds in this scenario but the dialer does not go into overdrive / avalanche mode because of the 80% drop on the first hop.

I imagine a boolean parameter on the NAP that would choose the behaviour among:
- NO DELAY (current behaviour)
- DELAY OVER RATE (delay only when request if over limit but within a burst)
- DELAY ALL (delay all to spread evenly)

One might also implement an explicit delay limit - eg of 10000ms as a parameter where calls with longer computed delayed that limit would be dropped.
A call flag, settable in a script, could also be implemented to change the delay behaviour on per call basis. This could be used to set NO DELAY for emergency calls .

This seems a simple hack and requires an immediate 100 response but a delayed outgoing leg creation by bucket depth expressed in milliseconds
20ms precision is OK but 5ms is better for load approaching 1k CAPS

This can be also applied as inbound ratelimiter to avoid CPU spikes on script processing as well.

Number of Messages : 8
Point : 22
Registration Date : 2019-09-08
Age : 46

Back to top Go down

Traffic shaping Empty Re: Traffic shaping

Post by Admin Mon Sep 09, 2019 12:45 am

Thank you for this information. We will consider your suggestion.


Number of Messages : 508
Point : 1199
Registration Date : 2017-11-27

Back to top Go down

Back to top

- Similar topics

Permissions in this forum:
You cannot reply to topics in this forum