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

From: Volker Hilt <[email-masked]>
Date: Thu, 1 Apr 2010 20:55:58 -0400

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.

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 2 Apr 2010 11:11:35 -0400

> 
> [sip-overload] Proposed SIP Overload Control Charter
> 
> Volker Hilt 
> 

This text

> to a hotline during a ticket-giveaway event.

seems to imply that there are ONLY TWO complementary approaches. 

There are, in fact, a much larger number of possible approaches.

Filters based on the SOURCE domain, telephone number prefix or for a 
specific user are the most obvious omission, but I am sure there are many 
more.

Perhaps better wording would be 

"At least two complementary approaches exist for handling overload 
situations:..."

Janet

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

---

From: Charles Shen <[email-masked]>
Date: Fri, 2 Apr 2010 11:28:36 -0400

On Fri, Apr 2, 2010 at 11:11 AM, Janet P Gunn <[email-masked]> wrote:
> specific user are the most obvious omission,

"Filters based on the SOURCE domain, telephone number prefix or for a
specific user" are still part of (and included in) the filter-based
approach.

Maybe what we are talking about is either a single user or a group of
users specified by URIs (e.g., SIP, Tel), and the grouping can be
based on domains or telephone number prefixes?

Thanks

Charles

> but I am sure there are many
> more.
>

---

From: Robert Sparks <[email-masked]>
Date: Fri, 16 Apr 2010 10:56:51 -0500

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.

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 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 working group will develop the following deliverables:

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. 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.
>

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 16 Apr 2010 12:42:54 -0400

I know I said it before, but I am going to say it again.

First, the "second mechanism" should explicitly mention filtering based on 
SOURCE "domain, telephone number prefix or specific user", not just 
DESTINATION.

Second, I would like to see an explicit statement that the work will be 
consistent with the requirements in RFC 5390.

Thanks

Janet

[email-masked] wrote on 04/16/2010 11:56:51 AM:

> [image removed] 
> 
> Re: [sip-overload] Proposed SIP Overload Control Charter
> 
> Robert Sparks 
> 
> to:
> 
> Volker Hilt
> 
> 04/16/2010 11:57 AM
> 
> Sent by:
> 
> [email-masked]
> 
> Cc:
> 
> DISPATCH, "[email-masked]", Gonzalo Camarillo, Lars Eggert
> 
> potential deployers to make the best use of these mechanism in 
theirparticular
> Dec 2010 Specification for a SIP overload control mechanism based on
> implicit/explicit feedback to IESG for publication as Proposed Standard
> > 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. 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.

---

From: Volker Hilt <[email-masked]>
Date: Fri, 16 Apr 2010 14:51:59 -0400

I think the updated charter and the milestones look good.

Volker

---

From: Volker Hilt <[email-masked]>
Date: Fri, 16 Apr 2010 15:58:27 -0400

---

From: Volker Hilt <[email-masked]>
Date: Fri, 16 Apr 2010 16:02:11 -0400

An slight update to the charter Robert has sent out to address Janet's 
comment.

Volker

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 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 source or 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.

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

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 16 Apr 2010 19:19:53 -0400

Works for me

Janet

[email-masked] wrote on 04/16/2010 04:02:11 PM:

> Robert Sparks, DISPATCH, [email-masked], Lars Eggert , 
> Gonzalo Camarillo
> 
> 04/16/2010 04:00 PM
> 
> Sent by:
> 

> > to goodput, and clarifying the discussion of scope and 
> limitations. I've also added some strawman
> specify its
> their particular
> > Dec 2010 Specification for a SIP overload control mechanism based 
> on implicit/explicit feedback to IESG for publication as Proposed 
Standard
have.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 21 Apr 2010 10:28:39 -0500

Please comment on what these dates should actually be 

RjS

---

From: <[email-masked]>
Date: Fri, 23 Apr 2010 10:53:42 +0200

I would prefer to see the SIP load filtering specification released by the end of 2010. 
BC

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Robert Sparks
> Envoyé : mercredi 21 avril 2010 17:29
> À : Robert Sparks
> Cc : Volker Hilt; DISPATCH; [email-masked]; Gonzalo 
> Camarillo; Lars Eggert
> Objet : Re: [sip-overload] Proposed SIP Overload Control Charter
> 
> > 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
>

