Where exactly BitTorrent breaks
Understanding Peer-to-Peer Protocol Resilience
Yousef AbuHashem, Shounak Ray, and Jacob Roberts-Baca. Stanford EE384s, Spring 2025.
Everyone knows BitTorrent gets worse on a bad network. We wanted the specifics: how much worse, at what point it breaks, and why.
So we built a testbed in Mininet with up to 30 peers and degraded the network in controlled, reproducible ways. Three results surprised us.
- Throughput lost to a flapping network
- 60%
- Throughput lost crossing 10% packet loss
- 82%
- Throughput lost growing a single-seeder swarm
- 71%
An unstable network is worse than a bad one
We used a Markov chain to switch the network back and forth between 1% and 25% packet loss, and varied how often it switched.
BitTorrent’s unchoking algorithm runs in 10 to 30 second cycles, because it needs that long to figure out which peers are worth talking to. When conditions changed every few seconds, it never got there. Peer relationships were torn down before they paid off, and the protocol kept restarting peer selection instead of moving data.
Throughput fell 60% at high switching rates, which is worse than just leaving the network in its bad state. The worst point was at p=0.8, not at p=0.5 where the switching is most random, so what hurts is how often conditions change, not how unpredictable they are.
There’s a cliff at 10% packet loss
Up to 10% loss, throughput drops gradually, from 27 KB/s to 15.4 KB/s. Between 10% and 15%, it collapses to 2.7 KB/s, an 82% drop over a five-point range.
The cause is the fixed 2-second request timeout. Below that threshold, failed requests get retried fast enough to keep making progress. Above it, peers spend more time waiting on timeouts than transferring data, and downloads basically stall.
22.4 KB/s Slowing down gently.
More peers can make things worse
With a single seeder, we expected throughput to improve at first as peers started trading pieces with each other, then drop off once they were competing. We never saw the improvement. Throughput went down the whole way, 71% from 107 KB/s with one leecher to 30 KB/s with 25 or more.
Peer-to-peer only helps when peers have something to trade. When one seeder is the source of every piece, new peers mostly end up waiting on the same bottleneck. The best swarm size was about 1 to 5 leechers, which is a funny result for a protocol built for scale.
How we ran it
We extended an open-source BitTorrent client to expose the settings we cared about: unchoking intervals, request timeouts, and bandwidth accounting. Mininet gave us virtual networks with exact loss rates, latencies, and topologies, so every run was reproducible.
Each experiment changed one variable and held the rest fixed: volatility through Markov transitions, uniform packet loss from 0 to 40%, or swarm size from 5 to 50 leechers. We also wrote a mock tracker with JSON-based peer coordination, so nothing depended on the outside world while the peers still spoke real BitTorrent.
What it means
If you run a BitTorrent swarm, 10% packet loss is a useful line to watch, because past it performance collapses instead of degrading gradually. If you design protocols, fixed timeouts and intervals are usually tuned for good conditions and can behave badly under stress, so it’s worth making them adapt to what they observe. The same trade-off between aggressive forwarding and patient timeouts shows up in CDNs with P2P parts, blockchain propagation, and distributed storage.
More generally, distributed systems tend to fail at thresholds rather than degrading smoothly, so it’s worth knowing roughly where those thresholds are, not just your average throughput.
