[sip-overload] Survey on SIP Overload Control Re: Proposal: Support for the restriction algorithms should be mandatory for clients

[<[e-mail]>]

Dear all,

 

Thanks for ERIC's TAC 1991 paper.

 

We have published a survey on SIP overload control algorithms (including IETF RFC "SIP overload control").

http://www.researchgate.net/publication/231609451_A_Comparative_Study_of_SIP_Overload_Control_Algorithms" rel="nofollow">http://www.researchgate.net/publication/231609451_A_Comparative_Study_of_SIP_Overload_Control_Algorithms
http://arxiv.org/abs/1210.1505" rel="nofollow">http://arxiv.org/abs/1210.1505
http://www.igi-global.com/chapter/comparative-study-sip-overload-control/67496" rel="nofollow">http://www.igi-global.com/chapter/comparative-study-sip-overload-control/67496

 

I agree with Eric's comment "As offered load increases, rate control is the only algorithm that controls load close to the target."

 

We have also used control theorectic approaches to model the interactions between an overloaded SIP server and its upstream servers in two different scenarios (IEEE Globecom 2010 and ICC 2011).

"Mitigating SIP Overload Using a Control-Theoretic Approach" IEEE Globecom 2010
http://www.researchgate.net/publication/221284946_Mitigating_SIP_Overload_Using_a_Control-Theoretic_Approach" rel="nofollow">http://www.researchgate.net/publication/221284946_Mitigating_SIP_Overload_Using_a_Control-Theoretic_Approach

 

Implementation of implicit SIP overload control in the real system
http://link.springer.com/chapter/10.1007%2F978-3-642-23641-9_15" rel="nofollow">http://link.springer.com/chapter/10.1007%2F978-3-642-23641-9_15#

 

"Design Of A PI Rate Controller for Mitigating SIP Overload" IEEE ICC 2011
http://www.researchgate.net/publication/224249824_Design_of_a_PI_Rate_Controller_for_Mitigating_SIP_Overload" rel="nofollow">http://www.researchgate.net/publication/224249824_Design_of_a_PI_Rate_Controller_for_Mitigating_SIP_Overload
http://features.rr.com/article/01vBgtc8TR17z?q=Skype" rel="nofollow">http://features.rr.com/article/01vBgtc8TR17z?q=Skype

 

Best regards,

 

Winston Hong
Software Engineer
InBay Technologies Inc.
Ottawa, Canada K2K 1Y3
http://www.inbaytech.com/" rel="nofollow">http://www.inbaytech.com/

 

---

• From: "NOEL, ERIC C (ERIC C)" <ecnoel at research.att.com>
• To: Volker Hilt <volker.hilt at alcatel-lucent.com>, "sip-overload at ietf.org" <sip-overload at ietf.org>
• Date: Fri, 29 Apr 2011 08:56:32 -0400
• In-reply-to: <4DBA1D11.7030001 at alcatel-lucent.com>
• References: <E4B3F0DC6D953D4EBEC223BC86FE322C4A42034FB7 at EMV04-UKBR.domain1.systemhost.net> <4DBA1D11.7030001 at alcatel-lucent.com>

---

Volker, 

Wrt Phil's comment on vulnerability to sudden increases on the offered load at client sources, I believe the paper from Arthur Berger in IEEE Transactions on Automatic Control Vol 36, No2, February 1991 titled "Overload Control Using Rate Control: Selecting Token Bank Capacity for Robustness to Arrival Rates" supports that observation.

In that paper, Figure 3 compares rate control to call gapping and to percent blocking. As offered load increases, rate control is the only algorithm that controls load close to the target. Basically Phil's point.

Because it is a copyrighted document, I do not think I can broadcast on distribution list. However, if you cannot get a copy of the paper let me know and I will assist you.

Thanks,

Eric Noel 
LMTS
AT&T Labs, Inc. 
Rethink Possible

Network Design and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174
ecnoel at http://att.com" rel="nofollow">att.com