Chapter 2: First Principles for Networked Systems
The Four Invariants
2026-04-02
Five protocols, five different designs — why?
Last lecture, you loaded a web page. Five protocols fired in sequence:
| Protocol | What it does |
|---|---|
| DHCP | Get an IP address from a server |
| ARP | Resolve the router’s MAC address |
| DNS | Resolve google.com to an IP |
| TCP | Establish a reliable connection |
| HTTP | Fetch the page content |
Quick recall — which of these uses a central server? Which doesn’t? Why?
The tool from Lecture 1 — now we learn to use it
Last lecture, you saw this teaser:
| Invariant | Question | TCP’s answer |
|---|---|---|
| Interface | What’s exposed, what’s hidden? | Socket API above, IP datagrams below |
| Coordination | Who decides — and why? | Distributed — each sender alone |
| State | What does it believe? Is that correct? | cwnd, SRTT — inferred from ACKs |
| Time | When are decisions made — and how? | Event-driven (ACKs) + inferred timers (RTO) |
You saw the answers. Today you learn why each answer is forced — and how to generate answers for any system.
The dependency chain starts from the constraint. For TCP, the binding constraint is Interface (IP’s unreliable datagrams). That shapes Coordination, which shapes State, which shapes Time. For other systems, the chain may start from a different invariant — we’ll see this in later lectures.
Applying the Tool: TCP
Invariant 1 — Interface: what did TCP inherit?
↪ What’s exposed, what’s hidden — and can it ever change?
TCP sits between two interfaces it didn’t choose:
Below: IP’s contract
- Best-effort datagrams
- Unreliable, unordered, no guarantees
- IP deliberately hides reliability
TCP must provide reliability because IP chose to hide it.
Above: the socket API
connect(),send(),recv()- Unchanged since 1983 (43 years)
- Applications depend on this contract
TCP can’t change its own API without breaking everything above.
Interface is the most permanent invariant. IP’s choice forced TCP to exist. TCP’s API froze its evolution. QUIC had to tunnel through UDP to escape.
Invariant 2 — Coordination: why is TCP on its own?
↪ Who decides — and what constraint forced that choice?
Given IP’s interface: could a central server schedule all TCP flows? Tell each sender exactly how fast to send?
No. Three constraints prohibit it:
- No single entity controls the Internet — administrative decentralization
- Billions of flows, microsecond decisions — no server can keep up
- Who gets authority over your bandwidth? — trust
TCP must be distributed: each endpoint runs independently, making its own decisions with only local information.
The consequence: each endpoint needs its own machine
Because TCP is distributed, each endpoint runs its own finite state machine:
CLOSED → SYN_SENT → ESTABLISHED → FIN_WAIT → CLOSEDThe FSM makes every decision: whether to send data, how much, whether to retransmit, when to give up, how to tear down.
No coordinator tells TCP what to do. The FSM reacts to local events (ACK arrived, data ready, timeout fired) using only its own internal state.
Coordination dictated the FSM design. If TCP were centralized, endpoints wouldn’t need their own state machines — a controller would decide for them.
Invariant 3 — State: what must the FSM track?
↪ What does the system believe? Is that belief correct?
The FSM needs internal variables to make decisions. TCP’s primary goal: figure out how fast to send without overwhelming the network.
| Layer | What it is | TCP |
|---|---|---|
| Environment | What’s actually happening | Bottleneck capacity, queue occupancy, competing traffic |
| Measurement | What TCP can observe | ACK arrivals (timing + sequence), duplicate ACKs |
| Belief | The FSM’s internal model | cwnd (capacity estimate), SRTT (delay estimate) |
The FSM decides based on belief, never environment. It cannot observe the network directly — it can only interpret ACK patterns.
When does the belief go wrong?
TCP’s belief (cwnd) sometimes gets it catastrophically wrong:
Bufferbloat: router queue fills to 500ms of delay. TCP doesn’t slow down.
- Environment: queue is full
- Measurement: ACKs keep arriving — nothing dropped — signal says “all clear”
- Belief: cwnd grows — TCP thinks there’s capacity
Which layer broke? Not the algorithm. Not the belief logic. The measurement signal failed — large buffers absorbed packets without generating a loss signal. Belief diverged from environment.
Every protocol failure is a gap between belief and environment, caused by an inadequate measurement signal.
Invariant 4 — Time: when does the FSM act?
↪ When are decisions made — and how?
The FSM makes decisions in two ways:
| Trigger | Example | How the timing works |
|---|---|---|
| Event-driven | ACK arrives → update cwnd, advance send window | React immediately to observed signal |
| Timer-driven | RTO expires → retransmit lost segment | Wait for a deadline, then act |
Not all decisions are time-based. Most FSM transitions are event-driven — the ACK arrival IS the trigger.
But when timers ARE needed (RTO), how is the value set?
Inferred. TCP estimates RTT from ACK round-trips (Jacobson’s algorithm), then derives RTO. No authority prescribes the timeout — each endpoint computes its own.
TCP through all four invariants — the dependency chain
| Invariant | TCP’s answer | Forced by |
|---|---|---|
| Interface | IP datagrams (unreliable) ↔︎ Socket API (ossified) | IP’s design decision; 43 years of deployment |
| Coordination | Distributed — each endpoint alone | Interface + admin decentralization → no central controller |
| State | FSM + cwnd + SRTT (belief from ACKs) | Distributed → each endpoint needs its own FSM and belief model |
| Time | Event-driven (ACKs) + inferred timers (RTO from RTT) | No authority → must infer; RTT bridges State and Time |
For TCP, the chain runs Interface → Coordination → State → Time. Each row follows from the previous one because the binding constraint is Interface.
For other systems, the chain starts elsewhere. WiFi’s binding constraint is the shared medium (physics → Coordination). Video streaming’s binding constraint is human perception (Time). The chain always starts from the constraint — not always from Interface.
Your Turn: Apply the Tool
Apply all four invariants to DNS (2 minutes)
DNS resolves google.com → 142.250.80.46. Apply the tool:
| Invariant | Question to answer | DNS |
|---|---|---|
| Interface | What’s exposed/hidden? What’s the contract? | ? |
| Coordination | Who decides? Central, hierarchical, distributed? | ? |
| State | What does it believe? Where does belief fail? | ? |
| Time | Event-driven or timer-driven? Prescribed or inferred? | ? |
Hint: start with Interface (what protocol/port?) and trace the chain.
DNS through the tool
| Invariant | DNS’s answer | Why |
|---|---|---|
| Interface | UDP port 53 (query-response). Evolving: DoH/DoT | Plaintext DNS inspected by ISPs → ossification pressure |
| Coordination | Hierarchical — root → TLD → authoritative | Namespace too large for one server; too structured for pure distribution |
| State | Cache = belief. Zone file = environment. TTL = measurement timer | When record changes but TTL hasn’t expired → stale belief (same structural bug as bufferbloat) |
| Time | Timer-driven: TTL expiry triggers re-query. Prescribed — zone admin sets TTL | Authority exists → can prescribe |
DNS stale cache and TCP bufferbloat are the same structural failure: belief ≠ environment because the measurement signal is delayed.
Two protocols. Zero shared mechanisms. Identical failure pattern diagnosed by the same tool.
Harder: ARP vs. DHCP — same LAN, why different? (3 minutes)
Both run at boot. Both use broadcast. Both on the same LAN.
| Invariant | ARP | DHCP |
|---|---|---|
| Interface | ? | ? |
| Coordination | ? | ? |
| State | ? | ? |
| Time | ? | ? |
The diagnostic question: why is ARP’s coordination completely different from DHCP’s?
This is representative of a midterm question.
ARP vs. DHCP: same constraints, different resources
| Invariant | ARP | DHCP |
|---|---|---|
| Interface | Broadcast query, unicast reply | Broadcast discover, unicast offer/ack |
| Coordination | None — any host can claim any mapping | Centralized — server decides |
| State | Distributed cache per host | Centralized allocation table |
| Time | Prescribed timeout (~20 min) | Prescribed lease (server sets) |
The difference is the resource. ARP maps pre-assigned addresses (MACs). No scarcity → no authority needed. DHCP allocates scarce addresses (IPs). Uniqueness → centralized authority required.
Side effect: ARP’s lack of coordination → ARP spoofing is trivially easy. Coordination choices have security consequences.
Compression
One tool. Four invariants. One dependency chain.
| Invariant | The question | The chain |
|---|---|---|
| Interface | What’s exposed/hidden? Can it change? | For TCP, this is the binding constraint — but not always |
| Coordination | Who decides? Why that entity? | Forced by interface + resource constraints → dictates FSM design |
| State | What does it believe? Where does belief fail? | FSM tracks state; failures = belief ≠ environment |
| Time | When are decisions made? Event or timer? Prescribed or inferred? | FSM transitions; timers prescribed (if authority) or inferred (if not) |
The skill you just built
Given any networked system, find the binding constraint and trace the chain:
- Identify the constraint — What’s hardest to change? (For TCP: Interface. For WiFi: medium physics. For video: human perception.)
- Interface — What’s exposed/hidden? What contract was inherited?
- Coordination — Who decides? What forced that choice?
- State — What does each participant track? Where does belief fail?
- Time — Event-driven or timer-driven? Prescribed or inferred?
Transfer question (try before Tuesday): apply the four invariants to HTTP. What’s the binding constraint? Trace the chain.
Next lecture: design principles and the dependency graph — why one constraint forces all four answers.