netsim is an online toolkit for simulating networks. It's geared toward education, with just enough real-world simulation to keep things grounded.

We've found that good resources on computer networking are few and far between. Networks are very dynamic, reactive systems, and yet the best way to learn about them is...reading RFC's? We wanted a network sandbox; something where we could play with the various parameters and see for ourselves how a network would react.

We're proud of our work after just one week of jamming - we managed to implement decent simulations of IPv4 and internet routing, a pretty solid simulation of TCP, and lovely visuals of packets moving around the network.

You can play with it yourself at https://bvisness.me/apps/netsim.

What does it do?

As of the jam, netsim simulates a simple network using TCP on IPv4. Nodes in the network are preconfigured to send messages to each other over TCP; when you click Play, they all start sending.

netsim simulates core features of TCP like the three-way handshake and retransmission. It also simulates simple congestion control, which you can toggle on and off. Different TCP control signals are color-coded, so it is easy to distinguish the handshake from ACKs from RSTs from typical data.

netsim also support IPv4 routing rules, similar to iptables. You can edit the routing rules yourself to try different routes through the network.

Clicking on a node allows you to view detailed logs for that node, including graphs of various packet stats and all the data reliably transmitted via TCP.

Also, if you click the danger button, we generate a bunch of extra garbage traffic just to make your life difficult.

How does this reinvent the wheel?

Existing network simulators are old, jank, and not usable on the web. The most popular by far, it seems, is Cisco Packet Tracer, which, I mean:

Do you want to use that? I don't. And because these tools are so archaic, they're not available on the web. This is actually a problem if you want to use these things for education these days! We wanted something we could embed directly into a web page as part of larger articles, something like Desmos for networks.

Plus, we wanted to teach networking fundamentals. Tools like Cisco Packet Tracer are, naturally, tied into Cisco hardware. I'm sure it's very useful if you need to pass Cisco's exams, but we want to teach the fundamentals to a wider audience than just network engineers! Doing so allows us to make simplifying assumptions for the sake of education, cutting through the fiddly details.

(Turns out there are still a lot of fiddly details.)

What went well?

• The visuals are fun, and useful too. When we weren't sitting there mesmerized, watching our marble machine, we were actually able to get an intuitive feel for issues in the network. I (Ben) found a lot of bugs just by thinking "hmm, that seems like too many packets and not enough ACKs!" This is very promising for educational applications; this hopefully means it can really help students build mental models.
• We actually did manage to implement a lot of serious simulation! Our simulation runs a legitimate (albeit broken) TCP stack that does, in fact, reliably transmit data. Just really slowly, sometimes.

What went poorly?

• We lost two full days to Odin bugs. Odin supports WASM, but it has not yet received much use and there were some really nasty bugs that cost us a lot of time. This is understandable, but a real bummer.
• TCP implementation took a really long time. We feel it was worth it, since our overall goal was to visually demonstrate congestion control and reliable transmission concepts, and you don't get much of that with half a TCP implementation. But it really took a ton of time. We would never have achieved as much as we did without RFC 9293 being released literally hours before we started implementing it.
• We had to spent some time building UI components and stuff, since we weren't using the DOM. This is always kind of a pain.
• The network does not recover well from disturbances. Something about our recovery algorithm for TCP is very bad right now, and once the network is unhealthy, nodes almost never ramp back up properly.

What do we want to do next?

So many things:

• Visualize send and receive windows for TCP. We ran out of time to do the visualization we wanted - although perhaps if we had done the visualization first, we would have spent less time on congestion control bugs. 🙃 Here's a sketch, anyway:

  

• Network editing - add and remove nodes, intuitively add connections. Maybe simulate routing table updates, or maybe don't?

• Visual filters - view packets related to a specific TCP session or a specific node.

• Packet inspector & packet history - view the specific contents of each packet, follow it through the network, and maybe even trace its path. Maybe you could see some packets trapped in loops!

• Keep implementing TCP more accurately, and build educational views specific to it. TCP is really complicated, but very, very relevant to most programmers today! We have some ideas for how to visualize and explain specific parts of it, but further work will be necessary to make it really approachable.

• Mobile support and whatever else we'd need to deploy broadly on the web