CS 176C: Advanced Topics in Internet Computing

Welcome & Course Overview

Arpit Gupta

2026-03-31

Welcome to CS 176C

About Me

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)

Quick Logistics

  • Lectures: Tue & Thu, 2:00–3:15 PM, TD-W 1701 (Sanjay covers when Arpit is traveling)
  • Discussion: Fri, 1:00–1:50 & 2:00–2:50 PM, NH 1109 — attendance required
  • Communication: Slack — join today
  • Grading: PAs (40%), Midterm (20%), Project (20%), Participation (20%)
  • Participation: Discussion attendance + PA oral check-ins (can you explain your own code?)
  • Midterm: May 5, in-class, closed-device — no LLMs, no notes
  • Book: First Principles of Networking — free, online, work in progress
  • Full details: course website

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 Researcher

My North Star: Performant Internet for All

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.

The Data Gap: What We Can’t See, We Can’t Fix

Policymakers allocate billions based on ISP self-reported data.

The problem: ISPs have incentives to overstate coverage and quality.

  • The FCC’s National Broadband Map relied on ISP certifications — nobody independently verified them
  • Crowdsourced speed tests (Ookla, M-Lab) lack context: a “slow” result might be a cheap plan working correctly, or a premium plan failing
  • No independent dataset for broadband affordability existed at all

“What we can’t see, we can’t fix.” — Benton Institute OpEd, January 2026

BQT: Independent Broadband Data at Street-Address Granularity

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

What BQT Revealed: A $10 Billion Audit

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.

BQT’s Impact

Intellectual Impact

Policy Impact

  • City of LA: speed test measurements now require subscription tier context
  • FCC: DSL-served locations reclassified as underserved
  • Virginia JCOTS: broadband affordability report delivered to legislature
  • U.S. Supreme Court: contributed evidence to amicus brief in Wisconsin Bell v. United States

One research tool — bridging the gap between measurement and accountability at every level of government.

What Lies Ahead: From Auditing to Continuous Monitoring

BQT is now shaping legislative decisions across the country:

  • California: CPUC using BQT data to audit ISP compliance and support digital discrimination cases
  • Virginia: JCOTS broadband affordability report delivered to the state legislature
  • New York City: Partnership with NYC Office of Technology & Innovation on broadband equity assessment

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.

Path 2: Self-Driving Networks

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.

From Research to Tools: The Data Generation Ecosystem

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.

The Thinker

What My Research Taught Me

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 Generates the Future

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 Is a Product of These Layers

AI emerged from decades of computing abstractions stacked on top of each other:

Packet switchingIP thin waistHTTP/WebCloud/virtualizationGPU clusters + distributed trainingLLMs

Remove any link and LLMs don’t exist:

  • No packet switching → no resource sharing across distances
  • No IP thin waist → no interoperable global network
  • No cloud APIs → no elastic GPU clusters for training at scale

Computing generated AI. Not the other way around.

The Frontier Has Moved: From LLMs to Agentic Systems

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.

What This Means for Your Education

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.

The Teacher

First-Principles Thinking + AI = Superpowered Engineers

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.

Three Capabilities You’ll Build

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.

Puzzles This Course Will Solve

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.

The Framework — A Teaser

The Core Idea

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.

The Anchor

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.

Example: Loading a Web Page

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:

  1. DHCP — Get an IP address, learn the router and DNS server IPs
  2. ARP — Resolve the router’s MAC address to send Ethernet frames
  3. DNS — Resolve www.google.com to an IP address (216.58.193.196)
  4. TCP — Establish a reliable connection to Google’s server
  5. HTTP — Fetch the page content

Why does each protocol make fundamentally different design choices?

Visualizing the Web Page Load

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.

Three Protocols, Three Design Patterns

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.

Looking Ahead

The Book & What’s Next

First Principles of Networking

  • Free, online, written specifically for this course
  • Organized around the four invariants
  • Work in progress — I refine the book as we go through the course

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

Welcome Aboard

Before Thursday: (1) Join Slack, (2) Read Ch 2: First Principles, (3) PA1 drops Wednesday, (4) Check the course website

For curious minds:

Questions?