Downloading data from a FreeBSD server over a fast (~700Mbps with 0.1% loss) internet connection that suffers from a lot of packet reordering, I'm seeing very bad transmission rates (~4Mbps whereas Linux gets ~40Mbps on the same connection). Traffic analysis shows that when the client (Windows in my tests) receives out-of-order packets, it first sends out SACKs until the missing packet arrives (usually just ~1ms late). Then it ACKs everything normally. Linux reacts to this by just carrying on - after all, no packets were dropped. FreeBSD however appears to react to each SACK immediately and indepentently, assuming that the late packets were actually lost. Because of that, it retransmits them and lowers the transmission rate (I tested with several different congestion control modules and it affects all of them).
Yes, you are right. We don't do well with loss in general and ooo packets in particular. We are trying to fix a bunch of issues around that right now. Would it be possible to you to test -CURRENT? That should work a little better.
(In reply to Hiren Panchasara from comment #1) >Would it be possible to you to test -CURRENT? That should work a little better. I grabbed the latest snapshot (FreeBSD 12.0-CURRENT #0 r308137: Mon Oct 31 19:21:13 UTC 2016 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64) and did not see any significant improvements.
(In reply to noah.bergbauer from comment #2) You'd also want to get r308180 so probably try next snapshot. But let me clarify a few things. We don't currently have a way to detect reordering and thus react to it in sensible way. So that's something we'd have to deal with at least for next few months. The fixes I mentioned should help the case where previously we were going down to 1MSS on any loss, thus slowing down all the way to reacting a little better.
I think we should close this. Base TCP does not dynamically adjust the reordering window (dupack threshold). However, the RACK Stack in FreeBSD should have this new property (since this is an intrinsic property of the RACK spec). For RFC standards based TCP, the described behavior is works-as-designed.