Subject: [dispatch] SIP based Media overload control draft

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 25 Jan 2011 01:07:40 +0530

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-media-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:[email-masked]] 
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.

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 25 Jan 2011 09:28:00 +0100

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Parthasarathi 
> R (partr)
> Sent: 24 January 2011 19:38
> To: [email-masked]
> Subject: [dispatch] SIP based Media overload control draft
> 
> Hi all,
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 25 Jan 2011 11:01:11 +0100

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

Regards

Keith

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

Partha,

John

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 25 Jan 2011 11:13:35 +0100

Probably. I am trying to tease out the real problem that Partha is trying to solve, but it does seem likely that MRB would address it.

John

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: 25 January 2011 10:01
> To: Elwell, John; Parthasarathi R (partr); [email-masked]
> 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
> 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> 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
> 
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 25 Jan 2011 17:53:13 +0530

John,

Thanks for your comments. Please read inline.

Thanks
Partha 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Tuesday, January 25, 2011 1:58 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: 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,

<Partha> Server may not be overloaded in few scenarios like DSO or DSP
is exhausted. There are other set of Server which may be (CPU/Memory)
overloaded in case SIP and RTP uses same CPU/Memory. For simplicity, Let
us take Address hiding server which hides the address in both SIP
signaling and RTP packet. There is no DSP or other resources involved in
this server. When the overload occurs in the device, SIP signaling may
not be able to process further request and it may also impact media
(RTP) as well. Here, current SoC solution will not work for these sort
of devices. Please correct me in case you have other opinion here.
</partha>   

 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? 
<partha> As you mentioned, Load balancing the collection of media server
will see tremendous performance improvement with the proper media
overload control mechanism. The solution shall be extended to
multisource and mesh networks as well</Partha>

It seems the document could certainly do with more on use cases and
potential benefits that a solution might bring.
<Partha> I'll add more usecase and its benefits in -01 version of the
draft </partha>

John

> [mailto:[email-masked]] On Behalf Of Parthasarathi R 
> (partr)
> signaling server only. There is an another kind of SIP servers exists 
> in SIP deployment which handle SIP signaling and its related media 
> (RTP,
> 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
> 
> 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
> 

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

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 25 Jan 2011 18:22:47 +0530

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:[email-masked]] 
Sent: Tuesday, January 25, 2011 3:31 PM
To: Elwell, John; Parthasarathi R (partr); [email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
Sent: 25 January 2011 08:28
To: Parthasarathi R (partr); [email-masked]
Subject: Re: [dispatch] SIP based Media overload control draft

Partha,

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