One of my own old blog posts. Incrementally refactors normal Enumerator and Observer interfaces (in the object-oriented sense) using algebraic reasoning, gradually bringing them closer and closer to realistic networking protocols, and quite quickly arriving at a place where the networking concepts of “acknowledgement of messages” and “flow control to avoid overwhelming a receiver” fall out for free.

Extra for experts. A full textbook covering advanced topics in wireless communication.

This textbook […] explains the web of concepts underpinning these advances [in wireless communications] at a level accessible to an audience with a basic background in probability and digital communication. Topics covered include MIMO (multiple input multiple output) communication, space-time coding, opportunistic communication, OFDM and CDMA. […] This book is intended for use on graduate courses in electrical and computer engineering

This is the story of a one-afternoon hack that turned into a one-weekend hack. I woke up on Saturday with a silly idea: what would it be like to use content-defined chunking (CDC) and serve the chunks over DNS?

A fabulous reference resource from the Jepsen and Antithesis teams. A glossary of key concepts related to distributed systems.

Let’s do experiments on measuring the internet, at scale, from multiple perspectives! (Got a query you want to run? I have tokens to spend!)

RIPE Atlas is a global platform for Internet measurement. Thousands of volunteers all around the world allow their machines to be used to run pings, traceroutes, DNS queries and so on. Users ask a question, the system selects a subset of probes, all probes run the query, and the system collects the results and timings.

A very interesting blog by Internet veteran Geoff Huston. Deep articles about IETF standards, BGP, DNS, IPv6 deployment, and the economics of the Internet.

A daily dashboard and set of statistics on the Internet’s BGP routing table. See also the ISP Column.

An accessible and informal discussion of threat modeling, with examples. See also the Threat Modeling Manifesto.

An architectural white paper on secure distributed state synchronisation (including key management), from (inter alia) the author of the Noise Protocol Framework.

Implementation tricks needed to implement a production-scale BGP speaker able to cope with “tends of millions of routes”. Constantly changing routes, at that.

Recent research on intra-datacenter routing topologies:

We design and deploy in production the first flat datacenter networks. Our design, called RNG, is based on quasi-random graphs. While the cost and fault-tolerance benefits of such topologies have been long known, their practical realization has been hampered by a lack of scalable routing and cabling approaches. RNG has a new distributed routing protocol that exploits the properties of random graphs to find a large number of edge disjoint paths between pairs of endpoints. It uses a novel passive optical device that internally shuffles cables, which makes its cabling complexity similar to that of fat trees. We show that RNG matches or exceeds the performance of fat trees for a range of traffic patterns, despite being up to 45% cheaper. RNG is now the default datacenter network for most workloads at Amazon.

An open-source tool that bypasses deep-packet inspection by faking TLS ClientHello packets with a low TTL, fooling the inspector. A concrete demonstration of the leaky abstraction that “layering” is.

Huston describes a clever (ab)use of the DNS system to query the ASN-to-prefix mapping database. DNS is a global, replicated key-value store that is useful for much more than just mapping hostnames to IP addresses. See also this.

Geoff Huston’s annual review of BGP statistics from 2025:

At the start of each year, it’s been my practice to report on the behaviour of the Internet’s inter-domain routing system over the previous 12 months, looking in some detail at some metrics from the routing system that can show the essential shape and behaviour of the underlying interconnection fabric of the Internet.

See also the daily CIDR Report.

A quick overview of length extension attacks on constructions involving cryptographic hash functions. (TL;DR: Use HMAC; see the “How to do it right” section of the post.)

A three-part series from the Tailscale people on how they are thinking about and improving NAT traversal for peer-to-peer connectivity.

• Part 1, “NAT traversal, and how we’re improving it” (this linklog entry)
• Part 2, “Challenges in cloud environments”
• Part 3, “Looking ahead”

A recent stab at “personal cloud” network management.

