Internet Measurement

A research-oriented course on learning about the Internet from partial and indirect observations.

Spring 2027 · University of Maryland

Instructor: Loqman Salamatian
Course number: To be announced
Meeting time and place: To be announced
Format: Research seminar with hands-on measurement work
Status: Planning draft

Course description

The Internet is not directly observable. Its structure and behavior must be inferred from partial, indirect, and sometimes contradictory signals.

This course examines how we measure the Internet, what those measurements can and cannot reveal, and how they can be used to understand the systems and services that depend on it. We will study paths and topology, interdomain routing, performance, outages, Internet-wide scanning, services and DNS, traffic engineering, censorship, broadband access, physical infrastructure, and datacenter workloads.

For every topic, we will ask: What question are we precisely trying to answer? What data can we actually observe? What assumptions connect those observations to the underlying system? When methods disagree, what does the disagreement teach us?

Our recurring approach will be:

  1. Observe: collect a route, BGP update, DNS answer, packet sample, speed test, scan response, or application-level observation.
  2. State the assumptions: explain what must be true for the observation to stand in for the hidden system.
  3. Infer: make a bounded claim with an explicit scope and uncertainty.
  4. Test: compare vantage points, datasets, methods, and any available ground truth.

Learning objectives

By the end of the course, students should be able to:

  • Turn a broad question about the Internet into a precise, measurable claim.
  • Choose and combine active, passive, control-plane, and application-layer observations.
  • Separate what was directly observed from what was inferred.
  • Identify selection effects, vantage-point bias, confounders, and missing ground truth.
  • Design ethical and reproducible Internet measurement experiments.
  • Reconcile conflicting measurements without forcing them into a single false answer.
  • Communicate measurement results with appropriate uncertainty and limitations.

Course format

Each week pairs research literature with hands-on work. The goal is to understand both how a measurement is built and why its conclusions deserve—or fail to deserve—our trust.

Research seminar. We will closely read classic and recent papers. Discussions will compare questions, observations, assumptions, and methods rather than proceed as a sequence of paper summaries.

Hands-on work. Short investigations will use real data and tools, including traceroute, BGP archives, DNS, Internet-wide scans, throughput tests, and public measurement platforms.

Project meetings. We will hold regular design reviews covering questions, data, ethics, validity, analysis, and communication.

No traditional exams are planned. Evaluation centers on sustained preparation, careful empirical work, and a semester project.

Expected background. Graduate students and advanced undergraduates should have prior exposure to computer networking, be comfortable programming in Python or a comparable language, and be willing to work with imperfect real-world datasets. Permission of the instructor can substitute for formal prerequisites.

Grading

Component Weight Description
Measurement notebook 20% Concise weekly entries separating the question, observation, assumption, claim, and threat to validity.
Lab investigations 20% Three small empirical studies developing fluency with measurement tools, data cleaning, and validation.
Discussion and synthesis 15% Prepared participation, one facilitated class discussion, and short comparisons across readings.
Project milestones 15% Question memo, ethics and data review, proposal, pilot result, and peer design review.
Final project 30% A defensible measurement study, presented in class and delivered with a paper and reproducibility package.

This grading scheme is a planning draft and may change before the course is formally listed.

Schedule and readings

Main readings anchor each week’s discussion. Complementary readings extend, challenge, or provide alternative approaches to the same measurement problem.

Week 1: What can be known, and how do we measure it well?

Main reading

Complementary readings

Week 2: Paths and topology

Main readings

Complementary readings

Week 3: Interdomain routing

Main readings

Complementary readings

Week 4: Performance

Main reading

Complementary readings

Week 5: Outages and reachability

Main readings

Complementary readings and resources

Week 6: Internet-wide active measurement

Main readings

Complementary readings

Week 7: Services and dependencies

Main reading

Complementary reading

Week 8: DNS as a measurement signal

Main readings

Complementary readings

Spring break

No class.

Week 9: Internet traffic engineering

Main readings

Complementary readings

Week 10: Censorship and interference

Main readings

Complementary readings and resources

Week 11: Broadband access and inequity

Main reading

Complementary readings

Week 12: Hidden and physical infrastructure

Main readings

Complementary readings

Week 13: Datacenter measurement and AI workloads

Main readings

Complementary readings: classical datacenter measurement

Complementary readings: AI workload and failure characterization

Complementary readings: AI datacenter systems

  • Adithya Gangidi, Rui Miao, Shengbao Zheng, Sai Jayesh Bondu, Guilherme Goes, Hany Morsy, Rohit Puri, Mohammad Riftadi, Ashmitha Jeevaraj Shetty, Jingyi Yang, Shuqiang Zhang, Mikel Jimenez Fernandez, Shashidhar Gandham, and Hongyi Zeng. RDMA over Ethernet for Distributed AI Training at Meta Scale. ACM SIGCOMM, 2024.
  • Qingkai Meng, Hao Zheng, Zhenhui Zhang, ChonLam Lao, Chengyuan Huang, Baojia Li, Ziyuan Zhu, Hao Lu, Weizhen Dang, Zitong Lin, Weifeng Zhang, Lingfeng Liu, Yuanyuan Gong, Chunzhi He, Xiaoyuan Hu, Yinben Xia, Xiang Li, Zekun He, Yachen Wang, Xianneng Zou, Kun Yang, Gianni Antichi, Guihai Chen, and Chen Tian. Astral: A Datacenter Infrastructure for Large Language Model Training at Scale. ACM SIGCOMM, 2025.

Week 14: Research presentations

Final project presentations and discussion.

Semester project

Teams of two or three will design and carry out an original measurement study.

Scope matters less than the quality of the inference. Projects may reproduce or challenge a published result, compare methods that claim to measure the same phenomenon, construct a new dataset or measurement tool, or apply an established method in a setting where its assumptions deserve re-examination.

Projects should begin with a question rather than a dataset. Finding an interesting dataset and reporting correlations in it is generally not sufficient; students should be able to explain what property of the underlying Internet they want to learn and why their observations provide evidence about that property.

Project milestones will include:

  1. Question: Define the claim, its scope, and why it matters.
  2. Observations: Identify what can actually be measured.
  3. Assumptions: Make explicit the bridge between observations and the desired claim.
  4. Design: Choose measurements, vantage points, controls, and comparisons.
  5. Review: Address ethics, safety, data access, and foreseeable sources of bias.
  6. Pilot: Test feasibility and deliberately look for disagreement or counterexamples.
  7. Report: Present results, limitations, alternative explanations, and reproducibility artifacts.

A good project may end with a narrower claim, a failed measurement approach, or a well-explained null result. The course rewards credible reasoning rather than a predetermined headline.

Course policies

Ethics and safety

Any measurement that may create load, scan systems, collect user-related data, interact with potentially censored services, or expose vulnerable communities requires instructor review before data collection.

Students must respect platform terms, institutional rules, and applicable law. The fact that a measurement is technically possible does not by itself make it appropriate to perform.

Reproducibility

Projects should preserve code, queries, parameters, data provenance, measurement timing, vantage-point selection, filtering decisions, and analysis decisions.

When data cannot be shared, teams must document why and provide the strongest safe substitute.

Reproducibility does not imply that repeating an experiment will necessarily produce the same observation. The Internet changes. The goal is to preserve enough information to understand how the observation was produced and to distinguish methodological differences from changes in the underlying system.

Collaboration and credit

Discussion and teamwork are central to the course. Submitted work must make individual and shared contributions clear, cite sources, and distinguish reused artifacts from original work.

Access and participation

Please communicate early when access needs, health, caregiving, religious observance, or other circumstances affect participation. We will work within university policy to make a reasonable plan.

The final syllabus will specify submission channels, late-work and generative-AI policies, classroom recording rules, accessibility procedures, and all required UMD course-related policies.