A few weeks ago we passed the three year anniversary of founding Systems Approach LLC. The Systems Approach, of course, is much older than that, but it seemed like a good time to look back and assess what we’ve been able to achieve since we made the decision to focus on producing books and other educational materials approximately full-time.
As many of our readers will know, Larry and I have been writing books together since 1995, and the Systems Approach has been our guiding principle from day one. When Larry first approached me to come on board as a co-author, he already had the title picked out and a contract in place with Morgan Kaufmann Publishers. MKP in those days was a small, CS-focussed press whose main claim to fame was publishing “Computer Architecture: A Quantitative Approach” by Hennessy and Patterson. That book had already achieved legendary status and a huge chunk of the computer architecture market, so our goal was to be as much like them as possible. That included having a paper dust-jacket in a shade of beige and a similar structure to our title: hence “Computer Networks: A Systems Approach”.
To be honest, I needed Larry to explain what he meant by “Systems Approach” even though I’d been working on systems research for quite some time. As we say in the book’s preface, the key to the Systems Approach is the “big-picture” view: you don’t get to optimize inside a single box without thinking about the bigger interactions among components. For me, one of the pivotal moments that turned me into a “systems thinker” was hearing David Clark present the ideas of Application Layer Framing at the 1990 SIGCOMM conference, which made me realize that you shouldn’t just optimize a single layer of the protocol stack without thinking about how other layers depend on the services of that layer. In recent years, the rethinking of layers that is apparent in QUIC is a good example of how systems thinking is applied in protocol design–and also a reminder that rigid layering is often not the best way to think about networking.
The big change for us three years ago was that I left the corporate world (in a so-called “retirement” from VMware) while Larry moved to part-time at ONF and Princeton, so the work of Systems Approach LLC became our “main job”. Coincidentally, the publisher of our original book from 1995 had just pushed us to produce a sixth edition and so our first order of business was to complete the edits and handle all the back-end processing that happens when doing a book with a big publisher. The content edits were largely in place thanks to the open source nature of the book (we’d been taking inputs on GitHub since the fifth edition). One of the few valuable tasks performed by a big publisher is a professional copy edit, which takes a fair bit of time to review. So we were busy enough in those first few months putting the last finishing touches on the book. We also undertook a complete update to the ancillary materials for teachers (lesson slides and solutions to the exercises). Experience has shown that instructors struggle to get access to these materials through the publisher, so do reach out to us if you are looking for them.
Our main vision for Systems Approach, however, was not to keep on working for Big Publisher but to produce our own books. So back in 2020 we drew up a list of possible topics to cover in the Systems Approach book series and in the last three years we have chipped away at that list, occasionally adding to it and sometimes shelving topics as they lose appeal. (I’m pretty sure a book on blockchains is off the table now.) Here are the books that we have managed to complete in the last three years: Software-defined Networking, TCP Congestion Control, Edge Cloud Operations, and Private 5G. Add in the revision of the big textbook and that’s five books in three years, which feels like a decent amount of progress. On top of that, we’ve created an online class about Magma, the open source mobile core project.
We are both fans of physical books, and we are benefiting from the increased quality and cost-effectiveness of print-on-demand that enables us to make print books without a big publisher. There is something very satisfying about seeing your work in a printed volume, and so we make the extra effort to get our books nicely formatted and ready for printing once we are fairly happy with the content. We’ve also worked with translators to produce foreign language versions of several of our books. A particular highlight was working with three of our Japanese colleagues to expand and customize our SDN book for the Japanese market.
Producing physical books turns out to be something that we really enjoy. It is admittedly a bit annoying to get all the page breaks in the right place and wrestle with LaTeX to make everything look nice, but in the end we believe we’re producing a professional and aesthetically pleasing product. I also enjoy hunting around for the ideal cover art; we’ve made extensive use of the public domain images on Unsplash. We very nearly ended up with a picture of a marijuana farm on the cover of the 5G book–which would have been fine, I guess, but we opted for something less potentially controversial.
Much of what we have written draws on our personal experience (especially Larry’s–he’s really quite good at building systems and then writing about them). Three of the above books are based on experience with open source projects such as Aether and other SDN projects of the ONF. We also leveraged my experience with the open source projects Open vSwitch and Magma. In our ideal world, every book we write would have a companion set of open source software so that students could get hands-on experience with whatever it is we are writing about. We’ve met that goal for all the books to date aside from TCP Congestion Control. Of course, there is open source code for congestion control, but it’s mostly in the Linux kernel and thus not ideal for our instructional purposes. As Larry pointed out in his post about Aether OnRamp, there is more to making a technology accessible than open source software.
Because we make all our books freely available online, we’re not expecting to make much money from selling physical books and ebooks, and we are totally meeting those expectations! We’ve discussed the rationale behind this choice before–we’re more interested in impact than revenue. But of course it’s much easier to measure revenue. Once upon a time our publisher even measured course adoption rates for us (ah, those halcyon days of working with a small publisher). Today we are measuring things like the number of readers of this newsletter (growing nicely, thank you–tell your friends) and visits to our web sites (also doing well, although maybe a bit less well as Google search deteriorates). We definitely appreciate direct feedback from our readers. We even have our favorite Amazon one-star review (called “Wall of Text”) that we use as inspiration to write more concisely and to draw more pictures.
The open source model is working well in my view. We’ve received dozens of corrections, issues, and pull requests from around the world, and we try to thank every contributor in the preface of each book. Sometimes it’s corrections to our grammar, sometimes it’s a bigger error like mixing up big- and little-endian (which was wrong in every edition of our big book until last month). Our books are better because we adopted this model. And occasionally one of us gets the satisfaction of resolving a merge conflict using git so we feel smart for a day.
At this point we have a number of books in the pipeline. Network security feels like a topic that we should cover, but will take some time given our relatively limited first-hand experience. There is part of me that wants to tackle quantum computing but that would definitely be a stretch. Machine learning is clearly close to our hearts and its application to networking is a topic that we plan to cover soon. We find that writing these books (and this newsletter) keeps us hungry to understand new technologies well enough to explain them to others, especially when there is a real system to underpin our learning.
Got an idea for something that Systems Approach should cover in either a book or a newsletter? Send us a note.
In our periodic coverage of broken networks, Australian Telco Optus made a solid contribution last week with an outage lasting over eight hours. The best analysis we’ve seen so far comes from Mastodon user Rob Thomas who used routing advertisements to deduce the root cause (suspected to be route reflector upgrades gone wrong). Optus has said little of substance other than to claim such outages are not unusual (!).
Speaking of Mastodon, we will soon celebrate our first anniversary of leaving the dead bird site. Follow us here.