Are we assuming that ~all packet loss is due to the physical medium, and almost none due to congestion? The reason why TCP will usually fall over at high loss

Are we assuming that ~all packet loss is due to the physical medium, and almost none due to congestion? The reason why TCP will usually fall over at high loss rates is because many commonly-used congestion controllers assume that loss is likely due to congestion. If you were to replace the congestion control algorithm with a fixed send window, it'd do just fine under these conditions, with the caveat that you'd either end up underutilizing your links, or you'd run into congestive collapse. I'm also not at all sure that the benchmark is even measuring what you'd want to. I cannot see any indications of attempting to retransmit any packets under TCP -- we're just sometimes writing the bytes to a socket (and simulating the delay), and declaring that the transfer is incomplete when not all the bytes showed up at the other side? You can see that there's something especially fishy in the benchmark results -- the TCP benchmark at 50% loss finishes running in 50% of the time... because you're skipping all the logic in those cases. https://github.com/nyxpsi/nyxpsi/blob/main/benches/network_benchmark.rs#L110-L112 https://github.com/nyxpsi/nyxpsi/blob/main/benches/network_b... Mathis equation suggests that even with 50% packet loss at 1ms RTT, the max achievable TCP [edit: Reno, IIRC] throughput is about 16.5 Mbps.