15 AIPC COUNTER-ACTIVE ANALYSIS OF OVERLOAD CONTROL...

International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-

6367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME

128

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) 2(Department of CSE., BBDU, Dr. Akhilesh Das Nagar, Lucknow, UP., India)

3(Department of CSE, BBDNITM, Dr. Akhilesh Das Nagar, Lucknow, UP., India)

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.

INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING &

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

© I A E M E

International Journal of Computer Engineering and Technology (IJCET), ISSN 0976


1.1 EASE OF USE

1.1.1 SIP Overview

SIP is widely being adopted by the IP telephony

as the foundation of large scale deployments. Such providers typically deploy Sip Proxies which are

responsible for Call routing operations,

to efficiently deal with the increasing volumes of traffic. In centralized server architecture, these

proxies also deals in authentication and signaling

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.

b. SIP Redirect Server—returns “contact this address” responses.

c. SIP Proxy Server—forwards SIP

1.2 Causes of SIP Server Overlaod

In SIP server architecture, there are two main reasons for performance

to the larger network latency between the Proxy & SIP Server

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.

a new request and the requests are rejected.

This leads to lower call throughput.

Secondly, with the increase in notable volume of traffic leads to Overload situation.

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


6375(Online), Volume 5, Issue 1, January (2014), © IAEME

129

Figure 1

SIP is widely being adopted by the IP telephony providers [1], including Vonage and AT&T,


erations, assisting request & response, across a larger


proxies also deals in authentication and signaling request.

cification RFC 3261 (previously RFC 2543bis) divides SIP Server

functionality into the following parts:

handles location registration messages.

returns “contact this address” responses.

forwards SIP requests and responses.

SIP Server Overlaod

In SIP server architecture, there are two main reasons for performance problem:

to the larger network latency between the Proxy & SIP Server (authentication as well) in order to

e query the authentication requests because the Digest authentication requires a separate


to wait for the response to continue processing the next message. During this time, it cannot process

rejected.

Figure 2

with the increase in notable volume of traffic leads to Overload situation.

] suggests that overload situations not only reduce the performance of a VoIP server but




Vonage and AT&T,


across a larger geographic area


cification RFC 3261 (previously RFC 2543bis) divides SIP Server

problem: Firstly, due

as well) in order to

e query the authentication requests because the Digest authentication requires a separate


During this time, it cannot process

with the increase in notable volume of traffic leads to Overload situation. Work

] suggests that overload situations not only reduce the performance of a VoIP server but




130

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



131

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.



• In order to avoid the sudden changes , we sh

• AIPC combines linear growth of the transmission rate with the Probabilistic change during an

overload condition.

3.3 Equations

• At Receiver Side AIPC defines two threshold

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 Probability of Rejection (PoR). This can be illustrated by rejecting the incoming requests

on SIP with PoR

