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

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