Re: [MEDIACTRL] FW: [dispatch] SIP based Media overload control draft

"MUNSON, GARY A (ATTSI)" <gm3472@att.com> Wed, 09 February 2011 00:08 UTC

Return-Path: <gm3472@att.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 28A433A68DF for <mediactrl@core3.amsl.com>; Tue, 8 Feb 2011 16:08:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 fKa0FTzLiOrJ for <mediactrl@core3.amsl.com>; Tue, 8 Feb 2011 16:08:23 -0800 (PST)
Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 59D133A68B1 for <mediactrl@ietf.org>; Tue, 8 Feb 2011 16:08:23 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: gm3472@att.com
X-Msg-Ref: server-13.tower-167.messagelabs.com!1297210110!39308769!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [144.160.20.146]
Received: (qmail 5740 invoked from network); 9 Feb 2011 00:08:30 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-13.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Feb 2011 00:08:30 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p1907YhK014825 for <mediactrl@ietf.org>; Tue, 8 Feb 2011 19:07:36 -0500
Received: from gaalpa1msgusr7b.ugd.att.com (gaalpa1msgusr7b.ugd.att.com [135.53.26.16]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p1907Uo5014481 for <mediactrl@ietf.org>; Tue, 8 Feb 2011 19:07:30 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 8 Feb 2011 19:08:23 -0500
Message-ID: <2F41EF28ED42A5489E41742244C9117C038A73BA@gaalpa1msgusr7b.ugd.att.com>
In-Reply-To: <A11921905DA1564D9BCF64A6430A623904594D38@XMB-BGL-411.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MEDIACTRL] FW: [dispatch] SIP based Media overload control draft
Thread-Index: Acu7+lyOL6q/0agWRuinGl+8LnohWAAACHagABtidVAAA6oooAAFAN1AAYvtnVAAJY1L4AEjHFaw
References: <A11921905DA1564D9BCF64A6430A623904594D38@XMB-BGL-411.cisco.com>
From: "MUNSON, GARY A (ATTSI)" <gm3472@att.com>
To: "Parthasarathi R (partr)" <partr@cisco.com>, <mediactrl@ietf.org>
Subject: Re: [MEDIACTRL] FW: [dispatch] SIP based Media overload control draft
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: Wed, 09 Feb 2011 00:08:25 -0000

Hi Partha,

I'll offer a partial answer.

The MRB context is looking at the endpoint type of 'media servers' -
i.e., for IVR or conferencing, and not other types of 'media servers'
such as a PSTN Gateway or SBC.

MRB should address the overload issue for such MSes to some extent by
keeping them out of overload. In some fashion (through information
received over the Publish interface from MSes and/or keeping track of
what MS resources have been assigned to AS requests) MRB can be aware of
the loads on MSes, and accordingly not send calls to MSes that might be
nearing an overload condition. A good MRB implementation should keep the
MSes away from overload. What happens if that's not the case hasn't been
much discussed, as far as I know.

BR,

Gary



-----Original Message-----
From: mediactrl-bounces@ietf.org [mailto:mediactrl-bounces@ietf.org] On
Behalf Of Parthasarathi R (partr)
Sent: Thursday, February 03, 2011 12:51 AM
To: mediactrl@ietf.org
Subject: [MEDIACTRL] FW: [dispatch] SIP based Media overload control
draft

Hi all,

draft-partha-dispatch-sip-media-overload-control-00
(http://tools.ietf.org/search/draft-partha-dispatch-sip-media-overload-c
ontrol-00) is created to define the problem statement for SIP based
Media overload control. AFAIK, Media Resource Broker (MRB) in mediactrl
does not solve this issue. Please let me know in case my understanding
is wrong. 

I'm interested in hearing from you whether this problem has to be solved
in mediactrl if it is not solved already. Also, Please provide any
specific usecase related to mediactrl.

I forward the earlier mail thread on dispatch to provide more context.

Thanks
Partha

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Parthasarathi R (partr)
Sent: Wednesday, February 02, 2011 3:01 PM
To: DRAGE, Keith (Keith); Elwell, John; dispatch@ietf.org;
dworley@avaya.com
Subject: Re: [dispatch] SIP based Media overload control draft

Keith/John/Dale,

Mediactrl (MRB) discusses about Resource monitoring at media server and
currently, there is no mechanism exists for overload control. I attached
SoC WG stance on SIP based Media overload control as a note of this
mail.

As a follow up query, Please let me know your take on whether SIP based
media overload has to be  solved as part of 

1) Mediactrl WG
2) Any other WG exists. If so, Please name it.
3) New WG has to be created.
4) solve as individual draft.
5) or any other IETF way

Thanks in advance
Partha

Note: Sec 1 of draft-ietf-soc-overload-design-04

There are cases in which a SIP server runs other services that do not
   involve the processing of SIP messages (e.g., processing of RTP
   packets, database queries, software updates and event handling).
   These services may, or may not, be correlated with the SIP message
   volume.  These services can use up a substantial share of resources
   available on the server (e.g., CPU cycles) and leave the server in a
   condition where it is unable to process all incoming SIP requests.

