Thank you, this is a very accessible writeup. A torrent library makes a good laboratory to explore the effects of design decisions around concurrent activity.
Testing with many very high bandwidth seeds is important because torrenting is often used to maximize available-bandwidth utilization while replicating local resources. A key insight will be how to manage wasted activity: minimizing waste forbids maximum usage, but too much waste is wasteful.
A point: TCP slow start does not, at all, work the way described. Original 1970s slow start was very simple; much of the increased complexity in recent years has come from experiments, many since abandoned, that try to fix its failings while maintaining backward compatibility. It stinks, in part, because packet drops are a very poor measure of congestion, but drops are considered the only reliable signal from untrusted peers. I say "considered" because it really can be faked, though it rarely is, and nobody seems to have any protection against that.
Numerous network resources, particularly across Pacific and Indian Ocean links, exhibit dropping behavior overwhelmingly greater than can be accounted for by congestion, so that TCP never ramps up to channel capacity. Using multiple peers can help, but often you have only one or two peers in these circumstances, that are often running old stacks, and that is when it is especially important to maximize performance. So, a testbed with just a few simulated very bad links is essential for real-world usefulness.
It probably will take quite a long time to pass the performance of battle-tested torrent libraries, but you might also be surprised at what they leave on the table.
4 comments
[ 3.9 ms ] story [ 20.9 ms ] threadTesting with many very high bandwidth seeds is important because torrenting is often used to maximize available-bandwidth utilization while replicating local resources. A key insight will be how to manage wasted activity: minimizing waste forbids maximum usage, but too much waste is wasteful.
A point: TCP slow start does not, at all, work the way described. Original 1970s slow start was very simple; much of the increased complexity in recent years has come from experiments, many since abandoned, that try to fix its failings while maintaining backward compatibility. It stinks, in part, because packet drops are a very poor measure of congestion, but drops are considered the only reliable signal from untrusted peers. I say "considered" because it really can be faked, though it rarely is, and nobody seems to have any protection against that.
Numerous network resources, particularly across Pacific and Indian Ocean links, exhibit dropping behavior overwhelmingly greater than can be accounted for by congestion, so that TCP never ramps up to channel capacity. Using multiple peers can help, but often you have only one or two peers in these circumstances, that are often running old stacks, and that is when it is especially important to maximize performance. So, a testbed with just a few simulated very bad links is essential for real-world usefulness.
It probably will take quite a long time to pass the performance of battle-tested torrent libraries, but you might also be surprised at what they leave on the table.