Subject: [siprec] FW: [dispatch] SIP based Media overload control draft

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 3 Feb 2011 10:53:55 +0530

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. SRS in SIPREC is a media server with disk
storage. I have included the usecase in the draft. I'm interested in
hearing from you in case you have more specific requirement to be solved
in this area. 

IMO, there is a need for generic SIP based media overload control.
Please provide your valuable comments.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Parthasarathi R (partr)
Sent: Wednesday, February 02, 2011 3:01 PM
To: DRAGE, Keith (Keith); Elwell, John; [email-masked];
[email-masked]
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; [email-masked]
Cc: [email-masked]'
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:[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,

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: [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,
> 
> 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:[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.
> 
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
> 
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 7 Feb 2011 15:49:51 -0800

Hi Partha,

Thanks for putting this draft together. I gave it a read and I can
appreciate the point you are making regarding servers that handle SIP
signaling and media (media servers) potentially having unique overload
requirements to those that handle signaling only. You mention two
initial concerns, 488 and 503.
For 488, it seems worthwhile in general to try another media server. Is
the point you are making that for 488 for a session requesting 10 Mbps
of bandwidth may need to be treated differently than a 488 for a session
requesting 100 kbps of bandwidth? I think signaling servers might well
make similar decisions based on analysis of the SDP signaling.
For 503, it seems to be handled by RFC 5390. Is there something specific
about media servers that you think needs to be addressed?

Thanks,
Charles

> From: [email-masked] [mailto:[email-masked]] On
> Sent: Wednesday, February 02, 2011 9:24 PM
> To: [email-masked]
> Subject: [siprec] FW: [dispatch] SIP based Media overload control
draft
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 9 Feb 2011 10:46:43 +0530

Hi Charles,

Thanks for looking into the draft. 

As you mentioned, 488 response shall be used for redirection to
alternate server but the open questions are

1) Whether forthcoming new request has to be sent to the first server or
to the alternate server.
   A) In case of first server is selected for all the forthcoming
request, downstream will  reply with 488 response till overload is over.
Forthcoming request will put load in the first server for creating
negative response. In case of load balance scenario with
1:75(upstream:downstream) topology, 488 is not appropriate as it leads
to multiple redirection (488) from upstream. The feedback from the
downstream is more appropriate compare to 488 with warning-code 307. I'm
making the point that 488 has to be considered as last resort and there
is a need for feedback mechanism from downstream.
   B) In case alternate server is selected for all the forthcoming
request, there is a need of feedback from first server to indicate that
the overload is over and the server is ready for processing more
request.

Based your comments, I'll add more text in the draft for better clarity
between 488 vs feedback. Please let me know in case you have other
opinion here.

2) Limitation of 503 response in RFC 5390 are taken care by
draft-ietf-soc-overload-design but SoC design is based on number of SIP
message only. This is not well suited for all types of media servers.
For example: Media servers share CPU/Memory for Media and SIP signaling,
503 response *MAY* be due to excess of media handling rather than
signaling.

3) As you mentioned, Upstream server *SHALL* be signaling server or
application server which takes informed decision based on the received
SDP feedback (10 Mbps or 100 Kbps).

Thanks
Partha

-----Original Message-----
From: Charles Eckel (eckelcu) 
Sent: Tuesday, February 08, 2011 5:20 AM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [siprec] FW: [dispatch] SIP based Media overload control
draft

Hi Partha,

Thanks,
Charles

> hearing from you in case you have more specific requirement to be 
> solved in this area.
> 
> 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

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

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