This document is for informational purposes only, and Tekelec reserves the right to change any aspect of the products, features or functionality described in this document without notice. Please contact Tekelec for additional information and updates. SIP Overload Control Dorgham Sisalem Director Strategic architecture Tekelec. For What’s Next. Where are we today?

Overview › Introduction and background  Introduction to SIP  Motivation and issues › Building blocks of SIP Overload control  What is out there and why it is not sufficient › Summary Tekelec Confidential 2 | Tekelec. For What's Next.

How does SIP work? 3 | Tekelec. For What's Next. VoIP Network 2VoIP Network 1 User Agent (UA2)User Agent (UA1)Home proxy REGISTE (SIP name to IP addr) OK REGISTER (SIP name to IP addr) OK INVITE UA1 OK ACK Media (RTP) BYE OK BYE REGREG CALLCALL TREMTREM

What could go wrong? › Flash crowds › Denial of Service attacks  Too many new calls that go nowhere  Too many BYE messages › Unintentional attacks › System issues  Under provisioning/engineered system  Software errors  Updates/Maintenance  Failure of supporting systems: Database, DNS, accounting.. Tekelec Confidential 4 | Tekelec. For What's Next.

Why isn’t something like TCP sufficient? › Why not just use a window-based scheme with Receiver X only accepting Y SIP messages each period Z? › SIP is a rather complex application › Different messages have different implications on processing ›INVITE consume more resources than other SIP requests and will cause the creation of other requests ›A lost call is probably less crucial than an infinite bill ›Some call models require more resources than others ›Some calls are more important than others ›Some users are more important that others › Trusted traffic needs to be dealt with differently that untrusted traffic › Different SIP applications have different characteristics Tekelec Confidential 5 | Tekelec. For What's Next.

Architecture Overload Control Building Blocks Tekelec Confidential 6 | Tekelec. For What's Next. Monitor React Logic

Monitoring › Monitor the causes of the overload  Must know what is causing overload in order to react correctly Observe traffic anomalies Distinguish between trusted and untrusted traffic Distinguish between trusted and good and trusted but bad traffic Tekelec Confidential 7 | Tekelec. For What's Next.

Monitoring › Monitor the indicators of the overload  Must know when to start reacting to overload by observing system resources CPU: ­Has a rather oscillatory behavior ­Difficult to determine the right overload threshold that enables a high level of utilization and is resistant to sudden bursts of traffic Memory ­Different messages and calls require different memory usage »What is the right amount of memory to use as an overload indication ­Memory more easily available than CPU »What happens if the memory threshold was reached but CPU is still available Bandwidth ­Only relevant for applications doing media relay and processing (SBC, application servers …) Load ­How many calls am I processing »What if threshold was received but memory and CPU were available Tekelec Confidential 8 | Tekelec. For What's Next.

Monitoring › Monitor the indicators of the overload  Main problem: Thresholds can only be established safely for predictable traffic patterns With only trusted traffic in mind this is already complex Need to take DoS and unintentional traffic into account Tekelec Confidential 9 | Tekelec. For What's Next.

Reaction › When Overloaded then  Forward  Stateless forwarding to some other server  Drop Traffic amplification Lost BYE: Incomplete CDRs Lost updates: terminated calls  Reject traffic with 500 Try the request later The server must have sufficient resources to process incoming requests and send a response  503: Leave me alone Ask the neighbors not to send any traffic for a certain period of time In the worst case can lead to traffic oscillations ­Overland server is rejecting traffic ­Traffic is forwarded to another server ­The other server gets overloaded immediately and rejects the traffic ­Traffic is forwarded to the first server – which gets overloaded Tekelec Confidential 10 | Tekelec. For What's Next.

Overload handling with I Tekelec. For What’s Next. Forwarder Senders 80% load 100% load % load 503

Logic › Once overload was determined, how can load be reduced  Forward suspicious traffic to a storage for later analysis  Process messages belonging to running sessions if possible  Drop messages belonging running sessions if not possible Will be resent later  Reject messages that require more processing with higher probability  ……… › Determining the optimal behavior will require processing messages and collecting information  Need to balance between used resources and loss of optimality Tekelec Confidential 12 | Tekelec. For What's Next.

Architectural Choices: Receiver’s Burdon Tekelec Confidential 13 | Tekelec. For What's Next. Receiver proxy Sender proxy Senders Receivers Load = Ok Do Nothing Load = Ok Do Nothing Load = high Drop/reject Load = high Drop/reject

Architectural Choices: Receiver’s Burdon › Receiver checks resources (memory, CPU, buffer) › If thresholds exceeded Reject/drop traffic › Overl oad control logic at receiver + Easy to introduce − Can contain overload as long as there are sufficient resources for checking local state and rejecting traffic Tekelec Confidential 14 | Tekelec. For What's Next.

Architectural Choices: Sender’s Burdon Tekelec Confidential 15 | Tekelec. For What's Next. Receiver proxy Sender proxy Senders Receivers Load = Ok Do Nothing Load = Ok Do Nothing Load = high Drop Load = high Drop Drop rate > X Throttle traffic Drop rate > X Throttle traffic

Architectural Choices: Sender’s Burdon › Interpret the receiver’s behavior › If thresholds exceeded Reject/drop traffic › Overload control logic at sender (and possibly receiver) + Excess traffic is prevented from entering the network − Requires that all the neighbors interpret the receiver’s behavior in a similar manner − Misbehaving entities have an advantage − Sender’s have even less clue what to reject or drop than the receivers Tekelec Confidential 16 | Tekelec. For What's Next.

Architectural Choices: A Cooperative Burdon Tekelec Confidential 17 | Tekelec. For What's Next. Receiver proxy Sender proxy Senders Receivers Load = Ok Do Nothing Load = Ok Do Nothing Load = high Inform senders about load Load = high Inform senders about load Throttle traffic based on feedback

Architectural Choices: A Cooperative Burdon  Receiver checks resources (memory, CPU, buffer)  Inform neighbors about status Neighbors increase/decrease the amount of traffic sent to the receivers Neighbors inform their neighbors about overload status Overload logic at senders and receivers + Excess traffic is prevented from entering the network − Requires that all the neighbors understand the feedback and react to it Standardize the feedback information − Misbehaving entities have an advantage − Sender’s have even less clue what to reject or drop than the receivers Tekelec Confidential 18 | Tekelec. For What's Next.

Summary › SIP overload control is more complex than expected › Multidisciplinary topic ›Monitoring ›Security ›System and traffic modeling ›Control protocols › No one solution fits all ›Standardization is of little help Tekelec Confidential 19 | Tekelec. For What's Next.