Bruce was asked a thought-provoking question at his SIGCOMM Keynote, which I’ll paraphrase as: How should we think about educating the next generation of students about networking, given how different and more complex today’s Internet is from the mid-90’s version your book originally used as a reference? The main point was that a lot has changed over the last 30 years, which raises the question whether or not the sum of those changes should fundamentally impact how we teach the subject.

Bruce’s answer was pretty much the same as I would have given: Because networks are both complex and constantly changing, what you need to teach students is how to reason about system design, as opposed to being overly fixated on any particular set of layers or technology choices. With the benefit of a couple weeks to think about the question, I would double down on that answer, but with the caveat that maybe it is time to rethink how the book is organized and scoped. This might help draw attention to what is most important—the invariants that survive change—while making sure students have a working understanding of today’s most important artifacts.

As a starting point, the one thing I would not change is the spirit of first sentence of the first chapter (although I would update the list of applications to use today’s vernacular):

Suppose you want to build a computer network, one that has the potential to grow to global proportions and to support applications as diverse as teleconferencing, video on demand, electronic commerce, distributed computing, and digital libraries.

My view is that framing an introductory networking course around “building” is the key to keeping system design perspective front-and-center. The rest of the first paragraph talks about selecting the right building blocks and devising an architecture to integrate them into an effective solution—valid next steps, to be sure, but this is where I might rethink the approach.

All system designs start by identifying the available building blocks, and the commodity components available today are much different than those available in 1995. So instead of starting at the very bottom and taking a bottom-up approach, I might work middle-out and assume we’ll be building our network using commodity Ethernet switches; the de facto building block of today’s Internet. This is an opportunity to drill down on an example artifact that represents a uniquely network-centric topic—where else would you learn about packet switching and switching devices than in a networking course. It also sets us up to introduce two other core networking challenges: (1) how to route across a network of switches, and (2) how to scale a network by federating multiple autonomous networks.

Generalizing on this idea, an important objective for how we teach networking is to identify the central challenges of the discipline. For example, when you teach an OS course, you know you have to cover concurrency and synchronization, no matter what else you teach or how you organize the material. Routing is one of those topics in networking. Mediating access to a shared medium is another, with Wi-Fi serving as the exemplar. Congestion control is yet another “big idea” in networking, for which TCP is the anchor artifact. As networks infiltrate every aspect of our world and the cloud becomes ubiquitous, it’s tempting to take an expansive approach, and bring as many topics as possible under the networking umbrella as possible. But I would approach the scoping question from the opposite direction, and identify the topics that are uniquely networking (and define everything else as out-of-scope). In addition to the ones I’ve identified so far, I would add one more to that list: defining powerful communication abstractions that serve as the interface between the network and all the applications that run on top of it. Defining abstractions is not unique to networking, but it is one of the most important skills students need to learn, and networking is rich with opportunities.

Where Does Architecture Fit?

There are many details to be worked out, but I think this approach can be crafted to cover the important artifacts a student needs to know about. And just as importantly, it provides an opportunity to sharpen our “system design muscles” on the hard problems at the core of networking as a discipline. The missing piece is to talk about network architecture, which I believe is another opportunity to do things differently. For the past 30 years, our textbook has introduced the Internet architecture in Chapter 1, and then used it as a roadmap for covering all the topics. Roughly speaking, there’s a chapter for each box in the architectural diagram. It’s important to have an architecture in mind before you start to build, but framing it as the Internet architecture is probably worth revisiting. Exactly what constitutes an architecture is a topic Bruce and I have touched on many times in this newsletter (for example here, here, and here)—as have others—so I’m confident we have a good place to start a discussion about the topic. The important point is that teaching students how to think about system design and teaching students how to craft an architecture are pretty much the same thing. It would be important to frame any discussion of Internet architecture in those terms, as opposed to treating it as a given.

Finally, back to the original question Bruce was asked: an interesting observation was that, back in 1995, the Internet, although already quite complex, was still simple enough to “fit” in a person’s head; the claim was that this is no longer the case. While I understand where that comment comes from—look at the explosion of RFCs for one illustrative metric—I think the most important thing an introductory network class can do is explain the Internet in such a way that it can fit in a person’s head. This “mental model” is what students take away, and it needs to include only the essentials, with everything else abstracted away. Carefully choosing examples to cover in detail is an important part of that, but the whole point is to help students build that model for themselves. My own mental model includes a note-to-self that I once knew the details, and could recover them again if needed. The details are a means to an end, not the end itself.

All of this is just me thinking out-loud about how we might approach a new edition of our main book, which is something we’re starting to do. There are certain to be more posts on the topic in coming weeks, and we’re happy to hear your feedback as we brainstorm.

Bruce was lucky enough to visit the Biblioteca Joanina while in Coimbra, which is an amazing example of functionality combined with decorative design. The preview image this week is from the vault (the only place where photography was allowed) but check out the wikipedia page for pictures of the stunning main library.

Please note that we are still looking for help in the final proof-read of our security book and will offer free copies to the most prolific bug hunters.