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

I think the requirement looks good.

Volker

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.
> 
> Albrecht.Schwarz@alcatel.de 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 
>> <fluffy@cisco.com>                                              
>>                       bs.com>                  cc:      sipping 
>> <sipping@ietf.org>                                                      
>>                                                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
>>>> 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