Prof. Sherry | A. Nico Habermann Associate Professor of Computer Science at CMU
Course Official Website | CMU SCS Description
Projet0 focuses on making use of AWS VMs and Linux tools to measure the performance of network systems in different scenarioes.
- Key Words: AWS, network tools, ping, iperf, SSH, Linux/Unix environment, RTT, Throughput, etc.
We were required to develop hypothesis, perform experiments, and conduct inferences based on the experimental evidence to either corroborate or disprove our original hypothesis. 3 sets of VMs are needed to set on different AWS region to use ping to measure RTT and iperf to measure throughput.
Proj1 focuses on building a privacy-preserving overlay network (Mix Network) that hides both message contents and communication patterns using redirection, mixing, and source routing.
The project emphasizes practical routing algorithms, control-plane protocols, and data-plane packet handling in a custom network stack implemented in C.
- Key Words: Mix networks, source routing, privacy-preserving routing, Spanning Tree Protocol (STP), link-state routing (LSA), Dijkstra, packet formats, C networking, PING, etc.
The mixnet consists of multiple nodes connected in arbitrary topologies. Each node acts as both an end host and a router, forwarding packets for other nodes.
Key architectural features include:
- Source routing: The source node computes and encodes the entire route to the destination inside the packet.
- Node roles: Each node dynamically acts as a source, forwarding node, or destination depending on the packet.
- Mixing: Nodes buffer packets and forward them in batches to obscure traffic patterns and improve privacy.
The first part of the project is to implement a Spanning Tree Protocol (STP) to enable safe flooding in arbitrary network topologies that may contain cycles. The spanning tree is used exclusively for control-plane flooding and does not restrict data-plane routing.
My implementation includes:
- Neighbor discovery: Nodes learn the mixnet addresses of their neighbors at runtime.
- STP construction: Nodes elect a root and establish a loop-free virtual topology.
- Hello mechanism: The root periodically sends heartbeat messages to detect link failures.
- Reelection logic: Nodes trigger re-election when heartbeats are missed.
- Flood packet handling: Control packets are flooded only along spanning-tree links to avoid broadcast storms.
After safe flooding is established, the project extends to implementing link-state routing, inspired by OSPF. Once converged, source nodes encode shortest paths directly into outgoing packets.
Key components include:
- Link State Advertisements (LSAs): Each node advertises its neighbors and link costs.
- Topology construction: Nodes maintain a global graph of the network.
- Shortest-path computation: Dijkstra’s algorithm is used to compute minimum-cost paths.
- Forwarding table (FIB): Each node memoizes shortest paths for efficient route lookup.
- Deterministic tie-breaking: Equal-cost paths are resolved using neighbor address ordering.
To improve privacy, the mixnet also supports random routing.
Features include:
- Non-deterministic path selection: Nodes generate multiple distinct routes over time.
- Traffic obfuscation: Random routing prevents eavesdroppers from inferring communication pairs.
- Compatibility with mixing: Random routing integrates seamlessly with packet batching.
The project requires strict adherence to a custom packet format and multiple packet types.
Implemented packet types include:
- STP & FLOOD: Control-plane topology discovery and testing.
- LSA: Network state dissemination.
- DATA: Source-routed application payloads.
- PING: RTT measurement using request–response semantics.
Nodes correctly parse, modify, forward, and deliver packets while maintaining hop indices and routing headers.
This project provides hands-on experience with routing protocols, control-plane safety, and privacy-aware network design.
Proj2 focuses on implementing a reliable transport protocol from scratch, closely modeling the behavior of TCP Reno, and evaluating its performance under real network conditions.
The project emphasizes end-to-end reliability, congestion control, flow control, and experimental evaluation of transport-layer behavior.
- Key Words: TCP Reno, sliding window, congestion control, flow control, RTT estimation, UDP-based transport, packet loss recovery, C networking.
In this project, we implemented CMU-TCP, a TCP-like transport protocol that runs entirely in user space. CMU-TCP packets are encapsulated inside the UDP payloads, which require the protocol to explicitly implement reliability, ordering, and congestion control.
Core design aspects include:
- User-space transport: All protocol logic is implemented above UDP without kernel TCP support.
- Bidirectional communication: Both endpoints can send and receive data concurrently.
- Asynchronous backend: A dedicated backend thread handles retransmissions, acknowledgments, and timers independently of the application thread.
The first part of the project focuses on implementing basic TCP functionalities to enable efficient and reliable data transfer. This stage transforms the starter stop-and-wait protocol into a functional and pipelined transport protocol.
My implementation includes:
- Three-way handshake: Full TCP-style connection establishment with randomized initial sequence numbers.
- Sliding window protocol: Multiple packets can be in flight simultaneously using a sliding window with fixed size.
- RTT estimation: Dynamic RTT estimation is used to improve timeout-based retransmissions.
- Go-Back-N retransmission: Lost packets are recovered using timeout-based retransmission.
- In-order delivery: Received data is reordered and delivered reliably to the application.
The second part extends CMU-TCP with performance-aware control mechanisms, closely following TCP Reno.
Key features implemented include:
- Flow control: The sender respects the receiver’s advertised window to prevent buffer overflows.
- Congestion window (cwnd): The sender dynamically adjusts its sending rate based on network conditions.
- Slow start & congestion avoidance: The congestion window grows exponentially during slow start and linearly during congestion avoidance.
- Fast retransmit & fast recovery: Packet loss is detected using duplicate ACKs, which enables faster recovery without waiting for timeouts.
- Timeout handling: On timeout, the sender re-enters slow start with reduced thresholds.
In addition to implementation, the project includes an experimental component evaluating TCP behavior under controlled network conditions.
Experiments include:
- Loss sensitivity analysis: Measuring throughput under varying packet loss rates.
- Congestion window visualization: Plotting cwnd over time to observe Reno’s characteristic sawtooth pattern.
- Throughput modeling: Evaluating the relationship between throughput and loss probability.
This project provides hands-on experience with the design tradeoffs and real-world behavior of transport-layer protocols.
Proj3 focuses on implementing and optimizing an Adaptive Bitrate (ABR) algorithm for video streaming, which targets at realistic last-mile network conditions. The project is built on top of CMUTube, a DASH-based video streaming system using the dash.js player.
The goal of this project is to understand how ABR algorithms trade off between startup latency, video quality, and playback stability. Thus we need to design an algorithm that maximizes overall Quality of Experience (QoE).
- Key Words: Adaptive bitrate streaming, DASH, BBA-0, QoE optimization, Docker, buffer-based algorithms, video streaming systems, JavaScript, etc.
CMUTube is a browser-based video streaming application that uses dash.js to:
- Parse DASH manifest files
- Request video chunks at different quality levels
- Feed chunks into the browser using Media Source Extensions (MSE)
We were mainly required to implement the ABR decision logic, which selects the quality level for the next video chunk.
The first part of the project is to implement BBA-0 (Buffer-Based Adaptation), a buffer-occupancy-based ABR algorithm.
Key features of my implementation include:
- Buffer-driven quality selection: The next chunk’s bitrate is chosen based solely on current buffer occupancy.
- Reservoir and cushion regions: The buffer is divided into regions that map buffer level to bitrate selection.
- Manifest-aware bitrate bounds: The algorithm dynamically adapts to the available bitrate representations defined in the DASH manifest.
- QoE metric evaluation: Performance is measured using time-to-first-frame (TTFF), average bitrate, rebuffer events, stall time, quality switches, and an aggregate QoE score.
Extensive experiments were conducted under multiple controlled workloads to analyze how BBA-0 behaves across different bandwidths, delays, and session durations.
The second part of the project builds on the BBA-0 baseline to design an customized and improved ABR algorithm that achieves higher QoE. The optimized ABR algorithm is evaluated against a wide range of steady, dynamic, and real-world network traces, and ranked on a QoE-based leaderboard.
Key improvements include:
- Adaptive startup behavior: Optimizations to reduce time-to-first-frame without causing early rebuffering.
- Stability-aware switching: Logic to reduce unnecessary quality oscillations under fluctuating network conditions.
- Robustness to dynamics: Improved performance under bandwidth drops, oscillations, and real-world network traces.
- QoE-driven tuning: Algorithm parameters are adjusted based on empirical observations from Part A experiments.
The project uses a reproducible Docker-based environment and includes tooling to:
- Run streaming experiments under configurable network traces
- Collect detailed playback metrics
- Visualize performance trends across different scenarios
This project provides hands-on experience with real-world video streaming systems and highlights the challenges of designing customized ABR algorithms on ourselves facing different improvements.
This repository only contains descriptions of the projects I worked on during this class. As per the Academic Integrity (AI) Policy of CMU, all solutions and code are stored separately in private repositories.
If you are a hiring manager evaluating my skills, or if you are simply interested in contributing to its further development, please contact me via email.