Transport Protocols Hangout 06 Oct 16
- gnn has created a freebsd-net organization on github where we can collect tools and tests that don't belong in the main FreeBSD tree. These include, for now, the nettest repo that gnn@ used to do his IPFW, PF and IPSEC perf tests as well as hiren@'s SoC students packetdrill tests.
- Hiren has a version of rrs@'s Rack code now running on 10. The base Rack code is not yet in HEAD but that is coming soon. Hiren and rrs@ will work on the MFC after the HEAD commit.
- Ryan found that our DCTCP does not perform as well as default congestion control in his testing. That testing was only done on one card (Mellanox Connect X3).
- The pluggable stacks API is about to change in HEAD where a function that once returned void now returns an int. This will likely be MFC'd to 11 soon so as to minimize API breakage.
- The long fixes are being committed RIGHT NOW.
https://reviews.freebsd.org/D7821 needs review ASAP
- The port of packetdrill needs to be updated to follow Michael's port.
- rrs@ is working on an implementation of BBR based on the latest work from Jacobsen et al
rstone@ is seeing issues with the callout wheel implementation with low RTO (200usec). Backend connections are scheduling and canceling too quickly for the system to keep up. One issue is that the callout system does not have a priority queue. There are concerns about a non O(1) implementation with lots of connections and a priority queue is not O(1). There have been a few discussions of this topic by jtl@, gallatin@, rrs@, and hiren@. If you assume an RSS world, you can pin all the operations for a TCP session to a particular core. At that point you could have a per-CPU pacer instead of a shared callout wheel. (See notes here.) It is also possible that there are issues in the callout system relating to hash collisions in the callout system but this has not been verified.
- hiren@ says we're still clamping congestion window down to 1 seg based on 3 dup acks. We should follow what CC says. rrs@ says that after BBR this will not be a big issue. hiren@ will put a review up to do the right thing in the short term.
stevek@ says that Juniper is again looking at hierarchical interfaces between physical and logical interfaces. gnn@ will put this on the MeetBSD DevSummit schedule.