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" <jf.mule@cablelabs.com> 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: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