Our mission is to make sure peer-to-peer, user-controlled, community software can beat Big Tech solutions. That’s why we’re working on platform fundamentals that would open the way for our FOSS stack to match the usability and convenience of proprietary platforms.

Phil Eaton on orienting oneself when beginning the study of distributed systems:

Distributed systems is simply the study of interactions between processes. Every two interacting processes form a distributed system, whether they are on the same host or not. Distributed systems create new challenges (compared to single-process systems) in terms of correctness (i.e. consistency), reliability, and performance (i.e. latency and throughput).

Phil’s recommendations are to find a couple of friends and work together on reading Martin Kleppmann’s book Designing Data-Intensive Applications and working through MIT’s 6.5840: Distributed Systems course.

Broad high-level remarks on consensus in distributed systems from Graydon Hoare, originator of the Rust programming language and several other influential software projects.

A fascinating from-scratch construction of something approaching CRDTs starting from a much simpler idea, “server reconciliation”. You, yes you, can implement this!

Collaborative text editing is arguably the hardest feature to implement in a collaborative app. […] Or rather, that’s what I thought until recently. This blog post describes an alternative, straightforward approach to collaborative text editing, without Conflict-free Replicated Data Types (CRDTs) or Operational Transformation (OT).

Pretends a local machine’s containers are a little LAN, exposing that LAN to a browser (via a custom SOCKS proxy) to form a hyperlinkable namespace:

We have Ptyxis as a container-aware terminal emulator… why isn’t there a container-aware web browser that would just communicate directly with the containers? […] As the title suggests, now there kinda is a container-aware browser.

Oh my. IPv4 is complex. These posts discuss the idea of “unnumbered interfaces” in IPv4:

These blog posts will help you understand why IPv4 uses interface addresses, what we can gain with unnumbered IPv4 addresses, how they work over Ethernet links, and how they interact with routing protocols.

Discussion of segmentation offload, coalescing small packets into larger ones before bringing them to the attention of the networking stack (on the receive path) and splitting large packets into smaller ones just before they hit the wire, outside the kernel (on the send path).

This post surveys the deployment and correctness of fq_codel and sch_cake, two “smart queue management” algorithms designed to combat bufferbloat by keeping network latency low under load.

A rigorous approach to threat modelling. Well, more rigorous than Soatok’s Informal Guide to Threat Models, anyway. Documents the values, principles, and key characteristics of threat modelling as an industry practice. Covers patterns, anti-patterns, and overall philosophy.

The Noise Protocol Framework underpins secure communication protocols including e.g. WhatsApp, WireGuard and many others. I’ve used it in my own work. Well worth a read.

Avery Pennarun (one of the original authors of Tailscale) summarises the state-of-the-art wisdom with respect to network queue management. Bookmark this to come back to when you need it.

How big should your queue be, and what should you do when it fills up? Many times, we implement or even deploy a networking system before we have answered those questions. Luckily, recent research has given us some guidelines. Here’s what we know: […]

An examination of several approaches to handling overload, flow-control, and backoff, with examples drawn from Erlang/OTP programming.

[…] there is a rich zoo of overload problems and potential solutions […] ranging far beyond a simple queue boundary for mailboxes. By reasoning and looking at your system, it becomes interesting to figure out which approach is best: a small system with some relatively infrequent load-spikes may be fine with a queue or a pull-based mechanism. An all-synchronous system may be fine with simple counter-based protection for most tricky cases. […]

A TCP edge-case: a client can connect to itself!

Note that you didn’t start any server and there is no process listening on port 50000 on localhost, but yet, it connected! […] What happened? In short, client connected to itself. :)

A collection of 100 impossibility results and some discussion of commonalities and differences among them:

This talk is about impossibility results in the area of distributed computing. In this category, I include not just results that say that a particular task cannot be accomplished, but also lower bound results, which say that a task cannot be accomplished within a certain bound on cost.

You may ask yourself why impossibility proofs are important: my answer is that if you don’t know what’s impossible, you run the risk of wasting a lot of time trying to achieve the unachievable!