• add prr_out in preparation for PRR/nonSACK and LRD
• fix style nit

yes, after this particular assignment was commented out (effectively) yesterday evening, to collect some detailed logs when this may occur, this change is the functional equivalend.

• remove cleanup

I agree with Rod's assessment here.

there are siimilar constructs in the tcp stack, when checking for ECN (extracting the "common, legacy" TOS byte first:

Behavior without this patch:

• set fack for old pipe in prr

The set of other PRR patches is applied also in the first set of statistics? The unnecessarily retransmitted statistics looks interesting - possibly without this, and reordering in the network, PRR would push our retransmissions faster than the original (but reordered) packet arrives at the client. Interesting.

• revive basic LRD
• add tcp_input() logging for prr
• add cc_cong_signal to LRD trigger condition.
• make the compiler happy
• add tunable for LRD
• track prr sent bytes from prior window for LRD
• move LRD into dedicated function to reduce clutter
• nicify comments

• allow one more potential transmit opportunity

• updated timestamp in man file

• changing vnet 6675_pipe to newsack
• rename and shuffle rfc6675_pipe to sack.newsack
• onboard the cc modules to the change
• rebase to HEAD

• rebase to HEAD

The code above is my current understanding of the 6927bis draft. Note that this will make PRR loss recovery slightly less aggressive especially under heavy loss.

As discussed in the transport call, checked if TOF_SACK would only be set by tcp_dooption() when TF_SACK_PERMIT was received/send. But this is not the case.

from transport: check if tcp_doopt is tracking incoming sack blocks only, when SACK_PERMIT is enabled, and reduce this to a single check (TOF_SACK presence).

• change pretty name of sysctl to 'revised'
• rebase to include PRR pipe calculation

• rebase to HEAD

Looks to be the same as 0a4f851074a3ca74cd4859c20e7d9807b2aeca65

I prefer the traditional approach taken in D28759.

looked into uipc_socket.c, sonewconn() does as you mention, and yes, I would agree that the expected behavior should be to retain the settings of the listening socket rather than change this... But I leave it to @tuexen to give the verdict on this.

Certainly, I'm definitely open to suggestions. functional descriptions would be a mouthful, as 6675 has pipe, faster_lossrecovery, and rescue_rexmit.

The problem is with the negotiation part - a zero length cookie, while acceptable per RFC, still needs to be sent back to a client, for it to send out SYN+data. Otherwise, a regular SYN followed by a PUSH,ACK appears to be happening.

Glancing at this, the current fastopen infrastructure doesn't seem to have any mechanism to provide shorter key-length keys. The server side key generation is apparently done asynchonously, and reused for all clients requesting TFO. Thus special casing the acceptany when sending out the TFO option, to send out a shorter key there.

In D28686#641967, @tuexen wrote:

My understanding is that if net.inet.tcp.fastpath.acceptany is set, all cookies are excepted. This includes empty cookies as mentioned in RFC 7413.

• moving the parallel SYN check further down, to gracefully disable FASTOPEN

• remove check in tcp_newtcpcb() again

Programmatically, correct. Which makes me wonder, shouldn't the TF_NOOPT (and other flags) be inherited from a listening socket, when you accept() an incoming connection?

• typo

Generalizing, the other options need to be disabled too, in case of a simultaneous SYN. Disabling the request before that, during the tcp_newtcpcb() for an abundance of safety.

• consider TF_NOOPT for all SYN options (simultaneous SYN)

Good catch.

FWIW, I did perform a statistically questionable quick "test", comparing this patch (with rfc6675_pipe enabled) against HEAD just running PRR, by effectively browsing over some Alexa Top-343 websites.
Number of RTO went down, exchanged SACK blocks up (which would be expected).
Average and Stdev for flow completion went down (~10%), while median went up slightly (1%). However, this was not a true valid test, as caching and temporary effects could have impacted these results, especially as only the get request itself (with all the headers and redirections) could have improved in goodput.

Further steps discussed in this weeks transport call:

Validated 6675 style loss recovery entry, and rescue retransmissions using the test script. Addressed an interop issue with PRR (partial ACK with no SACK blocks should be dealt with in sack_partialack, not prr_partialack).

• expand tcp(4) man page to discuss new mechanisms enabled by rfc6675_pipe
• on partial ack w/o SACK blk, use sack_partial_ack for rescuerexmit

Should be mentioned in the releasenotes, when it comes to that, since this is a change in behavior exposed to the user.