---

From: "NOEL, ERIC C (ATTLABS)" <[email-masked]>
Date: Mon, 26 Apr 2010 09:53:40 -0400

Folks,

Wrt milestones deadlines:

   1. A document describing key design considerations for a SIP overload
      control mechanism ==> Sep 2010
   2. A specification for an SIP overload control mechanism based on
      implicit/explicit feedback ==> Dec 2010
   3. A specification for a SIP load filtering mechanism ==> May 2011

I have a few comments:

- Is item 1 a cleaned up version of draft-ietf-sipping-overload-design-02.pdf?
    ==> if so I am OK with Sep 2010 date.
- Could item 2 consist of the documentation of one of the SIP overload control mechanism studied by the SIP overload design team coordinated by Volker? 
    ==> Provided work consists of documenting one of the control mechanism studied by the SIP overload design team, then I am ok with Dec 2010.
- With respect to item 3, are there any other related IETF activity besides draft-shen-sipping-load-control-event-package that need consideration? Is the expectation to validate the proposed load filtering mechanism through simulation?
    ==> Would like feedback on questions prior agreeing on May 2011 deadline.

Lastly, what will be the mode of operation to actually work on these items? Continue sending comments on the sip-overload distribution list? Have regular sub-teams meeting (via conference calls)? 

Thanks,

Eric

---

From: Volker Hilt <[email-masked]>
Date: Mon, 26 Apr 2010 16:21:25 -0400

Eric,
>      ==>  Would like feedback on questions prior agreeing on May 2011 deadline.
The charter lays out milestones for items the proposed working group 
should produce. It is up to the WG to evaluate the drafts that have been 
proposed and adopt drafts that meet these milestones. The drafts you 
mention are candidates. They may or may not be adopted by the WG.

> Lastly, what will be the mode of operation to actually work on these
> items? Continue sending comments on the sip-overload distribution
> list? Have regular sub-teams meeting (via conference calls)?
>
All discussions will happen on the sip-overload mailing list and all 
comments need to go to this list. We may use conference calls for 
specific topics if needed. If there is a need, calls will be announced 
on the mailing list.

Thanks,

Volker

> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 27 Apr 2010 20:23:26 +0530

Hi all,

>        implicit/explicit feedback ==>  Dec 2010

draft-partha-sip-overload-resource-availability is a draft based on explicit feedback mechanism (SUBSCRIBE/NOTIFY).  This draft is an enhancement of H.323 Resource Availability Indication mechanism (RAI) which is widely deployed in H.323 network for handling overload situation.  The draft mechanism is tested in our Lab and it is working fine for overloading of different resources like CPU, Memory, DSP, DS0. The proposed mechanism works well in case server has capability to handle audio & video and audio only call simultaneously. Could you please consider this draft for the above requirement. 

Thanks
Partha
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Volker Hilt
Sent: Tuesday, April 27, 2010 1:51 AM
To: NOEL, ERIC C (ATTLABS)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dispatch] [sip-overload] Proposed SIP Overload Control Charter

Eric,
>      ==>  Would like feedback on questions prior agreeing on May 2011 deadline.
The charter lays out milestones for items the proposed working group should produce. It is up to the WG to evaluate the drafts that have been proposed and adopt drafts that meet these milestones. The drafts you mention are candidates. They may or may not be adopted by the WG.

> list? Have regular sub-teams meeting (via conference calls)?
All discussions will happen on the sip-overload mailing list and all comments need to go to this list. We may use conference calls for specific topics if needed. If there is a need, calls will be announced on the mailing list.

Thanks,

Volker

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
>> Envoyé : mercredi 21 avril 2010 17:29 À : Robert Sparks Cc : Volker 
>> Hilt; DISPATCH; [email-masked]; Gonzalo Camarillo; Lars Eggert

---

From: Volker Hilt <[email-masked]>
Date: Tue, 27 Apr 2010 15:12:22 -0400

Partha,

please feel encouraged to submit your draft for consideration to the wg 
once it is chartered!

Thanks,

Volker