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

[Cullen Jennings <[e-mail]>]

That captures what I was trying to say - thanks. I can see how people  
would say this is an obvious implicit requirement and does not need  
mentioning but I have been involved with some, uh, systems that  
failed this requirement.

On Nov 14, 2006, at 9:32 PM, Jonathan Rosenberg wrote:

> I think its reasonable to make it an explicit requirement. How about:
>
> <t hangText="REQ 21:"> The overload mechanism should ensure that the
> system remains stable. When the offered load drops from above the
> overall capacity of the network to below the overall capacity, the
> throughput should stabilize and become equal to the offered load.
> </t>
>
>
> -Jonathan R.
>
> [e-mail] wrote:
>
>> Stability is an implicit requirement of every load control and  
>> overload
>> protection mechanism (for network elements and networks targeting  
>> high
>> system and/or service availability).
>> The rational behind is the fact that any overload control may be  
>> modeled (&
>> realized) as open or closed control loop. Any control arround  
>> signalling
>> protocols is typically realized as closed loop (e.g. due to realtime
>> background).
>> A well designed closed control requires a proof of stability for the
>> intended range of operation; stability is an implicit requirement  
>> from
>> control theory, particularly for load control with stochastic  
>> components as
>> in our case here.
>> - Albrecht
>>                                                                       
>>                                                                       
>>                     Volker  
>> Hilt                                                                  
>>                                                              
>> <volkerh@bell-la         To:      Cullen Jennings  
>> <[e-mail]>                                                    
>>                  bs.com>                  cc:      sipping  
>> <[e-mail]>                                                    
>>                                                   Subject: Re:  
>> [Sipping] Re: draft-rosenberg-sipping-overload-reqs  
>> recovery                                      08.11.2006  
>> 17:18                                                                 
>>                                                                       
>>                                                                       
>>                                 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
>
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ  
> 07054-2711
> Cisco Systems
> [e-mail]                              FAX:   [phone]
> http://www.jdrosen.net                         PHONE: [phone]
> 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