Re: [MEDIACTRL] [sip-overload] WGLC: draft-ietf-soc-overload-design

Volker Hilt <volker.hilt@alcatel-lucent.com> Mon, 30 August 2010 14:58 UTC

Return-Path: <volker.hilt@alcatel-lucent.com>
X-Original-To: mediactrl@core3.amsl.com
Delivered-To: mediactrl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747713A6819; Mon, 30 Aug 2010 07:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXIH+o57AjCd; Mon, 30 Aug 2010 07:58:01 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id C40723A676A; Mon, 30 Aug 2010 07:58:01 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o7UEwUrP016031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Aug 2010 09:58:30 -0500 (CDT)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o7UEwUTW019601 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Aug 2010 09:58:30 -0500
Received: from [127.0.0.1] (135.3.63.242) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 30 Aug 2010 09:58:30 -0500
Message-ID: <4C7BC713.3010208@alcatel-lucent.com>
Date: Mon, 30 Aug 2010 10:58:27 -0400
From: Volker Hilt <volker.hilt@alcatel-lucent.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: "Parthasarathi R (partr)" <partr@cisco.com>
References: <4C71B1C3.6070805@ericsson.com> <A11921905DA1564D9BCF64A6430A62390293A4AF@XMB-BGL-411.cisco.com><4C7AA34D.4020000@alcatel-lucent.com> <A11921905DA1564D9BCF64A6430A62390293A4B0@XMB-BGL-411.cisco.com> <4C7AC02D.1000200@alcatel-lucent.com> <OF5FC5A3A1.0A30DB2F-ON8525778E.006FC85F-8525778E.0070FB2C@csc.com> <A11921905DA1564D9BCF64A6430A623903054F93@XMB-BGL-411.cisco.com>
In-Reply-To: <A11921905DA1564D9BCF64A6430A623903054F93@XMB-BGL-411.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
X-Mailman-Approved-At: Mon, 30 Aug 2010 14:43:34 -0700
Cc: "Paul Jones \(paulej\)" <paulej@cisco.com>, "sip-overload@ietf.org" <sip-overload@ietf.org>, "mediactrl@ietf.org" <mediactrl@ietf.org>
Subject: Re: [MEDIACTRL] [sip-overload] WGLC: draft-ietf-soc-overload-design
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Aug 2010 14:58:03 -0000

Partha,

if other load causes a congestion collapse on the SIP signaling plane of 
a server, it is within the scope of an overload control algorithm. 
Whenever a SIP server runs out of resources to process incoming SIP 
messages, it needs to take action to make sure it is not encountering a 
SIP congestion collapse.

It may use other mechanisms or intelligent design choices to control the 
load generated by other processes on a SIP server. E.g., it may perform 
access control for admitting audio streams for processing, use overload 
control mechanism for other protocols, give less priority to other 
processes (e.g., a virus scanner), etc.

Thanks,

Volker





