• TransportProtocols
• 25January2024

Attendees

• glebius@
• olivier@
• peterlei
• rscheff@
• thj@
• tuexen@

Ongoing Short Term Projects

• glebius@ asks whether it makes sense to improve the TCP timer precision. tuexen@ states that this is very useful for testing purposes. glebius@ will provide a patch to tuexen@ for testing and tuexen@ will provide feedback, if such a patch us useful for FreeBSD in general. This applies to the default stack only, not the the RACK or BBR stack, which uses HPTS for timers. Setting the sysctl variable kern.timecounter.alloweddeviation to zero allows the timers to run of very precisely, which is useful when running packetdrill. However, it affects the overall system performance.

• At least for testing purposes (packetdrill) it would be good to have LRO support for tun interfaces. tuexen@ suggested to generalize LRO to not depend on an Ethernet header being present. gallatin@ prefers to not make the LRO code more complex, since it most likely will impact the performance. tuexen@ has implemented LRO support for the tap interfaces. packetdrill support will be committed soon.
• BBLog is missing a man page. tuexen@ will write one.
• tuexen@ will add tests for handling RST ACK segments in all states and test the base, RACK and BBR stack.

• rscheff@ wants feedback for D41715, which is based on a patch from VMWare for CUBIC. cc@ will tested and reviewed and rscheff@ will integrate the feedback. Also cc@ should look at D41672.

• PR 275169 is based on the vland and the TCP layer using the same field for different purposes. Since this is a different times, it is OK. But it needs to be done in a correct way. glebius will provide a patch. He will also re-activate D35199 which would not mitigate the bug, but allow faster finding of it.

• rgrimes@ reports that FreeBSD using the default parameters can not saturate a Gigabit pipe with a delay used by recent access technologies. He will test some parameter changes and report back.
• rscheff@ brought up issues in the base stack and the RACK stack which can be improved by not throwing away the score board on the first RTO. He also presented some follow-up issues. rrs@ will look into improving the RACK stack to not throw away the score board on the first RTO.
• There is a TCP related bug which results in a panic. glebius@ has a set of patches which will improve the situation, but will make it harder to find the root cause of the problem. glebius@ will put his patches up for review, but will commit these changes only after the root cause has been found.

• Not clearing the score board after the first timer based retransmission, results in uncovering several old bugs on SACK enabled connections. rscheff@ wants review of D43447 and D43560. tuexen@ will review. rscheff@ also wants review on D43520 (maybe also on RACK), D43539, D43355. There is also work in progress: D43470.

Ongoing Longer Term Projects

• Now the RACK and the BBR stack are compiled by default in head. rrs@ will remove the BBR stack, since it has several limitations. tuexen@ will mark it as deprecated. We discussed if the RACK stack could be made the default and what should drive this decision. tuexen@ will reach out to the mailing list to ask people to test the RACK stack and provide feedback. In January, we will look again at the decision process based on the feedback we got. Feedback received:
  • You need to compile in the TCPHPTS. It is a module now, glebius@ will fix issues resulting a panic().
  • RACK is on the loopback interface slower than the base stack (CPU limited). olivier@ has a script to test combinations of stacks and CC modules.
  • A problem with RACK an pf, which couldn't be reproduced by olivier@. tuexen@ has an idea what is going wrong and will provide a patch to the reporter for testing. There are also problems with dtrace when compressed ACKs are used.
• There seem to be some BBR users. Try to get them testing RACK.
• It was discussed that it would be a good idea to move the freebsd stack from ticks to micro seconds.

• rscheff@ is improving AccECN code: D36303. rrs@ will review it and implement it for the rack stack. Also the interaction between LRO and AccECN++ has to be taken into account. D42563 further adds the support of ACKofACK.

• D23230 is implementing ECN++. rrs@ will review it.

• tuexen@ wants to write a tool which dumps the BBLog information of a TCP endpoint from a life system or a core. Using kvm_read() has drawbacks as glebius@ pointed out, using a python kgdb script may be an alternative. An alternative is to write a python kgdb script which pumps data into tcplog_dumper. This would allow to minimize code duplication. glebius@ will try to work on this soon.

• The handling on ECN with TSO by NICs was discussed. It was decided to get gallatin@ involved.

Next Meeting

08 February 2024 @ 1500 UTC using FreeBSDTCPCall