Reduce, Reuse, Recycle
Improving Reliability By Simplifying Infrastructure

Vivek Pai
Princeton University

While computer users would benefit if the research community improved
computer reliability to match telephone reliability, computers are far
more complicated than telephones, and no single entity controls what
most people consider "the computer" -- applications, the operating
system, and the network. Even if one were to develop a better
application design methodology, its impact would be limited by the
difficulty in getting significant numbers of applications to use the
new approach.

Instead, we focus on managing on infrastructure -- protocol evolution
will continue to add complexity to infrastructure management, and this
area provide significant opportunities for improvement. For example,
consider how protocol popularity has changed in a few short
years. Previously, an ISP serving Web, e-mail, FTP, and DNS would have
sufficed for most users, but now, even average users commonly use
Instant Messaging, VOIP, BitTorrent, etc.  Managing these protocols
requires an array of dedicated equipment, such as firewalls, packet
shapers, e-mail filters, Web caches, SSL accelerators, load balancers,
virus scanners, etc.

This growth in complexity can leave gaps in what would otherwise seem
to be a natural combination of features -- virus scanners should
examine e-mail, the Web, FTP, and IM; caching can help FTP, HTTP, and
P2P; SSL is useful for HTTP, IM, and possibly VOIP. However, without
any way of sharing infrastructure, these logical combinations cannot
be realized in practice.

We propose to improve network infrastructure reliability by
consolidating these pieces to the extent possible, via reduction,
reuse, and recycling. In the process, network operators will become
more agile in providing protection and support to emerging protocols
and services. Fundamentally, all of the services mentioned above are
"bumps in the wire" -- they take a stream of bits from the network,
and pass most along while modifying or rejecting others. Building a
support infrastructure that consolidates and shares these functions
reduces complexity, improves coverage, and eliminates the
special-purpose hardware for each task.

This task will require research in several areas: (a) design of
composable systems for network management, allowing pipelines of
services to operate on incoming/outbound data, (b) fault isolation
techniques, ranging from handling processing errors in one pipeline
stage to safely reducing boundaries between processing stages, and (c)
operating system support for scalably handling thousands of flows,
possibly spanning multiple systems. We are aided by trends in future
hardware -- multiple cores per chip, cheap memory with 64-bit
addressing, and hardware virtualization support. Our proposal can
naturally exploit all of these directions.

In such an environment, sharing becomes natural, and as techniques are
developed to protect one service against attacks, they can naturally
be used across any range of services for which they apply. Eventually,
application-neutral, best-of-breed approaches will supplant
per-application support, allowing a separation of concerns not found
in today's software design approaches.  As processors become more
powerful and memory more abundant, more services can be processed on
the same hardware, eliminating the growth of "one-off" special-purpose
appliances for various protocol tasks.