1. Volker Hilt volkerh@bell-labs.com Bell Labs/Alcatel-Lucent SIP Overload Control IETF Design Team Status

2. Slide 2 | 72 IETF Meeting | July 2008 SIP Overload Control Design Team Current Status Team Members  New design team members  Ahmed Abd el al, Tom Phelan (Sonus Networks)  Existing team members  Eric Noel, Carolyn Johnson (AT&T Labs)  Volker Hilt, Indra Widjaja (Bell Labs/Alcatel-Lucent)  Charles Shen, Henning Schulzrinne (Columbia University)  Mary Barnes (Nortel)  Jonathan Rosenberg (Cisco)  Nick Stewart (British Telecom) Four independent simulation tools  AT&T Labs, Bell Labs/Alcatel-Lucent, Columbia University, Sonus Networks Draft submitted  draft-hilt-sipping-overload-design-00

3. Slide 3 | 72 IETF Meeting | July 2008 draft-hilt-sipping-overload-design-00 Design considerations and models for an overload control solution for SIP.  Frame the discussion of an SIP overload control mechanism.  Describe possible design choices and models.  This is NOT a proposal for a solution! Contributors are the members of the SIP overload control design team.

4. Slide 4 | 72 IETF Meeting | July 2008 draft-hilt-sipping-overload-design-00 Implicit/Explicit Overload Control Implicit Overload Control Goal is to achieve a gentle decline in throughput as overload increases without explicit overload feedback.  SIP server overload is regenerative.  Messages that get dropped due to overload are retransmitted and increase the offered load for the already overloaded server.  Selecting messages to be dropped during overload requires processing at a SIP server.  Resources spend on parsing messages to identify new requests that can be discarded during overload are lost.  The number of successful transactions declines as load increases, even with fully non-regenerative overload behavior. Explicit Overload Control An explicit overload signal is used to request a reduction in the incoming load. Enables a SIP server to adjust the incoming load to a level at which it can perform at maximum capacity.

5. Slide 5 | 72 IETF Meeting | July 2008 draft-hilt-sipping-overload-design-00 Topologies/Degree of Cooperation Client-to-Server vs. Server-to-Server Hop-by-hop vs. End-to-end Server-to-Server D B A C D Client-to-Server a b c z … AB C D Hop-by-hop AB C D End-to-end x x

6. Slide 6 | 72 IETF Meeting | July 2008 draft-hilt-sipping-overload-design-00 Overload Control Feedback Types Rate-based Overload Control Idea: limit the request rate at which an upstream element is allowed to forward requests to the downstream neighbor.  A server instructs each upstream neighbor to send at most X requests per second. Loss-based Overload Control Idea: reduce the number of requests an upstream element would normally forward to the downstream neighbor by a percentage X.  A server instructs each upstream neighbor to reduce load by X%. Window-based Overload Control Idea: allow an entity to transmit a certain number of messages before it needs to receive a confirmation for the messages in transit.  An upstream neighbor maintains an overload window that limits the number of messages in transit without being confirmed.

7. Slide 7 | 72 IETF Meeting | July 2008 draft-hilt-sipping-overload-design-00 Next Steps Is this document useful to the SIPPING WG?

8. Slide 8 | 72 IETF Meeting | July 2008 SIP Overload Control Design Team Simulation Models (1) Different Network Conditions Evaluate overload control mechanisms under varying network conditions.  Different network loss probabilities.  Different transmission delays.  Combination of transmission delay and loss probability. Offered Load Distribution Evaluate the impact of an uneven distribution of load on a network of SIP servers.  Fraction 1-f of edge servers operate at engineered load, fraction f operate above engineered load.  Examine steady-state as well as transient behavior.

9. Slide 9 | 72 IETF Meeting | July 2008 SIP Overload Control Design Team Simulation Models (2) Overload Events Evaluate the transient behavior of SIP servers when overload occurs/ is removed. Scenarios:  Sudden peak  Sudden peak with gradual release  Temporary, light overload Changes in Neighbor Set Evaluate how well an algorithms adapts to senders starting/stopping to transmit.

10. Slide 10 | 72 IETF Meeting | July 2008 SIP Overload Control Design Team Fairness A criteria to evaluate overload control algorithms is how well they fulfill a given fairness criteria: Basic user-centric fairness  Definition: equal success probability for each individual user  Example: “Third caller receives free tickets” Basic provider-centric fairness  Definition: equal success probability for each provider  Example: specific SLAs Customized user-centric and provider-centric fairness  Definition: any fairness requirements other than the basic ones.  Examples:  Specific source sending an unusually high load is throttled more than other sources.  A SLA requires specific (un-equal) sharing of the capacity among upstream servers.