Traffic shaping
2 posters
Page 1 of 1
Traffic shaping
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.
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.
Similar topics
» How can I capture ethernet traffic?
» How is excess traffic is dropped or queued?
» FreeSBC How To Series – Network Traffic Management & Intelligence
» Does it get MOS for RTP streams and can it route traffic based on voice quality per trunk?
» How is excess traffic is dropped or queued?
» FreeSBC How To Series – Network Traffic Management & Intelligence
» Does it get MOS for RTP streams and can it route traffic based on voice quality per trunk?
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum