50120140501015 2
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

50120140501015 2

on

  • 395 views

 

Statistics

Views

Total Views
395
Views on SlideShare
395
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

50120140501015 2 Document Transcript

  • 1. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING & 6367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME TECHNOLOGY (IJCET) ISSN 0976 – 6367(Print) ISSN 0976 – 6375(Online) Volume 5, Issue 1, January (2014), pp. 128-140 © IAEME: www.iaeme.com/ijcet.asp Journal Impact Factor (2013): 6.1302 (Calculated by GISI) www.jifactor.com IJCET ©IAEME AIPC : COUNTER-ACTIVE ANALYSIS OF OVERLOAD CONTROL MECHANISM FOR SIP SERVER Bikash Upadhyay, Atul Mishra, Shraddha Bikash Upadhyay 1 (Department of IT., BBDNIIT, Dr. Akhilesh Das Nagar, Lucknow, UP., India) (Department of CSE., BBDU, Dr. Akhilesh Das Nagar, Lucknow, UP., India) 3 (Department of CSE, BBDNITM, Dr. Akhilesh Das Nagar, Lucknow, UP., India) 2 ABSTRACT We have introduced a new mechanism similar to earlier used AIMD algorithm in which there will be a probabilistic change in the sending rate during the overload condition. The probabilistic change will be sender-receiver synchronized by mechanism “Additive Increase and Probabilistic Change (AIPC)”. We show that mechanism is effective, counter-active, reliable and fair. Sender will change its sending rate in accordance with the receiver’s capacity. Sender-receiver is synchronized such that former reduces the sending rate and the later prevents from being overloaded. Simulation is used to analyze the factors viz. effectiveness, efficiency, fairness and stability. Keywords: SIP, AIPC, AIMD, VoIP, SIP Server, Probability of Rejection. 1. INTRODUCTION SIP is the major protocol used for Multimedia communication such as VoIP. It is an application layer protocol, independent of sub layer protocols (TCP, UDP). SIP is proposed by Internet Engineer Task Force (IETF). SIP works in various phases of call such as Localization of terminal, Analyzing recipient profile and resources, negotiating the type of media & communication parameters and the availability of the correspondent. It’s also works out during the call Set-up and Call Follow-up. SIP protocol is a transaction based protocol designed to establish and end media sessions. 128
  • 2. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME 1.1 EASE OF USE 1.1.1 SIP Overview Figure 1 SIP is widely being adopted by the IP telephony providers [1], including Vonage and AT&T, as the foundation of large scale deployments. Such providers typically deploy Sip Proxies which are responsible for Call routing operations, assisting request & response, across a larger geographic area to efficiently deal with the increasing volumes of traffic. In centralized server architecture, these sing proxies also deals in authentication and signaling request. The SIP baseline specification RFC 3261 (previously RFC 2543bis) divides SIP Server functionality into the following parts: a. SIP Registrar Server—handles location registration messages. handles b. SIP Redirect Server—returns “contact this address” responses. returns c. SIP Proxy Server—forwards SIP requests and responses. forwards 1.2 Causes of SIP Server Overlaod In SIP server architecture, there are two main rea reasons for performance problem: Firstly, due to the larger network latency between the Proxy & SIP Server (authentication as well) in order to handle the query the authentication requests because the Digest authentication requires a separate request for each authentication operation. Each time a proxy process authenticates a message, it has to wait for the response to continue processing the next message. During this time, it cannot process ue a new request and the requests are rejected. This leads to lower call throughput. Figure 2 Secondly, with the increase in notable volume of traffic leads to Overload situation. Work done in [5] suggests that overload situations not only reduce the performance of a VoIP server but ] can finally lead to a complete standstill of the complete VoIP service. To withstand sudden increases 129
  • 3. International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME in traffic or temporary lack of resources, SIP servers and Proxies need to implement overload control mechanisms that aim at reducing the work load of these servers and prevent a complete depletion of their resources. 1.3 Measured Parameters for Analysis We used the parameters defined in IETF draft for all the measurements [6], [8]. But we use hardware utilization parameters as well, in order to monitor the performance of memory and resources of the proxies. The parameters are measured based on sender and receiver ends. Call statistics and duration of calls during the message exchange is monitored at the Sender end. Real time protocol samples are also captured as well. At receiver end, Hardware utilization parameters are measured directly. This would include the measurement of memory and resource utilization. The complete list of measured parameters includes: • CPU Utilization • Memory Utilization • Number of Successful calls • Number of (Un)Successful calls • Request delays 1.4 Categories of SIP Server Overload There are two main categories of SIP Server overload viz. Server-to-Server overload and Client-to-Server overload. In this paper we have adopted the former category. When server capacity is reached and if the server continues to accept requests, application performance and stability can exhausted. a. Serve- to-Server Overload It occurs when upstream server starts sending substantial amount of traffic (Engineered Traffic E) to the main server (SIP Server, here), pushing it towards overload. We have adopted this scenario for our research in this paper. b. Client-to-Server Overload It occurs when a large number of clients make a simultaneous request not handled by the next server, thereby, putting the server into overload. 2. RELATED WORK Aim of any Overload control mechanism is to reduce the load or burden on the SIP Server. Overload condition is observed as condition in which certain pre-requisite threshold values are exceeded. This leads to dropping or rejection of SIP requests. Work done in [2] analyzes that Performance of SIP Server and VoIP calls during a DoS attack. Quality of Calls is reduced substantially during the attack. Packet loss occurs but can be neglected. A sudden decrease in delay increases with the increase in flooding and stress on SIP server increases. It is also concluded in [6] variation at receiver jitter increases as load on server increases. Detailed analysis of rate based control mechanism [7] suggests that a new class of AIMD algorithm works well during overload condition. Additive increment is decreasing functions of the current sending rate. The congestion control algorithm is globally asymptotically stable and will converge to equilibrium. Mechanism uses a decreasing function of the increase factor and a constant decrease factor. A special case of DAIMD algorithm is considered for various grid based applications. D.Sis [3] proposed R-SOCA which aims at stabilizing the proxy behavior during the overload condition. It prevents the server from being completely exhausted. It takes nature and cause of 130
  • 4. International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME overload together. Dropping and rejecting the incoming request are realized by sending back a 5xx response. AIPC mechanism adopted the probabilistic factor obtained as a change factor between sender and receiver in synchronized manner. Sender-Receiver depicts the probabilistic change during an overload condition. R. kusching [10] illustrates that Multiplicative decrease step of AIMD algorithm reduces the receiving window (and the corresponding throughput) in case of the packet loss drastically, before the Additive increase step is initiated and tries to increase the window again. This can lead to remarkable variation of the throughput in networks with large RTTs. 3. AIPC MECHANISM 3.1 Problem Statment The goal of any overload control scheme is to reduce the load on engaged resources. Reducing the load has their costs in terms of CPU and Memory Utilization as well. Figure 3 3.2 Proposed Mechanism • The mechanism would synchronize both the sender and the receiver. Mechanism focus on both, reducing the incoming traffic at receiver end by either dropping or rejecting the traffic, based on a Probabilistic factor. While at the sender end, the sender would adjust its transmission strategies in accordance with the Receivers capacity. Receiver would increase the rate of transmission until the notice of overload occurrence and would decrease it substantially as soon as overload is noticed. In this way, both the sender and the receiver share their status to get synchronized and decrease the rate of rejection which will surely enhance the CPU utilization and corresponding Proxy Throughput. • A SIP Server is said to be overloaded if atleast one of its resources is having a value more than a specified limit. In our mechanism, we set this limit as RLOW. It is a point beyond which a server starts overloading to some extent. And beyond RUP (upper limit), a SIP Server is said to be overloaded. Above RUP, the system is considered as Overloaded and it cannot handle any more requests and it starts rejecting the entire request until the Rate of Transmission falls between the RLOW and RUP. Reducing the load on the SIP proxy can be realized by either dropping incoming requests or rejecting them, e.g., sending back a 5xx reply. It is suggested in [4] that dropping incoming requests, consumes slightly less CPU at the SIP proxy than rejecting them. • In order to reduce the possibility of an overload situation at the receiver side, the senders of the SIP traffic should adapt their transmission rates to the capabilities of the receivers. That is, if a SIP proxy that is currently sending traffic to another proxy notices that the receiving proxy is overloaded; the sending proxy should reduce its transmission rate so as to avoid overloading the receiving one. 131
  • 5. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME • In order to avoid the sudden changes , we should take the average of Probability of rejection sh ty • AIPC combines linear growth of the transmission rate with the Probabilistic change during an Probabilistic overload condition. 3.3 Equations • At Receiver Side AIPC defines two threshold points (for CPU and memory): lower (RLOW) and Upper Threshold (RUP). AIPC work in a way that the number of rejection during the overload condition is minimized. Once the lower threshold is exceeded, the AIPC starts reducing the load on the SIP server by the Probability of Rejection (PoR). This can be illustrated by rejecting the incoming requests on SIP with PoR PoR = 0 {RTRANS < RLOW} (1) Αll incoming requests coming from SIP Server is rejected as the Upper Threshold value is exceeded. This threshold is set to the amount of resources required to handle the requests in some worst case scenarios. Engineered traffic [4] is the amount of requests a SIP server is expected to receive and process simultaneously under normal operational conditions i.e. during DoS attacks or Flash crowd scenarios. PoR = 1 {RTRANS >= RUP} (2) There will be a probabilistic change size of receiving window when the rate of receiving incoming requests lies between the Upper and Lower thresholds PoR = RTRANS >= RLOW} (3) Parameter obtained in eq. (3) is the Probability of rejection calculated at fixed time intervals (say T) where RTRANS is the load status on SIP Server [3]. In order to avoid sudden change . and to obtain a smooth graph, Average of PoR is taken in eq. (3) over the time. When : graph, o PoRAVG≤5 system is not considered as Overload and there will be no dropping or rejection  of incoming request is initiated. o 1 ≥ PoR ≥ 0.05, SIP Sever is considered as Overloaded. Counteractive measures are required to Sop is from being overloaded. Hence, the incoming successful INVITE messages are rejected with the parameter used in eq. (3). 132
  • 6. International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME o PoR = 1, SIP Server is considered as complete overloaded and no incoming request is entertained viz. requests are rejected. • At Sender Side Sender side will use same parameter used on receiver side for reducing the rate of sending requests. AIPC enables SIP Server to estimates the overload status at its neighboring servers and adopt the change in transmission accordingly AIPC mechanism allows a faster reaction to a substantial overload condition and careful preventive reaction during the under load phases. Figure 4 I= ୖ୲୰ୟ୬ୱିୖ୪୭୵ ୖ୳୮ିୖ୪୭୵ At starting or under normal condition, when no overload status is received and no retransmission occurs, the sender adjusts its sending rate in an increasing manner. It follows additive increase behavior probing to usable bandwidth until the loss occurs. AIPC increases the sending by a fixed amount every round trip time. RTRANS +1 = RTRANS + δ {δ = Linear increase} (4) Upon receiving a Overload Status (i.e. 5xx reply) AIPC uses Probabilistic parameter used in eq. (3) for reducing the rate of transmission. It is observed that overload status is received when the transmission rate exceeds the Lower threshold value. The sender will adjust its rate of transmission accordingly. When : o RTRANS ≥ RLOW , corresponding value of I lies between 0.5 to 0.9 and the rate of transmission is illustrated as RTRANS + 1 = RTRANS (1 – I) (5) The transmission rate will be adjusted in the manner of PoR at the receiver side. o RTRANS ≥ RUP, corresponding value of I will be 1 and the receiver side is regarded as complete or severely overloaded. The rate of transmission will be illustrated as RTRANS + 1 = RTRANS x I (6) Note that the working of the equation (5) and (6) is somewhat similar. The blocking probability is lower when the transmission rate lies between lower and upper bound while it is max during the complete or severe overload condition. 133
  • 7. International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME 3.4 AIPC Constraints • The overloaded server sends explicit congestion information to the proxy or neighboring server, the sender side (receiving this information) needs to entirely adjust its transmission rate accordingly. The complication lies here not in the rate adjustment but in determining the appropriate overload information at the overloaded server. Hence, in our approach, we will restrict the analysis to the conditions in which the overloaded servers send only implicit congestion information, e.g., rejecting or dropping traffic. These mechanisms are already part of the SIP specifications and do not require any additional logic at the receiving SIP proxies server. • We assume the overload notification purely based on closed loop feedback: Detection, Signaling and Reaction. Detection phase will monitors the buffer utilization at Overload point and collects data. Signaling phase will generate proper message response (5xx) and gives feedback. The Reaction phase will refine the changes in the sending rate according to the receiver failure message. Figure 5 • Send routines should be non-blocking (asynchronous) whereas the receive routines can be blocking or non-blocking. • Actions are taken on the sending and receiving end through the message response buffer. • The value of probabilistic factor can be negotiated between severs at service level, for adjusting its sending rate at sender side, and for decreasing its receiver window at receiver side. • Since data and signal take separate paths in SIP, hence, RTP stream does flow through the SIP server and will not represent any load for it. [9] • Do not confuse “imply” and “infer.” 3.5 AIPC Analysis Tools For evaluation of our mechanism, we have used following tools for conducting the experiment: 1. Asterisk Server [14]: It is a complete PBX in software. Its runs on various platforms viz. Linux, windows, MAC OS etc. It supports three way calling, caller ID services, ADS1, IAX, SIP, H.32x, MACP and SSCP. 2. Star Trinity SIP tester [16]: It is a VoIP load testing tool which enables you to test VoIP network, SIP Software and hardware. It can simulate thousands of incoming and outgoing SIP calls with RTP streams. It can also analyze call and real time reports. 134
  • 8. International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME 3. SIPp tool [15]: SIPp is a free Open Source test tool / traffic generator for the SIP protocol. Features include dynamic display of statistics about running tests (call rate, round trip delay, and message statistics) and dynamically adjustable call rates. 4. Average CPUcylce [13]: It is an open source tool used to analyze the CPU usage for specific program and to find the total average CPU usage of a program for its entire uptime. 4. EXPERIMENTAL TEST BED In this section, we describe our experimental setup used for the performance analysis of AIPC mechanism under several load conditions. The test setup consists of sender and a receiver emulated using a SIP tester. Major parts of the test setup are: 4.1 SIP Server ASTERISK is used as a SIP server. It is an open source PBX machine in software. 4.2 Evaluation Machine To analyze the CPU utilization, we have used AVERAGE CPUcycles on Linux console. This is an open source tool used for measuring the CPU usage for specific program and to find the total average CPU usage of program for its entire uptime. 4.3 Hardware configuration The experiments are done with two systems in computer lab at BBD University, having following configurations. The machine acting as a Server is Intel® Core 2 Duo 2.0 GHz processors with 3GB ram and 160 GB disk drive. Figure 6 The machine hosting UAS are Intel® Pentium®4 1.80 GHz processor with 1GB ram and 80 Gb disk drive. Both the machines run Ubuntu OS. 5. PERFORMANCE EVALUATION For analyzing the scenario to an extent, SIP requests (INVITE) are sent to a proxy server. Successful INVITE requests are followed by another two requests viz. ACK & BYE. Rejecting INVITE requests, thereby, will save the resources required for processing the INVITE request and corresponding in-dialog request as well. The goal of our experiment is to evaluate the ability of Sip Server to handle the number of simultaneous requests during an overload condition. We evaluated the performance of AIPC during several scenarios. 135
  • 9. International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME Sender 5.1 Assumption and Simulation Due to the limitation of the traffic generator tool i.e. it’s simple and single threaded architecture design, which prevents it from using the multiple cores at a time. Thus, to increase the call capacity, it is required to run the processes of SIPp on multiple machines. 25500 25000 24500 24000 23500 23000 22500 22000 21500 21000 20500 20000 21000 21500 22000 22500 23000 23500 24000 24500 25000 Receiver Figure 7 Fig. 7 illustrates the message transfer between sender and the receiver when there is no attack or overload situation [2] During the simulation, we observed that a single SIPp process on a machine can generate 250 simultaneous requests. Hence we adopted four machines to generate 1000 simultaneous requests. The upper threshold beyond which the server gets overloaded is 1000. Ultimately the lower threshold is assumed to be 500 simultaneous requests. Since the media stream and signaling follow separate path in SIP, hence on the load on media stream will not affect the signaling stream. For evaluating the blocking probability, we used the Star Trinity SIP tester. The Simulation includes both single and load variance approach. Since AIPC aims at reducing the number of rejections during an overload condition according to the capability of the server to handle the simultaneous request. Figure 8 (Source Star Trinity SIP Tester [16]) 5.2 Result For testing the performance of AIPC, the test cases are implemented on sender and receiver separately. During no overload condition, there will no probability of rejection. At Receiver Side The AIPC will starts as the number of incoming request exceeds the Lower threshold. Fig. 9 and 10 illustrates the affect of Probability of rejection on number of incoming requests. There is slight increase in the projection of rejection with the increase in the incoming request. Fig. 11 illustrates the percentage reduction in the number of requests with the probability of rejection with variable difference of 0.1. The slope in the figure represents the variance in the reduction of incoming requests with the probability of rejection. 136
  • 10. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME No. of Incoming Requests At Sender Side Sender side will reduce the rate of transmission or simply the number of request sent to the overloaded 1200 1000 Probabilit y of Rejection Incoming Requets 800 600 400 200 Rejected Requests 0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Probability of Rejection Figure 9 Probability of Rejection Rejected Requests Incoming Requets 850 900 950 800 750 1000 855 650 700 550 600 595 720 500 375 480 195 280 120 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 55 0 0.1 0.2 0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Figure 10 No. of Incoming Requests 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Server Overloaded Rejected Requests Probability of Rejection 0 0.1 0.10.20.30.40.50.60.70.80.9 1 Probability of Rejection Figure 11 server as the Lower threshold is exceeded. The transmission rate is thus adjusted in accordance with the table 1. No request will be entertained beyond the upper threshold. Table1 represent the effect of probabilistic factor I on the outgoing request. 137
  • 11. International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME For smooth working of the AIPC mechanism, the triggering policies are based on the response messages i.e. the AIPC is revoked on sender side till the overload response is received on the sender side. It will automatically start increasing the rate of transmission linearly thereafter. Fig. 12 illustrates the effect of AIPC mechanism on the rate of transmission at sender side. It clear stated from the figure that the sending rate is inversely proportional to the probabilistic factor. Only the initials requests i.e. INVITE messages are dropped by the AIPC mechanism at the sender side. This will not only reduce the load on the overloaded server but also reduce the number of resources required to process theses requests. It is because of the fact that a successful INVITE message is followed by two more consecutive in-dialog messages viz. ACK and BYE. No. of Incoming Requests 1200 Probabilit y of Rejection 1000 800 Incoming Requets 600 400 Rejected Requests 200 0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Request Processed Probability of Rejection Figure 12 5.3 Tables The table represents the effect of PoR on the outgoing request at sender side. Prob. Of Rejection 0 Table 1 Outgoing Requests 500 Rejected Requests 0 0.1 550 55 0.2 600 120 0.3 650 195 0.4 700 280 0.5 750 375 0.6 800 480 0.7 850 595 0.8 900 720 0.9 950 855 1 1000 1000 138
  • 12. International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME 6. CONCLUSION In our findings , we observed that the dropping the INVITE requests at sender side during an overload condition , not only save the resources required to handle the requests but also reduces the extra load on the Server as well. During an interoperability event, we measured the performance of our server using a professional performance measurement tool and our server was able to fully saturate the tool. We thus, conclude that: • • • No. of requests processed Successful INVITE requests are followed by another two requests viz. ACK & BYE. Sender drops the initial request while the receiver (Server here) reject the active sessions. Finally, our simulation states that unresponsive active sessions can cause overload. AIPC rejects these active sessions during overload condition. Fig. 13 illustrates the performance comparison of AIPC mechanism with that of AIMD mechanism. Our curve analysis shows that AIPC mechanism performs better during the overload condition. The analysis is based on comparison between the previous and current simulation along with the mathematical model. 2000 AIPC Mecha nism 1500 1000 AIMD Mecha nism 500 0 1 2 3 4 5 6 7 8 9 10 11 Time (ms) Figure 13 FUTURE WORK Our future can extend to analyze the working of AIPC mechanism in various types of attacks. Also, enhancement tuning can also be performed in order to obtain customized result. This can be done on the basis of complexity analysis. REFERENCES [1] [2] [3] Italo Dacosta, Vijay Balasubramaniyan, IEEE, Mustaque Ahamad & Patrick Traynor, Member, IEEE “Improving Authentication Performance of Distributed SIP Proxies”, IEEE Transactions On Parallel And Distributed Systems, Vol. 22, Issue: 11, pages: 18041812, November 2011 Bansal, A. , Kulkarni, P. ; Pais, A.R. “Effectiveness of SIP Messages on SIP Server”, 2013 IEEE Conference Information & Communication Technologies (ICT), pages: 616-621. Dorgham, John “Protecting VoIP Services against DoS using Overload Control”, International Conference on Computer Communications and Networks , copenhegen, october, 2008. 139
  • 13. International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] Dorgham Sisalem, John Floroiu “VoIP Overload, a Senders Burden” ,62-69 , International Conference on Computer Communications and Networks (CCN-10), Orlando, USA, July 12-14, 2010 M. Ohta, “Simulation study of sip signaling in an overload condition.” In Communications, Internet, and Information Technology, M. H. Hamza, Ed. IASTED/ACTA Press, 2004, pp. 321–326 Book on “SIP Security”, Dorgham Sisalem, John Floroiu, Ulrich Abend, Henning Schulzrinne , Wiley Publications 2009 Yunhong Gu, Xinwei Hong, and Robert L. Grossman, An Analysis of AIMD Algorithm with Decreasing Increases, National Science Foundation S. Poretsky , V. Gurbani, C. Davids , “ Terminology for benchmarking Session initiation Protocol (SIP) Networking Devices”, Dorgham Sisalem, John Floroiu, Ulrich Abend, Henning Schulzrinne , Wiley Publications 2009 Miroslav Voznak and Jan Rozhon, SIP End to End Performance Metrics, International Journal Of Mathematics And Computers In Simulation . 2012 Robert Kuschnig, Ingo Kofler , hermann Hellwagner “Improving Internet video streaming performance by parallel TCP-based request-response Streams “ In the proceedings of 7th IEEE conference on Consumer Communications and Networking Conference (CCNC’10), 2010, pages:200-2004. .R.N. Manda, R.A. Auguste “Proposed mathematical model for a SIP call”, In the proceedings of International Conference on Multimedia Computing and Systems (ICMCS), pages: 41-45, 10-12 May, 2012 Martin Rohricht, Roland Bless “Advanced Quality-of-Service signalling for the Session initiation protocol (SIP)” In the Proceedings of first IEEE ICC 2012 workshop on Telecommunications: From research to Standards, Ottawa, Canada, June 2012. http://www.boray.se/software/averagecpu/ http://www.asteriskwin32.com/ http://sipp.sourceforge.net/ http://startrinity.com/VoIP/SipTester/SipTester.aspx P.Vigneshwaran, Dr. R. Dhanasekaran, “A Novel Protocol to Improve TCP Performance – Proposal”, International Journal of Computer Engineering & Technology (IJCET), Volume 3, Issue 2, 2012, pp. 372 - 377, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375. Sonia, Satinder Pal, “An Effective Approach to Contention Based Bandwidth Request Mechanism in Wimax Networks”, International Journal of Computer Engineering & Technology (IJCET), Volume 3, Issue 2, 2012, pp. 603 - 620, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375. 140