15 AIPC COUNTER-ACTIVE ANALYSIS OF OVERLOAD CONTROL ... · 1.2 Causes of SIP Server Overlaod In SIP server architecture, there are two main rea to the larger network latency between
Post on 22-Aug-2020
5 Views
Preview:
Transcript
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
6367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
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 requests and responses.
1.2 Causes of SIP Server Overlaod
In SIP server architecture, there are two main rea
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. During this time, it cannot process
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
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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976
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,
as the foundation of large scale deployments. Such providers typically deploy Sip Proxies which are
operations, assisting request & response, across a larger
sing volumes of traffic. In centralized server architecture, these
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:
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
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
ue 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. Work
] 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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-
6375(Online), Volume 5, Issue 1, January (2014), © IAEME
Vonage and AT&T,
as the foundation of large scale deployments. Such providers typically deploy Sip Proxies which are
across a larger geographic area
sing volumes of traffic. In centralized server architecture, these
The SIP baseline specification RFC 3261 (previously RFC 2543bis) divides SIP Server
problem: Firstly, due
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
ue processing the next message. During this time, it cannot process
Overload situation. Work
] 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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-
6367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-
6367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
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.
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976
6367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
• In order to avoid the sudden changes , we sh
• AIPC combines linear growth of the transmission rate with the Probab
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 to the amount of resources
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
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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976
6375(Online), Volume 5, Issue 1, January (2014), © IAEME
132
In order to avoid 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
the Probability of Rejection (PoR). This can be illustrated by rejecting the incoming requests
LOW} (1)
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
during DoS 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
required to Sop is from being overloaded. Hence, the incoming successful INVITE
messages are rejected with the parameter used in eq. (3).
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-
6375(Online), Volume 5, Issue 1, January (2014), © IAEME
ty of rejection
ilistic 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
the Probability of Rejection (PoR). This can be illustrated by rejecting the incoming requests
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.
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
required to Sop is from being overloaded. Hence, the incoming successful INVITE
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-
6367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
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.
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-
6367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
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.
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-
6367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
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.
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-
6367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976
6367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
At Sender Side
Sender side will reduce the rate of transmission or simply the number of request sent to the
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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976
6375(Online), Volume 5, Issue 1, January (2014), © IAEME
137
Sender side will reduce the rate of transmission or simply the number of request sent to the
Figure 9
Figure 10
Figure 11
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
Probability of Rejection
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
Probability of Rejection
Server
Overloaded
Rejected
Requests
Probability
of
Rejection
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-
6375(Online), Volume 5, Issue 1, January (2014), © IAEME
Sender side will reduce the rate of transmission or simply the number of request sent to the
Lower threshold is exceeded. The transmission rate is thus adjusted in accordance with
represent the effect of
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-
6367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
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
Probability of Rejection
Probabilit
y of
Rejection
Incoming
Requets
Rejected
Requests
Request
Processed
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-
6367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-
6367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
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. 372 - 377, 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.
top related