Defining “A Systems Approach”
Welcome to the first issue of the Systems Approach newsletter. We’ll be sharing our thoughts on networking and related technologies as we work on our Systems Approach series of books. We hope you enjoy an inside view of our thinking and some previews of upcoming content. To kick us off, we thought we’d start with a discussion of our guiding philosophy: The Systems Approach.
Last week we noticed that our book, Computer Networks: A Systems Approach, was discussed in a thread on Hacker News. It was nice to see mostly positive commentary, but we also noticed a fairly involved debate about the meaning of “Systems Approach”. Some readers had a pretty good idea of what we meant, others mistakenly took it for a reference to “Systems and Cybernetics”, which we definitely never intended. Others interpreted it as an empty, throw-away term. “Don’t these people read prefaces?” we thought, before remembering that we dropped the definition from the latest edition, thinking it was old news. Clearly, we had been making some assumptions that left many of our readers in the dark. Rather than just rescuing the old preface from the recycling bin, we thought it would be timely to revisit the meaning of “Systems Approach” as we’re now building a whole series of books around that theme.
The term “Systems” is used commonly by computer science researchers and practitioners who study the issues that arise when building complex computing systems such as operating systems, networks, distributed applications, and so on. At MIT, for example, there is a famous class 6.033: Computer System Design (with an excellent accompanying book) that is a typical introduction to the systems field. The required reading list is a tour through some of the most influential systems papers. The key to the systems approach is a "big picture" view – you need to look at how the components of a system interact with each other to achieve an overall result, rather than fixating on a single component (either unnecessarily optimizing it or trying to solve too many problems in that one component). This is one of the important takeaways of the End-to-End Argument, a landmark paper for system design.
A systems approach also has a strong focus on real-world implementation, with the Internet being the obvious example of a widely-deployed, complex networking system. This seems incredible now, but when we wrote our first edition in 1995, it was not yet obvious that the Internet would be the most successful networking technology of all time, and organising our book around the principles that underlie the design and implementation of the Internet was a novel idea.
The Systems Approach is a methodology for designing, implementing, and describing computer systems. It involves a specific set of steps:
Defining the problem (or the need for a new system) which is typically a combination of (a) identifying a new use case/application, and (b) incorporating a new technology or technological capability.
Specifying requirements, taking into account multiple stakeholders (e.g., those who use the system, those who administer the system, those who pay for the system, and so on).
Considering design alternatives and articulating the rationale for selecting one implementation choice over another.
Empirically evaluating the effectiveness -- with respect to the requirements -- of a realization of the design.
Extracting the lessons learned (i.e., contributing best practices and general design principles back to the field).
Over time, this leads to the iterative evolution of computing systems, for example, from time-sharing mainframes, to client/server LAN-based distributed systems, to wide-area scalable services, to today’s cloud services.
In following this methodology, there are requirements that come up again and again. Scalability is an obvious example, and appears as a key design principle throughout networking, e.g., in the partitioning of networks into subnets, areas, and autonomous systems to scale the routing system. A good example of cross-disciplinary systems thinking is the importing of techniques developed to scale distributed systems such as Hadoop to solve scaling challenges in software-defined networking.
Generality is another common requirement: the way that the Internet was designed to be completely agnostic to the applications running over it and the class of devices connected to it distinguishes it from networks like the phone network and the cable TV network, whose functionality has now been largely subsumed by the Internet.
And there are a set of system-agnostic design principles that are used extensively to guide systems designers. They are not mathematically rigorous (compared to, say, Maxwell’s Equations or the Shannon-Hartley theorem) but are considered best practices:
Separation of policy and mechanism
The end-to-end argument
Scalability through hierarchical aggregation (Information Hiding)
Optimization through caching
Separation of control and data planes
The use of abstraction to limit complexity
Most of these and more can be found in the iconic paper by Turing award winner Butler Lampson: Hints for Computer System Design.
In applying the Systems Approach applies to networking, and to our books, you’ll notice that we start every chapter in Computer Networks with our problem statement. In chapter 1 we go on to develop requirements for a global network that meets the needs of various stakeholders, satisfies scaling objectives, manages resources cost-effectively, and so on. Even though the Internet is already built, we’re walking the reader through the system design process that led to it being a certain way, so that they are learning systems principles and best practices like those mentioned above. We call many of these out explicitly in “Bottom Line” comments such as this one.
One of the most challenging aspects of teaching people about networking is deciding how to handle layering. On the one hand, layering is a form of abstraction–a fine system design principle. On the other hand, layering can sometimes prevent us from thinking about how best to implement the system as a whole. For example, in recent years it’s become clear that HTTP, an application layer protocol, and TCP, a transport layer protocol, don’t work terribly well together from a performance perspective. Optimizing each independently could only take us so far. Ultimately by looking at them as parts of a system that needs to deliver reliability, security, and performance to applications, both HTTP and the transport layer evolved, with QUIC being the new entrant to the transport layer. What we have tried to do is give readers the tools to see where such system-level thinking can be applied, rather than just teach them that the 7-layer model was handed down from on high and can’t be touched.
Hopefully this helps give some clarity around what we mean by “A Systems Approach”. It’s certainly a way of thinking that becomes natural over time, and we hope that as you read our books and these newsletters it will become part of your thinking as well.