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

[Volker Hilt <[e-mail]>]

Partha,

if other load causes a congestion collapse on the SIP signaling plane of 
a server, it is within the scope of an overload control algorithm. 
Whenever a SIP server runs out of resources to process incoming SIP 
messages, it needs to take action to make sure it is not encountering a 
SIP congestion collapse.

It may use other mechanisms or intelligent design choices to control the 
load generated by other processes on a SIP server. E.g., it may perform 
access control for admitting audio streams for processing, use overload 
control mechanism for other protocols, give less priority to other 
processes (e.g., a virus scanner), etc.

Thanks,

Volker





On 8/30/2010 1:42 AM, Parthasarathi R (partr) wrote:
> 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:[e-mail]]
> *Sent:* Monday, August 30, 2010 2:04 AM
> *To:* Volker Hilt
> *Cc:* [e-mail]; Parthasarathi R (partr); Paul Jones (paulej);
> [e-mail]; [e-mail]
> *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 <[e-mail]>
> To: 	"Parthasarathi R (partr)" <[e-mail]>
> Cc: 	"[e-mail]" <[e-mail]>, "[e-mail]"
> <[e-mail]>, "Paul Jones \(paulej\)" <[e-mail]>
> 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:[e-mail]]
>  > *Sent:* Sun 8/29/2010 11:43 PM
>  > *To:* Parthasarathi R (partr)
>  > *Cc:* Salvatore Loreto; [e-mail]
>  > *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:* [e-mail] on behalf of Salvatore Loreto
>  > > *Sent:* Mon 8/23/2010 4:54 AM
>  > > *To:* [e-mail]
>  > > *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
>  > > [e-mail]
>  > > https://www.ietf.org/mailman/listinfo/sip-overload
>  > >
>  >
> _______________________________________________
> sip-overload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload
>
>