%% $Id: casestudy.tex,v 1.11 2005/04/25 12:45:56 gokhale Exp $
\section{Performability Analysis of Virtual Router}
\label{sec:vr_perf}

In this section we illustrate how the SRN model of the reactor pattern
is used for the performability analysis of a Virtual Private 
Network (VPN) service provided by a Virtual Router (VR). The main
purpose of this exercise is not to draw any conclusions about 
specific parameter values, but to demonstrate how reasonable values
of the parameters can be systematically determined through 
careful analysis at the time of designing a service.

We consider a scenario where a VR is used to provide VPN services
to two organizations, with each organization having a customer edge 
(CE) router connected to the VR. The employees of each organization
issue VPN set up and tear down service requests to the VR via CEs. 
Also, the VR offers a differentiated level of service, with organization \#1
receiving prioritized service over organization \#2. From the 
point of view of the employees of the organizations, it 
is necessary that the service requests be handled in a 
reasonable amount of time. Also,
the probability of denying the service requests should be minimal.
From the point of view of the VPN service provider, the rate at
which the service requests are processed or the throughput is
of interest, since this will determine the revenue generated 
for the provider. 

In order to implement the VPN service, a reactor pattern with
the characteristics described in Section~\ref{sec:reactor_modeling}  
can be used to demultiplex the events. The SRN model of the 
reactor pattern can thus be used for the performability
analysis of the VPN service provided by the VR. 
In order to use the SRN model, we designate the requests 
originating from organization \#1 as events of type \#1 and requests
originating from organization \#2 as events of type \#2. 

In the early stages of application development lifecycle, it is
necessary to analyze the impact of design  
choices and configurations on the performability measures.  Also, in these
stages, it is rarely the case that the values of the
input parameters can be estimated with certainty, which makes
it imperative to analyze the sensitivity of
the performability measures to the variations in the input parameters. 
Sensitivity analysis will enable the provider to determine the 
regions of operation during which service performance is acceptable.
In the subsequent subsections we demonstrate how the 
SRN model can be used to explore alternative
design configurations, as well as to facilitate sensitivity analysis.

\subsection{Impact of Buffer Space}
\label{sec:n1n2}
The buffer space available to hold the incoming events of each type
is a configuration parameter of the reactor pattern and
the VPN service that uses the pattern. 
This choice will have a direct impact 
on all the performability metrics. Most importantly, 
from the employees' perspective, the
buffer space will influence the probability of denying the service
requests.

We analyze the impact of the buffer capacities on the 
performability measures. The values of the 
remaining parameters (except for the buffer capacities) are reported 
in Table~\ref{table:param}. We consider two values of buffer capacities 
$N_1$ and $N_2$. In the first case, the buffer capacity is 
set to $1$ for both types
of events, whereas in the second case the buffer 
capacity of both types of events is set to $5$. The performability metrics for 
both these cases are summarized in Table~\ref{table:perf}.  
Because the values of the parameters of the service requests
from organization \#1 ($\lambda_1$, $\mu_1$ and $N_1$) are the same 
as the values of the parameters
for the service requests from organization \#2 ($\lambda_2$, 
$\mu_2$, and $N_2$), the
throughputs, queue lengths, and the loss probabilities are the same
for both types of service requests for each one of the buffer capacities 
as indicated in Table~\ref{table:perf}.
It can be observed that the loss probabilities are significantly higher 
when the buffer capacity is $1$ 
compared to the case when the buffer space is $5$. Also, due to the
higher loss probability, the throughput is slightly lower when
the buffer capacity is $1$ than when the buffer capacity is $5$. 

For both buffer capacities, the total number of service requests 
from organization \#2, denoted $E_2$, is slightly higher than the 
total number of requests from organization \#1, 
denoted $E_1$. Because the requests from organization \#1
are provided prioritized service over the requests from organization \#2,
on an average it takes longer to service a request from organization \#2 
than it takes to service a request from organization \#1. This results
in a higher total number of requests from organization \#2 than 
the total number of requests from organization \#1. This may result in a 
higher response time for service requests from organization \#2 
as compared with the service requests from organization \#1.
The reward rates to obtain the response times can be obtained 
using the tagged customer approach~\cite{melamed84} and is a 
topic of our future research. 

\begin{table}[htb]
\begin{center}
\caption{Parameter values}
\label{table:param}
\begin{tabular}{|c|c|c|c|} \hline 
Event type & Arrival rate & Service rate & Failure rate \\ \hline 
\#1 & $\lambda_1$ = $0.400$/sec. & $\mu_1$ = $2.000$/sec. & $\gamma_1$ = $0.02$/sec. \\ \hline 
\#2 & $\lambda_2$ = $0.400$/sec. & $\mu_2$ = $2.000$/sec. & $\gamma_2$ = $0.02$/sec. \\ \hline 
\end{tabular}
\end{center}
\end{table}

