Subject: [Sipping] draft-rosenberg-sipping-overload-reqs recovery

From: Cullen Jennings <[email-masked]>
Date: Fri, 3 Nov 2006 18:23:59 -0800

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?

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.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 8 Nov 2006 18:15:00 -0500

So the requirement is to get damped versus undamped oscillations.

Mike 

> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]] 
> 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:
> > >>> 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:[email-masked]]
> > 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:
> > >>
> > >>> 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
> > >> 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
> > >> [email-masked]                              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 
> > > [email-masked] for questions on current sip Use 
> > > [email-masked] for new developments of core SIP
> > 
> > 
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> 
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 8 Nov 2006 18:16:16 -0500

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

Mike 

> From: Janet P Gunn [mailto:[email-masked]] 
> Sent: Wednesday, November 08, 2006 5:54 PM
> To: Jean-Francois Mule
> Cc: Cullen Jennings (fluffy); Volker Hilt; sipping
> 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" <[email-masked]> wrote on 
> 11/08/2006 05:42:20
> PM:
> 
> >
> > Volker wrote:
> > > 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,
> > > >>> 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
> > 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.
> >
> 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.
> >
> > > 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:
> > > > 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
> > > > 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
> > > >>> 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
> > > >>> I have seen systems that never recover - that is bad. I think 
> > > >>> one
> > > of