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

[RahulSrivastava 71616 <[e-mail]>]

SIP + RTP is just one usecase and I don't think it can be easily found it what caused overload very easily in the automata.
Only overload can be detected.

Hence I agree whatever be the cause if the overload exists apply the overload. It doesn't matter what was the reason.

Regards,
Rahul


******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: "Parthasarathi R (partr)" <[e-mail]>
Date: Tuesday, August 31, 2010 7:59 am
Subject: Re: [MEDIACTRL] [sip-overload] WGLC: draft-ietf-soc-overload-design
To: Volker Hilt <[e-mail]>
Cc: "Paul Kyzivat (pkyzivat)" <[e-mail]>, "Paul Jones (paulej)" <[e-mail]>, [e-mail], [e-mail]

> Volker,
> 
> In case you think that SIP overload control algorithm includes the 
> other loads in the signaling plane then the current algorithms 
> mentioned in the design document is not sufficient. In IETF-78 SoC 
> interim meeting, SIP-overload design experiments slides mentioned 
> that media congestion is not part of the experiment. 
> 
> SIP is the control protocol for RTP traffic. There is no need of 
> separate overload control for RTP in case SIP overload control 
> algorithm is designed for Media load as well. The access control 
> mentioned by you has to be considered as "local overload control" 
> which is not suffice as per the current SIP overload design as 
> well as in the reality. 
> 
> Even I discussed about different RTP load in IETF-78 SoC as part 
> of draft-partha-soc-overload-resource-availability-00 
> presentation. I'll explain again here:
> 
> B2BUA with address hiding service (SBC), memory requirements vary 
> for different types of call as indicated below
> 
> SIP Audio (RTP) call - 0.2%
> SIP Video (RTP) call - 1%
> SIP telepresence (RTP) call - 10%
> 
> The memory of SIP and RTP shall be shared across. RTP load varies 
> depends upon the negotiated codec during the call. The incoming 
> SIP INVITE message acceptance depends upon the dialog(call)-hold 
> time as well as negotiated codec. There is no relationship between 
> the number of SIP messages and the system load in case of SIP 
> media servers. I'm sure that the above problem is not addressed as 
> part of the current design. Please explain me in case the current 
> algorithms solve the above mentioned problem.
> 
> I could not visualize that media congestion is not part of SIP 
> overload design (document) till I'm attending IETF-78 interim 
> meeting. Please add the explicit text in the SIP overload design 
> document that Congestion collapse in SIP server due to other load 
> is outside scope of the document. The text will surely help other 
> implementers like me.
> 
> Thanks
> Partha 
> ________________________________
> 
> From: Volker Hilt [mailto:[e-mail]]
> Sent: Mon 8/30/2010 8:28 PM
> To: Parthasarathi R (partr)
> Cc: Janet P Gunn; [e-mail]; Paul Jones (paulej); sip-
> [e-mail]: Re: [sip-overload] WGLC: draft-ietf-soc-
> overload-design
> 
> 
> 
> 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 
> performaccess 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]>, "sip-
> [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
> >
> >
> 
> 
>