Volker Hilt <volkerh@bell-labs.com> · 01/15/2010 09:47 AM

Gonzalo,

it would be great to understand what the specific concerns are.

We had a design team working on simulations on SIP overload control for

a substantial period of time. The group has produced many results and 

has published these results at scientific conferences and status reports

to the IETF. Some of the drafts have been implemented and tested in 

prototypes or products by multiple vendors. What else is needed?

I'm worried that we are taking yet another detour which will further 

delay the process.

Volker

Gonzalo Camarillo wrote:

> Folks,

> 

> as you know, we agreed to charter the SIP overload work a while ago.

> Below you can find the proposed charter.

> 

> We have gotten some comments back from the IESG. There are some concerns

> about the effects of the proposed solutions in real networks. It seems

> that those concerns would disappear if we chartered the WG to develop

> Experimental proposals, at least at the beginning. Those proposals
would 

> be able to eventually move to the standards track once we got 

> operational experience with them. Comments?

> 

> Thanks,

> 

> Gonzalo

> 

> 

> 

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

> 

> 

> _______________________________________________

> dispatch mailing list

> dispatch@ietf.org

> 
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________

sip-overload mailing list

sip-overload@ietf.org

https://www.ietf.org/mailman/listinfo/sip-overload

sip-overload-bounces@ietf.org wrote on 01/15/2010
10:34:12 AM:

> [image removed] 
> 

> Re: [sip-overload] [dispatch] Chartering SIP Overload
> 

> Robert Sparks 
> 

> to:
> 

> Volker Hilt
> 

> 01/15/2010 10:41 AM
> 

> Sent by:
> 

> sip-overload-bounces@ietf.org
> 

> Cc:
> 

> DISPATCH, sip-overload, Gonzalo Camarillo, Lars Eggert
> 

> (Copying Lars - please preserve him on the CC for this thread).

> 

> The big concern, as I understand it, is that the state of what the

> team's explored so far

> reduces the degradation of throughput as load increases, but still

> eventually collapses.

> Is that accurate? (I might have missed something the team's done that

> manages to converge

> to a stable point.)

> 

> RjS

> 

> 

> On Jan 15, 2010, at 9:08 AM, Volker Hilt wrote:

> 

> > Gonzalo,

> >>> I'm worried that we are taking yet another detour which
will  

> >>> further delay the process.

> >> this would not delay the process in any way. If something,
it could  

> >> speed it up, because the requirements to review Experimental
RFCs  

> >> are lower than to review standards track RFCs... at the end
of the  

> >> day, I do not expect this to influence the time it takes
to publish  

> >> the specs because I am sure the group will make sure the
quality of  

> >> the specs as high as for a standards-track RFC.

> > I'd like to understand the concerns that lead to the proposal
of  

> > putting this work through the experimental track.

> >

> > What are we missing that prevents us from creating a standards
track  

> > document?

> >

> > Volker

> >

> >

> >

> > _______________________________________________

> > dispatch mailing list

> > dispatch@ietf.org

> > 
https://www.ietf.org/mailman/listinfo/dispatch

> 

> _______________________________________________

> sip-overload mailing list

> sip-overload@ietf.org

> 
https://www.ietf.org/mailman/listinfo/sip-overload

From:	Volker Hilt <volkerh@bell-labs.com>
To:	Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Cc:	DISPATCH <dispatch@ietf.org>, "sip-overload@ietf.org" <sip-overload@ietf.org>
Date:	01/15/2010 09:47 AM
Subject:	Re: [sip-overload] [dispatch] Chartering SIP Overload