\begin{table}[htb]
\begin{center}
\caption{Impact of buffer capacity on performability measures}
\label{table:perf}
\begin{tabular}{|c|c|c|} \hline 
Performability measure & \multicolumn{2}{|c|}{Buffer space} \\ 
                    & $N_1=1$, $N_2=1$ & $N_1=5$, $N_2 = 5$ \\ \hline 
$T_1$ & $0.37$/sec. & $0.39$/sec. \\ \hline 
$T_2$ & $0.37$/sec.  & $0.39$/sec. \\ \hline 
$Q_1$ & $0.06$ & $0.12$ \\ \hline 
$Q_2$ & $0.06$ & $0.12$ \\ \hline 
$E_1$ & $0.25$ & $0.31$ \\ \hline 
$E_2$ & $0.27$ & $0.34$ \\ \hline 
$L_1$ & $0.06$ & $0.00024$ \\ \hline 
$L_2$ & $0.06$ & $0.00024$ \\ \hline
\end{tabular}
\end{center}
\end{table}

\subsection{Impact of Service Rates}
\label{sec:mu}
Another design parameter that will impact the service
performance is the service time of the event handlers.
Obviously, a faster rate of service will improve performance,
but from the provider's perspective, increasing the service
rate may require higher levels of resources thereby increasing 
the cost. Therefore, it is necessary to determine what service rate would be
``good enough'' to provide acceptable service performance. This
can be accomplished by analyzing the sensitivity of
the performability metrics with respect to the service rates, namely, 
$\mu_1$ and $\mu_2$.

The results reported in Section~\ref{sec:n1n2} indicate that
the loss probability is significantly lower when the buffer space
is $5$ as compared to the loss probability when the buffer space is 
$1$. As a result, for the purpose of sensitivity analysis 
with respect to $\mu_1$ and $\mu_2$, we 
set the buffer capacity for both service requests to be $5$. 
We vary the service rates $\mu_1$ and $\mu_2$
in the range of $0.4$/sec. to $2.0$/sec. roughly in steps of $0.025$, one 
at a time, to obtain the expected performance
measures by solving the SRN model shown in Figure~\ref{fig:srn}. 
The remaining parameters are held at the values reported in 
Table~\ref{table:param}. 

The plots in the left column of Figure~\ref{fig:sens_mu} 
show the variation of the performability measures with
respect to $\mu_1$, while the plots in the right column of 
Figure~\ref{fig:sens_mu} show the variation with respect
to $\mu_2$. The topmost plot in the left column shows the 
variation of throughputs of service requests from organizations
\#1 and \#2 with respect to $\mu_1$. The figure 
indicates that as $\mu_1$ decreases, 
the throughputs of requests from both organizations decrease; however,
the magnitude of decrease in the throughput of requests from
organization \#1 is higher than the magnitude of decrease in the throughput
of the requests from organization \#2. The second and the fourth 
plots in the same column 
show the variation of the total number of requests and the queue length 
for requests from both organizations as a function of $\mu_1$.
It can be observed that both the total number of requests and the queue 
length increase as $\mu_1$ decreases, and the magnitude of 
increase for service requests from organization \#1 is higher 
than the magnitude of increase for requests from organization \#2.
Similar trends can be observed in
the variation of the loss probabilities in the third plot.
  
\begin{figure*}[!t]
\centerline{\hbox{
\psfig{file=eps/tputmu1.ps,height=2.5in,angle=270}
\hspace*{0.0in}
\psfig{file=eps/tputmu2.ps,height=2.5in,angle=270}
}}
\centerline{\hbox{
\psfig{file=eps/totmu1.ps,height=2.5in,angle=270}
\hspace*{0.0in}
\psfig{file=eps/totmu2.ps,height=2.5in,angle=270}
}}
\centerline{\hbox{
\psfig{file=eps/lossmu1.ps,height=2.5in,angle=270}
\hspace*{0.0in}
\psfig{file=eps/lossmu2.ps,height=2.5in,angle=270}
}}
\centerline{\hbox{
\psfig{file=eps/quemu1.ps,height=2.5in,angle=270}
\hspace*{0.0in}
\psfig{file=eps/quemu2.ps,height=2.5in,angle=270}
}}
\caption{Sensitivity of performability measures to service rates $\mu_1$ and $\mu_2$}
\label{fig:sens_mu}
\end{figure*}

