A First-Principles Approach to Networked Systems
Preface
Why This Book Exists
Every breakthrough in my research came from asking the right first question — not from knowing the right mechanism.
When we built BQT to audit billions of dollars in broadband subsidies, the tool didn’t start with “how do I build a better speed test.” It started with: what is the fundamental data gap in broadband policymaking? When we built a closed-loop ML pipeline for self-driving networks, the work didn’t start with “which model architecture is best.” It started with: why don’t existing ML models for networking generalize? In both cases, the mechanism came later. The first-principles question came first.
This pattern — identify the structural constraint before optimizing the mechanism — is the foundation of this book.
Computing is a generative discipline. It produces the abstractions from which entirely new problem spaces emerge: packet switching created networking, the IP thin waist created the Internet, HTTP created the Web, cloud APIs and virtualization created the infrastructure that made large-scale AI training possible. AI itself is a product of computing’s generative layers. And the frontier has already moved again — from large language models to agentic systems, architectures whose foundations are distributed systems, state management, security, and control. The abstractions that matter keep changing. The ability to reason about them from first principles does not.
The AI wave has also forced a question that every educator must now answer: what knowledge is durable? An LLM can recite how TCP’s three-way handshake works. It can describe AIMD. It can list the fields in an 802.11 frame header. Mechanism-level recall is now automated. But a human trained in first-principles reasoning — someone who can identify the anchor constraint of an unfamiliar system, trace the dependency graph, and predict how a constraint shift will restructure the design — brings something that makes AI collaboration qualitatively better. The trained human knows what to ask, how to structure the problem, and when the LLM’s output is wrong. AI becomes a force multiplier, not a crutch. This book teaches the human side of that equation.
Every networked system answers four questions. The designer may answer them deliberately or by default — but the questions are inescapable.
- State — What exists? What does the system know, and how does it learn?
- Time — When do things happen? How fast must decisions be?
- Coordination — Who decides? One entity or many?
- Interface — How do components interact? What’s exposed, and what’s hidden?
These four invariants define the design space. A WiFi access point answers them. TCP answers them. A video streaming client answers them. A broadband measurement system answers them. The answers differ radically — but the questions do not.
This book grew out of an undergraduate course at UC Santa Barbara that was redesigned around a single intellectual commitment: that networking is best taught not as a catalog of protocols and mechanisms, but as a discipline of systems design under constraint. The goal is not to produce students who can describe how TCP works. The goal is to produce systems thinkers — people who can analyze any networked system by identifying its invariant answers, trace how one design choice constrains the rest through anchored dependency graphs, and generate new designs when environmental constraints shift. That skill is what survives every innovation wave.
The Framework
The framework has three components:
Invariants define what must be answered: State, Time, Coordination, Interface. These are structural — every system answers them whether the designer thinks about them or not.
Principles describe recurring strategies for constructing good answers: Disaggregation (separate concerns so each can evolve independently), Closed-loop reasoning (feedback loops stabilize adaptive systems), and Decision placement (push decisions to the entity with the freshest information).
Method — the anchored dependency graph — provides the analytical tool. Identify the anchor (the inherited constraint from physics, architecture, or deployment history), trace how it constrains feasible answers to the remaining invariants, and evaluate the resulting dynamics against objectives and failure modes.
The Six Components
The Internet is a complex system that decomposes into functional subsystems. This book defines networked systems as compositions of six fundamental components, each answering a distinct engineering question:
- Medium Access — “How do I share a transmission medium fairly among competing transmitters?”
- Transport — “How do I deliver data reliably and efficiently across a path I don’t control?”
- Queue Management — “What do I do when packets arrive faster than I can forward them?”
- Multimedia Applications — “How do I deliver time-sensitive content over a best-effort network?”
- Network Management — “How do I allocate resources and enforce policy across heterogeneous demands?”
- Measurement — “How do I observe what’s actually happening in a system I can’t fully instrument?”
A real networked system — a video call over WiFi, a web page load over LTE — instantiates several components simultaneously. The coupling between them is where the deepest design challenges live.
Three Stages of Analysis
The book progresses through three stages of analytical sophistication:
Stage 1 — Component Analysis. Each component is analyzed in isolation with the full framework. TCP congestion control, 802.11 medium access, DASH/ABR streaming, VoIP, CoDel — each gets its own invariant analysis, anchored dependency graph, and failure-mode inventory. (Chapters 2–5, 7–8)
Stage 2 — Composition Analysis. Components share environments and shape each other’s behavior. Bufferbloat emerges from the coupling between transport (TCP) and queue management (large buffers). QoS vs. QoE emerges from the gap between network-layer metrics and application-layer perceptual quality. This stage teaches students to reason about mutual constraints and the coordination signals that flow between components. (Chapter 6)
Stage 3 — Architectural Analysis. Redesigning the decomposition itself. L4S redefines the transport↔︎queue interface. ECN adds a richer coordination signal. QUIC moves transport over UDP to escape middlebox ossification. The question shifts from “how does this component work?” to “should these components be separated this way?” (Chapter 6, later sections)
How to Use This Book
Each chapter opens with the anchor constraint that shapes the system under study, proceeds through the four-invariant analysis, and connects to the design principles that explain why the system was built the way it was. Interactive visualizations (in the HTML edition) let you manipulate parameters and observe system dynamics directly. The dependency graphs are not decorative — they are the analytical backbone.
The book is designed for upper-division CS undergraduates who have completed an introductory networking course. Familiarity with TCP/IP, basic queuing, and protocol layering is assumed. What is not assumed is any particular way of thinking about these systems — that is what this book teaches. A note on terminology: this book uses “component” to refer to functional subsystems (medium access, transport, queue management, etc.), not protocol stack layers. When we refer to OSI or TCP/IP layers, we say so explicitly.
The HTML edition of this book includes interactive Observable JS visualizations that let you explore system dynamics by manipulating parameters directly. Look for the interactive figures throughout the text.
This book is under active development. It is being refined as I teach CS 176C in Spring 2026. A more stable version is expected by Fall 2026.
Arpit Gupta, UC Santa Barbara Spring 2026
This chapter is part of “A First-Principles Approach to Networked Systems” by Arpit Gupta, UC Santa Barbara, licensed under CC BY-NC-SA 4.0.