Mid-term Project

Table of contents

  1. Overview
  2. Background
    1. Congestion Control Algorithms
    2. The CCAnalyzer Methodology
  3. Setup
    1. Tools
    2. Network Topology (Controlled Experiments)
  4. Part 1: Controlled Experiments
    1. Setup
    2. Experiment Design
    3. Analysis
  5. Part 2: Experiments in the Wild
    1. Suggested Test Servers
    2. Procedure
    3. Discussion
  6. Checkpoint
    1. What to submit
  7. Deliverables
    1. 1. Write-up (PDF, 2–3 pages)
    2. 2. Experiment Artifacts
    3. 3. Platform Questionnaire
  8. Grading
  9. Timeline
  10. Requirements

Overview

In this project you will replicate the methodology described in this (CCAnalyzer) research paper, which proposes a technique for inferring which congestion control algorithm (CCA) a remote server is using, without any cooperation from that server. Specifically, the paper motivates looking at how the size of the packet queue changes over time as an indicator for classifying the congestion control algorithm being used.

We will be using a workflow where we run a simple wget command to retrieve a file that is hosted on a server. You have the option to run two types of experiments when designing your replication study:

  1. Controlled (local): you host a file yourself and set the CCA, so you have ground truth
  2. In the wild: you fetch a file from a public web server to try and infer the CCA

You will use the Pramana system to facilitate your efforts in this replication study. This system allows you to easily run network experiments with control over bandwidth and latency through a natural language intent interface.

Background

Congestion Control Algorithms

A congestion control algorithm (CCA) governs how a TCP sender adjusts its sending rate in response to network conditions. Different CCAs exhibit distinct behavioral signatures in terms of how throughput ramps up, how they react to packet loss or delay, and how they interact with cross-traffic.

For this project you will primarily work with two CCAs:

  • TCP CUBIC — the default CCA in most Linux kernels. Uses a cubic function to grow its congestion window and reacts to loss by multiplicatively decreasing the window.
  • TCP BBR (Bottleneck Bandwidth and RTT) — a model-based CCA developed by Google that estimates the bottleneck bandwidth and RTT and targets the BDP (bandwidth–delay product) rather than inferring congestion from loss.

You may also include a third CCA for comparison:

  • TCP Reno — a classic loss-based AIMD algorithm. Reno increases the congestion window linearly in congestion avoidance and cuts it in half on loss, often producing a characteristic sawtooth throughput pattern.

These CCAs should exhibit different signatures when we observe the size of the packet queue at the bottleneck link, the key signal CCAnalyzer exploits.

The CCAnalyzer Methodology

For this project, we will use a simplified version of the paper’s idea: for each download, we will look at how the packet queue at the bottleneck link changes over time and use that queue-size trace to classify the CCA. This is the signal exposed most directly by the Pramana setup, so you do not need to reproduce any broader feature set from the paper.

The working assumption is that different CCAs create different queue-occupancy patterns at the bottleneck. For example, a loss-based algorithm may build up a queue until a loss occurs and then back off, while a model-based algorithm may keep the queue smaller or fluctuate differently over time.

To make this signal observable, the experimental setup needs:

  • A bottleneck link that actually limits the download, so queue buildup reflects the sender’s behavior rather than excess unused capacity.
  • A file large enough that the transfer lasts long enough to show meaningful queue dynamics rather than only startup behavior.
  • Enough delay and bandwidth constraint that queue growth and draining are visible across the download.

Setup

Tools

ToolPurpose
wgetClient-side file download; the tool you use to trigger transfers
tc / netemLinux traffic control, which enforces bottleneck bandwidth, added delay, and queue policy on the bottleneck interface
Python http.server or nginxSimple local file server for Part 1
sysctl net.ipv4.tcp_congestion_controlSets the CCA on the server (or client, depending on kernel defaults)
Wireshark / tcpdumpOptional packet capture for deeper analysis
Agentic Thin Waist platformOrchestrates all of the above through a natural language API

Network Topology (Controlled Experiments)

[Client / wget]  ---  [Bottleneck link (tc/netem)]  ---  [Local file server]
                           ^
                    BW, delay, CCA knobs

The bottleneck is enforced with tc qdisc on the interface between the two hosts (or namespaces). You control three knobs:

  • Bandwidth (BW): e.g., 1 Mbps to 100 Mbps
  • One-way delay (RTT/2): e.g., 10 ms to 100 ms
  • CCA: cubic, bbr, or reno

Part 1: Controlled Experiments

Goal: Design and run experiments on a locally hosted file where you control the CCA, then verify that the CCAnalyzer methodology can correctly identify which CCA was used.

Setup

  1. Start a local HTTP server serving a file of your chosen size.
  2. Configure sysctl on the server to use the CCA you want to test (cubic, bbr, or reno).
- show current congestion control
sysctl net.ipv4.tcp_congestion_control

- show available algorithms
sysctl net.ipv4.tcp_available_congestion_control

- temporarily change it (until reboot)
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
  1. In your intent, you can specify the BW and delay you want to test.
  2. Run wget on the client to download the file.
- For serving the file with web server:
cd /path/to/files
python3 -m http.server 8000

- To download the file:
wget http://SERVER_IP:8000/filename
  1. Record queue size over time (e.g., from wget --progress=dot output or a tcpdump-derived trace).
  2. Repeat for at least two CCAs under identical network conditions.

Experiment Design

