← cs
$ cat projects/MAUSA.md

Interplanetary Delay-Tolerant Network Protocol (MAUSA)

Routing protocol design for deep-space communication with extreme latency and intermittent connectivity.

Final project for 6.1800 - Computer Systems Engineering

2025-05-08
Systems DesignNetworkingProtocol Design

MAUSA: Modular Architecture for Urgent and Stable Advancement

A routing protocol for NASA's simulated SolarNet, designed for 6.1800. The whole design follows from one number: Earth to Mars round trip is about 20 minutes, so any globally shared view of the network is stale before it arrives. Everything a node decides, it decides from what its immediate neighbors told it recently.

Congestion monitoring

Nodes send a heartbeat once per second carrying queue occupancy for each of the three priority classes, and ACK each bundle by sequence number. That gives every node a local view of its neighbors without anyone coordinating globally. With 100 neighbors at 500 B/s the monitoring traffic is 50 KB/s, which against the slowest 622 MB/s link in the network is 0.008% of bandwidth. Cheap enough that the frequency was never the thing to argue about.

Link failure is detected the same way: missed monitor beacons past a second, or missed ACKs.

Dynamic fragmentation

Fragment Size = F_max / (1 + α_p × c_avg)

with F_max = 1 MB and α_p = {2.0, 1.0, 0.5} for high, medium, and low priority. High-priority traffic under congestion fragments smaller so it traverses queues faster; low-priority traffic under light load fragments larger so it doesn't pay header overhead it doesn't need. Fragment size adapting to network state is the part I'd keep in any redesign.

Duplication

High-priority bundles flood via a BFS TSUNAMI primitive, with a KILL-ACK that purges the copies once delivery is confirmed. Routine traffic duplicates only after two consecutive timeouts, and only to the second-best neighbor.

Flooding is a lot of copies, and it is the right call anyway: it delivers even if 90% of paths fail, it never depends on a routing table that went stale during flight, and high priority is under 1% of traffic. The KILL-ACK costs 200 B per high-priority message and keeps the replication from accumulating.

The network

| Node Type | Distance | Bandwidth | Storage | RTT | |-----------|----------|-----------|---------|-----| | LEOCom | 833 km | 2 GB/s | 0.5 TB | 10 ms | | GEOCom | 36,000 km | 1.2 GB/s | 0.5 TB | 250-300 ms | | Ground | Earth | 622 MB/s | 10 TB | n/a | | Relay | Moon/Mars | 500 MB/s | 0.5 TB | 2-20 min |

Storage splits into priority queues at 1.2% high, 18.8% medium, 80% low, with high-priority bundles replicated to all neighbors and cleared on KILL-ACK, under 6 GB of overhead per node. Routing is flood for high, lowest-congestion neighbor with timeout fallback for medium, and single-path lowest-congestion for low.

Bundle format and reliability

The design extends NASA's Bundle Protocol with a 134-byte primary block carrying IPv6 addresses, timestamps, and flags for fragment, custody, ACK, and priority.

The reliability layer is TCP-shaped but scaled by priority:

W ← W + α_p    (on ACK)
W ← W × β_p    (on timeout)
RTO = RTT_smooth + 4 × RTT_var

High priority ramps faster and backs off less. Same machinery, different constants, which was much easier to reason about than three separate control loops.

Results

Fragmentation costs 0.5s per hop for a 100 MB bundle, which is 0.6% of a 20-minute transit. Flooding a 10 MB high-priority bundle takes 24s against a 10-minute SLA. Under 10% random link failures, delivery holds at 95% where the baseline drops to 60%, and dynamic fragmentation cuts latency 45% under stragglers.

The two things I took from it: local signals scale where global coordination cannot, and per-flow fairness is the wrong objective whenever the thing you actually care about is a collective finishing. That second one is what I went on to attack directly in the straggler-aware scheduler.

This was a design project, so it was evaluated analytically rather than in simulation. A packet-level ns-3 build is the honest next step.