Forthcoming: Computer Networking Problems and Solutions

The new book should be out around the 29th of December, give or take a few days. For readers interested in what Ethan and I (and Ryan, and Pete Welcher, and Jordan Martin, and Nick Russo, and… the entire list is in the front matter), the general idea is essentially grounded in RFC1925, rule 11. There is really only a moderately sized set of problems computer system needs to solve in order to carry data from one application to another. For instance, in order to transport data across a network, you need to somehow format the data so everyone can agree on how to write and read it, ensure the data is carried without errors, ensure neither the sender nor the receiver overrun or underrun one another, and find some way to allow multiple applications (hosts, etc.), to talk over the same media. These four problems have somewhat proper names, of course: marshaling, which involves dictionaries and grammars; error control; flow control; and multiplexing. So the first step in understanding network engineering is to figure out what the problems are, and how to break them apart.

Once you understand the problems, then you can start thinking about solutions. As it turns out, across the entire history of network engineering, there are only a handful of useful solutions for each of these problems. There are, for instance, only two ways to solve the error control problem; you can either find some way to carry enough information to correct any errors on the fly, or you can detect errors and then discard the data, or request a retransmission. There are lot of different ways to implement either one of these solutions, but this is all implementation detail.

For each solution, some implementation is then chosen and considered in some detail (sometimes more detail, sometimes less). The idea is not to provide a definitive guide to every solution, but rather just to give the reader a sense of how the solutions outlined have been implemented in either past or current protocols.

Overall, then, the book teaches a simple workflow:

• What problems are being solved here?
• What is the range of possible solutions?
• Which solution am I looking at in this particular case, and what are the common tradeoffs for this solution?

The result is supposed to teach readers how to think about these problems as much as it is what to think. Of course the book is not going to follow this model perfectly, nor is it going to teach every possible technology. And I’m certain there are many problems, and some solutions, we have either missed or simply left out because of space and time constraints.

Is this a new introduction? I have called it this in the past, but people who have read it say calling this an introduction is a mis-characterization. Rather, this book is more about the fundamentals you need to work as an effective network engineer. It is about finding the patterns, and then using the patterns to ask the right questions.

Some has asked me: who do you think will really read this book? While the book is designed to be usable as a college textbook, hopefully the style of writing, the level of explanations, and the range of material will be attractive to every network engineer out there. There will always be things you didn’t learn about, and yet you need to know the fundamentals. Knowing the fundamentals this way should allow you to understand each space enough to either develop a lot more knowledge quickly, or to simply know when something does not sound right.

There are four sections in the book. The first covers data transport, an area I have not written about before. The second covers the control plane; this is, I would guess, the deepest part of the book technically, at least partially because this is where I spend most of my time. The third section of the book considers different aspect of network design. The final section moves away from the problem/solution/example format, and discusses current trends in network engineering. The total page count is probably close to 600, but I’ve not seen the proofs, so I’m not entirely certain.

The goal here is not to become a millionaire (although my wife would really like that!). Rather, it is to present a new way of thinking about the problem. A way that can be helpful in managing the firehose network engineers deal with, and a way that will help engineers truly become engineers.

Again, look for a publication date around the 29th of December, give or take a few days. I am certain it will not roll over into the new year, unless some major disaster strikes, but it might be published a few days earlier than the currently planned date. I’ll post here when it is available, so you can just watch this space if you’d like.