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

["Dolly, Martin C, ALABS" <[e-mail]>]

Is requirement #22 a step function, or does it support a gradual
recovery? 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Thursday, November 16, 2006 2:50 AM
To: Volker Hilt
Cc: Cullen Jennings; sipping
Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs
recovery


Agree to make an explicit requirement, but the current proposal is now
containing two requirements in my understanding.
One related to the stability criteria, and one related to performance
(->
throughput) under overload.
The 2nd one is so far only considering throughput ("maximize throughput,
=
equal to offered load"), but not the requirement of bounding response
times
of (SIP) messages. A successfully processed SIP message and the
correspondent response time are tightly coupled. A successfully
processed
message, but with too much delay, is typically meaningless. (The maximum
response time is typically given by SIP protocol timers, or timers of
the
SIP served application, or behaviour of human beings behind a UA, or
...)

Like to split them therefore into two:

<t hangText="REQ 21:"> The overload mechanism should ensure that the
system remains stable independent of the offered load (i.e., in the
entire
load range).
</t>

<t hangText="REQ 22:"> 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 (under
steady-state conditions).
Response times (or system times; given by service time and all waiting
times within the SIP entity) should be below a maximum value under all
load
conditions.
</t>

- Albrecht




 

                      Volker Hilt

                      <volkerh@bell-la         To:      Jonathan
Rosenberg <[e-mail]>                                        
                      bs.com>                  cc:      Albrecht
SCHWARZ/DE/ALCATEL@ALCATEL, Cullen Jennings <[e-mail]>,      
                                               sipping
<[e-mail]>

                      15.11.2006 23:34         Subject: 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.
>
> [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
>>
>





_______________________________________________
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