A few weeks ago I took part in the SIGCOMM 2026 Education Workshop, provocatively titled “Networking Education in the Age of AI”. Perhaps that title isn’t provocative to most educators today, but it is to me: I’ve repeatedly voiced my skepticism about AI in education (and other fields). I was also a student in another “age of AI” in the mid-1980s, which was followed by one of several “AI Winters,” but of course that couldn’t happen again, right? Fortunately there was much more to the workshop than its title might suggest, and Larry and I came away with some fresh energy and new ideas on what we still need to do for our 7th edition. I should mention that the event was a successful hybrid event, thanks to some serious effort by the organizers and support from SIGCOMM to use professional camera operators and audio gear. There was no escaping the early wakeup call to attend an event eight time zones away, but at least I didn’t need to fly anywhere. The large number of remote participants and high-quality setup ensured that the interactions never devolved into local-only discussions (although I missed the coffee breaks). I’m going to have to leave out a lot of what was good about the workshop (especially since I only joined at lunchtime) but I recommend taking a look at the accepted papers and artifacts to get a sense of the level of creativity and enthusiasm that was brought to the occasion. Notably, the papers were not actually presented; in some cases they were summarized or provided a jumping off point for a discussion. But this was a real working session, not a set of paper presentations. Engaging students with design One highlight for me was co-chairing an open mic session with Jim Kurose. Jim’s networking book (co-authored with Ken Ross) is the leader in our field, with Computer Networks: A Systems Approach at best a distant second. In a discussion about different teaching approaches including the use of labs as a primary teaching tool, I asked a question about the role of programming assignments in driving adoption of a textbook, and Jim’s answer was something like “programming exercises, Wireshark labs, etc.—all important, but don’t underestimate the value of nice, animated PowerPoint slides.” It’s a reminder that we have more work to do than just writing a book if we want it to be chosen for classroom instruction. One reason this is challenging is that neither of us has taught using our book for a long time – in my case, all my classroom teaching was in graduate classes that used systems papers rather than a textbook as the assigned reading. There were a dozen speakers in the open mic session, all of whom had something worthwhile to say, but I’ll highlight a few things that stuck with me. Karen Sollins shared some experiences in modeling her systems classes on law school case studies. The idea is that the professor doesn’t deliver a lecture but rather assigns papers that get students to talk about what goes on in systems papers. They might discuss questions such as “what constraints led to this system design” or “what alternatives were considered by the designers.” This contrasts with the more traditional approach (which I recall using when I was teaching) of walking the students through the design as I understood it, hoping they would walk away with some insights. This importance of getting students to engage with the challenges of the design process came up over and over, and it gets to the heart of what we are trying to emphasize in our new book. To take an example, we don’t simply want students to read our book to learn how TCP works; we want them to understand the tradeoffs that have been made and broad challenges that any reliable transport has to deal with, such as the difficulty of accurate round-trip time estimation and of achieving stability in a control system with imperfect knowledge of current conditions. One approach to getting students engaged in design has them tackle problems in class without the use of computers, described as “Networking Unplugged”. For example, pairs of students are given a piece of rope and asked to design a mechanism to send bits along it, leading them to “discover” encoding techniques such as NRZ and various forms of modulation. Of course there was plenty of discussion about using AI in teaching. One positive view is that students could be given bigger and more realistic system-building and measurement assignments because of the availability of AI coding agents to take on the implementation tasks. One paper made this case and combined it with suggestions on how to assess how well students are learning by getting them to discuss the design. Test the learning, not the implementation. I remain skeptical of the value of using LLM-generated code in production, because of the risks of hard-to-detect bugs and difficulty of maintenance (among other concerns), and my experience suggests code generation is a small part of building and shipping production systems. But as a tool to help students tackle more interesting and complex networking problems, I am willing to suspend disbelief. There is also a good argument for using open source models and shared research infrastructure especially given the dubious financial position of the AI model giants. I was intrigued by a discussion on how one becomes a networking educator. My contribution – I learned by watching and emulating the experts who I was lucky to work with at MIT – was not entirely satisfactory to me, and I continue to ponder this question. For one thing, I never had to supervise grad students myself, so there are some definite holes in my experience (which are growing in the “AI era”). An interview with me conducted in 2020 by SIGCOMM chair Matt Caesar, who generously calls me a great educator, contains a few ideas, but this seems like a topic we need to invest more time in, especially as we think about what extra materials need to accompany our next book. What remains at the core? Larry and I joined a breakout to discuss the questions: “What should remain at the core of networking education? Which traditional topics should we keep, and which should we rethink?” Larry started the discussion with the motivating example of QUIC, which is new enough, and complex enough, that it’s missing from a lot of introductory networking courses. His position (which I share) is that a student encountering QUIC for the first time should be able to make sense of it, by relating it to other things they already understand (like reliable transmission, congestion control, and end-to-end security). And from that it follows that we need to teach students enough about the underlying principles of networking and system architecture so that they can make sense of a new thing and fit it into their mental model. This brings us back to the centrality of understanding system design as a discipline, not just learning the details of the existing artifacts. We use the artifacts to illustrate principles at work and to highlight challenges that have existed since the early days of networking. We also highlight the role of judgement: deciding how to make certain tradeoffs by judging the relative importance of different axes by which a system is measured (performance, scalability, reliability, evolvability, etc.). This gave me my opening to elaborate on my belief that teaching mental models is central to what we as educators need to do. I managed to quote Rodney Brooks one more time on the symbol-grounding problem. He makes the point that robots can’t use transformer-like LLMs to reliably perform tasks, because LLMs don’t have grounding in the real world of physical objects in which robots operate. They manage symbols (words) but can’t connect those words to real objects. I believe this is equally true when the objects in question are networks. A real understanding of, say, transport protocols and their relationship to end-to-end security is not the same as how the words written about transport protocols normally show up in a document. Certainly this matches my experience from asking an LLM about QUIC and the Internet hourglass for a previous discussion about LLMs in networking education. I was challenged on the question of how one builds a mental model of networking, and my initial answer – that it is built up over years of experience – was rightly challenged by Jim as well. What can we teach in a one semester course if that’s the expectation? To take an example of a famously complex protocol, I think it’s fair to expect that a student can learn the broad design challenges that are tackled by a protocol like BGP, while we would not expect them to be able to configure BGP policies for an ISP at the end of one semester. So our approach takes the problem/solution model, where understanding the problem space is more important than learning every last detail of the protocol that addresses that problem. And a semester worth of such problems should give them a solid mental model to build on going forward. There was also a lively discussion about which principles need to be taught. We particularly discussed abstraction, which I think of as the hiding of details behind an interface or inside a model. As an example, Jim had suggested using Zoom to teach students about modern applications, which are increasingly not simple end-to-end connections but rather a rich distributed system with significant components living in cloud datacenters. (This is exactly the way we are explaining application architecture early in our new edition.) One way to apply abstraction in this case is to abstract away the details of the connection between the client and the datacenter. Not because they are uninteresting or unimportant, but because you need not worry about them if your goal is to understand the workings of a multipoint control unit (MCU) serving a large video conference. At the same time we need to teach about how abstracting away the details can lead to later problems, of which the initial design of HTTP over TCP is a famous example. Perhaps it was the presence of three senior textbook authors in the room that did it, but we did seem to have something like a consensus around a few ideas: teaching principles and the design process more than artifacts; helping students build a solid mental model of networking; and using a problem/solution approach rather than just teaching the current set of protocols. It’s clear that networking education is changing and the issue is top of mind for many SIGCOMM attendees. The workshop was both a bit of validation that we’re on the right track with our book, and a reminder that a book on its own won’t be sufficient. It’s a perfect time to be developing a new textbook, but we also need to develop additional teaching materials that will assist the community of educators in this changing landscape. Speaking of Rodney Brooks … … his new piece on time scales for technology deployment draws on his own experience with AI that goes back to the 1980s. He has a good track record predicting the rate of new tech deployment (and offers a good antidote to the current hype for AI). Yet another sobering paper suggesting that AI may be impeding students’ ability to learn. Very relevant to the discussions at the workshop. You can find all the SIGCOMM talks on YouTube, and a good place to start would be SIGCOMM award winner Walter Willinger’s keynote. We share some of his concerns about AI models and are big fans of his work on traffic modeling. ® Larry Peterson and Bruce Davie are the authors behind Computer Networks: A Systems Approach and the related Systems Approach series of books. All their content is open source and available for free on GitHub. You can find them on Mastodon, their newsletter right here, and past The Register columns here.