Download presentation
Presentation is loading. Please wait.
Published byMervyn Mills Modified over 9 years ago
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.
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.