Megaco overload

[Hakan Mattsson]

On Wed, 24 Aug 2005, Tibor Bognár (IJ/ETH) wrote:

TB> Is there any solution in the Megaco to regulate the possible
TB> number of requests?
TB>
TB> Because it seems the Megaco isn't protected against DoS like
TB> "attacks" and tries to serve every request even if it causes an CP
TB> overload situation. It would be useful to give a threshold for the
TB> maximum number of request in a given time period.

No, there is no such automated mechanism in the Megaco application.

One problem here is that in order to determine if a message contains a
request or not you need to decode it. Normally you would like to
process replies and acknowledgements in order to release resources
bound to a request.

You may control an own counter of the number of active requests in
your callback function that handles requests (handle_trans_request/3).
There you could directly return an error reply instead of further
consume more resources. The drawback is that you already has consumed
some resources during decoding.

If you have some means of detecting when your system reaches some
overload threshold (number of active requests, available memory etc.)
you can use the block/unblock functions in the transport modules
(megaco_udp and megaco_tcp) to more effectively stop processing of
incoming messages during the overload periods. This could either be
done in some supervising process or in some callback function.

When a transport module has received a message it is expected to
invoke megaco:process_received_message/4 in order to forward it to the
Megaco engine where the processing takes place. You can configure the
transport modules (megaco_udp and megaco_tcp) to use an own customized
callback function (the 'module' option).  In that function you could
put some overload protection code and possibly drop the message
instead of forward it to megaco:process_received_message/4. But this
would require that both you and your peer is using ALF.

Good luck!

/Håkan