A systematic Characterization of Application Sensitivity to Network Performance

113
The perturbation nature of the method has much in common with the experiments in the
life-sciences. Even the smallest living organisms contain a complexity well beyond anything man-
made. A fundamental question is thus how to even begin to understand such systems. Yet, many
experiments in the life sciences take a similar, simple approach as in this thesis. The first step is to
“damage” (in our case, slowdown) a component in a controlled manner. Next, a stimulus is applied
to the system (e.g. running the application) and then the experimenter can observe differences in
behavior from the baseline, “undamaged” system. Differences in behavior are thus related in some
way to the modified component. An experiment in the field of neuroscience using this style of anal-
ysis can be found in [85]. It is somewhat eerie that computer systems are approaching a level of
complexity that necessitates this style of analysis.
Another advantage of the method is that we can probe the system in a systematic manner
without having to rely on factor analysis. This is quite different from more traditional studies com-
paring systems. Many studies compare two or more systems which differ from each other in many
dimensions. A factor analysis must then be used to quantify the impact of each component. The
method presented in this thesis takes an opposite approach. Because each factor can be controlled,
we can use a single system and adjust the factors one at a time.
As computer systems become more complex, perhaps the methods used in this thesis will
become more widespread. For example, often the claim is made that “the network is too slow”. Us-
ing the methods in this thesis, we could slow the network down and observe if any application metrics
changed. If nothing changed, we can rest assured that some other component is the bottleneck. If, on
the other hand, we observe an immediate slowdown, we may conclude that improving the network
will improve performance to until some other component becomes the bottleneck.
Our style of analysis is not limited to networks; we could apply our methodology to com-
ponents in computer architecture, operating systems, graphics, and indeed, any computer systems
area. For example, often the claim is made that the context switch time of the operating system is
too slow. One could artificially inflate this time and observe the effects on application behavior in or-
der to determine the sensitivity to context switch time. In a like manner, we could slow down the file
system, virtual memory and other sub-systems in the operating system to help us isolate the impact
of these systems.
The reasons for a dearth of live sensitivity approaches in the computer sciences are two-
fold. First, it is a formidable engineering effort to construct a tunable apparatus. As we saw in Chap-
ter 2, the construction requires access to components that were not designed for modification. Simu-
lation suffers from a similar drawback in that a reasonable simulation requires substantial engineer-

---

114
ing effort. A second reason for the lack of live approaches is that the calibration can be almost as
involved as building the apparatus itself. The calibration aspect cannot be taken lightly; a bug in the
apparatus can easily ruin the whole experiment. The calibration aspect again mirrors experiments in
other sciences, where recording calibrations can become a daily event. Fortunately, the calibrations
needed in this thesis, although extensive, are not so tedious.
There is a large weakness with the method of this thesis, however. Although straightfor-
ward to observe cause and effect, without a model such data is merely adds to an increasing obscure
pile of experimental results. As the quote in Chapter 5 shows, such data in an of itself is of little
value unless it leads to an understanding of the how and why a system works. In this thesis, we have
attempted to use as simple models as possible to understand application behavior. We discuss the
effectiveness and character of our models in Section 7.4.
7.2
Application Behavior
The “live system” nature of our method is much more powerful than relying on analytic
modeling or simulation alone, because we can make statements about application behavior. These
observations, coupled with the LogGP model, allow us to draw architectural conclusions as well.
We have found that applications use a wide range of latency tolerating techniques, and that
these work quite well in practice. A little reflection shows that this should not be too surprising given
the tremendous attention given to latency tolerating techniques from many areas of computer science.
Indeed, the 1990’s has seen a broad, if somewhat disorganized, assault on the “latency” problem
from the theory, language, and architecture communities. For example, models such as BSP, LogP
and QSM are important theoretic tools needed to design algorithms which mask latency. Languages
such as Id and Split-C were designed to allow the programmer and run time system to tolerate latency.
On the architectural front, recent designs have emphasized reduced overhead and simpler interfaces
to allow for greater latency tolerance (e.g. the T3D vs. T3E). The importance of these techniques
across a broad range of computer science is such that they have entire book chapters devoted to the
them [32].
In spite of the many latency tolerant programs, NFS does exhibit hyper-sensitivity to la-
tency for the performance regimes of traditional LANs. However, as was noted in Chapter 5.6, IP
switching hardware has crossed a fundamental threshold into the 10-20 microsecond regime. Al-
though these latencies are still an order of magnitude higher than current SANs, they push NFS into
a latency-insensitive region.

---