SIP and Congestion Control: Exploring Solutions
Posted by Dorgham Sisalem on Tue, May 25, 2010 @ 04:11 PM
In continuation of my last posting - The Problem with SIP Congestion Control - I would like to briefly discuss some proposed solutions for solving this issue.
As mentioned in the last posting, the only mechanism provided in the SIP specifications is for the server to reply back with a 503 response. However, as the 503 response is kind of a binary mechanism, the server will either receive traffic or not. This can easily lead to oscillations and might cause the entire SIP infrastructure to become unstable under overload situations.
In general, one can distinguish between standalone and feedback based overload mechanisms.
In the standalone approach, an overload control mechanism is implemented at the SIP server. This server will then monitor its own resources, e.g., memory, CPU and bandwidth. Based on the monitored resources the server will recognize when it starts to become overloaded and will have to deal with the incoming traffic by either rejecting new calls or even dropping them -whereas rejecting is preferred as dropping a request will cause the caller to retransmit the request and hence the server will end up having to deal with the same call a number of times.
When dropping/rejecting requests the server will have to ensure that running calls are not interrupted -i.e., it would be a bad idea to accept a new call, but reject a BYE request as losing the BYE request might cause irregularities in the charging process. An example of a standalone approach can be found in the paper - Protecting VoIP Services Against DoS Using Overload Control.
The other approach for overload control is more of a cooperative process. In this scenario the overloaded server regulates the amount of traffic it is receiving from its neighbors by informing them about its current load. The load information can be sent to the neighboring servers by either adding a header in the SIP response or by using the SUBSCRIBE/NOTIFY mechanisms of SIP. The neighboring servers will then adapt the amount of traffic that they are sending to the overloaded server. In case they have to reduce the amount of traffic they want to send to the overloaded server then they will also inform their neighbors to send less traffic to them. This way, the congestion is pushed to the border of the network and calls are not forwarded to the core components only to be dropped there. A survey of different control mechanisms can be found in the article - Session Initiation Protocol (SIP) Server Overload Control: Design and Evaluation.
Both approaches have their pros and cons. The standalone approach can be deployed without having to rely on other SIP components in the network to also support overload handling. It also does not require any standardization with regard of how to exchange status information. This makes this approach the ideal one for now. However, this mechanism does not cause the overall load of the SIP network to go down.
The feedback based approach can adapt the number of calls in the network to the actual available resources and would push the overload to the borders of the network. In this way, excess calls will be prevented from even reaching the overloaded servers and access points can consider using non-overloaded paths for establishing the calls. On the down-side, a server that ignores the feedback information would still cause overload and packet drops. Hence, to be on the safe side, a SIP server will have to implement a combination of both approaches.