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

Janet P Gunn <jgunn6@csc.com> Mon, 30 August 2010 11:14 UTC

Return-Path: <jgunn6@csc.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 B1DA73A682E; Mon, 30 Aug 2010 04:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.41
X-Spam-Level:
X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 9YHUR1q8u6KE; Mon, 30 Aug 2010 04:13:59 -0700 (PDT)
Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by core3.amsl.com (Postfix) with ESMTP id 100063A6403; Mon, 30 Aug 2010 04:13:58 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-7.tower-164.messagelabs.com!1283166867!10911121!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [20.137.2.87]
Received: (qmail 27990 invoked from network); 30 Aug 2010 11:14:28 -0000
Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-7.tower-164.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Aug 2010 11:14:28 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id o7UBER7o010022; Mon, 30 Aug 2010 07:14:27 -0400
In-Reply-To: <A11921905DA1564D9BCF64A6430A623903054F93@XMB-BGL-411.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>
To: "Parthasarathi R (partr)" <partr@cisco.com>
MIME-Version: 1.0
X-KeepSent: 745EE267:B1FB9FFE-8525778F:003D820A; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009
From: Janet P Gunn <jgunn6@csc.com>
Message-ID: <OF745EE267.B1FB9FFE-ON8525778F.003D820A-8525778F.003DBF89@csc.com>
Date: Mon, 30 Aug 2010 07:14:25 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.1FP1 HF440|June 18, 2010) at 08/30/2010 07:14:44 AM, Serialize complete at 08/30/2010 07:14:44 AM
Content-Type: multipart/alternative; boundary="=_alternative 003DBE518525778F_="
Cc: Volker Hilt <volker.hilt@alcatel-lucent.com>, "Paul Jones \(paulej\)" <paulej@cisco.com>, sip-overload@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 11:14:01 -0000

Well, there IS already text in the document,  but it could be made 
stronger.

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:
"Parthasarathi R (partr)" <partr@cisco.com>
To:
Janet P Gunn/USA/CSC@CSC, "Volker Hilt" <volker.hilt@alcatel-lucent.com>
Cc:
<mediactrl@ietf.org>, "Paul Jones (paulej)" <paulej@cisco.com>, 
<sip-overload@ietf.org>
Date:
08/30/2010 01:42 AM
Subject:
RE: [sip-overload] WGLC: draft-ietf-soc-overload-design



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