Networking students need an explanation of the internet that can fit in their heads
- Reference: 1763017148
- News link: https://www.theregister.co.uk/2025/11/13/networking_students_need_an_explanation/
- Source link:
It’s a good question because we published the first edition of our book [1]Computer Networks: A Systems Approach in 1996.
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.
[2]
With the benefit of a couple of 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.
[3]
[4]
As a starting point, the one thing I would not change is the spirit of the 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 from 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:
How to route across a network of switches
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.
[5]BGP’s security problems are notorious. Attempts to fix that are a work in progress
[6]DNS security is important but DNSSEC may be a failed experiment
[7]To progress as an engineer career-wise, become a great communicator
[8]What does it mean to build in security from the ground up?
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 unique to 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.
[9]
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 – 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.
[10]
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. ®
Get our [11]Tech Resources
[1] https://book.systemsapproach.org/index.html
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aRW6R13L8mit-q54wJi7IgAAAQg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aRW6R13L8mit-q54wJi7IgAAAQg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aRW6R13L8mit-q54wJi7IgAAAQg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2025/08/27/systems_approach_securing_internet_infrastructure/
[6] https://www.theregister.com/2025/07/25/systems_approach_column_dns_security/
[7] https://www.theregister.com/2025/05/18/communications_for_engineers/
[8] https://www.theregister.com/2025/02/02/security_design_choices/
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aRW6R13L8mit-q54wJi7IgAAAQg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aRW6R13L8mit-q54wJi7IgAAAQg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[11] https://whitepapers.theregister.com/
Hey, i know that book!
My university uses the Systems Approach book to teach networking! The specific study i was doing only did essentially a "networking 101" class, which wasn't much trouble for me as i'd been working as a network engineer for a few years at that point, but i really enjoyed being able to dig down into topics while bored during lectures.
For me personally, the high-level overview helps me more than anything else. Not just in networking, for any complex topic. This allows me to apply logic to new situations, slot it in to the mental model in my head, and work from there. This also helps slowly building up knowledge over time, it's all part of the model, it all makes sense, and it's all deductible. When misremembering something, it'll also set off alarms as it doesn't make sense in the mental model.
As humans our storage is limited and bit rot is a problem, we can't possibly expect to remember everything and also keep up with changes. We have to play to our strengths: Logic, reasoning, deduction.
Good question
" Routing, routing, traffic management… and routing " — would be my answer albeit not a network engineer. ;)
While it's always DNS, I cannot begin to list the mindless cockups with routing of one sort or other with which the network gods have seen fit to afflict me.
Network engineers appear to fall into two distinct camps: ¹the truly full bottle and ²the profoundly clueless. To add insult to injury the latter seem to have a propensity to rematerialise in IT security.
" Bless me, what do they teach them at these schools ? — Prof. Digory Kirke. (Not that Plato would be much help here.)
What's the goal?
I think the most important question when deciding to teach anything is to have an idea of who is reading this and what they intend to do at the end, then start with a high-level summary of that part. It doesn't mean you only cover the things they'll deal with most often, but it does at least change the order you cover them.
For networks specifically, there are at least two and probably more approaches which I will simplify as the administrator approach and the programmer approach. The administrator wants to use all these existing networking things from switches to software to connect their equipment to a network, that network to the internet, that network to another network over the internet without the rest of the internet getting in the middle, all of those things at the same time while consistently routing efficiently so traffic never goes over the more constrained or expensive or less secure parts unless it has to, then all the techniques you need to test that traffic does go where you want and to collect information about what it did so you can modify it. The programmer wants...exactly the same thing, but they want to do it from the perspective of writing a program that has some traffic and getting that traffic delivered, first over a network with no restrictions, then over a network that has many normal ones, then constrained ones, then from all those complex networking scenarios which means they'll also need to learn how those work in order to know what they need to include in their code. The introduction that works for one is likely to put off the other because the programmer doesn't want to start with how you configure VLANs and the administrator doesn't want to start by talking about what a socket's communication domain is.
Give the requirements
As well as the first statement, I would cover what people expect today.
Bits of the network will need to be replaced, for example your home router is connected to your service supplier. If they change their hardware, it should be transparent to you The "network" should carry on working.
You should not be impacted by other people. If the people next door are hammering the network, it should not affect you. If there is a lack of capacity they should be slowed down - not you.
When I stream my latest show - I expect it will display without hangs.
If you pay for a premium service, it should continue to work even if someone cuts an undersea cable.
Re: Give the requirements
This is only true
You should not be impacted by other people. if you pay for business internet. Otherwise, your video call will have to wait for my porn download to complete before its going to get any more of the available shared bandwidth.
The Internet is not a big truck...
...it's a series of tubes.
I find it very interesting to note that security doesn't seem to be a top concern for a new edition of a book designed to teach networking - in fact, the entire concept does not even appear in this article. It looks like, in some regards at least, things haven't changed that much since the 90s.
The Internet hasn't really changed since 1995.
In fact, it hasn't changed much since Flag Day, which was January 1st 1983.
Simply put, "The Internet" is the world-wide network of computers and networks that use the TCP/IP protocol suite to communicate.
The types of software that makes use of it, on the other hand ...
Re: The Internet hasn't really changed since 1995.
A lot more IPv6, a bit less IPv4, unless you count the explosion of things like CGNAT. Which exists due to the slowness or transitioning to the former. And now the growth of new and exciting transport protocols like QUIC. And yes, the fact that in 1995, probably 90% of the internet's traffic was "useful" stuff, and 10% was e-mail spam. Now, 90% of a vastly higher torrent of traffic is junk / nonsense / malware / attacks / slop, and only 10% is actually useful. But that's a whole different story!
Re: The Internet hasn't really changed since 1995.
IPv6, CGNAT and QUIC are (arguably, perhaps) all part of the TCP/IP suite.
What is carried over the network has no bearing on how the network is described.
At the risk of derailing with rants: consistent terminology defined by function!
Drilling in that the *functions* are what is important, not (unless you are really drilling down to minutiae this lecture) the implementation, especially not what is inside those black insects with the shiny legs.
The last commercial network project I worked on, none of the diagrams presented by the younger half of the team made any sense: there were no routers anywhere. Even though there were multiple LANs all operating with their own address ranges - and the magic ability to have some, but not all[1], traffic cross from LAN to LAN, like, um, an internet[2].
Turns out the boxes labelled "switch" were all routers, only because they were implemented with FPGAs and ASICs, just like the manufacturer's switches are, this meant they were no longer "routers" but "layer 3 switches"! Nope. If it routes, it is a router[3]. It may handle faster traffic, in which case give it a model name with "Turbo" or "3000" in it.
It is hard to have a sane a discussion about a network if people randomly change terminology, especially when there is only room at that scale to put one word into the box on the page. How this didn't get pushback from the client terrifies me: one bunch of youngsters approving the work of another bunch of youngsters.
[1] e.g. simple broadcasts constrained to a single LAN - i.e. totally normal stuff.
[2] but, FWIW, not via THE Internet, for perfectly sound reasons;
[3] and descriptions in today's search do not help: "a layer 3 switch can work as a switch as well as a router". No shit, Sherlock.
Google maps for Networks !!! :)
"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."
This so makes sense.
The way most people learn, in general, is to start with a 'high-level map' that you can hold in your head.
As you require more detail you 'zoom in' on specific items that reveal more information that can be applied generally to your 'high-level map'.
Think of it as the mental equivalent of zooming in on a Goggle map, the closer to the 'human' scale you get the more detail you see.
Starting too early with the minutae of 'Networking' will just complicate teaching the basics and frighten them away !!!
The biggest help is getting hands-on experience in a lab with real kit ... practical experience is such a useful reinforcement for teaching ... period.
[Try it out for real ... find the problems/failures/quirks ... fix them and understand why they happened ... scale the information learnt to 'real life' scale.]
:)