1. SIP Overload Control draft-hilt-sipping-overload-00 Volker Hilt volkerh@bell-labs.com Daryl Malas daryl.malas@level3.com Indra Widjaja iwidjaja@lucent.com Rich Terpstra rich.terpstra@level3.com

2. Status Combined the two overload drafts –draft-hilt-sipping-hopbyhop-overload-00 –draft-malas-sipping-congestion-header-01 Current draft explores design space and provides an initial proposal for a solution.

3. Scope Overload control is used when a SIP server does not have the resources to process all incoming SIP messages. It does not apply when a SIP server is unable to successfully process SIP requests for other reasons. –Examples where overload control does not apply: PSTN gateway that runs out of trunk lines. Registrar that has lost connectivity to registration database.

4. Overload Control Model Monitor: monitors SIP load and generates load samples (L). Control Function: implements overload control algorithm that decides when to throttle and to which extent. –Uses load samples (L) and generates throttle commands (T). Actuator: controls the load that is forwarded to the downstream entity. –Implements well-defined behavior for throttle commands (T). –Implements algorithm to transition between throttle states. SIP Processor Actuator SIP Processor Monitor Control Function Upstream EntityDownstream Entity Overload Control SIP System (L) (T)(L)

5. Hop-by-Hop vs. Full-Path Hop-by-hop: individual control loops between SIP entities. –Simple and can effectively prevent overload. Full-path: a single control loop for each source-destination pair. –May increase efficiency compared to hop-by-hop overload control. –Very complex! Requires endpoints to track load on all possible paths to a target. AB C D AB C D hop-by-hopfull-path

6. Load Feedback & Actuator Behavior Throttle command (T): –Reduce by percentage: redirect/reject x% of the requests normally forwarded to a given downstream server. Simple to determine for multiple upstream neighbors, simple to use. Load spikes are passed through and require re-adjustments. –Fixed request rate: do not send more than x requests per second. Requires the downstream entity to distribute its capacity across its upstream neighbors and to re-adjust the distribution. Stable throughput even if load varies. –Other operations? Current load (L): –Provides upstream entity with additional hints for selecting downstream servers. Other behavior on actuator –Implements algorithms to transition between throttling states. Examples: timeout throttle commands, slow start, etc.

7. SIP Mechanism Overload header –New header that conveys overload status in SIP responses (and possibly requests). –Requires the identification of adjacent proxies. May use sigcomp application identification mechanism (draft- ietf-rohc-sigcomp-sip). –Provides load feedback to all current upstream neighbors with very little overhead. Overload request –New request frequently sent to an upstream entity to report overload status. –Requires higher overhead and tracking of upstream neighbors. Subscribe/Notify –Upstream entities subscribe to the overload status of their downstream neighbors and receive notifications.

8. Backwards Compatibility Avoid preferred treatment of upstream servers that do not support overload control. Two issues: –How does a SIP server know that its upstream neighbor supports and uses overload control? Indicate support in Via header, similar to sigcomp? Infer usage from load forwarded? Not always possible. –How does a SIP server slow down an upstream neighbor that does not support overload control? Use 503 responses?

9. Next-Steps Current proposal –Hop-by-hop overload control. –Control function on downstream entity. –Response header to convey load information Throttle command (T) Current load (L) –Define behavior for actuator on upstream entity. Comments and feedback are highly appreciated!!