SIGCOMM 2026 Education Workshop pushes networking courses toward design
The event was the SIGCOMM Education Workshop 2026, officially titled "Networking Education for the AI Generation," or A4NE. It ran as a hybrid, full-day workshop on August 17, 2026, alongside the main SIGCOMM conference in Denver. Davie refers to it as "Networking Education in the Age of AI," which does not match the official title. The event is the same. Its call for papers said "The AI revolution demands we rethink networking education from the ground up." It invited work on frameworks for AI integration that deepen understanding rather than shortcut learning, transform labs and assessment for contemporary realities.
The day was built for discussion rather than a series of talks. Accepted papers were non-archival and were discussed on themed panels, one on AI and one on curriculum. The afternoon had an open-mic session moderated by Jim Kurose in person and Davie remotely, followed by small "Birds of a Feather" breakout groups. Peterson moderated the curriculum panel. Authors were also invited to share teaching materials such as labs, assignments, rubrics, slides and datasets.
Davie is open about his biases. He writes that he has repeatedly voiced his skepticism about AI in education (and other fields), and he recalls studying during an earlier "age of AI" in the mid-1980s that ended in an AI winter. He also joined only from lunchtime, eight time zones away. His column is one participant's account of the afternoon, not a formal set of workshop findings. The consensus he describes came from a breakout group with three senior textbook authors in it, not from a vote.
He still comes away with a clear thesis: networking students must learn system design as a discipline, not just the details of existing artifacts. Protocols stay in the syllabus as case studies that show the principles at work.
QUIC and RFC 9000 show why transferable concepts outlast protocol trivia
Peterson opened the breakout with QUIC as his example. It is new and complicated enough that many introductory courses still leave it out. His position, which Davie shares, is that a student meeting QUIC for the first time should be able to make sense of it by relating it to things they already understand: reliable transmission, congestion control and end-to-end security.
The IETF standard shows why that works. RFC 9000, published in May 2021, is titled "QUIC: A UDP-Based Multiplexed and Secure Transport." It gives applications flow-controlled streams, low-latency connection setup and the ability to move a connection to a new network path. QUIC packets travel inside UDP datagrams, which makes deployment through existing networks easier. The QUIC handshake builds in TLS 1.3. Connection IDs let a client's connection survive a change of network path or a NAT rebinding. RFC 9000 covers the core protocol only. Separate companion documents cover TLS integration, loss detection and an example congestion-control algorithm.
A student who has only memorized TCP header fields gets little from that list. A student who understands why a reliable transport needs acknowledgments, how congestion control keeps the network stable, and what it costs to tie a connection to one IP address can see QUIC as new answers to familiar problems. That is the mental model Davie and Peterson want to teach. It also explains a lot of practical behavior: a transport running over UDP looks different to firewalls and packet captures than a TCP flow does, and the reasons follow from its design.
Davie applies the same test to TCP. He wants students to understand trade-offs any reliable transport faces, such as how hard it is to estimate round-trip time accurately and to keep a control system stable when it has only partial knowledge of network conditions. For BGP, which he calls famously complex, he expects a one-semester student to grasp the broad design problems it tackles. He does not expect that student to configure BGP policy for an ISP.
Rodney Brooks and the symbol-grounding problem shape the case against LLM-only learning
Davie ties the argument to AI by quoting roboticist Rodney Brooks on the symbol-grounding problem. Brooks argues that robots can't rely on transformer-style LLMs for tasks because the models handle words without any link to the physical objects the words describe. Davie thinks networks work the same way. Knowing how transport protocols relate to end-to-end security is different from knowing how people usually write about transport protocols. He says his own experience of asking an LLM about QUIC and the Internet's hourglass architecture matched that view.
The workshop papers give this idea some data. The paper "An Agentic AI Approach for Hands-on Networking Education," from University of South Carolina and Fort Lewis College researchers, starts from the point that general-purpose LLMs can explain networking concepts but know nothing about a particular lab manual or the live state of a student's lab. Their system builds a knowledge base from the course manuals and uses retrieval-augmented generation (RAG), which feeds relevant documents to the model. It also has read-only tools that inspect the student's running IPv6 routing lab.
The authors checked the answers themselves on a set of 100 lab-specific questions:
| Configuration | Correct | Partially correct |
|---|---|---|
| LLM only | 34 | 17 |
| Document-only RAG | 79 | 9 |
| Full agent with live-state tools | 91 | 9 |
Those numbers apply to one lab sequence and one question set. They say nothing about AI assistants in general. The direction still supports Davie's point: accuracy rose sharply once the model could see the actual course material and the actual network state. The same paper warns that general assistants may hand out the final commands too early, taking away the student's chance to reason through the debugging.
A Cisco paper at the workshop makes a similar point about working engineers. It describes "solution-jumping" during outages, when engineers reach for a reload or a generative-AI fix instead of finding the root cause, and proposes training that requires an "Assess and Acquire" phase before any "Act" phase.
"Trust, but Verify" and "Grade the Learning" move assessment away from code
The practical core of the workshop was assessment. Davie reports that he remains skeptical of the value of using LLM-generated code in production, because of the risks of hard-to-detect bugs and difficulty of maintenance. For students tackling bigger and more interesting networking problems, however, he is willing to suspend disbelief. One paper Davie mentions argued that AI coding agents let students take on larger, more realistic system-building and measurement assignments, and that learning can be assessed by having them discuss the design.
Several accepted papers push the same way:
- In "Grade the Learning, Not the Implementation," Oliver Hohlfeld of the University of Kassel argues that if grading rewards implementations and written documentation, AI can meet those criteria without the student understanding anything. Drawing on a graduate Internet Measurements course, he proposes assessing the learning rather than the artifact.
- In "Transport It Your Way," UC Berkeley researchers say an upper-division project built around implementation can now be completed end to end by a coding agent. They propose a redesign that puts student effort into system design and trade-off analysis, and lets students use coding tools for the implementation.
- In "Trust, but Verify," Tanya Shreedhar and Christoph Lofi of TU Delft name a failure mode "vibe networking": accepting an AI answer because it looks plausible, without checking whether it works as claimed. Their course design gives the AI three roles. First it is an adversary whose calculations students redo by hand. Then it is an assistant whose proposed experiments students run on a live network. Finally it is an examinee whose diagnosis students confirm or refute from their own packet captures. Students are graded on their checking, not on the model's output.
- In "The Assessment Gap," Swarthmore's Ranysha Ware and Vasanta Chaganti argue that banning AI is neither enforceable nor sound teaching. They propose step-by-step changes, from giving proctored exams more weight to redesigning labs around process and reasoning.
The TU Delft design is sized for a nine-week undergraduate course of about 500 students, but it is a proposal, not a report of results. None of these papers is a controlled trial. Taken together, they show that networking educators with very different teaching setups are independently moving grades away from code output and toward reasoning and measurement.
A measurement study at the workshop tracks the shift in practice. "From Protocols-to-Prompts" analyzed 1,318 GitHub repositories of open networking course material from 2009 to 2026, using November 2022 as the dividing line. In the 208 repositories that span that date, the authors found a significant drop in mechanism-centric vocabulary and a rise in orchestration- and API-layer content. They also report Docker use rising from 9.6% to 14.3% and GNS3 overtaking Mininet as the most common emulation tool. That decline in mechanism-level content is exactly what Davie and Peterson are arguing against.
Networking Unplugged and law-school case studies bring design into the classroom
The discussion that impressed Davie most was about getting students to engage with the design process itself. MIT's Karen Sollins described running systems classes like law-school case studies. Instead of lecturing, she assigns papers and has students discuss what constraints led to a design and what alternatives its designers considered. Davie contrasts this with his own past teaching, which walked students through a design in the hope that the insights would stick.
"Networking Unplugged," another accepted paper, removes computers entirely. In one exercise, pairs of students get a piece of rope and must design a way to send bits along it, which leads them to rediscover encoding schemes such as NRZ and forms of modulation. The authors say they have used these activities for about a decade and report positive, informal observations about engagement. They did not run a quantified evaluation.
Abstraction was the principle discussed most. Davie defines it as hiding detail behind an interface or inside a model. Kurose suggested using Zoom to teach how modern applications work: not as simple end-to-end connections but as distributed systems with major parts running in cloud datacenters. Davie says their new edition explains application architecture the same way. To understand a multipoint control unit (MCU) serving a large video call, a student can set aside the details of the link between client and datacenter. The warning that goes with it is that abstracting away the wrong details can cause trouble later. Davie cites the original design of HTTP over TCP as a well-known example.
Kurose also offered a reminder about what actually gets a textbook adopted. Programming exercises and Wireshark labs matter, he said, but so do well-made animated PowerPoint slides. Davie concludes that a book alone won't be enough and that he and Peterson need to produce supporting teaching materials for the seventh edition of Computer Networks: A Systems Approach. The Systems Approach books are open source and free on GitHub.
What this means for IT teams and learners
If you hire, train or mentor people who work with networks, the decision is about what to test and what to teach. Tools can now produce configuration files and code on demand. The scarce skill is reasoning from a problem to a design and checking the result against a real network.
For sysadmins and developers teaching themselves, this points toward a problem-first approach: learn what reliable delivery, congestion control, path changes and end-to-end security each require, then study TCP, QUIC and BGP as different answers. For team leads, the "Trust, but Verify" pattern translates well to the workplace. Treat an AI assistant's network diagnosis as a claim to confirm with a packet capture or live device state before acting. Treat an AI-generated fix the way the Cisco paper suggests: assess the problem first, then act.
- The SIGCOMM Education Workshop 2026 took place on August 17, 2026, in Denver as a hybrid event, and its accepted papers are non-archival discussion papers, not peer-reviewed trials.
- Davie and Peterson argue that students should understand the problems behind protocols well enough to make sense of new ones such as QUIC, which RFC 9000 defines as a UDP-based, multiplexed and secure transport.
- Several workshop papers propose grading students on design reasoning and verification rather than on code that an AI agent can now write.
- In one South Carolina lab study, an AI assistant grounded in course manuals and live lab state answered 91 of 100 questions correctly, compared with 34 for an LLM on its own.
- A study of 1,318 GitHub course repositories found mechanism-level content declining since late 2022 while orchestration content grew.
- Checking any AI-generated network diagnosis against a packet capture or the live device state before acting on it is the most transferable practice from the workshop.
Davie describes this as a perfect time to be writing a new networking textbook. The accepted papers back him up in one respect: from Berkeley to Delft, educators are redesigning projects and assessments around design and measurement, because implementation alone no longer shows what a student understands. The seventh edition of Computer Networks: A Systems Approach, and the teaching materials Davie says it needs, will test how far a problem-first approach can go within a single semester.