Hangout 31 May 2018
Old Business
Ongoing projects/etc. (no real updates since last meeting):
- rrs@ will provide a fix for a bug in the default stack resulting in data corruption. (ETA: June 15)
jegg broke his locking review into multiple parts. Some committed. (Still awaiting work: D14624 and D14808.)
jtl requests further input on making the default stack buildable as a module. (D11105) He is concerned this will cause pain for downstream consumers and for backporting bugs, but thinks it is the right thing to do. Please review and comment.
- After much arm-twisting, jtl@ agreed to commit this.
bz requests review for D3721.
- thj may review once bz rebases onto current head
jtl plans to commit the "progress timer" (D14993) after dealing with review feedback
thj working on adding UDP options (IETF internet-draft). In the course, he found a bug with UDP checksum calculation using the IP length instead of the UDP length. Because of hardware offload, he may need people with multiple cards to test. (UDP checksum review is D15222.)
12.0 planning: what else do we need, or are we planning? (no updates since last meeting)
- Pacing (renamed to HPTS) is in
- TCPCB reshuffle is in
- RACK is after that (ETA: June 24)
- BBR is after that (Maybe)
- gallatin plans to commit unmapped mbufs by FreeBSD 12 code slush.
- gallatin may(?) commit kernel TLS (outbound only) by 12. Will be limited to platforms with a direct map.
@mmacy provided an update on high-precision timestamps.
New Business
@brooks proposed D15386. It needs review. Suggest call for final comments at BSDCan.
@tuexen proposed D15634, to correct some timestamp behavior on SYN/ACK. Needs review. Seems straightforward.
- @tuexen had some other related questions/comments, resolved as follows:
- Will limit SYN/ACK retransmissions sysctl to valid values.
- RTO timer limit
- ISN - why don't we protect against restarted sessions?
- ISN - per-src/dst-IP/port-tuple increasing on client side; purely random on server side
- If purely random, how do you detect packets without TSs from previous sessions? Unique per-src/dst-IP/port-tuple (if combined with unique local secret and cryptographic hashing function) should be secure enough.
- initial TS VAL - could be uptime or "random" number based on code path: purely random or random per-peer?
- random per-peer