SIP Server Overload Control: Design and Evaluation Charles Shen and Henning Schulzrinne Columbia University Erich Nahum IBM T.J. Watson Research Center
Session Initiation Protocol (SIP) Application layer signaling protocol for managing sessions in the Internet Run on top of common transport layer, e.g., UDP, TCP and SCTP Typical usage: voice-over-ip call setup, instant messaging, presence, conferencing UA Proxy Proxy UA INVITE INVITE Trying INVITE Trying 8 Ringing 8 Ringing 8 Ringing 2 OK 2 OK 2 OK ACK ACK ACK Media BYE 2 OK BYE 2 OK BYE 2 OK Slide 2
SIP Server Overload Problem Many causes to SIP server overload Natural disaster and emergency-induced call volume (earthquake) Predictable special events (Mother s Day) Flash Crowds: American Idol, Free tickets to the third caller Denial of service attacks Simply dropping requests on overload? INVITE INVITE Simple message dropping induces more messages due to retransmission (especially for SIP over UDP) E.g., Timer A for INVITE retransmission T = 5 ms, increases exponentially INVITE INVITE Slide 3
SIP Server Overload Problem (Cont.) Rejecting excessive requests upon overload? SIP 53 (Service Unavailable) response code used to reject individual request overall sending rate is not reduced rejecting costs comparable CPU cycles with accepting requests! 53 (Service Unavailable) with Retry-After? Client completely shut off during the period specified Reducing rate on/off may cause oscillation Trying an alternative server? Alternative server may soon be overloaded too -> cascading failure! Slide 4
Feedback-based SIP Overload Control RE controls the SE sending pace through a feedback channel Slide 5
SIP Overload Feedback Control Design Considerations Requirements approaching ideal performance Few tweak control parameters Design decisions SIP session as basic control unit Characterizing SIP session check number of INVITEs accepted Dynamic session backlog estimation count both INVITEs and non-invites for current session backlog Active source estimation directly tracking each current active SE sending incoming load Goodput.2.8.6.4.2 Ideal Goodput 2 3 4 5 6 7 8 9 Load Slide 6
Window-based Feedback Control Algorithms Win-disc Win-cont Win-auto Window size decrement upon receiving session request (INVITE) Window size adjustment algorithm every control interval every message arrival after processing new INVITE request budget queuing delay budget queuing delay N/A Tuning parameters control Interval measurement interval measurement Interval Slide 7
Rate-based Feedback Control Algorithms Rate-abs Rate-occ Rate adjustment algorithm (every control interval) acceptable rate request acceptance ratio Tuning parameters budget queuing delay control interval measurement interval budget CPU occupancy control interval measurement interval OCC tuning parameters Slide 8
Simulation Assumptions and Metrics RFC326 compatible simulator built on OPNET exponential call inter-arrival standard seven-message call flow 72 cps RE service capacity; 3 cps rejection rate UAs and SEs have infinite capacity UDP transport, no link delay and loss Piggyback feedback Goodput = # of calls whose INVITE-to- ACK delay below s Delay = time from INVITE sent to ACK (2 OK) received Slide 9
No Feedback Control Simple drop message dropped when queue full Threshold rejection queue length configured with a high and a low threshold value high threshold: new INVITE rejected but other messages processed Low threshold: new INVITE processing restored Similar congestion collapse * but different reasons: Simple Drop Only /3 of INVITEs arriving at the callee all 8 RINGING and most of the 2 OK also dropped due to queue overflow Threshold Rejection no INVITEs reache the callee RE only sending rejection messages Goodput.8.6.4.2 Simple Drop Threshold Rejection 2 3 4 5 6 7 8 9 Load * All load and goodput values normalized over server capacity in this presentation Slide
Sensitivity to Budget Queuing Delay and Control Interval Small queuing delay (< ½ T timer) avoids timeout and gives best results Example results for win-disc delay budget (D B ) <= 2 ms control interval (CI) = 2 ms goodput degraded by 25% for D B = 5 ms Similar results for win-cont and rate-abs Sensitivity of control interval smaller CI is better Example results for win-disc at D B =2 ms, CI <= 2 ms sufficient to archive unit goodput in our scenario Goodput Goodput.95.9.85.8.75.7.65.6.9.8.7.6.5.4 D B = 2ms D B = 3ms D B = 4ms D B = 5ms D B = 6ms 2 3 4 5 6 7 8 9 Load CI = 2ms CI = 5ms CI = s 2 3 4 5 6 7 8 9 Load Slide
Impact of Control Interval across Algorithms Comparing CI for win-disc, rate-abs and rate-occ * at D B = 2ms Both win-disc and rate-abs close to unit goodput except CI = s with heavy load win-disc more sensitive to CI than rate-abs rate-occ not as good as the other two.2 win-disc rate-abs rate-occ.2 win-disc rate-abs rate-occ Goodput.8.6.4 Goodput.8.6.4.2.2 4ms ms 2ms s Control Interval 4ms ms 2ms s Control Interval Goodput vs. CI at Load Goodput vs. CI at Load 8.4 * rate-occ has ρ B set to 85% which is seen to give the highest and stable performance across different load conditions in the given scenario Slide 2
Best Performance Comparison across Algorithms All except rate-occ reach unit goodput no retransmissions server always busy processing messages each single message part of a successful session rate-occ < unit goodput artificial 85% CPU limit occupancy too indirect extremely small CI improves performance at heavy load but incurs problems Goodput.95.9.85.8.75.7 win-cont win-disc rate-abs rate-occ2 rate-occ 2 3 4 5 6 7 8 9 Load Slide 3
Fairness User-centric fairness equal success rate for each individual user implementation: divide RE capacity proportionally to original SE load arrivals applicability example: Free ticket to the third caller Provider-centric fairness each provider (SE) gets the same aggregate share of total capacity implementation: divide RE capacity equally among SEs applicability example: equal-share SLA Customized fairness any allocation as pre-specified by SLA, penalizing the specific sources in denial-of-service attacks Slide 4
Dynamic Load Performance with Provider Centric Fairness Realistic server to server overload situations likely short periods of bulk loads accompanied by source arrivals or departures Example result using rateabs algorithm Each upstream SE share close to equal RE capacity Fast dynamic transition Load Goodput 5 ua3 4 3 ua2 2 ua 2 4 6 8 2 4 6 8 Time (sec).2.8 ua ua2.6 ua3.4.2 2 4 6 8 2 4 6 8 Time (sec) Slide 5
User Centric Fairness 5 4 ua3 Load 3 2 ua ua2 Double feed architecture Provide incoming load Example using win-cont algorithm Upstream SEs share RE capacity proportionally Fast dynamic transition Goodput 2 4 6 8 2 4 6 8 Time (sec) ua ua2.8 ua3.6.4.2 2 4 6 8 2 4 6 8 Time (sec) Slide 6
Win-auto Source arrival transition time could be noticeably longer Hard to enforce explicit fairness no processing intervention Still achieves aggregate unit goodput Load Goodput 5 ua3 4 3 ua2 2 ua 2 4 6 8 2 4 6 8 Time (sec).2 ua.8 ua2 ua3.6.4.2 2 4 6 8 2 4 6 8 Time (sec) Slide 7
Conclusions and Future Work Win-disc Win-cont Win-auto Rate-abs Rate-occ Optimal steady state performance ß Optimal dynamic performance ß User-centric fairness (with double-feed) (with double-feed) ß (with double-feed) Providercentric fairness ß # of tuning parameters 3 2 3 5 Future work: consider more realistic network configurations Slide 8
Archive slides Slide 9
Feedback-based SIP Overload Control RE controls the SE sending pace through a feedback channel Slide 2