Subject: Re: [sip-overload] Charter Proposal for SIP Overload

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Wed, 22 Jul 2009 16:54:42 -0400

This application overload, so your point is?

________________________________

From: [email-masked] <[email-masked]> 
To: Volker Hilt <[email-masked]>; SIP-OVERLOAD <[email-masked]> 
Sent: Wed Jul 22 12:36:12 2009
Subject: Re: [sip-overload] Charter Proposal for SIP Overload 

Volker,

Two tweaks indicated below.

While the requirements have been defined, is it documented anywhere why existing mechanisms (such as TCP, ECN, etc.) are insufficient?  If not, I would propose a deliverable of such a doc - e.g. an informational RFC.

Br,

Tim Moran

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Volker Hilt
Sent: Tuesday, July 21, 2009 7:46 PM
To: SIP-OVERLOAD
Subject: [sip-overload] Charter Proposal for SIP Overload

All,

below is a charter proposal for a WG on SIP Overload Control.

All comments, thoughts, feedback is very welcome!

Thanks,

Volker

SIP Overload Control WG Charter

-------------------------------

As with any network element, a Session Initiation Protocol (SIP)

[RFC3261] 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 a small fraction of the original

processing capacity.  This is often called congestion collapse.

To objective of a SIP overload control mechanism is to enable SIP

[tlm->] Suggest Changing "To" to "The"

servers to perform 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 prevent overload of a SIP server

and it cannot prevent congestion collapse.  In fact, it may cause

traffic to oscillate and to 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. 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

[tlm->] Suggest Changing determine to indicate

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

---

From: Volker Hilt <[email-masked]>
Date: Wed, 22 Jul 2009 17:40:23 -0400

Tim,

there has been work on SIP overload when TCP is used as transport and 
results have been published - among others in papers that are listed in 
the references section of the design considerations draft.

> I do not make the assumption that the application is 100% independent of 
> the lower (e.g. network and transport) layers.  If there are CPU or 
> memory issues – would this not result in congestion at the destination 
> node and thus invoke flow control at the lower layers? What are the 
> cases where the lower layers do not/can not control the congestion?
> 
Flow control would stop all incoming messages over a TCP link. I.e., you 
would not only stop receiving new INVITEs - you would also stop 
receiving 180s, 200 OKs, etc. for existing transactions where the INVITE 
was already processed. This will cause these transactions to fail as well.

> That said, I am of the view we need this work (even wrote a contribution 
> at one point), but I want to make sure there is a proper understanding 
> of how it fits in the grand scheme of things (congestion control 
> mechanisms).  I believe there was some discussion on this on the mailing 
> list some time ago.  Documenting the results of that discussion may save 
> some time and effort later.
> 
Your point is well taken. We did summarize this discussion in the design 
considerations document. Section 2 and 5 should cover some of the points 
discussed.

Thanks,

Volker

> ------------------------------------------------------------------------
> 
> *From:* DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]]
> *Sent:* Wednesday, July 22, 2009 4:55 PM
> *To:* Moran, Timothy L.; [email-masked]; 
> [email-masked]; [email-masked]
> *Subject:* Re: [sip-overload] Charter Proposal for SIP Overload
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From*: [email-masked] <[email-masked]>
> *To*: Volker Hilt <[email-masked]>; SIP-OVERLOAD 
> <[email-masked]>
> *Sent*: Wed Jul 22 12:36:12 2009
> *Subject*: Re: [sip-overload] Charter Proposal for SIP Overload
> 
> Volker,
> 
> While the requirements have been defined, is it documented anywhere why 
> existing mechanisms (such as TCP, ECN, etc.) are insufficient?  If not, 
> I would propose a deliverable of such a doc - e.g. an informational RFC.
> 
> Br,
> 
> Tim Moran
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Volker Hilt

---

From: "Moran, Timothy L." <[email-masked]>
Date: Wed, 22 Jul 2009 17:24:21 -0400

memory issues - would this not result in congestion at the destination

Br,

Tim M.

From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]] 
Sent: Wednesday, July 22, 2009 4:55 PM
To: Moran, Timothy L.; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [sip-overload] Charter Proposal for SIP Overload

From: [email-masked] <[email-masked]> 
To: Volker Hilt <[email-masked]>; SIP-OVERLOAD
<[email-masked]> 
Sent: Wed Jul 22 12:36:12 2009
Subject: Re: [sip-overload] Charter Proposal for SIP Overload 

Volker,

Br,

Tim Moran

-----Original Message-----

All,

Thanks,

Volker

servers to perform close to their capacity limit during times of
overload.

overload situations:

deliverables:

control mechanism.

[email-masked]

---

From: "Moran, Timothy L." <[email-masked]>
Date: Thu, 23 Jul 2009 16:32:44 -0400

Volker - Thanks for the reference.  The ability of the application layer
to better manage what messages are controlled is a real winner (IMHO).
I went back and looked at sections 2 and 5 - but afraid I didn't see
that mentioned anywhere. I'll look for it in future versions,

Br,
Tim M.

-----Original Message-----
From: Volker Hilt [mailto:[email-masked]] 
Sent: Wednesday, July 22, 2009 5:40 PM
To: Moran, Timothy L.
Cc: DOLLY, MARTIN C, ATTLABS; [email-masked];
[email-masked]

Tim,

was already processed. This will cause these transactions to fail as
well.

discussed.

Thanks,

Volker

overload.