Hi Clearwater,
We have some queries about the Clearwater dynamic overload control. We have had 
instances of SIP Request spikes which have invoked the controls, and were 
considering doing some load testing to verify the effect of changes to the 
token configuration items. However we would most appreciate some further 
explanation of the dynamic overload control.

The  Clearwater webpage explains that the token refresh rate is linked to the 
measurement of latency, and that the refresh rate rises and falls according to 
measured latency. However, it doesn’t say what the initial token number is, or 
if and how the total token number is controlled. It also doesn’t say how the 
token rate/number reduces back to a steady state once the load is removed.
For one “event” that I analysed, there were 7 SIP requests in the 10 seconds 
beforehand (0.7/sec). In the next second there were 52 requests, 7 of which 
were rejected by 503 Service Unavailable. In the next second there were 60 
requests of which 7 were rejected. After that the load dropped right back down, 
so the “event” lasted for only 2 seconds. So that means that 45 requests were 
accepted in the first second, and 53 in the next second. An apparent  increase 
of 8 per second.
If we were able to adjust the initial number of requests handled in the first 
second (and not even sure if we can) say to 60, then that would “solve” the 
issue for this case. But what if there were 80 requests in the first second? Do 
we increase it to 100? Then what if there are 120? How do we decide how many 
hits we should take in the all-important first second. If we make it too high, 
do we essentially negate the point of having overload control?
The Clearwater parameters allow you to modify the initial and maximum refresh 
rate, the maximum token number, and the target latency. It seems that none of 
these have a bearing on how many requests you can actually accept in the first 
second.

Are you able to clarify the operation of the overload control in terms of the 
“initial second token number”, the control of the total token number, and what 
happens to the refresh rate and total token number once the load is removed?
Of course we do not want to rush into any changes on our system and suspect 
that changes are not even necessary.
Regards,
Peter.




Peter Skrzynski

Technical Sales Support
NEC New Zealand Limited
NEC House, Level 6, 40 Taranaki Street, PO Box: 1936, Wellington 6011, New 
Zealand
T: 043816257, M: 0274849530, F: +6443811110
[email protected]<mailto:[email protected]>
nz.nec.com<http://nz.nec.com>

[cid:[email protected]]

Please consider the environment before printing this email

Attention:
The information contained in this message and or attachments is intended only 
for the person or entity to which it is addressed and may contain confidential 
and/or privileged material.  Any review, retransmission, dissemination, copying 
or other use of, or taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is prohibited. If you 
received this in error, please contact the sender and delete the material from 
any system and destroy any copies. NEC has no liability for any act or omission 
in reliance on the email or any attachment.  Before opening this email or any 
attachment(s), please check them for viruses. NEC is not responsible for any 
viruses in this email or any attachment(s); any changes made to this  email or 
any attachment(s) after they are sent; or any effects this email or any 
attachment(s) have on your network or computer system.
_______________________________________________
Clearwater mailing list
[email protected]
http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org

Reply via email to