A systematic Characterization of Application Sensitivity to Network Performance

9
Emulation
We define emulation, as distinct from simulation, as when some part of a live system is
run and the components which comprise the independent variables are emulated. That is, the part
of the system under test is a real, while the parts which compose the independent component of the
experiment are emulated. A primary advantage of such an approach is that it can be scaled larger
than simulation. For example, the data set sizes in [73] are a factor of 10 larger than the simulation
results for similar programs found in [52, 110].
Emulation is certainly not as flexible as simulation. A substantial limitation of emulation
is that it misses at least an order of magnitude of the design space possible compared to simulation
because the live system component requires real hardware and software. While the emulated por-
tion can be modified, the interfaces between it and the live portion will dictate how much of the
design space can be controlled. With full-blown simulation, only programming effort and computer
resources limit the simulation.
Another drawback of emulation over simulation is the reduced fidelity of the experiments.
It is often difficult to observe the live parts of the system in order to understand observed responses.
In the operating system community, there has been much recent research on live system measure-
ment [4]. An interesting tradeoff between fidelity and scale was explored by mixing multiple levels
of simulation and emulation in [89]. In the programming language realm, binary translators have a
similar effect [27, 92]. Increasing the fidelity of the “emulation” adds instructions, and this overhead
can be adjusted according to the needs of the experimenter.
Direct Measurement
Direct measurement is by definition the most “realistic” of experimental techniques. We
define direct measurement as when only a complete system is used in the experiment; no part of the
system is emulated or simulated. Most often, direct measurement is used to judge different systems
in similar points in the design space. For example, [49] compares Autonet, Ethernet and FDDI.
Direct measurement can only evaluate discrete points in the design space rather than a
range of designs. The single-point nature of direct measurement can be both beneficial and detri-
mental. On one hand, limiting the design space to a few points limits the number of independent
variables.
3
In addition, since the measured systems are real we could actually use such systems. On
the other hand, the inability to scale parameters in a controlled fashion makes determining impor-
£
Section 2.4 backgrounds experiment factor design.

---

10
tant parameters in the design space difficult. Direct measurement does not help us conceptualize a
system, and can even leave us more befuddled than before. The lack of a model may thus effect our
conclusions. Because the system under measurement is an actual artifact, as opposed to a model,
many studies often do not articulate the results in terms of abstract parameters.
A potential pitfall of using live systems is that the systems may not be configured “prop-
erly”. For example, a version of Solaris had certain TCP window constants set too low as shipped
from the manufacturer [61]. Although analyzing a system “as shipped” might still be a fair charac-
terization, it does not represent the true potential of a mis-configured system. Validating the results
of live systems against analytic models can expose mis-configuration errors.
1.1.3
Summary
Our two axes of categorization, experiment paradigm and methodology, allow us make
sense of the broad field of network experiments. Network-centric studies describe what happens to
the network, are useful for improving network performance, but tell us little about which aspects of
the network are most important. Application-centric studies describe application behavior, point to
network areas that yield the largest benefit, but do not describe how to make improvements.
On the methodology axis, we saw that analytic modeling requires little engineering ef-
fort and helps conceptualize how a system works. However, the models are somewhat inflexible
in their ability to capture how real systems operate and thus can be inaccurate. Simulation requires
substantial engineering, is limited in scale, but has unlimited flexibility. Emulation has limited flex-
ibility because it requires live system components. It also entails substantial engineering effort. The
results, however, can be quite accurate, because many important behaviors only appear at realistic
input set sizes. Direct measurement is the most inflexible technique, does not help us conceptualize
the system at all, but provides the most realistic results.
In the context of our framework, this thesis is clearly an application-centric, emulation
based study. Our method allows us to reason about application behavior, and thus conclude about
which aspects of the network are most important. Our emulation-based approach allows us to use a
wide range of applications with realistic data sets and networking parameters. The live experiment
data, coupled with analytic models, gives us greater confidence in our results and conclusions than
using a single method.

---

11
1.2
Contributions
Our contributions fall into four areas. The primary contribution is an investigation of a
novel performance analysis technique for network experimentation. Recall that because our study is
application-centric, we can also make statements about application behavior. Answers to networking
architecture questions make up the third area because of the close association of the LogGP model
to real machine components. Modeling is our fourth, and smallest, area of contribution. Although
the models are relatively simple, we can still draw some conclusions from them. The next sections
describe this thesis’s contributions in each of these areas. We also describe the questions this thesis
attempts to answer in these areas, along with a brief summary of our results. Chapter 7 contains our
humble attempt to answer these questions in more detail.
1.2.1
Performance Analysis
The primary contribution of this thesis is a methodology for the systematic exploration
of the space of network design. The experimental methodology is inspired by analytic bottleneck
analysis [57, 65], but is performed on a live system rather than on analytic models. The basic tenet
of the approach is to introduce carefully controlled delays in key system components. The delays
allow us to quantify the sensitivity of the system to each component. In our definition, sensitivity is
the change in an application-centric metric as a function of one of the LogGP parameters. In contrast
to bottleneck analysis, which only identifies peak performance, our method can expose bottlenecks
as well as characterize their nature by examining the sensitivity curve.
Returning to our taxonometric experiment design space described in Section 1.1, our ex-
perimental method is application-centric and emulation based. The apparatus allows us to “sandbox”
running applications in a network with the desired performance characteristics. That is, we run real
applications in a controllable network. The novelty of our approach is the use of this artificial net-
work. We gain the benefit of observing the effects that occur in applications running realistic data
sets. The disadvantage of our approach is that, although we do use a network which is higher perfor-
mance than what is generally available, we are unable to observe sensitivities beyond its operational
limits. Another encumbrance of our method is that in order to understand the sensitivity curves, we
must create models of the applications.
In spite of our method’s shortcomings, it allows us good observational fidelity. Sensitive
applications will exhibit a high rate of “slowdown” as we scale a given LogGP parameter. Insensitive
applications will show little or no difference in performance as we change the parameters. Another

---