On 8/30/2010 1:42 AM, Parthasarathi R (partr) wrote:
> My point is same as Janet's. I wish that SIP overload design document
> has to explicitly indicate about congestion collapse in SIP server due
> to other loads (like RTP message) is outside the scope of the document.
> Without this text in the document, the implementers of SIP servers with
> other load handling may be mislead.
> Thanks
> Partha
>
> ------------------------------------------------------------------------
> *From:* Janet P Gunn [mailto:jgunn6@csc.com]
> *Sent:* Monday, August 30, 2010 2:04 AM
> *To:* Volker Hilt
> *Cc:* mediactrl@ietf.org; Parthasarathi R (partr); Paul Jones (paulej);
> sip-overload@ietf.org; sip-overload-bounces@ietf.org
> *Subject:* Re: [sip-overload] WGLC: draft-ietf-soc-overload-design
>
>
> I guess the points are:
> 1- If a SIP actor is experiencing overload (regardless of whether the
> overload is due to "too many SIP messages" or something else entirely)
> it needs to reduce the rate at which SIP messages arrive at the SIP
> actor (the focus of this document).
> 2- If the overload is largely due to something other than SIP messages,
> then ONLY reducing the arrival of SIP messages may not significantly
> reduce the overload, and you may still have congestion collapse.
> 3- For devices which are SIP actors, and also serve other loads (e.g.
> RTP, database lookup, ISUP gateway), it is to be hoped that there is an
> overload control mechanism for each type of traffic, and that the
> mechanisms are coordinated in a sensible way (so that no one type of
> traffic is starved out by the others). But, other than a passing
> comment, that is out of scope for a document on SIP Overload Control.
>
> Janet
>
> This is a PRIVATE message. If you are not the intended recipient, please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery.
> NOTE: Regardless of content, this e-mail shall not operate to bind CSC
> to any order or other contract unless pursuant to explicit written
> agreement or government initiative expressly permitting the use of
> e-mail for such purpose.
>
>
> From: 	Volker Hilt <volker.hilt@alcatel-lucent.com>
> To: 	"Parthasarathi R (partr)" <partr@cisco.com>
> Cc: 	"mediactrl@ietf.org" <mediactrl@ietf.org>, "sip-overload@ietf.org"
> <sip-overload@ietf.org>, "Paul Jones \(paulej\)" <paulej@cisco.com>
> Date: 	08/29/2010 04:16 PM
> Subject: 	Re: [sip-overload] WGLC: draft-ietf-soc-overload-design
>
>
> ------------------------------------------------------------------------
>
>
>
> Partha,
>
> the CPU load of a SIP server can increase for many reasons, not only the
> processing of RTP packets. For example, the system might start the daily
> backup of a database, apply patches, run a virus scan or launch another
> application.
>
> If any of these events leads to a shortage of CPU cycles in which the
> SIP server may not be able to process all incoming SIP messages, it
> should use overload control to reduce the number of SIP messages.
>
> Thanks,
>
> Volker
>
>
>
>
> On 8/29/2010 4:06 PM, Parthasarathi R (partr) wrote:
>  > Volker,
>  > I doubt whether the current draft will serve for all SIP servers. I'm
>  > taking the example of B2BUA with media (RTP)topology hiding
>  > functionality and there is no DSP, DS0 or DISK resource involved. Here,
>  > Server experiences an overload of SIP message not just because of
>  > incoming SIP messages but also due to the incoming RTP messages and RTP
>  > messages flow varies depend upon the dialog (call) hold time whereas
>  > there may not any SIP message when the dialog is established. SIP
>  > processor mentioned in the system model of this draft may be shared the
>  > physical processor with RTP messages or other protocols messages. We
>  > have the problem in incorporating the current SIP overload design in
>  > media handling SIP devices.
>  > I'm including mediactrl to hear their experience with SIP overload
>  > design and mediactrl combined SIP implementation.
>  >
>  > Thanks
>  > Partha
>  > ------------------------------------------------------------------------
>  > *From:* Volker Hilt [mailto:volker.hilt@alcatel-lucent.com]
>  > *Sent:* Sun 8/29/2010 11:43 PM
>  > *To:* Parthasarathi R (partr)
>  > *Cc:* Salvatore Loreto; sip-overload@ietf.org
>  > *Subject:* Re: [sip-overload] WGLC: draft-ietf-soc-overload-design
>  >
>  > Partha,
>  >
>  > the design document discusses problems related to the overload of SIP
>  > messages. Any server that processes SIP messages can experience an
>  > overload of SIP messages. Therefore, the discussions in the draft apply
>  > to all servers that are involved in SIP message processing.
>  >
>  > SIP servers that also provide media handling services may need
>  > mechanisms to signal that they are out of trunk lines, DSP processors,
>  > storage capacity for voicmails, etc. These mechanisms will often be
>  > needed at times when the servers can still process SIP messages. These
>  > mechanisms are out of scope for the working group as discussed.
>  >
>  > Thanks,
>  >
>  > Volker
>  >
>  >
>  >
>  >
>  > On 8/29/2010 1:21 PM, Parthasarathi R (partr) wrote:
>  > > Sal/Volker,
>  > > The design document is designed for dedicated SIP signaling servers and
>  > > experiments are done based on the dedicated servers. The same
> design may
>  > > not scale for SIP server with media handling. As per IETF-78 meeting,
>  > > SIP servers with media handling
>  > > (draft-partha-soc-overload-resource-availability-00,
>  > > draft-jones-sip-overload-sce-00) is outside the scope of this working
>  > > group. I think that it is better to indicate the scope of this overload
>  > > design is for "dedicated SIP servers" only and does not include media
>  > > servers with SIP. Please let me know your opinion on the same.
>  > > Thanks
>  > > Partha
>  > >
> ------------------------------------------------------------------------
>  > > *From:* sip-overload-bounces@ietf.org on behalf of Salvatore Loreto
>  > > *Sent:* Mon 8/23/2010 4:54 AM
>  > > *To:* sip-overload@ietf.org
>  > > *Cc:* Volker Hilt
>  > > *Subject:* [sip-overload] WGLC: draft-ietf-soc-overload-design
>  > >
>  > > [as chair]
>  > >
>  > > the draft has been update to address all the concerns/suggestions that
>  > > have been raised during
>  > > the F2F meeting in Maastricht:
>  > >
>  > > http://tools.ietf.org/html/draft-ietf-soc-overload-design-01
>  > >
>  > >
>  > > the chairs believe the document has no remaining open issues, and is
>  > > ready for WG last call evaluation.
>  > >
>  > > Today we are starting a two-weeks working group last call.
>  > > This call end on September 5th.
>  > >
>  > > comments and especially full and deep reviews of the draft are really
>  > > appreciate.
>  > >
>  > >
>  > > cheers
>  > > Sal
>  > >
>  > > --
>  > > Salvatore Loreto
>  > > www.sloreto.com
>  > >
>  > > _______________________________________________
>  > > sip-overload mailing list
>  > > sip-overload@ietf.org
>  > > https://www.ietf.org/mailman/listinfo/sip-overload
>  > >
>  >
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
>
>