We need more test cases, both for things that work (so we don't break them), and for things that are broken (so we know when it is fixed)
OpenBSD has a python based v6 test suite that works on FreeBSD
tuexen@ has a set of test packages that are ready to be hooked up to CI
Take Away: status reports on the bi-weekly transport call
IP[46]/TCP Reassembly Bugs/Stuff
Researcher found that 'walking linked list is slow, and bad'
The kernel created long linked lists for out-of-order TCP segments and fragment chains.
IPv6: Used to limit resources in very differently than v4, now uses the same vocabularity
IPv6 fragments were not hashed into buckets, now they are
Performance suffers too much when the list exceeds 100, this is the new limit
Mostly just a workaround, papers over the problem. Needs an algorithmic fix
If more than a trivial number of fragments, needs a better solution. glebius@ is working on an implementation of fragment processing code using red-black tree. Needs a security review. Is the performance impact acceptable.
TCP: rrs@ working on collescing code
Updated version coming to phabricator soon
tuxen@ wrote test cases for reassmbly
jhb@ and jtl@ have a todo list
use queue.h
v6 code requires changes in many places
Need a modernization pass, remove #ifdef KAME etc
Too much noise in the code, harder to read and reason about
Need a regression suite
Give it the FreeBSD stink™
bz@ may have old project in perforce that does some cleanup, likely applies fairly well
Todo: pf
brooks@ would prefer a cleanup of the IOCTLs
TFO (TCP Fast Open)
Who might have patches?
Known interop problem with Windows
TCP option alignment
tuexen@ has test cases for this, need to extract them from him (with pliers)
Limelight extension with shared secret
Alternate Stacks
Infrastructure
Allow different TCP stacks concurrently (side-by-side)
Use setsockopt() to assign individual sockets to the alternative stacks
Requires that when you switch stacks you must update the common TCPcb
A/B test stacks, route n% of traffic to the new stack, compare stats from the two stacks
Can be used to different workloads
Live-patching by loading newer version of stack without rebooting
Allows much more active development, frees development from usual requirements (work across low cpu/ram count to high cpu/ram count)