A systematic Characterization of Application Sensitivity to Network Performance

6
requires the researcher to map application-level observations to specific architectural features. An
example of this problem is the lack of continuity across network interface designs. Returning to the
processor architecture analogy, the SPEC benchmarks are the most analyzed programs on the planet,
thus much is understood about their structure. A thorough analysis has been done for the SPLASH
benchmarks [110], but little analysis has been done for the other benchmarks.
Assuming we cross the application complexity barrier, a second advantage of the applica-
tion paradigm is that it focuses attention on the most important aspects of the network. For example,
in the CPU world many programs are known to be quite sensitive to caches and branch predictors.
The effect of this conclusion has been that many CPU designers focus on these aspects of their de-
signs. With networks, latency or bandwidth alone are often touted as the figure of merit in many
network-centric studies. In the WAN context, however, there are no agreed-upon standard applica-
tion workloads. Without a deconstructed workload, a credible evaluation of new designs in the WAN
arena will remain difficult.
1.1.2
Evaluation Methods Axis
Once the experimenter has chosen a perspective, a range of evaluation methodologies are
available to perform the experiment. We classify them in order of increasing approximation to real
systems. The four methods are: analytic modeling, simulation, emulation, and direct measurement.
Each approach has appropriate uses and a range of strengths and weaknesses. The discussion here
is presented as background to put this thesis into an appropriate context.
Analytic Modeling
Analytic modeling is traditionally not considered an “experimental” technique, although
it could be classified as a gedanken experiment
2
. The purpose of an analytic model is often the
same as an experiment, that is, answer basic questions about a network system, e.g., what is the peak
bandwidth through the system? The difference is that the technique results in a set of equations that
establish the relationship among various parameters and performance metrics. Unlike any of the
other methods, nothing is “run” in the usual sense.
The complexity of such models can range from very simple frequency-cost pairs, to queu-
ing theory models [50, 65], to advanced queuing theoretic techniques [57, 63]. Both the complexity
and accuracy of such models can cover a large range, depending on the purpose of the model. Of-
¢
a thought experiment

---

7
ten a high degree of accuracy is not required, so analytic modeling is a viable technique in many
circumstances.
Although at first they appear quite flexible, analytic models tend not to capture a wide range
of system behavior because of the assumptions needed to make the equations tractable, and also to
close the system of equations in the first place. For example, feedback loops in real systems are
difficult to capture using analytic models. Chapter 5 presents observations describing the difference
between measured data and models due to these effects.
In general, a scientific model is only “valid” as to accuracy of the model compared to real
systems. For example, claims are often made in the popular press that Newtonian physics models
are invalid because they can be quite inaccurate. However, a more accurate statement is that New-
tonian mechanics are only valid in the realm of everyday experience. Questions regarding accuracy
in the network models is a realm where much previous work in analytic modeling fails, not because
of inaccurate models, but because of the lack of validation against actual systems. Indeed, general
rules of thumb describing the accuracy of analytic models do not seem to exist for many classes of
networks. This is a regrettable state of affairs because analytic modeling can be a powerful predictor
of real systems.
An often overlooked power of analytic modeling is its ability to formalize how a system
behaves, not in questions of absolute accuracy. That is, analytic models help us conceptualize the
essence of the system, as opposed to merely describing the system’s response to some stimulus. At
this level, the value of the model is not in answering the absolute contribution of each component,
but instead identifying the important components and their relationships in the first place. At some
level, every researcher has a model in mind when answering performance analysis questions. The
model’s abstractions of a real system capture the essential elements without burdensome details. In
addition, the formulation of a formal model provides the researcher a way to put these abstractions
into a quantitative, testable form. The resulting advances in conceptual thinking are often the most
valuable part of a model. For example, the simple analytic models described by the iron triangle in
CPU design silenced endless artistic debates and forced designers into a realm of quantitative archi-
tectural tradeoffs. The absolute accuracy of such simple models for use in real programs was not
addressed until much later [90].

---

8
Simulation
A step closer to a real system is a simulator. One might think of a simulator as a model
without a closed form description. Simulation is perhaps the most popular technique in the research
arsenal because of its infinite flexibility. A simulation experiment can potentially explore the entire
design space. However, simulation suffers from a number of drawbacks some of which are com-
monly known, but a number of which are more subtle.
A well known drawback of simulation is its lack of scale. That is, the size of the system
which can be simulated with any fidelity is often quite limited. Indeed, expanding the scale of simula-
tion is an active area of research [54, 87]. In the parallel architecture regime, the effects of simulation
scale have been studied extensively [110]. A primary effect is that architectural parameters must be
scaled with the input in order to obtain meaningful results.
Simulation experiments also have a number of well known engineering drawbacks includ-
ing complexity, time to build the simulator, time to debug the simulator, and time to validate the
simulator. The importance of the last point cannot be over stressed. All too often, detailed simulator
results are constructed without a corresponding validation either using an analytic model or a live
system. While intuition can be used to validate a simulator [57], such an approach might only serve
to feed the experimenter’s previous bias.
An insidious danger with simulation is that the bias or misconceptions of the experimenter
will become encoded in the simulator. While also true of analytic modeling, the danger is increased
in simulation because of the increased level of detail when using simulation. Often, these bias mani-
fest themselves as invalid assumptions. For example, the assumption that traffic has uniform random
destinations is quite common and may not be true for many real networks [76]. In another example,
one simulation study showed that paging over a network would be much faster than to local disk [5],
but later results showed the performance to be much less than expected [3]. The inaccuracy origi-
nated because of the faulty assumption that network paging would have much lower overhead than
disk paging.
A more subtle danger than faulty assumptions is that often the simulator is adept at simu-
lating one class of system over another. For example, shared memory may be given preference over
message passing because extensive simulation tools have been developed for shared-memory sys-
tems. The network experimenter may observe artifacts of shared memory machines, e.g. very short
packets, while missing the effects of longer packets that occur when using message passing or WAN
protocols.

---