Attendees: melifaro@, glebius@, Peter Lei, rscheff@, rrs@, thj@, tuexen@

  * Gleb is suggesting to remove the compressed TCP TIMEWAIT state. The memory savings are limited, memory is not that critical anymore and it would simplify the code and allow further optimizations of the code. glebius@ will reach out to people if there are some objections. It was also discussed which information would be need to reduce the time a TCP connections stays in TIMEWAIT state. One thing he will implement is a counter how many compressed states where used at all. Discussion has been started on net@.
  * ECN implementation has been improved. The code is now contained in one file [[https://cgit.freebsd.org/src/tree/sys/netinet/tcp_ecn.c | tcp_ecn.c]].
  * iSCSI changes [[https://reviews.freebsd.org/D32540 | D32540]], [[https://reviews.freebsd.org/D34198 | D34198]], [[https://reviews.freebsd.org/D34230 | D34230]]. rscheff@ is looking for reviewers.
  * [[https://reviews.freebsd.org/D21011 | D21011]] is implementing Accurate ECN and has been updated and will be reviewed by rrs@ and tuexen@.
  * [[https://reviews.freebsd.org/D23230 | D23230]] is implementing ECN++.
  * [[https://reviews.freebsd.org/D30043 | D30043]] is a small whitespace cleanup.
  * [[https://reviews.freebsd.org/D28822 | D28822]] improves PRR, needs some cleanup.
  * There was bug reported on the current@ mailing list. When a TCP client connects to a server running on the same host, but using a global IPv6 address, the transmission and the first retransmission is reported as received on the interface the global IPv6 address is configured on. The second retransmission is reported on the loopback device. This results in dropping the first two packets if the `sysctl` variable `net.inet6.ip6.source_address_validation` is set to 1. The support for this `sysctl` variable was introduced by this [[https://cgit.freebsd.org/src/commit/?id=1817be481b8703ae86730b151a6f49cc3022930f | commit]]. A fix in the IPv6 code is under review [[https://reviews.freebsd.org/D35117 | D35117]]. In addition to that, a fix provided by Gleb on the mailing list is needed. This is still being worked on. @melifaor is working on the issue by improving the tests.
  * [[https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263445 | PR 263445]] and [[https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 | PR 264257]]: Both seem to have the same root cause. tuexen@ and rscheff@ are trying to figure out what that root cause is. [[https://reviews.freebsd.org/D2970 | D2970]] was mentioned. rrs@ thinks the patch is correct. rscheff@ will update the patch, tuexen@ will test and review it. It is not clear if this patch will fix the issue being reported. tuexen@ will also improve BBLog support for the FreeBSD default stack to help debugging such issues. 
  * rrs@ was observing a panic when using tcpsso. The root cause, as identified by glebius@, seems to be socket staying in the incomplete listen queue for a long time (during the use of accept filters). glebius has a sequence of patches to fix this: [[https://reviews.freebsd.org/D35663 | D35663]], [[https://reviews.freebsd.org/D35678 | D35678]], and [[https://reviews.freebsd.org/D35679 | D35679]]. tuexen@ will review them. tuexen@ identified a short period of time, where a TCP connection in the closed state is held on the incomplete listen queue, allowing races. tuexen@ will put up a review for a fix. glebius@ will review it.
  * glebius@ mentioned that the sysctl interface for tcpsso also allows to specify an endpoint by it pair of IP addresses. He will put up a review, tuexen@ will review it.
  * There is code, which should not be executed as stated by a comment from Robert Watson. gleibius, rrs@, and tuexen@ think it is true. After all other fixes related to the tcpsso bug have been committed, glebius will add a KASSERT.
  * rrs@ wants to have feedback on [[https://reviews.freebsd.org/D35166 | D35166]]. tuexen@ will review it and rrs@ will run some packetdrill scripts.
  * glebius@ wants feedback on [[https://reviews.freebsd.org/D35199 | D35199]]. bz@ isn't fine with it...


Next meeting: 14 July 2022 @ 1500 UTC