For each experiment, consider varying:

  • File size: too small and the transfer ends before CCA behavior is visible; too large and the experiment takes too long. A useful heuristic: the transfer should last at least 10–20 seconds to capture multiple congestion epochs.
  • Bandwidth: low BW (1–5 Mbps) makes CCA differences clearer; high BW (50–100 Mbps) may wash them out.
  • Latency: CUBIC is more RTT-sensitive than BBR; higher RTT (50–100 ms) tends to amplify the difference between them.

A concrete starting point for your first experiment:

ParameterValue
File size50 MB
Bandwidth5 Mbps
One-way delay40 ms
CCAcubic, then bbr

Document which parameter combinations best separate the two CCAs and which are ambiguous.

Analysis

For each experiment, plot queue size (y-axis) and time (x-axis). You can consider using binning to help smooth out the line in your graph. Things to discuss in your report:

  • What was the thought process behind the parameters that you chose for the experiment?
    • What worked / What didn’t?
  • Discuss your results, were you able to infer the difference between CUBIC and BBR (or Reno)?

Part 2: Experiments in the Wild

Goal: You can also try to apply the CCAnalyzer methodology to a real server where you do not control the CCA, then discuss the quality of your inference.

Suggested Test Servers

Use publicly accessible speed-test file servers, for example:

  • https://ash-speed.hetzner.com (Hetzner datacenter, Ashburn VA)

Other options: CDN nodes, university mirror servers, or any large static-file host you can download from repeatably.

Procedure

  1. Download a large test file (100 MB+) from the server using wget.
  2. Apply the client-side bottleneck to shape your own downlink (you cannot control the server). This lets you vary the effective BW and delay your experiments observe.
  3. Record the trace.
  4. Apply the features from Part 1 to make a CCA inference.
  5. If you can determine the server’s actual CCA throguh some other means (e.g., server banners) or documentation, compare your inference to the alternate method.

Discussion

Some topics that you can choose to discuss in your report:

  • What CCA does your methodology infer for each server?
  • How confident are you in the inference, and why?
  • How does the inference quality compare to Part 1 where you had full control?
  • What factors make inference harder in the wild (e.g., middleboxes, CDN path changes, cross-traffic you cannot measure)?
  • Is the CCAnalyzer methodology practically useful for passive CCA identification on the internet today?

Checkpoint

Due: June 5th, 2026 Submit on Gradescope: one PDF containing your graph and answers to the questions below.

The checkpoint is lightweight, its purpose is to make sure you have the platform working and have started thinking about your experimental plan before the final deadline.

What to submit

  1. One queue size VS. time plot from a completed Part 1 experiment. It can be a single run under any parameter combination you choose. Label the axes.

  2. Short answers to the following questions (a few sentences each, you can keep it brief):

    • What file size, bandwidth, and delay did you use for your first experiment, and why did you pick those values?
    • Does your initial plot show the CCA behavior you expected? What features can you see (or not see) in the trace?
    • What parameter combinations are you planning to try next, and what do you hope to observe?
    • Which public server(s) are you planning to use for Part 2? Have you been able to download a file from them yet?
    • Is there anything about the setup or methodology that is unclear to you at this point?

The checkpoint is graded for completion. If you have a working graph and have answered all the questions, you will receive full credit.

Deliverables

Submit the following on Gradescope by the final deadline (June 12th, 2026):

1. Write-up (PDF, 2–3 pages)

Keep it concise. You do not need to explain the CCAnalyzer paper in depth, assume the reader has read it. Focus on what you did, why, and what you found.

A suggested structure (not mandatory):

  • Motivation and experiment design: What questions were you trying to answer? What parameter choices did you make and why? (Part 1 and Part 2 can be covered together here.)
  • Results: Your throughput plots and what they show. Describe the features you observe and what CCA they suggest.
  • Analysis and discussion: Does your inference match ground truth in Part 1? How confident are you in your Part 2 inference, and why? What made the methodology work well or poorly in your experiments?

Negative results are fine and expected for some parameter regimes. If a set of conditions produced ambiguous or surprising traces, describe what you saw and what you think caused it — that is more valuable than cherry-picking clean results.

2. Experiment Artifacts

  • Scripts or Commands run on the pipeline
    • Specifically, which intents did you specify and which models did you use
  • Data / Code used for producing graphs

3. Platform Questionnaire

Complete the course questionnaire about your experience using the Agentic Thin Waist platform. This is required to complete for all students as part of the course project.

Grading

ComponentWeight
Checkpoint (working experiment + plan)20%
experiment design and execution25%
analysis and plots25%
discussion and critical reflection15%
Artifacts (reproducible experiments)15%

Timeline

The project spans the last few weeks of the quarter (Weeks 8–11). Discussion sections from Week 7 onward provide structured NetReplica training and project support.

MilestoneDeadlineDescription
CheckpointJune 5 (Week 10)Show code and results for 1 experiment that you were able to successfully run
Final ReportJune 12 (Week 11)Submit your complete report.

Both milestones have fixed deadlines — no late days may be applied. See the Late Policy for details.

Requirements

  • Team work: Teams of up to 2 students, you can work solo if you are comfortable. All team members are expected to contribute meaningfully to the experimental design, data collection, analysis, and written report.
  • NetReplica: All reproductions should use the NetReplica platform. Discussion sections in Weeks 7–10 provide structured training and support for working with NetReplica.
  • Report: Your team’s final report should include your experimental setup, methodology, results, and a comparison with the original paper’s findings. The analytical reasoning must be your own — see the LLM Usage Policy and Collaboration Policy.