Subject: Re: [sip-overload] Proposed SIP Overload Control Charter

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Fri, 16 Apr 2010 16:01:41 -0400

So where did the conference calls go ALU Volker

Speaking as ATT

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Robert Sparks <[email-masked]>
Cc: DISPATCH <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; Lars Eggert <[email-masked]>; Camarillo <[email-masked]>
Sent: Fri Apr 16 15:58:27 2010
Subject: Re: [sip-overload] Proposed SIP Overload Control Charter

On 4/16/2010 11:56 AM, Robert Sparks wrote:
> I have made some tweaks based on the list discussion and conversations with IESG members.
> This is my current working text. Please comment if you disagree with the changes I've made.
>
> The changes are in the description of overload in the first paragraph, changing the term throughput
> to goodput, and clarifying the discussion of scope and limitations. I've also added some strawman
> milestones. Please comment on those dates.
>
> SIP Overload Control WG Charter
> -------------------------------
>
> As with any network element, a Session Initiation Protocol (SIP) server
> can suffer from overload when the number of SIP messages it receives
> exceeds the number of messages it can process. Overload is said to occur
> when a SIP server does not have sufficient resources to complete the
> processing of all incoming SIP messages within the required time.
> These resources can include CPU, memory, network bandwidth, input/output,
> or disk resources.
>
> Overload can pose a serious problem for a network of SIP servers. During
> periods of overload, the goodput of a network of SIP servers can be
> significantly degraded.  In fact, overload may lead to a situation in
> which the goodput drops down to zero or a small fraction of the
> original processing capacity.  This is often called congestion collapse.
>
> The objective of a SIP overload control mechanism is to enable SIP
> servers to operate close to their capacity limit during times of overload.
>
> The SIP protocol provides a limited mechanism for overload control
> through its 503 (Service Unavailable) response code and the Retry-After
> header.  However, this mechanism cannot fully prevent overload of a SIP
> server and it cannot prevent congestion collapse.  In fact, its on/off
> behavior may cause traffic to oscillate and shift between SIP servers
> and thereby worsen an overload condition.  A detailed discussion of the
> SIP overload problem, the problems with the 503 (Service Unavailable)
> response code and the Retry-After header and the requirements for a SIP
> overload control mechanism can be found in RFC5390.
>
> The objective of the working group is to develop mechanisms for SIP
> overload control. The problem domain of SIP overload control can be split into
> overload control between a user agent and a SIP server and overload control
> between SIP servers.
>
> Any specification developed by the working group needs to clearly specify its
> scope. A specification also needs to clearly state any limitations, in
> performance or otherwise, the specified overload control mechanism may have.  In
> particular, the working group shall carefully define the deployment
> considerations for the effective operation of the specified mechanisms and
> discuss, for example, when a mechanism requires coordinated deployment and
> operation (if all servers need to deploy the same mechanism, certain
> configuration values need to be identical on all servers, etc), when a
> mechanism can become less effective or ineffective under some conditions, or
> especially if there are cases when a mechanism can reduce goodput compared to
> no overload protection. The intent of these considerations is to allow
> potential deployers to make the best use of these mechanism in their particular
> networks.
>
> The working group will consider two complementary approaches for
> handling overload situations:
> - The first mechanism aims at preventing overload in SIP servers by
>    adjusting the incoming load to a level that is acceptable for this
>    server. This mechanism uses implicit and/or explicit feedback to
>    determine when an overload condition occurs in a SIP server and a
>    reduction in load is required.
> - The second mechanism aims at preventing overload in SIP servers by
>    distributing load control filters to SIP servers that throttle calls
>    based on their destination domain, telephone number prefix or for a
>    specific user. Such filters can be used, for example, to throttle calls
>    to a hotline during a ticket-giveaway event.
>
> The working group will develop the following deliverables:
>
>    1. A document describing key design considerations for a SIP overload
>       control mechanism.
>    2. A specification for an SIP overload control mechanism based on
>       implicit/explicit feedback.
>    3. A specification for a SIP load filtering mechanism.
>
> Milestones:
>
> Sep 2010 Design Considerations to IESG for publication as Informational
> Dec 2010 Specification for a SIP overload control mechanism based on implicit/explicit feedback to IESG for publication as Proposed Standard
> May 2011 Specification for a SIP load filtering mechaism to IESG for publication as Proposed Standard
>
>
> On Apr 1, 2010, at 7:55 PM, Volker Hilt wrote:
>
>> All,
>>
>> below is an updated charter proposal for a SIP Overload Control WG. It has additional text that specifications developed by the proposed WG need to define scope and limitations (see below).
>>
>> Thanks,
>>
>> Volker
>>
>>
>>
>> SIP Overload Control WG Charter
>> -------------------------------
>>
>> As with any network element, a Session Initiation Protocol (SIP) server
>> can suffer from overload when the number of SIP messages it receives
>> exceeds the number of messages it can process. Overload is said to occur
>> when a SIP server does not have sufficient resources to process all
>> incoming SIP messages.  These resources can include CPU, memory, network
>> bandwidth, input/output, or disk resources.
>>
>> Overload can pose a serious problem for a network of SIP servers. During
>> periods of overload, the throughput of a network of SIP servers can be
>> significantly degraded.  In fact, overload may lead to a situation in
>> which the throughput drops down to zero or a small fraction of the
>> original processing capacity.  This is often called congestion collapse.
>>
>> The objective of a SIP overload control mechanism is to enable SIP
>> servers to operate close to their capacity limit during times of overload.
>>
>> The SIP protocol provides a limited mechanism for overload control
>> through its 503 (Service Unavailable) response code and the Retry-After
>> header.  However, this mechanism cannot fully prevent overload of a SIP
>> server and it cannot prevent congestion collapse.  In fact, its on/off
>> behavior may cause traffic to oscillate and shift between SIP servers
>> and thereby worsen an overload condition.  A detailed discussion of the
>> SIP overload problem, the problems with the 503 (Service Unavailable)
>> response code and the Retry-After header and the requirements for a SIP
>> overload control mechanism can be found in RFC5390.
>>
>> The objective of the proposed working group is to develop mechanisms for
>> SIP overload control. The problem domain of SIP overload control can be split into i) overload control between a user agent and a SIP server and overload control between SIP servers. A specification developed by the proposed working group needs to clearly specify its scope. A specification also needs to clearly state any limitations in performance or otherwise the proposed overload control mechanism may have.
>>
>> Two complementary approaches exist for handling overload situations:
>> - The first mechanism aims at preventing overload in SIP servers by
>> adjusting the incoming load to a level that is acceptable for this
>> server. This mechanism uses implicit and/or explicit feedback to
>> determine when an overload condition occurs in a SIP server and a
>> reduction in load is required.
>> - The second mechanism aims at preventing overload in SIP servers by
>> distributing load control filters to SIP servers that throttle calls
>> based on their destination domain, telephone number prefix or for a
>> specific user. Such filters can be used, for example, to throttle calls
>> to a hotline during a ticket-giveaway event.
>>
>> Specifically, the proposed working group will develop the following
>> deliverables:
>> 1. A document describing key design considerations for a SIP overload
>> control mechanism.
>> 2. A specification for an SIP overload control mechanism based on
>> implicit/explicit feedback.
>> 3. A specification for a SIP load filtering mechanism.
>>
>>
>

_______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload