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 degrades on a bad network. We wanted the specifics: where does it bend, where does it snap, and why there?
So we built a testbed in Mininet, put up to 30 peers in it, and started making their lives difficult 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 flip conditions back and forth between 1% and 25% packet loss, varying how often the flip happened.
BitTorrent’s unchoking algorithm runs on cycles of 10 to 30 seconds. It needs that long to figure out which peers are worth talking to. When conditions changed every few seconds, it never got to finish the thought. Peer relationships got torn down before they could pay off, and the protocol spent its time restarting peer selection instead of moving data.
Throughput fell 60% at high switching rates, which is worse than simply parking the network in its bad state and leaving it there. The worst point was p=0.8, not the maximum-entropy p=0.5, so what hurts is how often things change, not how unpredictable they are.
There is a cliff at 10% packet loss
Up to 10% loss, BitTorrent degrades like a well-behaved system: throughput slides gently from 27 KB/s to 15.4 KB/s. Then, between 10% and 15%, the floor gives out. Throughput collapses to 2.7 KB/s, an 82% drop across a five point window.
The culprit is the fixed 2-second request timeout. Below the threshold, failed requests get retried fast enough to keep making progress. Above it, peers spend more time sitting in timeouts than transferring anything, and graceful degradation turns into a stall.
More peers can make things worse
With a single seeder, we expected the usual story: throughput improves as peers start trading pieces with each other, then tails off once they are competing. We never got the first half. It just declined the entire way, 71% down from 107 KB/s with one leecher to 30 KB/s with 25 or more.
The peer-to-peer magic needs peers who have something to trade. When one seeder is the sole origin of every piece, new arrivals mostly queue for the same bottleneck. Optimal swarm size turned out to be about 1 to 5 leechers, which is a funny thing to say about a protocol built for scale.
How we ran it
We extended an open-source BitTorrent client to expose the knobs we cared about: unchoking intervals, request timeouts, bandwidth accounting. Mininet gave us virtual networks with exact loss rates, latency profiles, and topologies, so every run was reproducible.
Each experiment moved one variable and held the rest still: volatility via Markov transitions, uniform packet loss from 0 to 40%, or swarm size from 5 to 50 leechers. We wrote a mock tracker with JSON-based peer coordination so nothing depended on the outside world while still speaking real BitTorrent.
What it means
If you operate one
10% packet loss is a useful line to watch. Below it you are fine. Above it, expect the floor to disappear rather than sag.
If you design protocols
Fixed timeouts and fixed intervals are tuned for the good case and turn pathological under stress. Make them adapt to what they observe.
If you study distributed systems
CDNs with P2P elements, blockchain propagation, distributed storage: same trade-off between aggressive forwarding and patient timeouts.
The broader lesson is that distributed systems tend to fail at thresholds rather than along smooth curves. Knowing roughly where your cliffs are is worth more than knowing your average-case throughput.