PoR = 0 {RTRANS < RLOW

� Αll incoming requests coming from SIP Server is rejected as the Upper Threshold value is

exceeded. This threshold is set t

some worst case scenarios. Engineered traffic [4] is the

expected to receive and process simultaneously under normal operational

during DoS attacks or Flash crowd scenarios.

PoR = 1 {RTRANS >=

� 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 = R

� Parameter obtained in eq. (3) is

(say T) where RTRANS is the load status on SIP

and to obtain a smooth graph

o PoRAVG≤��5 � system is not considered as Overload and there will be no

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



132

d the sudden changes , we should take the average of Probability of rejection

AIPC combines linear growth of the transmission rate with the Probabilistic change during an

AIPC defines two threshold points (for CPU and memory): lower (R

AIPC work in a way that the number of rejection during the overload condition

exceeded, the AIPC starts reducing the load on the SIP server by

ity of Rejection (PoR). This can be illustrated by rejecting the incoming requests

LOW} (1)

ll incoming requests coming from SIP Server is rejected as the Upper Threshold value is

set to the amount of resources required to handle the requests in

Engineered traffic [4] is the amount of requests

expected to receive and process simultaneously under normal operational

attacks or Flash crowd scenarios.

>= 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

RTRANS >= RLOW} (3)

Parameter obtained in eq. (3) is the Probability of rejection calculated at fixed time intervals

the load status on SIP Server [3]. In order to avoid sudden change

graph, Average of PoR is taken in eq. (3) over the time. When :

system is not considered as Overload and there will be no dropping

of incoming request is initiated.

SIP Sever is considered as Overloaded. Counteractive measures are


messages are rejected with the parameter used in eq. (3).



ty of rejection

AIPC combines linear growth of the transmission rate with the Probabilistic change during an

lower (RLOW) and Upper

AIPC work in a way that the number of rejection during the overload condition

the AIPC starts reducing the load on the SIP server by

ity of Rejection (PoR). This can be illustrated by rejecting the incoming requests

ll incoming requests coming from SIP Server is rejected as the Upper Threshold value is

required to handle the requests in

amount of requests a SIP server is

expected to receive and process simultaneously under normal operational conditions i.e.

There will be a probabilistic change size of receiving window when the rate of receiving

the Probability of rejection calculated at fixed time intervals

. In order to avoid sudden change

, Average of PoR is taken in eq. (3) over the time. When :

dropping or rejection

SIP Sever is considered as Overloaded. Counteractive measures are




133

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.



134

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.



135

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.



136

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.

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.

200002050021000215002200022500230002350024000245002500025500

21000 21500 22000 22500 23000 23500 24000 24500 25000

Se

nd

er

Receiver



At Sender Side

Sender side will reduce the rate of transmission or simp

overloaded

server as the Lower threshold is exceeded. The transmission rate is thus adjusted in

the table 1. No request will be entertained beyond the upper

probabilistic factor I on the outgoing request.

0

200

400

600

800

1000

1200

0

No

. o

f In

com

ing

Re

qu

est

s

0 0.10 55

500 550

0 0.1

Probability of Rejection

Incoming Requets

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0 0.1

No

. o

f In

com

ing

Req

ues

ts



137

Sender side will reduce the rate of transmission or simply the number of request sent to the

Figure 9

Figure 10

Figure 11

server as the Lower threshold is exceeded. The transmission rate is thus adjusted in

the table 1. No request will be entertained beyond the upper threshold. Table1 represent

on the outgoing request.

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1


Probabilit

y of

Rejection

Incoming

Requets

Rejected

Requests

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 155 120 195 280 375 480 595720

855

0

550 600650

700750

800850

900950

1000

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Probability of Rejection Rejected Requests

Incoming Requets

0.10.20.30.40.50.60.70.80.9 1


Server

Overloaded

Rejected

Requests

Probability

of

Rejection



of request sent to the

server as the Lower threshold is exceeded. The transmission rate is thus adjusted in accordance with

represent the effect of



138

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.

Figure 12

5.3 Tables

The table represents the effect of PoR on the outgoing request at sender side.

Table 1

Prob. Of

Rejection

Outgoing

Requests

Rejected

Requests

0 500 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

0

200

400

600

800

1000

1200

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

No

. o

f In

com

ing

Re

qu

est

s


Probabilit

y of

Rejection

Incoming

Requets

Rejected

Requests

Request

Processed



139

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:

• 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.

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] 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: 1804-

1812, November 2011

[2] Bansal, A. , Kulkarni, P. ; Pais, A.R. “Effectiveness of SIP Messages on SIP Server”, 2013

IEEE Conference Information & Communication Technologies (ICT), pages: 616-621.

[3] Dorgham, John “Protecting VoIP Services against DoS using Overload Control”,

International Conference on Computer Communications and Networks , copenhegen,

october, 2008.

0

500

1000

1500

2000

1 2 3 4 5 6 7 8 9 10 11

No

. o

f re

qu

est

s p

ro

cess

ed

Time (ms)

AIPC

Mecha

nism

AIMD

Mecha

nism



140

[4] 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

[5] 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

[6] Book on “SIP Security”, Dorgham Sisalem, John Floroiu, Ulrich Abend, Henning

Schulzrinne , Wiley Publications 2009

[7] Yunhong Gu, Xinwei Hong, and Robert L. Grossman, An Analysis of AIMD Algorithm

with Decreasing Increases, National Science Foundation

[8] 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

[9] Miroslav Voznak and Jan Rozhon, SIP End to End Performance Metrics, International

Journal Of Mathematics And Computers In Simulation . 2012

[10] 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.

[11] .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

[12] 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.

[13] http://www.boray.se/software/averagecpu/

[14] http://www.asteriskwin32.com/

[15] http://sipp.sourceforge.net/

[16] http://startrinity.com/VoIP/SipTester/SipTester.aspx

[17] 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. 12 - 18, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375.

[18] 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.

15 AIPC COUNTER-ACTIVE ANALYSIS OF OVERLOAD CONTROL...

Documents

Transcript of 15 AIPC COUNTER-ACTIVE ANALYSIS OF OVERLOAD CONTROL...