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

["Jean-Francois Mule" <[e-mail]>]

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