1 / 10

SIP Overload Control IETF Design Team Status

SIP Overload Control IETF Design Team Status. Volker Hilt volkerh@bell-labs.com Bell Labs/Alcatel-Lucent. SIP Overload Control Design Team Current Status. Team Members New design team members Ahmed Abd el al, Tom Phelan (Sonus Networks) Existing team members

billywilliamson
Download Presentation

SIP Overload Control IETF Design Team Status

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. SIP Overload Control Design TeamCurrent 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. 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. draft-hilt-sipping-overload-design-00Implicit/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. C A A B D D B D … C Hop-by-hop Client-to-Server Server-to-Server b a z c x C A B D x End-to-end draft-hilt-sipping-overload-design-00Topologies/Degree of Cooperation • Client-to-Server vs. Server-to-Server • Hop-by-hop vs.End-to-end

  6. draft-hilt-sipping-overload-design-00Overload 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. draft-hilt-sipping-overload-design-00Next Steps Is this document useful to the SIPPING WG?

  8. SIP Overload Control Design TeamSimulation 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. SIP Overload Control Design TeamSimulation 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. SIP Overload Control Design TeamFairness 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.

More Related