-----Original Message-----
From: Parthasarathi R (partr)
Sent: Tuesday, January 25, 2011 6:23 PM
To: 'DRAGE, Keith (Keith)'; Elwell, John; dispatch@ietf.org
Cc: 'dworley@avaya.com'
Subject: RE: SIP based Media overload control draft

 
Keith,

AFAIK, the mentioned issue is not solved in MRB. Including Dale Worley
(Mediactrl WG Chair) in this mail thread to double confirm my
understanding.

Apart from the Mediactrl Mediaservers, I'm trying to find the solution
for devices which acts as both Application server(AS) and Media Server
(MS) at the same time. In the deployment, these devices shall be
realized as PSTN GW, SBC, IP PBX with media handling. 

Thanks
Partha

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]
Sent: Tuesday, January 25, 2011 3:31 PM
To: Elwell, John; Parthasarathi R (partr); dispatch@ietf.org
Subject: RE: SIP based Media overload control draft

If they are mediaservers, then does not the media resource broker in
mediactrl already address this issue.

Regards

Keith

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Elwell, John
Sent: 25 January 2011 08:28
To: Parthasarathi R (partr); dispatch@ietf.org
Subject: Re: [dispatch] SIP based Media overload control draft

Partha,

A fundamental difference between the problem addressed by SOC and the
problem stated in your draft is as follows. SOC addresses the problem
where a SIP server is so overloaded that receipt of further SIP requests
will compound the problem, and therefore it is essential to take steps
to reduce the number of SIP requests arriving at the overloaded server.
The problem described in your draft is where the server is not
overloaded in the sense of being unable to handle further SIP requests,
but is overloaded in terms of media it can handle. Therefore it can
still receive SIP requests, but it would have to reject some of them if
the necessary media resources are not available.

There may still be some benefit in preventing SIP requests arriving if
media resources are not available. The main benefit would be that those
SIP requests can more quickly be rerouted elsewhere, thereby reducing
call set-up time. One scenario that might benefit would be where there
are several, perhaps 10 or more, candidate media servers for a
particular request, and trying each of these in turn would definitely
impact call establishment times (or call rejection times on occasions
when all candidates are overloaded). Is this the essence of the problem
you are trying to address? It seems the document could certainly do with
more on use cases and potential benefits that a solution might bring.

John


> -----Original Message-----
> From: dispatch-bounces@ietf.org
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Parthasarathi R
> (partr)
> Sent: 24 January 2011 19:38
> To: dispatch@ietf.org
> Subject: [dispatch] SIP based Media overload control draft
> 
> Hi all,
> 
> IETF SoC WG is created for overload control solution of dedicated SIP 
> signaling server only. There is an another kind of SIP servers exists 
> in SIP deployment which handle SIP signaling and its related media 
> (RTP,
> T.38) in the same physical device. Those servers needs separate SIP 
> based overload control solution. SIP based Media overload control 
> draft summarizes problem specific to SIP media servers overload, 
> requirements for SIP based media overload control solution and the 
> draft is available at
> 
> http://datatracker.ietf.org/doc/draft-partha-dispatch-sip-medi
> a-overload
> -control/
> 
> draft-partha-dispatch-resource-availability-00 and 
> draft-jones-sip-overload-sce-00 are submitted in IETF-78 SoC WG for 
> addressing the same problem. But, SIP based media overload control is 
> considered as outside the scope of SoC WG. I'm interested in hearing 
> from you whether this is a worth solving problem in IETF.
> 
> This draft is in straw-horse proposal state. I post this draft in 
> dispatch to identify which WG is right place to solve this issue in 
> IETF in case it is considered as worth solving problem.
> 
> Thanks
> Partha
> 
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
> Sent: Tuesday, January 25, 2011 12:37 AM
> To: Parthasarathi R (partr)
> Subject: New Version Notification for
> draft-partha-dispatch-sip-media-overload-control-00
> 
> 
> A new version of I-D,
> draft-partha-dispatch-sip-media-overload-control-00.txt has been 
> successfully submitted by Parthasarathi R and posted to the IETF 
> repository.
> 
> Filename:	 draft-partha-dispatch-sip-media-overload-control
> Revision:	 00
> Title:		 Session Initiation Protocol (SIP) 
> based Media overload
> control Requirement
> Creation_date:	 2011-01-24
> WG ID:		 Independent Submission
> Number_of_pages: 6
> 
> Abstract:
> Overload occurs in Session Initiation Protocol (SIP) networks when SIP

> servers have insufficient resources to handle all SIP messages they 
> receive.  SIP based overload mechanism exists for dedicated SIP 
> signaling servers.  But there is a need for overload control solution 
> of SIP based media servers like PSTN GW, Session border controllers 
> (SBC), Session Recording Server(SRS).  This document summarizes 
> problem specific to SIP media servers, requirements for the solution 
> of SIP based media overload control.
>  
> 
> 
> 
> The IETF Secretariat.
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl