Attendees: jtl@, rscheff@, tuexen@, thj@
Discussion
PR 252913: tuexen@ got a tracefile and some information from Netflix. This impacts stable/12. rrs@ will commit an update to RACK in main and MFC to stable/13. We don't plan to fix this bug in stable/12.
- Actually, we probably should deprecate (and even remove) RACK code from stable/12. However, we do think we can maintain RACK code throughout stable/13 support cycle.
- Will update tcp(4) and tcp_bbr(4) man pages, and write a new man page for RACK, to note whether stacks are experimental or supported.
D23230: ECN++, rscheff@ updated the sysctl interface so sysctls are not checked in fast path. Needs review.
Lost retransmission detection: D28931 is an idea for doing SACK loss recovery in the base stack. (Documented in an I-D.) Committed.
D29441, D28822: PRR-related reviews still open. No plans to MFC D28822.
Follow up on the RST issue reported by NFS developer: We send a challenge ACK. Remote side sends a RST. We don't process the RST. rscheff@ proposed D29690. This fixes the upcall problem, but we are unable to reproduce the problem where RSTs are rejected. rscheff@ will commit D29690 to fix the upcall problem.
New Items
- We are more strict on timestamps. Some equipment negotiates timestamp support and never sends timestamps again. Apparently, at least one HP printer got a firmware upgrade this year and it now behaves in this way. tuexen@ will try to find someone at HP to notify them of the problem.
- tuexen@ reports panic on ARM server in LRO and VNET. On vnet_restore(), the VNETs are 0.
- tuexen@ reports a bug: send full-size frame in RACK, get packet-too-big message.
- Netflix stack retransmits immediately and does not clear the PSH bit
- FreeBSD stack retransmits 10ms later and does clear the PSH bit
- Can we change our code so we panic less. (e.g. convert KASSERTS to new macros which cleanup on non-INVARIANTS kernels)
Next meeting: 03 April @ 1400 UTC