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

"Parthasarathi R (partr)" <partr@cisco.com> Thu, 03 February 2011 05:48 UTC

Return-Path: <partr@cisco.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 3CA243A6875 for <mediactrl@core3.amsl.com>; Wed, 2 Feb 2011 21:48:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.201
X-Spam-Level:
X-Spam-Status: No, score=-10.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 h2uQO7EzJYVw for <mediactrl@core3.amsl.com>; Wed, 2 Feb 2011 21:47:59 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id EC6673A6874 for <mediactrl@ietf.org>; Wed, 2 Feb 2011 21:47:58 -0800 (PST)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlMBAIvRSU2Q/khNgWdsb2JhbACWS45kFQEBFiIkoHSbJoJ7glwEhHeKIA
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 03 Feb 2011 05:51:18 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p135pCIk030182 for <mediactrl@ietf.org>; Thu, 3 Feb 2011 05:51:19 GMT
Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 11:21:16 +0530
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: Thu, 03 Feb 2011 11:21:17 +0530
Message-ID: <A11921905DA1564D9BCF64A6430A623904594D38@XMB-BGL-411.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dispatch] SIP based Media overload control draft
Thread-Index: Acu7+lyOL6q/0agWRuinGl+8LnohWAAACHagABtidVAAA6oooAAFAN1AAYvtnVAAJY1L4A==
From: "Parthasarathi R (partr)" <partr@cisco.com>
To: mediactrl@ietf.org
X-OriginalArrivalTime: 03 Feb 2011 05:51:16.0323 (UTC) FILETIME=[5F4E2B30:01CBC366]
Subject: [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: Thu, 03 Feb 2011 05:48:01 -0000

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