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

["Michael Hammer \(mhammer\)" <[e-mail]>]

I would prefer to damp them than to keep the oscillation going, i.e.
stable.

Mike 

> -----Original Message-----
> From: Janet P Gunn [mailto:[e-mail]] 
> Sent: Wednesday, November 08, 2006 5:54 PM
> To: Jean-Francois Mule
> Cc: Cullen Jennings (fluffy); Volker Hilt; sipping
> Subject: RE: [Sipping] Re: 
> draft-rosenberg-sipping-overload-reqs recovery
> 
> 
> 
> 
> 
> 
> 
> 
> I think it is ineveitable that the overload control system 
> WILL oscillate.
> The thing is to make sure it is STABLE oscillation, not UNSTABLE.
> 
> Janet
> 
> "Jean-Francois Mule" <[e-mail]> wrote on 
> 11/08/2006 05:42:20
> PM:
> 
> >
> > 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:[e-mail]]
> > > 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
> > > >> [e-mail]                              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 
> > > > [e-mail] for questions on 
> current sip Use 
> > > > [e-mail] 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 
> > > [e-mail] for questions on current sip Use 
> > > [e-mail] 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 
> > [e-mail] for questions on current sip Use 
> > [e-mail] 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 [e-mail] for questions on current 
> sip Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP