[SR-Users] Max concurrent TCP connection that Kamailio support ?

[Khoa Pham]

Hi Yang Hong, thanks for your reply and those papers

1. When client make TCP connection, it usually get [FIN,ACK] and [RST] from
server. Does that mean that server has reach max TCP connection limit, or
server is busy handling other connections?

P/S: proposed that my server is very strong


On Mon, May 6, 2013 at 10:24 PM, Yang Hong <yang_hong at hotmail.com> wrote:

> Hi Khoa.
>
> The maximum number of concurrent TCP connections depend on the
> computational capacity of the server. Kamailio can be regarded as an
> application server of high performance SIP/VoIP.
>
> In the following post, the Kamailio user set max TCP connections to 64K.
> http://lists.sip-router.org/pipermail/sr-users/2013-April/077555.html
>
> Actually the theoretical maximum number of open TCP connections is
> general setting for all servers (not limited to Kamailio). The following
> link is a good reference for your question.
> "What is the theoretical maximum number of open TCP connections that a
> modern Linux box can have?" Stack Overflow
>
> http://stackoverflow.com/questions/2332741/what-is-the-theoretical-maximum-number-of-open-tcp-connections-that-a-modern-lin
>
> The max_tcp_connections set to 2048 is a very conservative setting.
> Theoretically you can set a large number of max_tcp_connections. However,
> Kamailio node may exhibit overload even collapse, when concurrent TCP
> connections reaches maximum setting during peak-hour and each connection
> perform heavy task by average.
>
> To be conservative, you can collect statistics about CPU and memory
> utilization of Kamailio node under 2048 connections (your current default
> setting). For example, if CPU utilization is only 10%, you can increase
> max_tcp_connections setting from 2048 to 20480.
>
> Similar to potential overload caused by too many TCP connections, SIP also
> faces with overload issue recently due to its popularity.
>
> Build-in overload mechanism cannot prevent overload effectively.
> Therefore, IETF SIP Overload Control (soc) Working Group works on IETF RFC
> "SIP Overload Control" currently.
> http://tools.ietf.org/html/draft-ietf-soc-overload-control-12
>
> IETF SIP Overload Control discussion archives
>
> http://www.ietf.org/mail-archive/web/sip-overload/current/threads.html#00874
>
> A survey on SIP overload control algorithms (including IETF RFC "SIP
> Overload Control") can be downloaded from the following link free of charge.
> Y. Hong, C. Huang, and J. Yan, “A Comparative Study of SIP Overload
> Control Algorithms,"Network and Traffic Engineering in Emerging Distributed
> Computing Applications, Edited by J. Abawajy, M. Pathan, M. Rahman, A.K.
> Pathan, and M.M. Deris, IGI Global, 2012, pp. 1-20.
>
> http://www.researchgate.net/publication/231609451_A_Comparative_Study_of_SIP_Overload_Control_Algorithms
> http://arxiv.org/abs/1210.1505
>
> http://www.igi-global.com/chapter/comparative-study-sip-overload-control/67496
>
> Control theorectic approaches have been applied to model the interactions
> between an overloaded SIP server and its upstream servers as a feedback
> control system in two different scenarios - redundant retransmission ratio
> control and round trip delay control (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
>
> http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5683124&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5683124
>
> Implementation of implicit SIP overload control in the real system
> "An Efficient Earthquake Early Warning Message Delivery Algorithm Using an
> in Time Control-Theoretic Approach"
> http://link.springer.com/chapter/10.1007%2F978-3-642-23641-9_15#
> http://www.ipv6.org.tw/docu/elearning8_2011/1010004798p_3-7.pdf
>
> "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
>
> Skype story published by Road Runner (TimeWarner Cable Inc.)
> http://features.rr.com/article/01vBgtc8TR17z?q=Skype
>
> http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5963029&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5963029
>
>
> Best regards,
> Winston Hong
> Software Engineer
> InBay Technologies Inc.
> Ottawa,
> Canada K2K 1Y3
> http://www.inbaytech.com/solutions.html
>
>
>
> ------------------------------
> Date: Mon, 6 May 2013 10:54:13 +0700
> From: onmyway133 at gmail.com
> To: sr-users at lists.sip-router.org
> Subject: [SR-Users] Max concurrent TCP connection that Kamailio support ?
>
>
> Hi,
>
> What is the maximum number of concurrent TCP connection that Kamailio can
> handle ?
> I see the max_tcp_connections (which is set to 2048), is that the answer ?
>
> How to test for this ?
>
> Many thanks
>
> --
> Khoa Pham
> HCMC University of Science
> Faculty of Information Technology
>
> _______________________________________________ SIP Express Router (SER)
> and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>


-- 
Khoa Pham
HCMC University of Science
Faculty of Information Technology
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130507/f95362ac/attachment.html>