It can be noted that as $\mu_1$ decreases, the 
performability measures degrade (loss probability, queue
length and total number of events increases,
and throughput decreases). Also, as $\mu_1$ decreases below 
$0.8$/sec., the performability measures deteriorate rapidly.  
With decreasing $\mu_1$, the time taken
to service a request from organization \#1 increases due to the additional time
taken to complete each snapshot. As a result, 
indirectly, this also increases the time taken to service a 
request from organization \#2 in each snapshot. Thus, the performance 
of requests from both organizations are adversely impacted,
even though only the service time for the requests 
from only one of the organizations increases.  
The variation of the performability measures with respect to
$\mu_2$ shows the same trend, with the role of event types 
reversed. 

\subsection{Impact of Request Arrival Rates}
\label{sec:lam}
The arrival rates of service requests, namely, $\lambda_1$ and $\lambda_2$,
constitute the input parameters. In this section we analyze the 
the sensitivity of the performability measures to these input
parameters.

Based on the results and analysis described in Section~\ref{sec:n1n2}
and Section~\ref{sec:mu}, we set $N_1$ and $N_2$ to $5$, and
we set $\mu_1$ and $\mu_2$ to $2.00$/sec for sensitivity analysis
with respect to $\lambda_1$ and $\lambda_2$.
The parameters $\gamma_1$ and $\gamma_2$ were held at the values reported in 
Table~\ref{table:param}. The parameters $\lambda_1$ and $\lambda_2$
were varied one at a time in the range of $0.4$/sec to 
$2.0$/sec. roughly in steps of $0.025$ to obtain the 
expected performability measures
by solving the SRN model shown in Figure~\ref{fig:srn}. 

\begin{figure*}[!ht]
\centerline{\hbox{
\psfig{file=../Sigmetrics-2005/eps/tputlam1.ps,height=2.5in,angle=270}
\hspace*{0.0in}
\psfig{file=../Sigmetrics-2005/eps/tputlam2.ps,height=2.5in,angle=270}
}}
\centerline{\hbox{
\psfig{file=../Sigmetrics-2005/eps/totlam1.ps,height=2.5in,angle=270}
\hspace*{0.0in}
\psfig{file=../Sigmetrics-2005/eps/totlam2.ps,height=2.5in,angle=270}
}}
\centerline{\hbox{
\psfig{file=../Sigmetrics-2005/eps/losslam1.ps,height=2.5in,angle=270}
\hspace*{0.0in}
\psfig{file=../Sigmetrics-2005/eps/losslam2.ps,height=2.5in,angle=270}
}}
\centerline{\hbox{
\psfig{file=../Sigmetrics-2005/eps/quelam1.ps,height=2.5in,angle=270}
\hspace*{0.0in}
\psfig{file=../Sigmetrics-2005/eps/quelam2.ps,height=2.5in,angle=270}
}}
\caption{Sensitivity of performability measures to arrival rates $\lambda_1$ and $\lambda_2$}
\label{fig:sens_lam}
\end{figure*}

Figure~\ref{fig:sens_lam} shows the performability measures as a
function of $\lambda_1$ and $\lambda_2$. The plots in the left
column show the variation of the performability measures with
respect to $\lambda_1$, whereas the plots in the right column
show the variation of the performability measures with respect
to $\lambda_2$. Referring to the topmost figure in the left 
column, it can be observed that initially, 
the throughput of service requests from
organization \#1 is nearly the same as the
arrival rate of the requests, indicating that the requests are serviced 
at the same rate at which they arrive. However, as 
$\lambda_1$ increases, the throughput starts lagging the arrival rate,
which indicates that the service rate is not sufficiently
high to process the requests at the rate at which they arrive. This 
may cause the queue for requests from organization \#1 to operate at 
full capacity for an extended period of time, which results in a 
rejection of the incoming requests from organization \#1.

It can be observed that a decrease in the 
rate at which the throughput increases is marked by an increase in
the loss probability of the requests (as shown in the third plot in 
the left column) and an increase in 
the queue length (as shown in the fourth plot in the left column) 
in Figure~\ref{fig:sens_lam}. The left plot in the second
row represents the total number of service requests
from each organization as a function
of $\lambda_1$. The plot indicates that the total number of 
requests from organization \#2
in the system increases as $\lambda_1$ increases. When $\lambda_1$
increases, the probability of having to service a request
from organization \#1 prior to servicing a request from 
organization \#2 event in a given snapshot increases. Because requests
from organization \#1 have priority over requests from organization \#2, 
requests from organization \#2 tend to reside longer in the
system as $\lambda_1$ increases. Thus, although the throughput of 
requests from organization \#2 is unchanged with respect to $\lambda_1$, the 
response time of the requests from organization \#2 may increase.  
The plots in the right column of Figure~\ref{fig:sens_lam} indicate
that similar trends can be observed in the performability measures with
respect to $\lambda_2$, except that the roles of the two types of 
requests are reversed. 
