A systematic Characterization of Application Sensitivity to Network Performance

3
plication change in performance, such as run time or updates per second, as a function of the LogGP
parameters.
The methodology to measure sensitivity is conceptually simple, although somewhat in-
volved in practice. First, we build a networking apparatus whose parameters are adjustable accord-
ing to the LogGP model. To build such an apparatus we start with a higher performance system than
what is generally available and add controllable delays to it. Next, we calibrate the apparatus to make
sure we can control the parameters accurately.
Once we have a calibrated apparatus, we can run the applications in a network with the
desired performance characteristics. We “turn the knob”, varying each parameter in turn and ob-
serving the resulting sensitivity of the application as a function of a single parameter. In all cases,
we must compare our measured results against an analytic model of the application. The analytic
models serve a check against our measured data. Points where the data and model deviate from one
another expose potential anomalies that warrant further investigation.
After we have collected the sensitivity data, we can answer a range of questions. These
include questions about the accuracy and applicability of our method, questions about application
behavior, questions about communication architectures, and finally, questions related to the accuracy
and applicability of simple application models.
The rest of this chapter is organized as follows. We first introduce two axes of experiment
design fundamental to networking research. The first axis categorizes the nature of the questions
of the experiment, and the second axis categorizes the nature of the experiment method. Next, we
describe the contributions of this thesis. Finally, we present a roadmap of the thesis organization.
1.1
Background
What does a “better” network mean? In order to answer the question in a concrete manner
a researcher must run quantitative experiments. As with any scientific experiment, a network exper-
iment aims to elucidate the nature of the system’s response to some stimulus. In computer network-
ing, the dependent variables are few, e.g., latency, bandwidth, packets-per-second, and run-time. The
number and types of independent variables are many. Because the most common type of experiment
evaluates two or more designs, the independent variable is often some aspect of the network design,
such as a retry protocol or routing algorithm. The number of independent variables thus spans the
entire design space. In addition to different types of variables, there are a number of methods used
to carry out the experiments.

---

4
In this section we present a simple way to categorize a wide range of networking research.
Our framework for categorizing computer network experiment design divides the design space along
two axes. These axes provide intuition into the nature of this thesis’ experiments, and taxonomic
placement of this work into a broad spectrum of computer networking research.
The first axis categorizes the response of interest along the spectrum from network to appli-
cation. Specifically, the axis defines the class to which the dependent variables belong. For example,
run time clearly belongs to the application class. Packet latency across a set of routers belongs to the
network class. Most experiments fall clearly into one class or another. Defining experiments along
this axis is important because it dictates what can be abstracted. For example, if the network is the
focus of the experiment, many application details can be eliminated. Likewise, if run-time is the
dependent variable, we may wish to focus our efforts on understanding the application and abstract
away network details.
The second axis categorizes the experimental method. Once the viewpoint of the exper-
iment has been established (network or application), we have a number of methods of evaluation,
e.g. simulation or direct measurement. These methods fall under general performance evaluation
techniques; we survey them in order to gain insight as to the rational for the method chosen in this
study.
In the next sections, we explore these two axes in greater detail. We start by describing
the two points on the experiment paradigm axis. We then describe four methodologies used in net-
working experiments. Finally, we summarize with an overview of the strengths and weaknesses of
the different experiment methods.
1.1.1
Experiment Paradigm Axis
Networking research traditionally has taken two perspectives with regards to evaluation.
In any network evaluation, there is the network itself, as well as the application load placed on it. A
network with no load is like a highway without cars—evaluation of the roadways is difficult if we do
not understand the characteristics of the traffic load. Over-extending the analogy a bit, applications,
like traffic, respond differently to changing network (road) conditions. In order to perform a tractable
study, an experimenter often has to focus on one response or the other. That is, either the network-
level or the application-level response will be the focus of the study.

---

5
Network Focus
The first, and most common perspective, is to observe the network response to some ap-
plication load. Two classic studies which exemplify this view are [24] and [56]. In these works,
the application load is presented as a “black-box”: only a series of packets bound for different des-
tinations is observable. The experiments use network-centric dependent variables, e.g. latency and
bandwidth, as the metric of evaluation. The network perspective evolved because it is close to what
is observable at network switches. All the switch “sees” is a stream of packets and traditionally they
have little, if any, information on the applications’ characteristic load.
Because the network perspective contains such little information on application character-
istics, many studies take a simple approach and model the applications as independent and identi-
cally distributed (IID) processes. These traditional loads have the twin advantages in that they are
amenable to analytic analysis and are easy to correctly generate in a simulator. However, a serious
drawback of these application models is that they do not approximate a real application load very
well. A recent half-decade series of empirical studies [62, 66, 67], has shown that application traffic
is bursty on all time scales. Traditional IID processes fail to capture this effect; the ramifications of
this discrepancy are still under investigation.
Application Focus
The second school of thought looks at the application performance given variable network
parameters. In these classes of experiments, the dependent variables are application related. For
example, what bandwidth can a single FTP transfer obtain with a certain loss rate?
The primary advantage of such a perspective is that it more closely models what a real user
might think of as “better”. The computer architecture community has taken this approach to the most
extreme level; every new microprocessor feature in the last 10 years has been defined by its impact
on the SPEC benchmark suite. In the parallel architecture community, a few application suites have
emerged, such as the SPLASH suite [110] and the NAS Parallel Benchmarks (NPB) [9, 11]. Among
wider-area networks, the state of affairs is such that no real application suites have been defined for
a broad segment of the community.
The application based perspective has the disadvantage of being quite complex to analyze.
Unless we have a good models and an understanding of the applications, they can become opaque
“black-boxes”. Experiments designed along this axis may not yield an understanding of how sys-
tem design facets shape application behavior. A more difficult problem is that the application focus

---