11-stable TCP reassembly queue

[Ryan Moeller]

There are some reports of network dropouts associated with the max TCP reassembly queue length:

https://forums.freenas.org/index.php?threads/11-1u6-update-transfer-aborts-on-smb-share-mac-client.69553/ <https://forums.freenas.org/index.php?threads/11-1u6-update-transfer-aborts-on-smb-share-mac-client.69553/>
https://forums.freenas.org/index.php?threads/network-issues-after-upgrading-to-11-1-u6.69506/ <https://forums.freenas.org/index.php?threads/network-issues-after-upgrading-to-11-1-u6.69506/>

I am aware that a sysctl can be adjusted to increase the maximum queue length if needed. However, I am curious if the default might be a bit low. Can anyone offer some advice on how to determine a rational limit to set?

To offer an additional data point: on my own desktop system (11.2-RELEASE-p2) there are currently 3191 discarded segments. I'm not sure if this is an unusually high number, and I honestly wouldn't have realized it was happening if I hadn’t been looking at my own stats out of curiosity. The most significant network activity for this machine is fetching code from GitHub or downloading package updates. I occasionally scp files to/from a macOS laptop over wifi.

It seems a bit odd that my moderate traffic would be exceeding the default threshold at all. Is this to be expected?

I saw the TCP reassembly improvements in https://reviews.freebsd.org/D16471 <https://reviews.freebsd.org/D16471> and wonder if this is perhaps related.

Finally, I see that a rewrite of the TCP reassembly code addressing the inefficiency underlying the original security concern has been committed to 12-CURRENT, and this is great for FreeBSD 12+, but it seems like it probably won’t be merged into the stable branches. Can anyone confirm that is the case?

Thanks,
Ryan Moeller