% $Id: conclusions.tex,v 1.8 2004/11/04 03:06:54 gokhale Exp $

\section{Discussion and Concluding Remarks}
\label{sec:conclusions}

The research in this paper is motivated by the realization that a
growing number of computing and networking resources are being expended
to control large-scale, often safety-critical distributed,
performance-sensitive software (DPSS) systems.
% Andy, have you already made the following points earlier in the paper?
% If so, I recommend removing them here and just focusing on what this
% paper covers!  I've taken a shot at this below, but please change it
% if it's incorrect...
\iffalse
DPSS systems have historically been relatively small-scale and
standalone, but the trend is toward significantly greater functionality,
complexity, and scalability.  In the past, moreover, DPSS systems have
been developed and validated using relatively static development and
analysis techniques (such as function-oriented design and rate monotonic
analysis~\cite{LSD:89}) to implement, allocate, schedule, and manage
their resources.
\fi

The next-generation of DPSS systems, such as sensor network applications
and emergency response systems, evolve rapidly and must collaborate
with multiple remote sensors, provide on-demand browsing and actuation
capabilities for human operators, and respond flexibly to unanticipated
situational factors that arise at run-time. These characteristics render
earlier static system development and analysis techniques less
effective.  Moreover, the availability of off-the-shelf software,
hardware, and networking building blocks -- compounded by economic and
market forces -- are causing DPSS systems to be assembled rapidly and
tested by composing building block components.  Design-time validation
and verification of end system performance is a necessity for the realm
of next-generation DPSS systems. This paper describes analytical
performance evaluation techniques that help improve
our understanding of the performance of the composed DPSS systems.

This paper concentrates on an important software building block called
the Reactor, which is used in many DPSS systems.  This paper shows that
Stochastic Reward Nets (SRNs) provide a powerful analytical technique to
model building blocks, such as the Reactor. Moreover, we show that SRNs
provide the desired capabilities to evaluate different performance
metrics for DPSS systems, including throughput, event loss, 
queueing delays, and even sensitivity analysis.  It is important to
apply these metrics as early as possible in the DPSS system lifecycle
({\em e.g.}, design-time) since DPSS developers can use these results to
guide decisions regarding appropriate resource provisioning and
schedulability analysis.

The primary goal of this paper was to evaluate the applicability of
different analytical techniques to accurately model and evaluate
individual software building blocks.  The insights we have gained will
shape our future R\&D efforts in this area, which involve developing
analytical models for larger DPSS systems that are composed out of
building blocks. This in turn will enable us to evaluate performance of
entire DPSS systems that are assembled out of different software
building blocks.

Our future work will also validate the performance evaluations of our
analytical models via empirical benchmarking.  We omit these results in
this paper due to the complexities of testing the Reactor as a standalone
unit without the confounding effects of underlying OS demultiplexing
and queueing mechanisms. For example, in POSIX-compliant operating
systems, there will always be a default buffering capability associated
with the socket handles on which the 
% Andy, please use {\tt select()} not {\tt select}!
{\tt select()} system call is invoked.  As a result, it is cumbersome
to showcase a Reactor with a configurable queue size for each of its
input event handles.
We plan to demonstrate these capabilities once our models for composable
building blocks have evolved.  We also expect to provide results for
more complex versions of the Reactor, including the {\em thread pool}
Reactor~\cite{Schmidt:02a}.
