Welcome & Course Overview
2026-03-31
Arpit Gupta Associate Professor, UC Santa Barbara UC Presidential Faculty Fellow Faculty Scientist, Lawrence Berkeley National Laboratory Fellow, Benton Institute for Broadband & Society
North star: Make performant Internet accessible for all
Research group: Systems & Networking Lab (SNL)
Your course team — all SNL PhD students building the tools you’ll use:
| Sanjay Chandrasekaran (TA) | Sylee Beltiukov (TA) | Jaber Daneshamooz (Staff) | Manni Moghimi (Staff) |
The Internet transformed work, healthcare, education, and government. But connectivity remains deeply unequal:
| Dimension | What it means | The gap |
|---|---|---|
| Availability | Can you get broadband service at your address? | 30M Americans lack access; 40% in rural/tribal areas |
| Quality | Does the service actually deliver what’s advertised? | ISP self-reported data is unreliable and noisy |
| Affordability | Can you afford the service that’s available? | 10% of the population cannot afford Internet |
| Adoption | Do people actually use the service when it’s available? | Seniors and low-income households lag behind |
My research focuses on two things: building systems that make high-quality connectivity cheaper to deliver, and building the data infrastructure to measure whether we’re succeeding.
Policymakers allocate billions based on ISP self-reported data.
The problem: ISPs have incentives to overstate coverage and quality.
“What we can’t see, we can’t fix.” — Benton Institute OpEd, January 2026
We built BQT — it automates querying ISP websites to extract advertised speeds and prices at individual street addresses.
BQT enabled querying 1M+ addresses for 50+ ISPs, bridging three critical data gaps:
| Gap | Before BQT | With BQT |
|---|---|---|
| Availability | ISP self-reports (unreliable) | Independent spot-checking of ISP claims |
| Quality | Crowdsourced tests (noisy, no context) | Subscription tier context to denoise speed tests |
| Affordability | No dataset | First-ever street-address pricing data |
The Connect America Fund (2011–2021) spent $10 billion subsidizing ISPs to serve high-cost rural areas.
We used BQT to audit what was actually delivered (SIGCOMM ’24):
| Metric | Finding |
|---|---|
| Addresses actually served | ~55% of what ISPs certified to the FCC |
| Plans meeting quality standards | ~33% compliance among served addresses |
| Largest recipient (~$1B) | Systematically ignored remote rural areas |
A decade-long, $10 billion investment didn’t deliver as promised — and nobody had the data to know.
Intellectual Impact
Policy Impact
One research tool — bridging the gap between measurement and accountability at every level of government.
BQT is now shaping legislative decisions across the country:
Next: BQT is positioned to track the $42B BEAD program — independent accountability at national scale.
And we’re building NetVibe — a continuous broadband quality monitoring platform that captures application-level quality of experience. We’ll discuss NetVibe later in the course.
The second research path: making networks that operate themselves.
Why this matters for my north star: Community networks can’t afford large operations teams. Self-driving networks bring down the cost of delivering performant connectivity.
Why this matters for the AI era: This is the networking instance of a broader challenge — embedding ML models inside reliable, trustworthy operational loops.
We are working with Google and the Department of Energy to build the representation layer that enables agentic systems to manage complex, massive networks — with minimal human intervention.
The self-driving networks pipeline required a data generation substrate — infrastructure for creating realistic, repeatable network experiments at scale.
That substrate became the tools you’ll use this quarter:
| Tool | What it does | Reference |
|---|---|---|
| NetUnicorn | Data-generation thin waist — connects learning problems to network infrastructure | CCS ’23 |
| NetReplica | Programmable control over real access network conditions | arXiv |
| NetGent | Agent-based automation of application workflows — the Agentic Thin Waist | NeurIPS MLforSys ’25 |
These aren’t textbook exercises. They’re research infrastructure built by my PhD students — the same TAs who teach your discussion sections.
Every breakthrough came from asking the right first question — not from knowing the right mechanism.
BQT didn’t start with “how do I build a better speed test.”
It started with: “What is the fundamental data gap in broadband policymaking?”
Self-driving networks didn’t start with “which ML model is best.”
It started with: “Why don’t existing ML models for networking generalize?”
The mechanism came later. The first-principles question came first.
This pattern — identify the structural constraint before optimizing the mechanism — is exactly what this course teaches.
Computing is a generative discipline — it produces the abstractions from which entirely new problem spaces emerge.
| Decade | Abstraction | What it is | What it created |
|---|---|---|---|
| 1960s | Packet switching | Breaking data into discrete, independently routed units | Networking — resource sharing, routing, congestion theory |
| 1970-80s | The IP thin waist | A single narrow interface (best-effort datagrams) between heterogeneous networks | The Internet — any network below, any application above |
| 1990s | HTTP + URL + HTML | Universal naming, transport, and rendering for hyperlinked documents | The World Wide Web — content creation, search, e-commerce |
| 2000s | Virtualization + cloud APIs | Hardware abstraction + on-demand elastic compute via programmatic interfaces | Cloud computing — MapReduce, containers, large-scale ML training |
Each row: a specific computing abstraction that opened a problem space with its own theory, methods, and communities.
AI emerged from decades of computing abstractions stacked on top of each other:
Packet switching → IP thin waist → HTTP/Web → Cloud/virtualization → GPU clusters + distributed training → LLMs
Remove any link and LLMs don’t exist:
Computing generated AI. Not the other way around.
Two years ago: LLMs will subsume everything.
Today: agentic systems — AI models embedded in larger frameworks that plan, use tools, maintain state, and interact with environments.
| Dimension | LLMs | Agentic Systems |
|---|---|---|
| Core abstractions | Statistical learning, optimization, parallel computation | Distributed systems, planning, state management, security |
| Key challenge | Scale model training | Build reliable systems around models |
| Foundation required | Linear algebra, probability, GPU programming | Systems design, formal reasoning, software architecture |
The shift happened in under two years. It demanded entirely different foundational knowledge.
Whatever follows agentic systems will require a different combination of computing abstractions.
The value of your education: learning to reason at the level of the abstractions that generate paradigms.
“Students who understood decomposition, resource allocation, and formal specification navigated the paradigm shift — because they were operating at the level of the abstractions that generate paradigms.”
This course teaches that level of reasoning — applied to networked systems.
An LLM can recite TCP, describe AIMD, list 802.11 frame fields. That recall is now automated.
A human trained in first-principles reasoning + an LLM > either one alone.
The trained human knows what to ask, how to structure the problem, and when the LLM is wrong. The LLM accelerates execution. Together: qualitatively better outcomes.
Someone without first-principles training struggles to outperform AI-only solutions. Someone with it turns AI into a force multiplier.
By the end of CS 176C, you will be able to:
1. Analyze — Given any networked system, identify its anchor constraint and trace how it shapes every invariant answer
2. Predict — When a constraint shifts, predict how the system must restructure — before looking at what engineers actually did
3. Design — Reason through how to build a new system under novel constraints, using the same framework
These capabilities are your leverage for AI collaboration.
March 2020: The EU asks Netflix to reduce streaming quality to prevent network collapse. Why did that help — and which three systems are coupled in the dependency chain?
2020: Zoom surges with remote work — and chooses UDP instead of TCP. What constraint forces that choice?
2025: 5G radio delivers 1ms latency. So why does your phone still buffer?
You already know these events happened. This course teaches you why they had to happen — by tracing the structural constraints that forced each outcome.
Every networked system must answer four structural questions:
| Invariant | Question | TCP’s Answer |
|---|---|---|
| State | What does the system know? How does it learn? | cwnd — belief about capacity, from ACK arrivals |
| Time | When do things happen? How fast? | RTT inferred via Jacobson’s algorithm |
| Coordination | Who decides? One entity or many? | Distributed — each sender adjusts via AIMD |
| Interface | What’s exposed? What’s hidden? | Byte stream above; datagrams below |
The answers differ radically across systems. The questions never change.
Every system has one constraint that shapes all four answers.
TCP’s anchor: Unreliable IP + no central authority
↓ distributed state (cwnd per sender) ↓ inferred timing (RTT from ACKs) ↓ distributed coordination (AIMD) ↓ byte-stream / datagram split
WiFi’s anchor: Shared wireless medium
↓ carrier sensing (listen first) ↓ microsecond timing (slots, DIFS/SIFS) ↓ distributed contention (no scheduler) ↓ frame-level collision handling
Find the anchor → the design becomes predictable.
You open your laptop, connect to WiFi, and type www.google.com. What happens?
Your laptop starts with nothing — no IP address, no idea where the router is, no idea where Google is, no reliable connection, no page.
Five protocols fire in sequence, each solving one problem and producing state the next one needs:
www.google.com to an IP address (216.58.193.196)Why does each protocol make fundamentally different design choices?
DHCP and ARP are local — confined to the LAN. DNS, TCP, and HTTP traverse the Internet to reach remote servers. Each protocol is color-coded to show the dependency chain.
| DHCP | DNS | TCP | |
|---|---|---|---|
| State | Centralized — server tracks pool | Hierarchical — partitioned namespace + caching | Distributed — independent cwnd per endpoint |
| Time | Lease-based — fixed duration | TTL-based — each record expires | Inferred — RTT from ACKs (Jacobson) |
| Coordination | Centralized — server decides | Hierarchical delegation — root → TLD → auth | Distributed — AIMD, no central scheduler |
| Interface | UDP broadcast (no IP yet) | UDP port 53, on IP routing | Byte stream above, datagrams below |
DHCP centralizes — unique addresses need one authority. TCP distributes — decentralization prohibits a central scheduler. DNS delegates — namespace too large for one server, too structured for full distribution.
Same four questions. Radically different answers. Each forced by different constraints.
First Principles of Networking
Before Thursday, read:
| Weeks | Chapter |
|---|---|
| 1–2 | Ch 2 |
| 3–5 | Ch 3 + Ch 4 |
| 6–7 | Ch 6 |
| 7–8 | Ch 8 |
| 8–10 | Ch 9 |
Before Thursday: (1) Join Slack, (2) Read Ch 2: First Principles, (3) PA1 drops Wednesday, (4) Check the course website
For curious minds:
Questions?