RE: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery

So the requirement is to get damped versus undamped oscillations.

Mike 

> -----Original Message-----
> From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] 
> Sent: Wednesday, November 08, 2006 5:42 PM
> To: Volker Hilt; Cullen Jennings (fluffy)
> Cc: sipping
> Subject: RE: [Sipping] Re: 
> draft-rosenberg-sipping-overload-reqs recovery
> 
> 
> Volker wrote:
> > I think that stability of overload control is an important
> requirement.
> > We certainly want to avoid building something that starts 
> to oscillate 
> > once it reaches overload state.
> 
> Oscillations are often unavoidable in overload conditions, 
> it's the characterization of these oscillations (amplitude, 
> duration, frequency,
> ...)  that may lead to instability.
> 
> 
> Cullen wrote:
> > >>> A possible additional requirement....
> > >>> Imagine a system (perhaps a single proxy) that could do 
> 100cps. It 
> > >>> is  in steady state doing 80cps with very few 
> retransmission. Then 
> > >>> for 5  minutes the incoming requests goes to 500cps then drops
> > back
> > >>> to an  incoming call rate of 80cps. The question is, how long
> > before
> > >>> the  system gets back to the state where it if is successfully 
> > >>> processing  all the 80cps?
> 
> Volker added:
> > It may be somehow implicit to REQ 1
> > since an unstable system will hardly be able to maintain 
> the overall 
> > useful throughput at a high level.
> 
> Following in Cullen's example, I interpret requirement #1 to 
> mean: out of the 500 cps, the system under load should pick 
> up the *useful* transactions to keep the using applications happy.
> 
> May be a way to help formulate Cullen's example is to 
> introduce some wording or requirements around oscillations or 
> the characteristics of the overload, and say something around 
> the recovery time like:
> the overload control mechanism should help predict the time a 
> system will take to recover based on the characterization of 
> the overload?
> 
> Jean-Francois.
> 
> > -----Original Message-----
> > From: Volker Hilt [mailto:volkerh@bell-labs.com]
> > Sent: Wednesday, November 08, 2006 9:18 AM
> > To: Cullen Jennings
> > Cc: sipping
> > Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs
> > recovery
> > 
> > I think that stability of overload control is an important
> requirement.
> > We certainly want to avoid building something that starts 
> to oscillate 
> > once it reaches overload state. It may be somehow implicit to REQ 1 
> > since an unstable system will hardly be able to maintain 
> the overall 
> > useful throughput at a high level.
> > 
> > Volker
> > 
> > 
> > 
> > Cullen Jennings wrote:
> > > Clearly this was a long way from the text for a requirement but,
> yes,
> > I
> > > was proposing that this be added as one of the 
> requirements. I don't 
> > > feel strongly about this and if we can't figure out how to express
> > this
> > > as a requirement that is useful, I can certainly live with not
> > adding it.
> > >
> > > The reason I think it is a requirement is I can easily 
> imagine that
> > the
> > > mechanism for doing overload push-back causes the systems 
> to fail in
> > the
> > > way I described below (i.e. never recover back to steady state).
> > >
> > >
> > > On Nov 6, 2006, at 11:17 AM, Jonathan Rosenberg wrote:
> > >
> > >>
> > >>
> > >> Cullen Jennings wrote:
> > >>
> > >>> A possible additional requirement....
> > >>> Imagine a system (perhaps a single proxy) that could do 
> 100cps. It 
> > >>> is  in steady state doing 80cps with very few 
> retransmission. Then 
> > >>> for 5  minutes the incoming requests goes to 500cps then drops
> > back
> > >>> to an  incoming call rate of 80cps. The question is, how long
> > before
> > >>> the  system gets back to the state where it if is successfully 
> > >>> processing  all the 80cps?
> > >>
> > >> As soon as it can. Are you suggesting a requirement here? Seems
> > like
> > >> this is an implementation thing and wouldn't impact any protocol 
> > >> mechanisms.
> > >>
> > >>> I have seen systems that never recover - that is bad. I 
> think one
> > of
> > >>> the design goals is that it is at least possible to build to
> > systems
> > >>> that recover back to steady state relatively quickly after an 
> > >>> overload impulse.
> > >>
> > >> Sure; but I'm not sure I see the protocol requirement.
> > >>
> > >> -Jonathan R.
> > >>
> > >>
> > >>
> > >> --Jonathan D. Rosenberg, Ph.D.                   600 
> Lanidex Plaza
> > >> Cisco Fellow                                   Parsippany, NJ
> > 07054-2711
> > >> Cisco Systems
> > >> jdrosen@cisco.com                              FAX:   (973) 952-
> > 5050
> > >> http://www.jdrosen.net                         PHONE: (973) 952-
> > 5000
> > >> http://www.cisco.com
> > >
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP Use 
> > > sip-implementors@cs.columbia.edu for questions on current sip Use 
> > > sip@ietf.org for new developments of core SIP
> > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP Use 
> > sip-implementors@cs.columbia.edu for questions on current sip Use 
> > sip@ietf.org for new developments of core SIP
> 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP 
> Use sip-implementors@cs.columbia.edu for questions on current 
> sip Use sip@ietf.org for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP